Open Source Business Defined
By webmink on Jan 31, 2006
Matt Asay disagrees with me. I suppose I should wear that as a badge of pride. In an item he wrote for InfoWorld, he mentions that I believe there to be six (yes, it's six, I'll write about them some time) ways to use open source in a company and he accuses Tim O'Reilly and I of semasiology - retrofitting the meaning to suit the word - out of devotion to Web 2.0.
But that's not what I'm about. My approach is as onomasiological as the rest (and I think that's the first octosyllabic word I have had cause to use in a blog entry) - it's a usage of the phrase "open source company" based on the meaning. I do agree with Matt when he says:
Open source implies more than mere use or integration of open source code into one's closed product. To me, "open source" implies liberty with the source, and not simply cost savings by free riding on open source projects. The right expression for this sort of Web 2.0 integration is "Borrowed source" or "Layer IP on top of the source code and forget about it". "Open source" really isn't a good fit, because the code isn't open (Google isn't releasing its Linux modifications, last time I checked) and isn't fundamental to how the customer acquires and interacts with the product.
It's that last phrase where I come unstuck. I have run into precious few customers who are actually interested in the source code for the open source software their supplier intimately engages to deliver the value they purchase. Even most customers of top-tier open source based products like StarOffice or SuSE Linux really aren't interested in the source. It's a supply-side interest, and if it was the lynchpin of a definition it would be susceptible to the sort of tokenism that the manufacturers of routers employ, dropping their source code on a web site and forgetting it. So to Matt's definition of an "open source business":
At its core, the OSI definition speaks to the value of source code access and redistribution. I'd therefore define an open source company as one that has distribution, modification, and evolution of (open access) source code core to its business model and to its financial success.
That seems pretty reasonable superficially, but it has at its heart a deep problem. What makes an open source project succeed is not the licensing rules but rather the governance rules - the rules that decide how the community works, who belongs, who can commit changes and so on. So trying to define an open source business by the same rules that define an open source license then leads to the caveats Matt feels forced to include:
Does this mean that all of its code must be open? No. Does it mean that it can't be a Web 2.0 company that heavily borrows open source code? No.
Instead, I would rather define an "open source business" in a way that recognises that it's the community around the code that matters and not the license that facilitates it. As I've said before, "open source" tags a cycle where a code commons is used by software craftspeople to create a work that meets their needs. In the process they contribute changes back to the code commons (mainly motivated by the desire not to maintain a fork) and the commons is enriched, benefiting all. That "virtuous cycle" is at the heart of successful open source.
Consequently I'm closer to Scott Dietzen here. I would define an open source business as a company that's business model fundamentally depends on open source software and is positively engaged in the "virtuous cycle" of the community from which that software is derived.
That definition leaves room for the business engagement diversity I referred to at the SDForum event. It makes it harder for an end customer to validate the bona fides of an open source company, but it gets to the heart of what open source really means for most of us. The fact a Web 2.0 company doesn't contribute its enhancements to Linux becomes a community violation, not the absence of a source file on its web site.
The definition renders the manufacturers of networking hardware who just dump the source code out of license duty non-players. It draws attention to the non-qualifying status of Microsoft, who despite dabbling with Rotor and other projects still don't fundamentally depend on open source. But it leaves room for many, many others whose focus is not on shipping source to their unwilling customers but on delivering value while playing well with others on the supply side.