Open Source Values & the Peanut Gallery

In BSD & GPL: Different Sources for Different Horses, I presented differences in two styles of open source development. Here, I'll examine the value proposition involved in choosing an open source strategy, and roast an emerging peanut gallery who are attempting to hijack and betray the free software movement.

The Open Source Value Proposition

The rational for starting any engineering task has to be compared with the value in doing it. Apple's open source efforts are designed to open up their code to developers, to expose bugs, to share technology, to promote interoperability, and to accelerate adoption of their technologies.

However, Apple is not in the business of giving away things that bring them no value, so you won't see Apple releasing QuickTime, Quartz, or Cocoa as open source until the point is reached where the value of Apple's code is overcome by the need to get attention.

For example, Apple opened their QuickTime Streaming Server after the company's streaming efforts fell to a distant third place behind Microsoft and Real. It was part of a strategy that included very low cost licensing for Internet broadcasting, to make Apple's QuickTime very attractive in comparison with the leading streaming vendors, who were charging a lot both for their streaming server and for streaming client licensing.

Apple was offensively competing in both price and code availability in a desperate bid for accelerating the adoption of their QuickTime technologies. If they hadn't opened QTSS, it might have otherwise eventually become worthless to them and their users.

Open up or else!

Many of the other commercial software products being opened are similarly faced with the threat of a dying market: Sun is working to open Solaris to retain some relevance in the wake of Linux, while Netscape famously released their Mozilla browser code only after their prospects for winning a war against Microsoft were completely vanquished.

Also consider Novell, which has cautiously held onto its core NDS technologies despite moving decisively into open source as a general strategy. The crown jewels don't generally get offered until the Queen has a gun to her head.

That's an important point to remember: much of the technology being opened up is being opened as a last resort. Commercial developers do not open up their code without risk. Opening commercially viable code risks not only lost sales but also market control; even opening abandoned code risks a fragmentation of development focus. It may also involve licensing issues that posed no problem for a commercial product, but are incompatible with free distribution.

Those factors all weigh against opening code; without compelling reasons for opening their source, a lot of software becomes lost to the world unless the planets align perfectly and the shrinking risks of code release happens to nicely coincide with a given product's wane in commercial viability.

Managing Complex Projects

Another factor counting against open source is the related risks of loss in direction and increased complexity. A vendor opening code has to balance the value of community input and contributions against the increase in complexity required to manage those contributions, and the potential for losing control of strategies and goals within the project.

Just as BSD allows for one way sharing, some open source projects demand one way sharing, but with a twist: outside developers get access to the code, but aren't given much room for input or contribution, simply because managing those contributions wouldn't be practical for the managing developer.

Apple's Darwin operates like this in some respects. Apple opened up their core OS so developers could look though it, but the company hasn't allocated the resources to build a complete code sharing repository infrastructure that can accommodate every contribution that outside developers might be able to offer.

Apple was recently the target of sharp criticism by unaffected parties after word leaked out that the company's contributions to KHTML were not organized and documented in a fashion ideal to the KHTML developers. Trying to contribute to open source, while being berated by a community of freeloading ingrates who say they represent open source developers by proxy, is not an easy task. Who makes up this open source peanut gallery?

The Open Source Peanut Gallery

The voice of the open source community is increasingly being drowned out by a penetrating sine wave of outcry coming from peripheral hijackers of the free software movement: people who do nothing to contribute to open source, but demand that the commercial world provide them with everything for free, simply to satiate their incessant need for new sources of unpaid, passive entertainment.

Richard Stallman’s vision for a world where ideas expressed in software could be freely shared has been twisted into a worn out political screed that demands something for nothing from anyone working on anything of interest.

Rather than contributing efforts to deliver shared technology, the open source peanut gallery scours the web like an army of GNU-bots, looking for infractions of openness to target with a disgorging of their vented spleens. In doing so, they betray the communal, sharing nature of open source ideals, much like a loafing bum on a collective farm, who expects to inhale organic food without tilling any soil.

In a recent stint as the acting chairman of the the open source peanut gallery, Tom Yager wrote a diatribe against Apple's Darwin software release schedule that was subsequently syndicated ad naseum throughout the various magazine and website properties of IDG: Computerworld, Macworld, InfoWorld, Network World, and their nearly 200 various regional versions.

He took Apple to task over their withholding of the kernel sources for Intel Macs in the interim period between the new machines' debut and the release of Mac OS X 10.5 Leopard.

His incessant articles suggested that Apple's unreleased kernel code was causing pain for a worldwide community of developers. In doing so, he painted an inaccurate portrayal of open source as a single entity with a single motivation and a single purpose.

Open Source as an Appropriate Tool

There are however many motivations for opening access to source code. Different needs and goals for opening software is evident even within Apple's various projects. The technology sharing and developer discovery motivations for opening Darwin are very different that the competitive motivations for opening the Darwin Streaming Server, or the technology adoption motivations behind opening Bonjour.

Apple's Darwin project is not open in the sense that it anticipates widespread codevelopment across a global community, as Yager and other extremist advocates like to portray. That's simply not the case at all. Nobody develops Apple's kernel for them. Apple actually discourages developers from doing kernel level work. They've built an object oriented IO Kit to allow developers clean, stable APIs, so Apple can work on the kernel without having to maintain compatibility with various hacks done by outsiders.

Apple maintains tight control over their projects to prevent creating a catastrophic mess along the lines of what Microsoft has to cope with in developing Windows. Apple wouldn't tangibly benefit from opening their development model to the random contributions from distributed sources; it would just complicate their project management for a project that is rapidly evolving and highly complex already.

Apple's Open Opportunities

Apple, like all commercial developers, has to carefully weigh the value proposition offered by a wide range of different open source strategies. Next up, I'll look at areas where Apple could open things up, and detail some of the challenges they face along the way. Stay tuned!

CNET's Charles Cooper Strikes Out in iPod Attack

This Series

Tech: Open Source & Intellectual Property

What do you think? I really like to hear from readers. Leave a comment or email me with your ideas.