Organic vs Inorganic: Whatever Works

It has been said that genius is the ability to simultaneously hold two contradictory thoughts in your head. But this is demonstrably false, because I can find room in my world view for both the Apache and Free Software Foundation definitions of freedom. And I am clearly no genius.

That I find this task easier than some is attributable to simple pragmatism, rather than any special philosophical grounding. As I’ve told a variety of audiences, I’m less concerned with which of Apache or the FSF – or indeed the BSD, Eclipse or Mozilla – has the quote unquote right definition of open source than the question of whether they’re all contributing to the end goal of more open source software. Which, of course, they are, albeit via different mechanisms.

Given this borderline ends-justify-the-means viewpoint, it is perhaps not a surprise that I have an elevated tolerance for so-called inorganic or synthetic open source software. As was probably clear from my remarks at Friday’s OSCON panel (thanks to those who attended, and sorry I couldn’t stick around: plane to catch).

Originally coined by Brian – who was the highlight of the panel, in my opinion – the organic and inorganic terms describe differences in open source project and governance philosophies. I’m not a believer that there are strict definitions – rather that projects exist on a spectrum ranging from organic to inorganic – but generally speaking, organic projects are less rigidly controlled by a single entity and simpler (read: less process, not less contribution oversight) to contribute to.

Many corporate open source projects, then, would fall under the definition of inorganic. And while I’m certainly in agreement with those that see advantages in a more organic approach, I have no problem with inorganic projects – whoever their authors might be.

To paraphrase Voltaire: I might not like or respect your choice, but I will defend your right to make it. The author retains the right to choose the license of the software they produce, organic or inorganic, open source or proprietary in my world. If you built it, it’s your choice. And pragmatically, if the only way an asset is going to be open sourced in practical terms is inorganically, it’s better than not being open sourced at all – from the user perspective.

This works because those choices have consequences. Organic projects might generate more contributions which in turn might allow them to evolve faster which in turn might allow them to compete more effectively. And so on. Which is ultimately why I’m comfortable with inorganic projects and contributions: I (generally) trust the market. With but a few exceptions, I’m a believer in allowing the market to make its own decisions on which software development and governance models they choose to support. I’m not naive; I understand that commercial deployment is hardly a strict meritocracy, and that influence – financial and otherwise – is rampant. But the continued existence and success of the LAMP stack (itself a combination of organic and inorganic projects) confirms for me the ability for bottom up adoption to counter most efforts to make it less than viable.

Meaning that I’m content to let the market decide whether or not it intrinsically prefers organic open source to inorganic open source. Thus far, I’ve seen few cases where, say, Postgres was selected over MySQL because it was the more organic project. But if the market does make that decision, then it’s MySQL’s job to react.

In the meantime, I’ll continue to support and defend the rights of open source projects – organic and inorganic alike – to exist and pursue their own ends. If you want to sell against a competing inorganic projects by citing the shortcomings of the approach, knock yourself out. But please, let’s not resort to specious claims that it’s somehow “not open source” simply because the project is governed differently.

Rob’s right; the problem is both hard and worth solving. Let’s try and tone down the rhetoric, ramp up the information, and let the market take it from there.

[…] are based on open source projects, either sponsored by your organization, third parties or “organic“. Your core competencies not only define your core value proposition, but they determine also […]

[…] are based on open source projects, either sponsored by your organization, third parties or “organic“. Your core competencies not only define your core value proposition, but they determine also […]

[…] assumptions and architecture is the potential malleability of the project. While sitting on a panel with him at OSCON this past July, Brian previewed some of his thinking on forking committed to the […]