Pandora's Box 2.0: Opening proprietary code
by Glyn Moody
What does it take to open up a proprietary application and make it a successful open source project? To answer this, Glyn Moody takes a look at some prominent successes and failures and identifies the best practices.
Open source lies at the heart of Google – it runs a modified form of Linux on its vast server farms, and uses many other free software programs in its operations. This makes giving back to the open source community not just the right thing to do but enlightened self-interest: the stronger free software becomes, the more Google can build upon it (cynics would say feed off it).
Google's contributions to open source take many different forms. It employs a number of the top hackers – people like Samba's Jeremy Allison and Python's Guido van Rossum – and it organises the Summer of Code scheme whereby young coders are paid to work on open source projects. That's also a double hit: it helps underfunded projects fill in the gaps – and lets Google scout out fresh coding talent.
Recently, it has added to that roster by donating two of its well-known projects – Android App Inventor and Sky Map – to the open source world. Once again, this is not entirely altruistic. Last year Google announced that it was "winding down" Google Labs; it therefore needs to park those projects it no longer requires somewhere else, and it turns out that one approach is to open source them.
That's obviously a neat solution for Google, but is it really so good for open source? This might seem a strange question: surely more open source code is always good? Well, not necessarily, because there's a danger that companies will think of open source as a kind of dumping ground for failed projects, with all that this implies for the work needed to turn them into viable free software. Indeed, the history of such code donations is a chequered one, with some turning into triumphs, while others turned out to be tragedies.
For example, perhaps the first and certainly highest-profile opening up of proprietary code was when Netscape announced that it was open-sourcing its browser suite (at the time, its once-sleek browser had turned into a horribly bloated collection of Net tools.) Here is the official justification:
“The time is right for us to take the bold action of making our client free – and we are going even further by committing to post the source code for free for Communicator 5.0,” said Jim Barksdale, Netscape’s president and chief executive officer. “By giving away the source code for future versions, we can ignite the creative energies of the entire Net community and fuel unprecedented levels of innovation in the browser market. Our customers can benefit from world-class technology advancements; the development community gains access to a whole new market opportunity; and Netscape’s core businesses benefit from the proliferation of the market-leading client software.”
It was an important statement at the time, because Netscape was still the iconic internet company, even if its market share was dropping and business failing. It brought open source to the attention of millions of people in the corporate world, and helped make it "respectable". Unfortunately, as a software strategy it was a complete failure.
The reasons were spelled out by Jamie Zawinski, one of the key Netscape engineers who worked on what became the open source Mozilla project:
It remained a Netscape project. Now, this was still a positive change – it meant that Netscape was developing this project out in the open, in full view of the world, and the world was giving important and effective feedback. Netscape made better decisions as a result.
But it wasn't enough.
The truth is that, by virtue of the fact that the contributors to the Mozilla project included about a hundred full-time Netscape developers, and about thirty part-time outsiders, the project still belonged wholly to Netscape – because only those who write the code truly control the project.
So while Netscape did the right thing by continuing to support the newly-open code with its engineers, it made a huge mistake by controlling it so tightly, rather than allowing it to develop freely. It was only when Mozilla became truly independent that the project finally released first Mozilla, and later Firefox.
That lesson about control was not learned when Sun open-sourced its StarOffice. This was not a full donation initially, but intended more as a tactical move to undermine Microsoft's Office suite by offering a free software option. Like Netscape, Sun, too, did not allow what became OpenOffice.org to go its own way as an independent open source project.
After Oracle bought Sun, OpenOffice.org was finally "liberated" twice – once in the sense of the copyright to the code being handed to the Apache Software Foundation, and once as the independent fork that later came to be known as LibreOffice. The former probably has better funding than the latter, but is likely to be more in tune with the interests of its commercial supporters who will presumably be paying some of the coders to work on it. LibreOffice has the advantage of more freedom, but could be hobbled by lack of funding. It will be interesting to see how they both fare.