Subject: Open Source and OpenGL
From: Matt Feinstein
I'm curious--what's your attitude towards OpenGL? It's not "official" open source, but it has most, if not all, of the open source-type virtues: cross-platform, robust, well-designed, popular, carefully documented, public specification/extension process, existing a reference implementation, on Microsoft's hit list, etc....
Personally, I have no problem acknowledging SGI's leadership, interest, and investment in OpenGL. In fact, (dare I say it) the comparison between the history of OpenGL development and the sometimes chaotic and personality-driven development in the open source movement is food for thought.... No?
Like you, I'm a believer that there should be room for more than the standard open source canon in the toolset of open source and free software developers. The openness of the standards underlying the software and the process by which developers are engaged in the development of those standards are often more important than the details of the licenses the software is released under. For example, many key internet standards have been developed by the IETF under an open and collaborative process that has many similarities to open source, even though not all of the resulting software is released under an open source license.
I have long argued that the success of open source has less to do with licenses and more to do with collaborative software development over a wide area network. (For example, see Open Source: The Model for Collaboration in the Age of the Internet, my talk at the Computers, Freedom and Privacy Conference in Toronto earlier this year. This is also the rationale behind CollabNet, the business we founded last year with Brian Behlendorf of the Apache Group. Collab's mission is to bring open source-style collaborative development to the software industry as a whole. Typically, this has involved helping large companies make the transition to open source, but we've also worked with companies on what we call "inner sourcing"--that is, helping them to use open source development techniques within the corporation, or with a cluster of key customers--even if they aren't ready to take the step all the way to releasing their software as a public open source project.)
Open source licenses are only one of many enablers for this new internet-era development model. Another key enabler is the architecture of the software. The difficulty developers have had in coming to terms with the massive Mozilla and Open Office code bases illustrates that a license that provides access to the source code is necessary, but not sufficient to engage developers. A modular architecture that makes it easy for developers to work independently on programs or modules that will nonetheless assemble into a larger whole may be at least as important. I discussed this point at length in my JavaOne keynote, The Network Really Is the Computer.
It's also been growing on me lately just how important the man page has been to the open source culture. The fact that the developer of each Unix program and library considered the job unfinished until the man page was written, and that those man pages were easily accessible online, was a major spur to the development of Unix and Linux. Even Windows would be so much more open and accessible to developers if every DLL came with a system-installed man page as well!
I rather like your formalization of many of the key open source virtues: "cross-platform, robust, well-designed, carefully documented, having a public specification/extension process, and an existing reference implementation." I would add to that key list an open and responsive stewardship of the software and the standard by those who control it.
After all, even open source projects do have individuals (though usually not companies) in control of them. That control may be de facto, by the moral authority of the creator or maintainer of the project, but it is real nonetheless. Eric Raymond discusses this issue at length in his essay, "Homesteading the Noosphere," which is reprinted in the book, The Cathedral & the Bazaar. The actual behavior of free software and open source developers indicates a strong system of control and "property rights" in software.
And as you imply by your reference to "sometimes chaotic and personality-driven development," those rights are not always exercised well. Open source developers can be as resistant to constructive input as proprietary companies. At the end of the day, the people who are building the software are human, and apply human judgement, with all its failings, to the choices they make.
That being said, there are still significant differences between software that is maintained in an open and responsible way and open source software. As the early history of Unix shows, a company that has long practiced an open and inclusive style of software development can change its mind and turn on the community that helped to build and popularize its software. This history shows that open source development can flourish without an open source-compliant license, but it also shows that without such a license, the standard is vulnerable to a change of heart on the part of its owner. As a result, there is always some danger in a standard that is controlled by a single company, however forthrightly they've acted in the past. A change of corporate ownership or strategy can leave a lot of goodwill in the dust.
By contrast, if an open source project leader fails to keep the trust of his users and developer community, those other developers can take his or her work and build on it independently. I do think that "the right to fork" is extremely valuable, even though that right should rarely be invoked. However, even it is not essential. As the BSD, Unix, and GNU projects demonstrate, if software is important enough, a developer community can recreate it free of license encumbrance.
(Note: I haven't actually studied the OpenGL license or SGI's stewardship of it, so these comments may not apply. Perhaps other readers would care to comment on the license details and any points of concern with regard to SGI's control of OpenGL at the end of this article.)
A final point: While 3D rendering has been "about to be really important" for many years, the time when that statement will be generally true does seem to be getting closer. It does seem fairly certain that OpenGL is going to matter to more and more developers in years to come, and attention to the openness of its ongoing development process is well worthwhile.