Organic vs. Non-Organic Open Source, Revisited

There’s been some controversy generated over my use of the terminology of “Organic” and “Non-Organic” Open Source. Asa Dotzler noted that it wasn’t Mozilla’s original intent to “make a distinction between how Mozilla does open source and how others do open source”. Nessance complained that he didn’t like the term “Non-Organic”, because it was “raw and vague – is it alien, poison, silicon-based?” and suggested instead the term “Synthetic Open Source”, referencing a paper by Siobhán O’Mahony, ” What makes a project open source? Migrating from organic to synthetic communities”. Nessance referenced a series of questions and answers by Stephen O’ Grady from Red Monk, where he claimed the distinction between the two doesn’t matter. (Although given that Sun is a paying customer of Red Monk, Stephen admits that this might have influenced his thinking and so he might be “brainwashed” :-) .

So let’s take some of these issues in reverse order. Does the distinction matter? After all, if the distinction doesn’t matter, then there’s no reason to create or define specialized terminology to describe the difference. Certainly, Brian Aker, a senior technologist from MySQL, thinks it does, as do folks like me and Amanda McPherson and Mike Dolan; but does it really? Are we just saying that because we want to take a cheap shot at Sun?

Well, to answer that, let’s go back and ask the question, “Why is Open Source a good thing in the first place?” It’s gotten to the point where people just assume that it’s a good thing, because everybody says it is. But if we go back to first principals maybe it will become much clearer why this dinction is so important.

Consider the Apache web server; it was able to completely dominate the web server market, easily besting all of its proprietary competitors, including the super-deep-pocketed Microsoft. Why? It won because a large number of volunteers were able to collaborate together to create a very fully featured product, using a “stone soup” model where each developer “scratched their own itch”. Many, if not most, of these volunteers were compensated by their employers for their work. Since their employers were not in the web server business, but instead needed a web server as means (a critical means, to be sure) to pursue their business, there was no economic reason not to let their engineers contribute their improvements back to the Apache project. Indeed, it was cheaper to let their engineers work on Apache collaboratively than it was to purchase a product that would be less suited for their needs. In other words, it was a collective “build vs. buy” decision, with the twist that because a large number of companies were involved in the collaboration, it was far, far cheaper than the traditional “build” option. This is a powerful model, and the fact that Sun originally asked Roy Felding from the Apache Foundation to assist in forming the Solaris community indicates that at least some people in Sun appreciated why this was so important.

There are other benefits of having code released under the Open Source license, such as the ability for others to see the implementation details of your operating system — but in truth, Sun had already made the Source Code for Solaris available for a nominal fee years before. And, of course, there are plenty of arguments over the exact licensing terms that should be used, such as GPLv2, GPLv3, CDDL, the CPL, MPL, etc., but sometimes those arguments can be a distraction from the central issue. While the legal issues that arise from the choice of license are important, at the end of the day, the most crucial issue is the development community. It is the strength and the diversity of the development community which is the best indicator for the health and the well-being of an Open Source project.

But what about end-users, I hear people cry? End users are important, to the extent that they provide ego-strokes to the developers, and to the extent that they provide testing and bug reports to the developers, and to the extent that they provide an economic justification to companies who employ open source developers to continue to do so. But ultimately, the effects of end-users on an open source project is only in a very indirect way.

Moreover, if you ask commercial end users what they value about Open Source, a survey by Computer Economics indicated that the number one reason why customers valued open source was “reduced dependence on software vendors”, which end users valued 2 to 1 over “lower total cost of ownership”. (Which is why Sun Salescritters who were sending around TCO analysis comparing 24×7 phone support form Red Hat with Support-by-email from Sun totally missed the point.) What’s important to commercial end users is that they be able to avoid the effects of vendor lock-in, which implies that if all of the developers are employed by one vendor, it doesn’t provide the value the end users were looking for.

This is why whether a project’s developers are dominated by employees from a single company is so important. The license under which the code is released is merely just the outward trappings of an open source project. What’s really critical is the extent to which the development costs are shared across a vast global community of developers who have many different means of support. This saves costs to the companies who are using a product being developed in such a fashion; it gives choice to customers about whether they can get their support from company A or company B; programmers who don’t like the way things are going at one company have an easier time changing jobs while still working on the same project; it’s a win-win-win scenario.

In contrast, if a project decides to release its code under an open source license, but nearly all the developers remain employed by a single company, it doesn’t really change the dynamic compared to when the project was previously under a closed-source license. It is a necessary but not sufficient step towards attracting outside contributors, and eventually migrating towards having a true open source development community. But if those further steps are not taken, the hopes that users will think that some project is “cool” because it is under an open-source license will ultimately be in vain. The “Generation Y”/Millennial Generation in particular are very sensitive indeed to Astroturfing-style marketing tactics.

