Open Source and Social Cloud Computing

Tim O'Reilly has written an excellent review post on Open Source and Cloud Computing which says, among other things:

The interoperable internet should be the platform, not any one vendor's private preserve.

So here's my first piece of advice: if you care about open source for the cloud, build on services that are designed to be federated rather than centralized. Architecture trumps licensing any time.

But peer-to-peer architectures aren't as important as open standards and protocols. If services are required to interoperate, competition is preserved. Despite all Microsoft and Netscape's efforts to "own" the web during the browser wars, they failed because Apache held the line on open standards. This is why the Open Web Foundation, announced last week at OScon, is putting an important stake in the ground. It's not just open source software for the web that we need, but open standards that will ensure that dominant players still have to play nice.

The "internet operating system" that I'm hoping to see evolve over the next few years will require developers to move away from thinking of their applications as endpoints, and more as re-usable components. For example, why does every application have to try to recreate its own social network? Shouldn't social networking be a system service?

This isn't just a "moral" appeal, but strategic advice.[...]

A key test of whether an API is open is whether it is used to enable services that are not hosted by the API provider, and are distributed across the web.

I think this API openness test is not strong enough. As I wrote in An API is a bespoke suit, a standard is a t-shirt, for me the key test is that implementations can interoperate without knowing of each others' existence, let alone having to have a business relationship. That's when you have an open spec.

The other thing I resist in the idea of an internet operating system is that that the net is composable, not monolithic. You can swap in and implementations of different pieces, and combine different specs that solve one piece of the problem without having to be connected to everything else.

The original point of the cloud was a solved piece of the problem that means you don't have to worry about the internal implementation.

Thus, the answer to "shouldn't social networking be a system service?" is yes, it should be a Social Cloud. That's exactly what we are working on in OpenSocial.

Here Comes Everybody - Tummlers, Geishas, Animateurs and Chief Conversation Officers help us listen

Bob Garfield's de haut en bas attack on web commenters upset two very skilled conversational catalysts, Ira Glass, and Derek Powazek. The false dichotomy of 'we choose who you get to hear' and 'total anarchic mob noise' was dismissed by Jack Lail too. At the same time, Ben Laurie explained how the IETF's open-to-all mailing lists can be hijacked by time-rich fools, talking about the Open Web Foundation.

At Supernova last month, listening to Clay Shirky talk about the problems of collective action reminded me of a small nit I have with his excellent book Here Comes Everybody (which you should all read). He talks about the deep changes that ridiculously easy group forming online has wrought, but he also explains that most of these groups fail, in various ways.

The key to this is finding people who play the role of conversational catalyst within a group, to welcome newcomers, rein in old hands and set the tone of the conversation so that it can become a community. Clay referred to Teresa Nielsen-Hayden, who is a great example of this, and I have had the privilege to discuss this with Teresa, Amy Muller,Christy Canida and others at the Troll Whispering session at Web2Open, and heard very similar stories from Gina Trapini, Annalee Newitz, Jessamyn West and Jeska Dzwigalski at The Users Are Revolting at SXSW.

The communities that fail, whether dying out from apathy or being overwhelmed by noise, are the ones that don't have someone there cherishing the conversation, setting the tone, creating a space to speak, and rapidly segregating those intent on damage. The big problem with have is that we don't have a English name for this role; they get called 'Moderators' (as Tom Coates thoroughly described) or 'Community Managers', and because when they're doing it right you see everyone's conversation, not their carefully crafted atmosphere, their role is often ignored.

In other languages there are words closer to this role - Suw and I thought of geisha a while back, whereas Teresa suggested the Yiddish Tummler - both Deb Schultz and Heather Gold liked that one. In French animateur has the broader connotations of discussion, leadership and guidance needed, but in English we are stuck with enervated latinate words like facilitator. Even an eloquent and charismatic presidential candidatehad a difficult time explaining what a 'Community Organizer' does, around the same time that Bartlett was resorting to card tricks.

Which brings me back to Clay's book - in it he gives an account of the #joiito chatroom that completely misses the rﾃｴle that JeannieCool played there, making her sound like a n00b. The software tool, jibot, that has helped keep that conversation going for 5 years, was built to support Jeannie's role as conversational catalyst. I do hope he gets a chance to correct this in the next edition.

The broader issue is one that we are still working on - building rules for who gets to speak where and when, re-imagining the historic model of a single hegemonic public record that print Journalism still aspires to, from its roots in the coffeeshops of London into the many parallel publics we see on the web, and how legal precedents designed for a monopoly of speech make no sense here.

In the meantime, if your newspaper, social media initiative or website isn't working right, you need to find your tummler, geisha, animateur or conversational catalyst, but you should consider giving them a big name title like 'Chief Conversation Officer'.

Shortening URLs, or getting inbetween?

With the rise of short message systems like Twitter, there is a growth in URL shorteners (as each one's namespace gets full, others get shorter). Today bit.ly launched to big fanfare in the blogosphere.

I took a closer look. What I noticed is that the older generation of these - tinyurl.com and xrl.us use a 301 Moved Permanently redirect, whereas bit.ly and is.gd use a 302 Found redirect, which means 'don't cache the redirected URL, keep checking the original'.

In other words, these services are saying in their HTTP responses that they may change what the short URLs point to in future, putting browsers, indexers and caches on notice that this may happen.

I also noticed that bit.ly, like tinyurl.com, allows you to pick a custom label from their namespace, but if you do it returns two 302 redirects in sequence (once to a more cryptic bit.ly url, then to the external one you chose). I pointed bit.ly/k at this blog, so you can check it yourself with curl:

$ curl --head http://bit.ly/k
HTTP/1.1 302 Found
Location: http://bit.ly/fwNKA

$ curl --head http://bit.ly/fwNKA
HTTP/1.1 302 Found
Location: http://epeus.blogspot.com

Apart from the extra delay this introduces, this is also telling your browser and web crawlers not to cache this, as they may change it in future. Compare tinyurl.com:

$ curl --head http://tinyurl.com/kevinm
HTTP/1.1 301 Moved Permanently
Location: http://epeus.blogspot.com

Google's advice for webmasters is to use 301 for redirects, as this signals the preferred URL.