Open by default, but subject to interpretation
Red Hat's business model is "open by default," but different companies can apply this principle in different ways.
Red Hat marketing guru Chris Grams posits a simple but powerful key to Red Hat's strategy: default to open. It's not new to Red Hat--Tim O'Reilly's analogue is the "architecture of participation"--but it has apparently influenced everything from product design to office layouts at Red Hat.
In a nutshell, it means:
...[R]ather than starting from a point where you choose what to share, you start from a point where you chose what not to share.
You begin sharing by default.
It's a good principle for any company, open or not. It's the same principle I hear from a wide variety of open-source companies today, including those that describe their business models as "Open Core." The first impulse is always to open source: holding anything back must clear a number of hurdles.
It seems to be working in accelerating adoption of open source, presumably because open source's transparency and ease of access makes adoption easy. Carol Rizzo, former CTO for Kaiser Permanente, suggests that "average Fortune 500 companies are using more than 100 open-source projects each." And those are just the ones they're tracking.
It also works on the development side, though a debate has resurfaced over the ideal way to encourage openness and adoption. A longtime GPL supporter, I've found myselfover the past year.
My reason follows Benjamin Black's excellent post on the topic:
...[T]he goal of the GPL and its variants...[is to act] as a virus to force the release of ever more source. The GPL serves to rigidly control what you can and cannot do with software covered by it, and is thus the license equivalent of digital rights management.
This leads to a related problem. The GPL produces, in practice, a two-tiered structure dividing those who control a software project from those who merely contribute to it. Those in the former group are free to create a dual-license: those who want to use the software for non-commercial purposes can do so freely, but those wanting to use the software commercially must pay. The latter group cannot do this, regardless of how much they may have contributed to the project....
When the GPL is abused like this, as it is more and more frequently, the most obvious difference between it and the permissive licenses is a matter of who decides who gets paid. Under the GPL, that control rests only with the project owner, just like content DRM. Under a permissive license, anyone can decide.
The GPL is basically proprietary software with the intent to control through openness rather than opacity. The result is largely the same.
What we thought was a software development methodology may have far more importance as a business strategy that undercuts competitors while driving down costs and shifting control to buyers. In such a world, those who understand and leverage open source commodification (or escape it) will thrive - everyone else will be marginalized into economic oblivion. Commodification, the highest stage of capitalism; open source, the highest stage of software.
Years later, I'm surprised by how consistent my thinking has been on this (right or wrong - you choose). The GPL is great for control, but if it's community you want, Apache may be the better bet because, following Grams' post, it may be "more open by default."
Glyn Moody offers an excellent defense of the GPL, but the primary thing that Moody misses, and that Richard Stallman and other free-software advocates miss, is Black's critical point about control over who gets paid.
This isn't their concern, and that's fair. But it is the concern of just about everyone else that has to make a living selling software or services around it, which is why you find no businesses of any significant scale that depend upon monetizing GPL software directly. (Even Red Hat doesn't count - it sells a subscription to a closed binary of otherwise open-source software, much of it GPL.)
"Open by default" is absolutely the right strategy for software, in my view. But how different people interpret it will be highly variable. And while I'm leaning toward Apache, I'm grateful that my views can dovetail with the GPL crowd the vast majority of the time. We share a commitment to openness. We just interpret it differently.
Follow me on Twitter @mjasay.