Author: Bill Weinberg
In my travels with OSDL, I frequently hear our eponymous Open Source employed as a transitive verb. As in “My company open sourced our product.” Now, I am no petty proscriptivist. English is a dynamic, productive language in which nouns can become verbs, and verbs can return the favor. Consider the word source (n. from Middle English sours, from Anglo-French surse spring, source, from past participle of surdre to rise, spring forth, from Latin surgere). Today, source is as often uttered as a verb as it is a noun, as in the dreaded labor term, outsource.
What I find nettling is the presumption of what syntacticians call agency. In pragmatic grammar (as opposed to case grammar), the subject of a transitive verb is the agent that performs some act upon the patient or direct object of the verb. Dog [agent] bites [verb] man [patient]. The dog bites the man because it wants to, because it can. (Maybe a better example for software is “Cat throws up hairball”). But is it meaningful to say that the owner of a piece of code can open source that code, by fiat?
There are actually four distinct stages for source code, only one of which I consider open source. Many software suppliers, including Microsoft, take tentative steps down this four stage path, sincerely or disingenuously hoping to scratch the itch for openness.
The first is source code as documentation: the supplier of a binary product includes (or sells) source code that need not be buildable (technically or by license), supported, or otherwise even related to the binaries in question. Code is supplied to satisfy requirements for source escrow (typical in sales to government) or as a substitute for useful documentation or even for bed-time reading.
The second is source code as bait: the supplier of a binary product accompanies his product with full, buildable source code, but under a license that prohibits modification, redistribution or deployment of derived binaries. If you actually want to make use of the source code, you must negotiate a new license, with commercial terms, that allows you to modify, redistribute and/or deploy. This second scenario most closely matches the terms and motivations of Microsoft Shared Source. In defense of Redmond’s fishing license, you should remember that even wriggling bait can be useful as documentation.
The third is source code under an OSI license: the supplier of a commercial software product makes source code available under a recognized open source license (BSD, GPL, Mozilla, etc.) and may even offer best effort support, accept patches and otherwise follow free and open source software project conventions. Conversely, even with an OSI license, the vendor may just take legacy code and throw it over the wall. This scenario most often applies to the open branch of a dual licensing business model and to as-is supply by hardware vendors of device drivers and other utilities.
All three of the above scenarios can be referents of the casually applied verb to open source. What is missing from the deep semantics of this shallow verb and from the actual scenarios is community. Without community, the source code behind open source is just a dusty tome, lifeless, static and unread.
The fourth and canonical scenario that embodies the true meaning of open source is a community of developers and users cooperatively building, deploying and maintaining project code. The source code for successful projects is most often released under an OSI license; GPL, Mozilla, Apache and BSD historically have been the licensing choice of the most successful community-based projects, including GNU, Linux, Firefox, Apache, and dozens of others.
If open source is not a verb, then where do open source projects come from? In the Beginning, was there Code? Or do projects spring, fully formed, from the shaggy heads of hackers like Athena from her Father? Or does open source pass through lengthy stages of evolution, undergoing incremental change, guided or unguided by its creator’s hand? As it turns out, the open source creation mythos can take many different turns.
Certainly the (re)release of existing proprietary code as open source has engendered some very important projects: Proprietary Netscape became Mozilla and then Firefox (after several massive rewrites); NCSA HTTPd became the Apache server (after the application of countless patches); the BSD OSes derive from commercial ATT UNIX (after a rancorous lawsuit between ATT and my alma mater); Eclipse.org emerged from IBM’s CodeSphere proprietary application development framework and OpenOffice from Sun’s StarOffice. But the mere act of releasing source code under a reasonable license (as in the third scenario) does not necessarily result in a vibrant, or even viable open source community. Only time and maturity bring ubiquity, and just as often convey obscurity.
Dual licensing is a case in point. Developer communities around dual-licensed source tend to be small and by comparison to uni-licensed projects, relatively closed. They are of primary interest to users and application developers building on the commercial versions (pre-existing or not). Dual license code bases revolve around the development teams at the commercial owner/sponsor of the code , with restrictions on patch submission and rate of change. These strictures can be practical or legal — commercial release cycles are seldom as aggressive as their open source counterparts, and over time it becomes impractical to allow drift (or full-blown forking) between commercial and open-licensed versions of the same code base.
Legally speaking, commercial project owners may not even have the right to integrate all patches into their commercial version code base. Re-released, re-licensed proprietary legacy code can share these attributes. The most visible example of such a self-limited semi-open community is the one that revolves around (Open)Solaris.
Independent, vibrant and organically evolved projects are common as the fish in the sea and birds in the air, and subject to similarly cruel forces of natural selection. As of this evening I count 132,386 registered projects on SourceForge.net, but how many will enjoy widespread adoption, deployment and community aggregation?
However, when the product of open source evolution does succeed, its triumph can be huge. Linux and GNU with their myriad sub-systems and utilities exemplify organic open source and provide model meritocratic communities. They “feel right” and provide archetypes for open and free software.
If, after my proscriptive linguistic harangue, you still insist on posing predicates with open source as a verb, at least refrain from using it transitively. Open source is not made; it is experienced by project teams, and by end-users; it is a process that code and people undergo together as a community. The fortunate among us can say, “our product/project became open source.” The enlightened can say, “we open source.” Can you?
Bill Weinberg is Senior Technology Analyst at Open Source Development Labs.
