5 Comments

Summary:

Open source is losing relevance as a standalone business strategy, but makes a great deal of sense as part of a larger strategy built on open data, open APIs, and more. Those still fixated on licensing are missing the point, not to mention big revenue opportunities.

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.

You’re subscribed! If you like, you can update your settings

  1. Matt,

    This is a very appropriate topic for discussion. The question of what prompted the open source movement is very relevant. If the intent was to free developers from the shackles of a specific development and operation environment, then virtualization goes a long way in fostering freedom.

    If the intent of open source was for developers to gain recognition among peers, then it has certainly worked for some. Only a very small group of stalwarts can afford to spend their free time contributing to the open source projects without expecting returns. I am not sure how successful the model has been for developers who use the recognition to get consulting gigs. I would assume that a large majority of developers are looking to monetize their expertise. Developers of the JBOSS project used the output as a starting point for professional services contracts. The business model seems backwards, because the gross margins on services are much lower than margins on software.

    If interoperability is the intent of open source projects, then the API makes sense. But how does the creator of the API benefit? What is the business model for the API creator/ operator? Is’nt the API operator helping the competitor?

    RKN

  2. What’s in a name? Pt. 2 – Open Source & Horseless Carriages « commons re:source™ Wednesday, August 25, 2010

    [...] with the underlying instance of “commons sourcing”.  Or as Matt Asay points out as part of his Can Open Source Be Saved From Itself? post on GigaOM, “Open-source licensing never deserved the single-minded devotion so many of [...]

  3. Open Sources » GigaOm: Can Open Source Be Saved From Itself? Wednesday, August 25, 2010

    [...] Read more at GigaOm. [...]

  4. Matt.. you are still blogging?

    I thought you are done with your anti-free software crap already. You are wrong on so many levels that it’s not even funny anymore.

  5. @gill: Normally I disagree with everything that Matt writes, but I find myself agog this morning. A reasoned, accurate and (somewhat) compelling argument that is probably the best point to take from the recent snarky “debates” around open source vs open core.

    We need to get past the license. One trick ponies don’t survive the hype. There is a reason why a brilliant man like RMS has been marginalized in the past few years: ideological freedom arguments don’t matter to 99% of software consumers. Are those arguments interesting, sure. Are they useful, absolutely. Are they relevant, to a small, specialized audience yes.

    The license is legally important, the concepts are ideologically important. But we as the OSS community need to use those points as stepping stones not preaching pulpits.

Comments have been disabled for this post