Where are all the clean room clients?

Recently, Danton Sideways did a nice roundup of Second Life viewers.  Naturally, this included the Linden Labs viewer, as well as editions by coders such as Nicholaz Beresford, Able Whitman and Dale Glass, and companies such as realXtend and the Electric Sheep Company.  However, what was very noticeable to me is that almost all these viewers build on the Linden Labs viewer codebase.  Only Katharine Berry’s client, the Sleek client and the OpenViewer client (the picture shows a comparison view between the Second Life client and a recent OpenViewer version) appear to be built independently of the Linden Labs code.  It’s this type of client that I would call a completely independent ‘clean room’ client.

One could argue that in some ways, this lack of clean room clients isn’t too unexpected.  The Linden Labs client is under the GPL (plus FLOSS exeption) (or a commercial license – though Nobody Fugazi reports that this seems rather hard to obtain), so why start again from scratch if you want to produce your own public viewer?  Much easier instead to adapt an existing codebase and redistribute the source as required by the viewer license (although there are still some restrictions, such as components that cannot be redistributed under the GPL + FLOSS).  Moreover, Linden Labs continues to enhance the base code of the client, both in terms of adding new features, and in terms of making protocol changes.  It’s noticeable that all the independently coded clients mentioned above are either non-graphical (in the case of Katharine’s client and the Sleek client) or at a very early stage of development without much current activity (in the case of OpenViewer).  I’m no graphics guy but I imagine it would take quite a lot of work to produce a usable graphical client – even building on pre-existing graphics engines such as Ogre3D.  To be fair, though, I want to acknowledge that the current non-graphical viewers may intentionally be that way (possibly to make them more useable in virtual world hostile environments such as unenlightened workplaces :).

So if it’s so considerably more difficult, why would anyone bother building a clean room client at all?  There are four reasons that I can think of right now.

1. Developers working on clean room clients could also potentially contribute code to OpenSim.  Any client derived from the Linden codebase has to be released under the GPL + FLOSS exception (unless one obtains a commercial license, though under that license I wouldn’t expect that code could be redistributed anyway).  A clean room client can potentially be released under any license (depending on the licenses of its constituent parts).  It’s interesting that all three of the independent clients discussed above are released under BSD licenses.  The somewhat selfish angle to all of this is that the OpenSim policy is not to accept patch contributions from anyone who has seen the Linden client’s source code (or by extension, any client based upon that code).  The justification is that, as OpenSim coders, we don’t want to risk a situation arising where some Linden viewer derived code that gets included in the BSD licensed OpenSim ends up forcing OpenSim itself to be released under the Linden viewer’s GPL + FLOSS arrangement.  I won’t go into the rights or wrongs of this since I’m not a licensing expert – there was a big discussion about this on the sldev mailing list a couple of months back if you’re interested in the debate.  Nonetheless, OpenSim has its strict policy, the practical upshot of which is that a single developer cannot work on modifications to both Linden derived client code and OpenSim server code – at least not if they want to contribute those changes back to the OpenSim source tree.  However, if that same developer had not seen the Linden client’s code, but instead were working with client source code that is licensed under an agreement that doesn’t require republication of modifications (such as the BSD or Apache licenses), we would happily look at any OpenSim patches they submitted.  This would make it easier for the individual hacker to code or prototype something really neat that requires changes on both the server and client sides of the Second Life fence.
   –
2. Clean room clients could improve our knowledge of evolving Second Life protocols. One of the major foundations of OpenSim is libsecondlife, which has done a truly excellent job, amongst other things, of figuring out large chunks of the Second Life client/server protocol.  Without libsecondlife, in my opinion, OpenSim wouldn’t be anywhere near as advanced as it is currently, if it existed at all.  Moreover, I think that any clean room Second Life client is very likely to use libsecondlife as part of its protocol stack.Nonetheless, I think that independent clients would very helpfully increase the number of eyes looking at the evolving Second Life server <-> client protocol.  To my knowledge, Linden Labs doesn’t document the use of these messages much – when a protocol change happens (such as the initial change of inventory item serving from UDP to CAPS in the 1.19.1.4 client), non Linden projects that can’t or won’t look at the client code usually have to work out the changes by painstakingly analyzing the client <-> server communication flows directly.  I’m sure this is nothing new to people who have been in and around Second Life much longer than I have, but it’s always annoying and time consuming when it happens.  We might start to get better documentation with the new Second Life standards on the horizon, but I think that this process would be strongly pushed along by the existence of clean room SL clients.
   –
3. A clean room client could have more modular code. This is not a topic about which I have any direct knowledge.  However, I’ve heard from a number of people that the current Linden Labs viewer code was not built with modularity in mind.  This makes it a somewhat laborious and awkward task to extend it.  If a clean room client was built with a modular architecture right from the very start, it would be much easier for different groups to extend and adapt it to their needs.
   –
4. Sheer fun.  I know that reinventing the wheel is supposed to be bad and all, but it must be great fun to write your own graphical client.  Imagine the thrill when you see your avatar’s first head bobble, or the first time a simple box appear on the screen in majestic pre-texture grey-o-vision.  In fact, out of all these reasons, this is the one that makes me surprised that we don’t already have a vibrant graphical clean room client project.

For all the reasons above, I hope we do see the growth of a viable clean room client soon.  Is it really the scale of the task that has discouraged this up till now?