Junto, Twitter, free platforms, and open protocols
Last week at Drumbeat Berlin, I had the pleasure of seeing Gabriel Shalom present on a project called Junto. We discussed the project that evening and the next day, and agreed that we should each post our ideas on the new perspectives the Drumbeat audience provided. He put together a video blog post about it, and my (long) post is below.
If I understand correctly, Junto is a multi-channel telepresence platform with an incorporated text chat window and support for a Twitter backchannel. Gabriel and the rest of the people working on Junto are huge fans of Twitter, and at Drumbeat he explained that he wanted Junto to be totally open, like that service.
But as fans of Status.net and Identi.ca know, Twitter is not a totally open service. To be sure, when Twitter launched in 2006, it was probably among the leaders for openness in online services: it provides an open and well-documented API, and is very liberal with how users can input and output data from site. There are prevalent mash-ups of Twitter data, and they’ve even planned to store the entire archive of tweets with the Library of Congress. However, as thinking about free network services has developed, as recorded in the Franklin Street Statement and the earlier Open Software Service Definition, in spite of being tolerant of external development Twitter fails some basic tests of being an open service; most significantly, the source code that powers Twitter is unpublished and proprietary, preventing users from modifying or copying it. As such, users are not free to set up their own Twitter servers. Most users wouldn’t want to do that anyway, but it’s important to note that in the absence of those freedoms, Twitter is something different from what enthusiasts like Gabriel think it is.
Twitter has postured itself–and the people most excited about it think of it–as an open protocol, when in fact it is just a service. Open protocols, like those that make up the internet and the web, are sets of rules that computers or humans can comply with in order to communicate with other computers or humans intelligibly. Some of these protocols are very technical, like TCP/IP which allows for packet-switching and robust connections between two computers in a network, while some are extremely social, like the etiquette that governs forums, e-mail lists, and chat rooms. People, or computers programmed by people, adhere to these protocols in order to send information, and they expect information sent to them to comply with the same protocols. Postel’s Law — “be conservative in what you send; be liberal in what you accept” — applies just as well to protocols of the social sort as those of the technical sort.
The reason it’s hard to see that Twitter the service is not a protocol is because its launch also marked the introduction, or popularization, of a new protocol. People tend to call that protocol Twitter, because for a while they were the only game in town, but it could also be described as micro-blogging, or real-time short-form public messaging, or anything like that. What’s important is that we can identify micro-blogging as being governed by a set of rules: messages can be no longer than 140 characters and are presented publicly in a chronological feed, there’s a mechanism for referring to other users, etc. And as it turns out, imposing this particular set of rules on the communication of a large group of people produces interesting results.
But when Gabriel et al talk about the power of Twitter, they’re really talking about the power of a widely adopted micro-blogging protocol. They’re right to praise Twitter for developing a cool set of rules, but are wrong to presume that those rules are tied to the Twitter service. Status.net and Identi.ca demonstrate that the micro-blogging protocol can function independently of Twitter, and because those services are designed to ensure the freedom of their users, are actually a superior implementation. However, many of even the most enthusiastic micro-bloggers haven’t heard of them. Why might it be the case that there are so many fewer users of the Status.net micro-blogging implementation than the Twitter one?
The answer is obvious to anybody who’s used both services: put simply, people like Twitter because of all the people on it. Combine that with the fact that the applications that use Twitter are superior because developers have focused plenty of attention on the dominant platform, and much less on the newcomers. @Evan and company have put plenty of effort into developing a pretty amazing product, but network effects are preventing them from gaining the traction they deserve. (It’s worth noting, here, that they are gaining plenty of traction, and there is more app support and users and interesting things happening there every day, but the numbers are still orders of magnitude below Twitter.)
That’s the scene that Junto enters into. Gabriel and the developers say, and probably with good reason, that there is no way to implement their ideas in a totally free stack. In particular, they will be depending on Adobe Flash Media Server, a non-free program that anybody running a Junto server would have to use. I respect their arguments of feasibility, and I totally understand why they wouldn’t want to wait for free software to catch up or develop it themselves. But it’s also important to consider that once a non-free implementation of a new protocol becomes entrenched, it can be really hard to displace it with a free alternative.
I say this not because developers are lazy, or will not produce substitutes for services with “good enough” freedom, but because of how hard it is to effect user switch. If everybody’s on the non-free Junto, experience has shown that freedom alone is not always enough to get people to switch to a free version.
In his video blog post, Gabriel makes a distinction between the concept of Junto as a process, and the software that they’re building to support it as a form. Relying on a non-free element as an essential part of the stack seems to preclude other forms from freely engaging in that process with them.