Since Linden decided to open source their Second Life client – or viewer, as they call it – there’s been a veritable flood of commentary, criticisms and everything in between. My first pass at parsing the news asked as many questions as it answered, so as promised I’ve been following up on those, both by digesting other commentaries and speaking with Linden Labs’ CTO Cory Ondrejka who very graciously gave me a half hour of his time this morning (and had already read my earlier piece – thank you Google, and thanks Cory for the time).
As is typical around here, we’ll tackle the subject in the Q&A format.
Q: How about the usual disclaimers?
A: I don’t know that I have any here. Linden Lab is not a RedMonk client, nor am I biased by an undue affection for Second Life. Mono, which will be addressed, is a technology I’ve argued on behalf of in the past, but that’s about the extent of it.
Q: You mentioned that you’d been digesting other commentaries: any in particular that you found interesting?
A: Way too many to list. The most complete, in my opinion, as I mentioned over on Luis’ blog, was Ethan Zuckerman’s take here. Charles River Ventures’s Susan Wu also has an interesting take, as unlike me she’s actually spent a fair amount of time in not just Second Life but other virtual worlds like World of Warcraft. As has IBM’s Bob Sutor, who sums up transcript from Cory’s town hall in a post here. Also looking at the town hall transcript was Novell/Mono’s Miguel de Icaza here. For the educator’s perspective, I looked at what Al Essa – ex-MIT, now Assoc. Vice Chancellor
/ Deputy CIO of Minnesota State Colleges and Universities – had to say. Those are a few of the posts still open in my Firefox instance anyhow. There are lots of interesting takes, just hunt around and you’ll find them.
Q: Let’s go back to some of the questions you had in your initial post: how about the complexity of the code itself?
A: According to Cory, the code is complex but not ridiculously so. It’s all C++ code, and was a.) not open source from day 1 and b.) is the product of a high paced development cycle, so it’s certainly not for the faint of heart. The code is, in fact, in the midst of being refactored. Plus, the functionality is non-trivial: real-time OpenGL rendering, protocol decompression, handling a tremendous number of textures, and so on. That said, within an hour of posting there was a Flickr shot of a full build (and Cory confirmed that the code would generally build in less than an hour, even without the help of something like distcc), they’ve already received their first patch, and Cory compared the client favorably to the complexity of the Firefox codebase. So it could be less complex, but it’s not impenetrable.
Q: Which of the clients (Linux, Mac, or Windows) is receiving the most attention?
A: Downloads are running about 85% Windows at this point, apparently. While that’s to be expected given the volume opportunities, Cory confirmed my impression that the lowest hanging fruit from a development perspective would be the Linux alpha. It’s fast, comparatively speaking, it’s just not reliable (my difficulties were attributed to deficiencies with my graphics card drivers, incidentally – or at least the way that the viewer uses them).
Q: What is Linden expecting in terms of contributions?
A: More or less what I expected: in the short term, mostly bug fixes and patches. Over the longer term, as people get to know the codebase better, then contribution could become more substantial, either from individual developers or – potentially – commercial entities with specific interests.
Q: How about the question of copyright assignment – is it a JCA? Outright assignment?
A: Shortly before getting on the phone this morning, I ran across their contributor’s agreement on the developer’s wiki. In short, it’s a JCA, as is fairly standard practice (much to the dismay of a substantial number of developers). I skimmed it, and it seemed fairly obtuse (as most legalese does to me), but maybe somebody legally inclined could give it a look to see if there’s anything unusual.
Q: What does that mean as far as accepting contributions?
A: Practically speaking it means that contributions back to Linden are owned jointly; this obviates the need for Linden to have to ask for your permission if they seek to relicense the code under a commercial license alongside the GPL version. It’s a fairly standard practice, if occasionally unpopular one.
Q: Are those the only terms under which contributions will be accepted?
A: Like many dual licensed and centrally maintained open source projects, such as MySQL, it’s certainly possible that Linden could specific license and integrate improvements to the code under commercial terms rather than the generic JCA. But those types of potential submissions, as discussed above, are a little ways away.
Q: What is Linden’s experience with open source?
A: In terms of using open source, quite extensive. The infrastructure is Debian (more proof, as if it was needed, of the importance of Debian), the web servers are Apache, they use Squid for caching, they’ve been working with Mozilla fairly extensively, and as has been much discussed, they’re betting heavily in Mono on the server. So as consumers of open source, they’re very well versed in a variety of projects on both client and server side.
But as project maintainers, it would seem, they’re very inexperienced. So that’s one reason to a.) start with the client, and b.) not wait until the aforementioned refactoring is complete. They need to learn, on the job as it were, what it’s like to run an open source project. The client is a more manageable open source project than the server.
Q: Speaking of the server…do you think it’ll be open sourced? And if so, when?
A: If Cory has anything to do with, I’d say they will. And as the CTO, one would assume he would have something to do with it. He seemed very genuine in his belief that open source was inevitable not just for the client but the server as well.
The obvious obstacle from my perspective is business model; at this point, Linden is essentially a toll collector for the Second Life network. Making the server software available would potentially undermine that ability, if not eliminate it entirely. And even presuming they can get that worked out, finding a way to not only establish multiple Second Life worlds but seamlessly bridge from one to another despite network gaps and so on is not the simplest of tasks.
But at the same time, it sounds as if Linden accepts the inevitability of the challenge. As I contended in my post the other day, they’ll face an Innovator’s Dilemma sooner or later as open upstarts challenge their superiority. Further, Cory’s view was that their ambitions to be a world rather than just a game preclude the idea that it would be an infrastructure that one vendor alone could run.
So while I can’t report any binding legal commitment, it does seem as if Second Life will be open source. As far as when, I couldn’t guess, except to agree with Ethan when he says not in ’07. Too much to be worked out.
Q: Speaking of Ethan, did Cory have any response to Dave Winer’s comment over on his blog that the server could reverse engineered from the protocol access granted by the open source client?
A: Yes. Cory’s answer was that the protocol was mostly available already, and he didn’t see the relatively small additional available information within the open source client making that significant a different in such an effort.
Q: Back on the open source front – have they selected a governance model for the project itself besides a license and basic copyright provisions?
A: No. With the project newly minted, and with the open source governance experience low organizationally speaking, Linden will be taking a wait and see approach with respect to governance. Personally, while Cory did not say this, I wouldn’t be surprised if they followed a path very similar to MySQL. But that’s just speculation on my part; I’m sure all options are still on the table.
Q: You mentioned Mono earlier: what does this decision mean for the platform?
A: Well, not much. As Miguel cited in his earlier post, this is from a post on the Linden blog:
Open Sourcing the client does not impact continued development of Mono or other planned improvements to LSL. Although Mono is also an Open Source project, that code will be running on the server, not the client. As has been previously discussed, part of the reason for going to Mono and the Common Language Runtime is to eventually allow more flexibility in scripting language choice.
I did ask Cory whether or not it was possible the codebase could be migrated from C++ to C#/Mono, and while he did mention that pulling scripting out to the client was a subject of interest, it’s not on the short to medium term horizons.
Q: Anything else from Cory that you found relevant?
A: Two points. First, that the decision to open source had actually increased developer interest in working for Linden Lab, which speaks to the desire that many developers have to work on projects out in the open. Second, that we need to bear in mind that a lot of the efforts within Second Life are in their extreme infancy – think of what web retailing mid to late nineties. I really hadn’t considered it in those terms, and that’s something I’ll have to think about.
Q: Any suggestions for Linden?
A: Tons, but we’re way over time on this already. So let’s just say this: if I were Linden, I would strongly consider committing – in a binding sense – to a timeframe for the open sourcing of the server. This would address many of the concerns that people like me have, and might prevent redundant efforts from reinventing what’s already been built. It might be far out, but it would go a ways towards ensuring that potential investors (in all senses of the that word) in Second Life would not be locked into the whims of a single vendor.
