When M Linden took over the CEOship at Linden Lab, many of us have been dreading what would happen with Linden Lab’s open source projects. Specially when Zero Linden sort of put his own Office Hours on the backburner for four months or so. People worried about the worst, except for the Luddite gang, of course, which was happy to see open source efforts to become a lower priority.
Then after a few months we heard about the standardisation effort at the IETF level to get a single inter-grid protocol — MMOX. So at least we knew that they hadn’t abandoned it.
But then we went through the Kirsten’s Viewer drama and the follow-up with the OpenLife Viewer drama. And it was clear that all these viewers out there have different agendas, different purposes in mind, different ideas on where to go with LL’s source code… and also different interpretations on licensing 🙂
Granted, some of them — Nicholaz, Kirstens’ Viewer — have been hallmarks in pure, raw performance. A few, like Imprudence, focus on features. The “Restricted Life” series addresses intriguing ways of adding “plugins” — in-world HUDs communicating directly with the SL client. And quite a few address interoperability with other, non-LL grids (including LL’s own “Open Grid” viewer). The trouble with all those projects — or most of them anyway — is persistence in time. Although quite a lot of developers submit patches now and then, even though most of these patches take 6-24 months to be incorporated in LL’s own code, keeping up developing a SL viewer for months and months is not an easy task.
You might have seen how most SL viewers are often tied to a single developer (Imprudence might be one of the exceptions). And what happens is that programmers, well, tire out, and give up supporting their code — it happens all the time. To do a long-lasting open source project, it takes stubbornness, a clear goal, and a team with “critical mass” of developers, that can keep it going even after many of the programmers have dropped out.
So what is the alternative? Currently, all those projects are highly individualistic, even if patches do, indeed, get submitted piecemeal on the Public JIRA and are popularly applied on almost all non-LL viewers.
When M Linden was quoted as allegedly saying that “Linden Lab needed to take better control over the viewer”, this sounded ominous — and some people dreaded the worst: LL’s stopping the continuous release of their open-sourced code. That would mean that all the independent developers would work on just what has been released so far — once GPL’ed, it remains GPL’ed — but future viewers would simply be closed-source. That would indeed be the worst-case scenario.
Instead, as if by miracle, Philip Linden just announced the complete opposite today. Not only is Linden Lab going to intensify their open source initiatives, but they’re doing something quite intriguing: opening up the co-development of the “official” SL viewer to any developer, without the time it takes to get a two-line patch approved.
At first sight, this doesn’t seem much of a difference — in fact, it seems pretty much what Phoenix Linden had in mind on his announcement of the open source client back in early 2007.
What happened in the mean time? Second Life in general and Linden Lab in particular complexified. An average “big” project at LL, according to Tateru Nino, takes about 14 months to complete — Mono, Havok 4, Windlight are typical examples. Probably Shadows, Flexisculpties, and Meshes will also take that long. But even small patches take months and months to get incorporated. This was always true in the past, but now that so many people with so many responsibilities use Second Life, Linden Lab felt (probably very correctly) that the time to “develop quickly, release often” is over. Moving from 1.21 to 1.22 took eight months and a dozen Release Candidates, with painfully long quality assurance tests between each release. The grid simulator software was even worse: it took 12 months to release a new version! Contrast that to the wild days of 2005, when you got a new release every two weeks — and most of them were a nightmare to deal with, but at least you knew that you would only suffer another 15 days for the next release…
These days, however, LL cannot afford to make their 17 million registered users to wait that long. So… change has to be moderate.
It gets even worse. Since pretty much 2007, the focus of development has been mostly on stability, and a bit on performance too — at least, on the grid side of things, less on the client side. Sure, we got a lot of nifty features on the client side as well: Windlight; voice; flexies; sculpties; (partial) HTML support. Still, compare that to, say, June 2004, when during a single month of development you suddenly got streaming audio, better vehicle support, custom gestures, user-generated animations, XML-RPC (to allow web servers to communicate with in-world objects), better estate tools, and a host of smaller features and bug fixes. You can see how huge the difference in development time was back then — and what grid-shattering changes it brought in a single month!
So Philip is planning to reintroduce that feel of “constant innovation” again. The details are not yet clear, but on the blog comments for the announcement, Rob Linden already tries to explain the procedure: Linden Lab will probably have a new branch of their code, the “Bleeding Edge” super-client, which will constantly incorporate all those gazillion of patches and innovative features submitted by independent developers. And on the other hand they will plod along with their “boring old client” as before. As soon as some of the “novelties” are deemed to be “safe” to incorporate on the “mainstream” client, they might be ported over — in due time. After several months. Maybe 🙂
So what is the big difference? After all, people have always been allowed to launch their own “bleeding edge” SL clients (at least since January 2007). Well, there are two major differences: with this change, LL becomes much more closer to a true open source shop, where one of their major products is actually co-developed with the independent developers and branded by LL (ie. they’ll give it their official “stamp of approval”). This naturally also means being able to overcome licensing problems (with the JPEG2000 library; or with the voice client; or even with the fonts!).
But more important than that, it means that Linden Lab will act as an official repository of the source code for all developers — just like any other open source project, really. Anyone will be able to ring over their patches and features and add to the common project — instantly — and a new release will be out during the night. A new official release!
Before you start trembling with fear at what that means when evil programmers start to contribute malicious code… remember, this will be the bleeding edge version, downloadable additionally to LL’s regular SL client. LL will surely warn everybody about the lack of support or guarantees on the “bleeding edge” version. Also — this will be peer-reviewed code, from a community of developers. Just like Wikipedia pages are subject to vandalism, since anyone can edit them, but the Wikipedia editors are always alert and revert the changes, LL’s “bleeding edge” version will also be subject to revision by a lot of people too — beyond LL’s own teams, of course. They’ll be able to change things quickly back. And, ultimately, it will be LL monitoring and supervising the procedure: e.g. instead of taking months to approve a harmless patch, they will allow any patch to be quickly implemented, but also quickly remove malicious or broken patches.
After all, big open source projects like Apache, MySQL, all the Linux/FreeBSD distributions, Mono, and even WebKit (also known as Safari under the Mac) work exactly that way — in some cases with big brands (like Novell or Apple) behind those projects, contributing with resources and validation. And these projects work. SL’s client is a tiny project compared to any of those, and it will not be too hard to keep it properly under control.
And obviously, if you are trembling in fear from the power of open source software, you’ll always be able to safely download that old, boring, painfully slow, bug-ridden, but official, stable version — where Linden developers approve each line of code after months and months of excruciatingly slow testing 🙂
Kudos to Jacek Antonelli on Plurk for the link!
