I will be on vacation next week and, in light of events decided y'all deserved an early present. So think of this as Volume 16, Number 35 of A-Clue.com, the online newsletter I've written since 1997. Enjoy.
I have covered open source since 2005, and there is an inherent contradiction in the model.
The contradiction is that projects may be “owned” and that owners can be trusted to maintain community.
The contradiction has been hiding in plain sight ever since the open source movement split from Richard Stallman's Free and Open Source Software (FOSS) camp in 1998, with the publication of Eric Raymond's “The Cathedral and the Bazaar.” Raymond and other advocates for a more “capitalist” model figured you could deal with the contradiction by just saying, in effect, “fork it.”
But that's a cop-out. You need funding to run anything. Private enterprises don't exist for code, they exist for profit. As soon as the needs of the code contradict the needs of profit, and that's solely at the profit-making enterprise's discretion, it's going to go bad for the code.
I have seen this play out many, many times. Companies have tried to change their licenses, but users revolted. Groups have revolted against their corporate overlords and forked, some successfully, others less so. We've had open source inclines – Stallman's GPL turns out to be better at building community than any BSD-like license. We've had open source development inclines – a foundation-based development model can build community better than a GPL license alone.
It's the golden rule. He who has the gold makes the rules.
The most effective approach has proven to be what I call the “scorpions in a bottle” methodology of the Apache Software Foundation. That is, you bring multiple stakeholders under a development group which is dedicated solely to the code. This is supposed to separate the business needs of the code from the development needs of the code.
But even this is subject to abuse. Oracle screwed Apache over royally when it seized Java. Other companies abuse Apache by tossing them failed products with promises of support, only to see that support (and the code) wither, damaging the Foundation's good name. It has taken Apache's leaders a lot of time to figure out that they might be getting “used” when they're offered projects, and to resist that abuse. It's an ongoing process.
Corporations understand the open source contradiction better than open source advocates do. Simon Phipps says open source “won” the Microsoft Word vs. Open Office format battle because Microsoft eventually decided to support the Open Document Format. But its gaming of the standards system maintained Word's enormous market share, and Office's profitability within the company. What was bad for the code was good for the company.
Many corporations confuse the open nature of open source development and the free downloads with free software. Open source and free software are different things. Red Hat is a true open source company, but it still requires you to buy Red Hat Enterprise Linux, even though you can look at that code, and even while that code is based on the free Fedora distribution every enterprise that's serious about using Red Hat's Linux pays for.
They pay and pay and pay. Because free code that's not understood isn't worth much to an enterprise, and the only way to truly understand that code is to engage fully in the open source process, offering “committers” to the cause who will work for the project on company time, contributing enhancements, filing bug reports, and testing buggy beta code. The love you take from open source code is always equal to the love you make, and while time is money, money is time. The deeper you engage with open source code, and its community, the more value you gain from it.
What's true for code can also be true for words, and this is what drives companies crazy. They see how Wikipedia destroyed what had been a thriving encyclopedia industry, despite all their efforts to sow Fear, Uncertainty and Doubt about the project – efforts that continue throughout academia to this day – and they get scared.
That's why Disney writers threw some open source misinformation into a kids' sitcom recently. A nerdy kid with a PC laptop asks her friends if they used open source code with a hidden virus inside it – as though open source code is virus-ridden but Microsoft code never has security flaws. The premise was stupid, but it's ingrained in the corporate mindset.
Fortunately, as with social issues like gay marriage, minds can be changed. My wife works at a company that is totally proprietary, that for security reasons never, ever trusted open source code. Until recently. Now it's suddenly using open source regularly, even asking, before engaging in a small project, whether there might be an open source workaround. That's called progress.
The open source contradiction may never be bridged, but over time it gets easier to jump over. You learn who code's friends are, who code's friends aren't. You learn that it's not just code, but people and organizations you have to learn to trust. And if you're burned once in a while – as every kid is as they grow into fully social adults – you learn from that.
Open source is growing up. It grows along with Moore's Law of Training, and as we all should know by now there is no Moore's Law of Training. There is just learning.