In a cloud world, source code is almost irrelevant. Tim O’Reilly was among the first to point this out in 2008 when he said, “Architecture trumps licensing any time,” but the meme has gone mainstream in the past year. It’s also increasingly germane to mobile business models. Those still fixated on open source qua licensing are missing the point that originally inspired its creation, not to mention big revenue opportunities.
There’s a lot of money to be made with open source, but first we need to stop fetishing antiquated notions of open source. Open-source licensing never deserved the single-minded devotion so many of us paid to it. It’s a starting point — a means — but not the end goal.
As Java founder James Gosling noted recently, freedom doesn’t start or end with source code (or its license):
Sun got a lot of heat for not going full open source early on (and there’s a lot of disagreement over what “full open source” would mean… GPL? Apache?). But freedom is a funny concept. It’s often a function of point of view: freedom for one could restrict the freedom of another.
The freedom we were most concerned about was the freedom of software developers to run their applications on whatever OS or hardware they wanted. In opposition to that, the platform providers wanted the freedom to make their platforms as sticky as possible….
When Google came to us with their thoughts on cellphones, one of their core principles was making the platform free to handset providers. They had very weak notions of interoperability, which, given our history, we strongly objected to. Android has pretty much played out the way that we feared: there is enough fragmentation among Android handsets to significantly restrict the freedom of software developers.
Android is, of course, open source. However, as Gosling argues, it doesn’t matter: hardware fragmentation can significantly undermine developer freedom that no open-source license can resolve.
Actually, it gets worse. As Jason Hiner writes, Android’s permissive openness is actually helping carriers perpetuate closed models:
[W]e now have a situation where the U.S. telecoms are reconsolidating their power and putting customers at a disadvantage. And, their empowering factor is Android. The carriers and handset makers can do anything they want with it. Unfortunately, that now includes loading lots of their own crapware onto these Android devices, using marketing schemes that confuse buyers…, and nickle-and-diming customers with added fees to run certain apps such as tethering, GPS navigation, and mobile video….
[T]he consequence of not putting any walls around your product is that both the good guys and the bad guys can do anything they want with it. And for Android, that means that it’s being manipulated, modified, and maimed by companies that care more about preserving their old business models than empowering people with the next great wave of computing devices.
Open-source licensing is no help in the Android example. It’s the enabling force driving the problem. Sure, it may not look like a problem today: More Android equals more profitable mobile search traffic for Google.
However, the more control carriers, not Google, have over Android, the less Google can control its destiny. So what to do to fix the problem?
First, we need widespread recognition that there is a problem. It needs to start with the Open Source Initiative, which has recently acknowledged the need to evolve our understanding of open source in order to preserve its relevance.
That understanding needs to include open data, open APIs, open source, Gosling’s interoperability principles mentioned above, and more.
As developers embrace a more holistic conceptualization of open source, they’ll discover it has real power to drive revenue, both out of competitors’ business models and onto one’s own balance sheet. Venture capitalist Brad Feld offers one clue as to how to accomplish this in a data-as-a-service world:
[I]t seems painfully obvious to me…that the best way to popularize “data as a service” is to start with an API (which creates the revenue model dynamic) and build a bunch of open source examples on top of it. Your goal should be to make it as simple as possible for a developer to immediately start using your API in ways relevant to them. By open sourcing the starting point, you both save an enormous amount of time and give the developers a much more interactive way to learn rather than forcing them to start from scratch and figure out how the API works.
Open source is more relevant than ever, but it means so much more than a simple OSI-approved license. Or it should. The savvy developers and companies will be those with a more complete game plan, one that may include open-source licensed software, but also includes federated services, open data, etc.
Will this work for you? That depends, but one thing I can guarantee: a simplistic “open source is a matter of licensing” strategy leads nowhere.
