Editor's Column
9 February 2001
Organizing Open Source
As a system of software production, Open Source usually says little to nothing about the how of its organization and implementation. But, in fact, merely releasing software under GPL (or some other such license) does not necessarily get you "there." Even if your release is Slashdotted, it still may not fly. What's lacking is the infrastructure comprised both of machines and persons, for ensuring that interested developers can securely download the open-sourced code and upload their patches without totally wrecking not just the software but also the whole enterprise. And what's also missing from this fanciful picture is any system for the creation and management of a developer community. Open Source, that is, is more than a number of individuals downloading source code and working on it alone; when it works, it is implicitly a communal and collaborative enterprise.
Of course, one could simply place the code on a server send a notice to a probably indifferent Slashdot, and then wait. If the code were interesting enough or somehow offered compellingly attractive benefits, it might very well attract developers who could form working groups, might establish a version system like CVS (Concurrent Versions System), and--maybe--articulate directions and goals for the community. And it might happen: Linux, for instance, was and remains pretty much a grassroots enterprise (what Eric Raymond calls the "bazaar"), with a widespread and disparate community of developers--and Linus Torvalds--maintaining and contributing to the code as they will, in implicit collaboration. And Linux, with its globally dispersed and active community is, as we all know, the defining model of Open Source.
But, does the Linux model still obtain, or at least with the same force as previously? I'd like to suggest that, for a variety of reasons, Linux is less the model for the future of Open Source than an exceptional paragon.. The community--or, communities--that have formed around the kernel have been more passionate than commercial. This is to say--heretically, to be sure--that the model of Open Source Linux exemplifies (a community of passionate users and developers) is probably not the model of open-source ventures to come-- and, according to recent reports, they will come.
Instead of a Linux-like model, however, the more likely scenario is that a company will wish to open source proprietary software because the company leaders have come to realize that it's not only cheaper in the long run to develop software using the open-source model, but that one also gets in better software faster. A company, that is, might open source its software to save money and get ahead of its rivals. The loss of proprietary control is, in this scenario, comparatively slight in exchange for what it gains.
And what do the developers gain? If the company has arranged its Open Source venture properly, developers benefit in at least two, obvious, ways: from the intellectual capital embodied in the code and from the communities organized around that capital. The interested developer can, at her will, deploy the available code for her own purposes; and learning from the construction of the code further enhances her own career. What is more, the collaborative community that develops in working on the code provides her with invaluable help both in the present and in the future.
But for this economy to work, the company open sourcing its property must not only make the source code it has opened in some way desirable and valuable to developers, but also provide an infrastructure, technical and managerial, that enables developers to work efficiently on the intellectual capital it has released. Without such an infrastructure, by which the code is made securely available and communities enabled, little might ever take place that will prove profitable for the originating company. In fact, one could state it even more strongly: Open Source, as a business and not as a hobby, demands sophisticated managerial support that will make sure the servers work, the pages load, and--importantly!--help shape the community of developers into productive groups, either through roadmaps, standards, or goals.
All this is fairly obvious to anyone who works in Open Source--such as the OpenOffice.org community. But it merits stating, for the myth of Open Source is still the myth of the West mapped to cyberspace: of individuals hacking at their favorite programs for by and large mysterious reasons, of which personal satisfaction ranks high. In the "real world" there is, of course, still that appeal to much of open-source work. But Open Source is more than a culture: it is a dialectical strategy by which developers are given enormous power and opportunity that requires a novel managerial approach.
Previous columns
1 February 2001 Open Source and Its Culture
23 January 2001 Community Action
16 January 2001 Quo Vadis OpenOffice.org?
9 January 2001 The 613 build: problems and opportunities
3 January 2001 Sun's open door
E-mail: Louis at collab.net