Ok, so this is why the distinction matters. Given that it does, what terms shall we use? I still like “Organic” vs “Non-organic”. While it may not have been intended by the Mozilla Foundation, the description in their web page, “only a small percentage of whom are actual employees [of the Mozilla Foundation]“, is very much what I and others have been trying to describe. And while I originally used the description “Projects which have an Open Source Development Community” vs “Projects with an Open Source License but which are dominated by employees from a single company”, I think we can all agree these are very awkward. We need a better shorthand.

When Brian Aker from MySQL suggested “Organic” vs “Non-Organic” Open Source, and I think those terms work well. If some folks think that “Non-Organic” is somehow pejorative (hey, at least we didn’t say “genetically modified Open Source” :-) , I suppose we could use Synthetic Open Source. I’m not really convinced that is any much more appetizing, myself, however.

So what would be better terms to use? Please give me some suggestions, and maybe we can come up with a better set of words that everyone is happy with.

14 thoughts on “Organic vs. Non-Organic Open Source, Revisited

  1. while i’m not so sure that the organic v. synthetic terminology holds much water as this seems to imply that one is purer than the other – it is interesting to note the direction that both communities have started from to meet somewhere in the middle .. with sun who started more in the enterprise space – they’re starting to see a broader reach in the SMBs, and home user categories through their open source stack (eg: with the open sourcing of the storage stack – we’re starting to see more of a break on the storage appliance lock-in within the enterprise space) .. whereas with linux which started in more of the home user to SMB space – there’s a pretty big adoption in the larger enterprise space. The confluence of both of these beginnings and end targets are going to have some very definite community differences (ie: how to take enterprise originated technologies back down to the casual user .. and how to take casual user originated technologies up to enterprise standards) with a nice meeting place in the middle SMB market (where sun really started in the mid 80′s) .. regardless there’s still a lot to do in both communities to move forward and develop stable code

  2. If there is a team of developers whose career is based upon their expertise in Apache, MySQL, Linux, Solaris, or any other Open Source technology, then those developers are sure of their ability to work in their chosen field whilst that software is in active use.

    I’ve written a longer response here

  3. Thanks for your detailed response on my blog, Ted. Good points, well made, of course.

    Is it more appropriate, then, to see OpenSolaris as a fix to the previous closed-source situation?

    Although “in truth, Sun had already made the Source Code for Solaris available for a nominal fee years before”, the principle for the typical customer (or sysadmin) that I met, was that the code (and some of the relevant bug reports, etc) were hidden away as Sun’s “secret sauce” and not for commoners to access.

    If we plot a graph of open-source awareness, with Linux, *BSD towards the far left, and Microsoft, Oracle, etc on the far right, then are Sun, who started out quite far to the left and later moved towards the right, now moving back towards the left again?

    Is that a more useful model to view the current climate, perhaps?

  4. How about “Marketplace” vs “Castle”, reminiscent of Eric Raymond’s years-old essay?

  5. I think the distinction being discussed here is of interest mainly to theorists. If a piece of open source software is useful to me I use it and contribute anything that comes from my usage of it. I don’t care if it was created organically or not. Really why would I? Given a choice of two packages I’ll take the one that best fits my needs. If they are identical in terms of functionality and fit for my purpose (a rare case) I’ll probably go with the one that seems to treat its non-development contributors the best as that will probably be the experience I will have. Again I still don’t care about the organic question.

    Some of the views above are heavily developer-centric. In my experience the contributions of the users are very important: use cases, finding bugs (often much harder than fixing them), platform testing, scalability testing, comparisons with alternatives, localizations etc. In fact these contributions outweigh (in terms of # of contributions) the contributions of the coders. The fact is you can do the coding behind closed doors (most small open source projects do it this way anyway) or in the open, but you CANNOT harden the software behind closed doors. You have to let the software out early and often to find out the functional and non-functional defects in the design and implementation. Sure there are a few high-profile examples where a distributed group of developers working to an existing spec (HTTP, Servlet or Unix kernel) have created things of great utility. If those developers were the only ones to ever use those creations open source would still be firmly in the hobby category.

    I don’t have much of an opinion on the terminology. When you look at many ‘organic’ projects what you are dealing with in reality is a ‘committee’ of core-developers or administrators that are the gatekeepers. This committee decides amongst itself what direction the project goes in, what contributions to accept, and how to prioritize the backlog of features. In some cases that committee does not pay attention to the needs of its community.

    Maybe ‘Managed’ or ‘Directed’ is a better term than ‘Non-Organic’. From the perspective of a CIO trying to manage their company’s usage of open source ‘organic’ is not necessarily a good thing, whereas ‘managed’ maybe sounds a little more comforting.

    James Dixon

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>