Get Social

I don’t pretend to know what the future of the Social Web holds, but I have some ideas about the markup language that will power much of it.  First though, let me recap the short history of Social Web Markup.

About a year ago Facebook launched their social network with a full application platform consisting of a rich set of social APIs, many of which were wrapped with easy to use tags called FBML (FaceBook Markup Language).  Since then, a few things have happened.  First, Bebo opened up their social network with their own markup language which they called SNML (Social Network Markup Language), which was mostly the same as the FBML collection, though it included some tags only offerred by the Bebo platform.  Finally, Ringside Networks released beta versions of their Social Application Server, which supported many of the FBML tags, and a few only available on the Ringside Platform.

This is all well and good, since tag libraries for specific social networks definitely enable social application developers and designers to create rich social applications quickly.  What is unfortunate about the current situation is that these tag libraries are closed in that they are only supported by the platforms that offer them (though the open source Ringside Social Application Server supports many FBML tags).  This means that social application developers would have to rewrite portions of their applications in order to deploy to multiple social networks.  I’m reminded of the early days of the J2EE application server market, when each vendor offered their own tag libraries in an effort to differentiate their platforms from each other.  In the end though, most of those tag libraries did many of the same things via different syntax, and ultimately JSR-52 was established and the JSTL (JavaServer Pages Standard Tag Library) was produced. Now all J2EE application server vendors support JSTL.

I don’t necessarily see the same course of events unfolding in the social web space, but perhaps there will be some similarities.  First of all, I’m inclined to believe that social application developers will want to be able to write a social application once and run it anywhere. In order for that to happen, those developers would have to code using standard APIs and tags, which is an argument for a standard for a social tag library.  Alternatively, because Ringside offers the ability to render social tags via widgets, I can see a whole community emerging around social tag development, which would in turn enable the rendering of those tags via widgets anywhere across the web.

What do you think?  Are you a social application developer?  Do you want to be able to write once and run anywhere?  If so, how do you see social tags evolving?

Last week Jonathan Otto, author of the Run Voomaxer Facebook application, and Eric Pascarello, highly acclaimed author of AJAX In Action and JavaScript: Your Visual Blueprint for Building Dynamic Web Pages, joined the Ringside team and participated in some great discussions with the team.  In one of those discussions, Rich Friedman gave an overview of various open source licenses and what they mean, including GPL, LGPL, BSD, and others.

Free video streaming by Ustream

Last week I started fiddling with UStream. At first it was just a cool new technology that I was trying out, but it has evolved into a daily part of our lives at Ringside Networks. We’ve been streaming live video for about a week, which has been working out very well. For those team members that are remote (we have 3-4 depending on the day), they have been privy to the office conversation that they have always missed. Since we started streaming, those remote teammates have been clamoring for better cameras, and more of them.

You can view our live stream here. Note that there are portions of the day that are very boring. For example, at the moment, anyone that is tuned in will be watching my face as I type this blog entry and listening to Weezer. However, Twitter is a great tool for notifications. Whenever an interesting discussion is going on, I’ve made a habit of turning the camera outward towards my colleagues and the white board and logging a message on twitter with a link to our live audio/video stream. Follow me on Twitter if you’d like to get these updates.

The most interesting part of our use of this technology is that it pairs nicely with our open source development model. For those developers out there using our software, they can watch and listen while we discuss how to resolve a bug, how we will prioritize our work for the next beta release (every two weeks), or just get a feel for where we stand on a daily basis (our daily stand up meetings are at 2:30pm EST). Even better than watching live though, is that the community will have the ability to participate through the chat window in the UStream interface. For our remote team members, we’ve been using Skype to bring them into the live discussion. As users of our software, you could potentially have the same level of access.

To me, live streaming takes open source development to the next level of openness and provides an engaging experience that will ultimately result in better software and faster solution delivery due to the availability of this rich communication medium.

By the way, we also tried Stickam for a day, which offers group video chat capabilities. Our experience has been that Stickam’s availability is not as good as UStream’s. Also, Stickam’s user interface wasn’t very intuitive or descriptive. We have tried on two separate occasions to coordinate three video streams in the same session without success. Regardless, this service has great potential, and I look forward to improvements that are surely coming.