Not many remember it, because the technology industry tends to focus on its future at the expense of its past, but in the beginning software was free. In both senses of the word free; it was available at no cost, and the source typically came without restrictions. One of the earliest user groups SHARE, founded in 1955, maintained a library, in fact, of users’ patches, fixes and additions to the source code of the IBM mainframe like a proto-GitHub. The modifications SHARE maintained were extensive enough, in fact, that in 1959 SHARE released its own operating system – what we would today refer to as a distribution, the SHARE Operating System (SOS) – for IBM 709 hardware.
IBM made available the software at no cost and in source code form because for the company at that time, the software was not the product, the hardware was. It wasn’t until June 1969 that IBM announced, possibly in response to an anti-trust suit filed by the United State Justice Department in January of that year, that it would “unbundle” its software and hardware. Theoretically this would open the hardware platform to market competition, but the side effect was that IBM began charging for the software it had once shared for free. The side effect of this side effect, arguably, was the creation of the software business as we know it today.
In a bit of historical irony, the company that created the software industry missed by far its most lucrative market opportunity, the opportunity that Microsoft perceived. This was the idea that software not only had value, but due to hardware commoditization, the potential for far more value than the hardware it ran on. As has been documented here and elsewhere, Microsoft rode software to unprecedented heights, and in doing so ushered in a new model for software, one that was philosophically at the opposite end of the spectrum from its origins.
From its beginnings as a freely available and no cost good, the new standard was to protect source code by distributing it only in binary form and for profit. The latter model was dominant for years, but the old ways were never forgotten, precisely. While SHARE’s ability to produce its own flavor of IBM’s operating system may have been eliminated, the distributed development model that made it possible eventually evolved and inspired what today we simply call open source.
Where the proprietary model was once ascendant over something that looked a lot like open source, in the present day it is open source not proprietary that is the default – in the subset that is infrastructure software, at least.
Which is an outcome celebrated by millions in the technology industry, because more open source software means more capability and less friction for developers. But for all that the return of open source is welcomed, the industry is to some extent still grappling with one very basic question: where does the money come from?
In the early days, remember, software was subsidized by hardware. Sales of the latter paid for development of the former. In the model that followed, software paid for itself: software authors created a product, and that product was marketed and sold on a standalone basis. This was possible in large part because software vendors were no longer competing with free: by not making the source available, they ensured a role as the single point of access. This was and is the model that generates Microsoft tens of billions of dollars annually for two software assets in Office and Windows, better known as the two most successful software products in history.
With proprietary software pressured and giving ground to open source competition, however, the process for selling software has become more challenging. It is possible, of course, to monetize open source software directly. A variety of mechanisms have been tried, from dual licensing to support and service to open core. It is inefficient and significantly less profitable than selling proprietary software was, however. Even the best in the industry depended heavily on volume to make up for the difficulty in converting users of free software to paid customers. MySQL, for example, reportedly was at its peak able to convert one in a thousand users to a paid product. Combined with generally lower margins (though Pivotal might disagree) due to increased competition from other open source projects, and it’s not difficult to understand why it’s harder for commercial organizations to extract revenue relative to proprietary competitors. Red Hat, then, is the exception that proves the rule.
But if it’s true, as Cloudera’s Mike Olson has said, “you can’t build a successful stand-alone company purely on open source,” why open source the software at all? For those that do, he has an answer, “You can no longer win with a closed-source platform.”
You can’t win without open source, in other words, but you can’t win with it either. How is software going to be produced then? What kind of model balances the costs and benefits of both the open and proprietary models in such a fashion that buyer, developer and vendor are all satisfied?
From a market perspective, the clear answer is open source software delivered as a service. Instead of attempting to sell open source software as a standalone entity, you couple it with a platform and sell the two together. Consider a few of the advantages:
- It can be difficult to compel developers or buyers to pay for software they can obtain for free. It is understood, by comparison, that that same software hosted will not be free.
- Gone are misalignments of customer and vendor needs. The paradox of being tasked with delivering a quality product while deriving in some cases 100% of revenue from support of it, the tension between continual delivery and withholding features to incent upgrades, all are eliminated in service businesses. In a SaaS business, you’re simply paid to run the software and deliver ever better versions of it.
- Developers or the customers they work for can still download and run a given open source project on their own if they choose, but increasingly are forced to address questions as to whether they’ll be able to operate it as well in house as the people who built it.
Not that the case for services is based strictly on theory. The available market evidence suggests that open source offered in a service context is increasingly the primary choice for growth. Businesses are acquiring OSS-aaS (e.g. IBM with Cloudant and Compose) or developing it internally (e.g. MongoDB and Atlas), and buyers are consuming it at an accelerating rate. PostgreSQL owes much of its recent resurgence to adoption by AWS, Heroku and lately, Google, while the MySQL-compatible but proprietary Aurora product is the fastest growing service in Amazon’s history.
As neatly as service-based open source offerings close loopholes and simplify customer conversion, however, they represent a model that can be less appetizing for startups, particularly small ones. Running a SaaS business is both more expensive and more challenging to manage than merely writing and selling software. For many commercial open source organizations, a hosted service is for reasons real or imagined not currently viewed as an option.
Which brings us back to licenses.
Commercial open source organizations today face significant challenges. On the one hand, open source itself is no longer viewed as an impediment to adoption; if anything, the opposite tends to be true. But it is difficult for such organizations to turn users into customers, as it has always been, and the competitive landscape is significantly more crowded than it has been in years past. Rampant fragmentation has led to significantly more choice arriving more quickly, and new models such as the previously discussed cloud offerings are options that didn’t exist a decade ago.
It should perhaps come as no surprise then that we’re seeing organizations look to new licensing mechanisms as a means of addressing questions of revenue.
While the history of software revenue models is rich in its variety, today most software is accurately classified as belonging to one of two categories: open source or proprietary. Free software advocates would likely take issue with being included in the open source bucket, and indeed that superset includes a multitude of approaches – many of which are radically distinct from one another. For our purposes here, it’s enough to recognize that most software is released under either a proprietary license or an open source license that meets the terms of the OSI’s Open Source Definition.
If Cockroach Labs, MariaDB or Sourcegraph have their way, however, we may have to add a third category to the list.
This category is not new; it borrows heavily from shareware (and crippleware, trialware, etc) models that preceded it, and similar efforts have been floated periodically. The model is clearly not a traditional proprietary approach, because the source code is made available. Neither can it be considered open source, however, because it does not meet the terms of the OSI’s definition of that term. The highest profile examples in this category are Sourcegraph’s Fair Source License (released March 2016), MariaDB’s Business Source License (August 2016) and Cockroach’s Community License (January 2017).
While these three licenses differ in their implementation details, they are all essentially trying to address the same need: balancing the availability of code that characterizes open source with the need to monetize the software to continue its development. Which is, of course, a company’s right. Those who write the software get to decide on the terms under which they make it available.
The question is not whether they have the right to use these neither open nor closed licenses, but rather if it’s a good strategic decision. While licenses are a matter of faith to many open source communities, and embody a given set of values, from an analyst’s perspective they are just tools. And different jobs may require different tools.
It’s not clear, however, that hybrid licenses – a term I’m using here as a placeholder until the market decides how to refer to them – are a worthwhile approach. There are several basic issues.
- Legal Departments: Through a monumental effort by thousands of organizations worldwide over a period of better than a decade, most legal departments that deal with software have acquired at a minimum an understanding of and trust in the the Open Source Initiative’s list of approved licenses. The most important consequence of which, typically, is that licenses that are on this list may be considered; everything else is explicitly disallowed. Hybrid licenses then face an uphill battle with legal departments worldwide.
- Developer Antipathy: As they do, notably, with developer populations. The steady erosion of proprietary software businesses by open source competition speaks to the central role OSS plays in a developer’s life today. Attempts to subvert or compete with open source, then, tend to be met with skepticism in a best case scenario and hostility at worst. Which means that the single most important constituency when it comes to adopting new technology is likely predisposed to being anti-hybrid licenses.
- Audits and Trust: In many cases, hybrid licenses explicitly refer to the honor system. Rather than building limitations into the software, they rely on companies to be honest in their self-reporting. But while enterprises tend to be scrupulous about paying for the software they use, there’s a reason that many vendors include audit teams. Software has a way of finding its way into places the people responsible for paying for it are unaware of. Advocates of these licenses tend to argue that this isn’t a problem because they won’t perform audits, but a) that can change and b) companies can get acquired by organizations with differing attitudes towards audits.
- General Confusion: Licenses, even those that have become well understood, are friction. Developers increasingly are responding to this friction by simply not selecting any license. As of March 2015, fewer than 20% of the repositories on GitHub carried a license. In this type of climate, new models that impose new responsibilities – and which are generally incompatible with existing licenses and/or package repositories – are unlikely to see widespread adoption.
- Limited Contributions: The importance of this can vary by project, but hybrid licenses are likely to significantly depress the volume of incoming contributions for projects governed by these terms. The historical trend at present is towards more permissive rather than more restrictive licenses, and developers and enterprises alike tend to be reluctant to contribute back to projects that contain significant licensing limitations. This is one of the most significant issues for projects such as MySQL that leverage a dual license model, as one example. Many of the most significant potential contributions to the core project cannot be merged because the patch authors refuse to assign copyright, prefer a more liberal license or both.
Ultimately, the question of whether hybrid licenses are necessary likely comes down to how they’re evaluated relative to their closest competition. Pure play open source is enormously popular with developers but difficult to commercialize, and open core has emerged as the default model. Open core essentially describes a product in which a proprietary layer with extra features or capabilities is sold on top of a fully functional open source foundation.
At issue, then, is which of these two options is preferable:
- Option A: Having most of a project be available under an OSI approved license with certain features and the source code they’re based on held back as a binary with a proprietary license.
- Option B: The entirety of a code base is made available and shared under a license that is not OSI approved and comes with more restrictions.
The bet here is that the costs of hybrid licenses and the restrictions they impose will outweigh the lack of full source access in open core projects. That as a result the former will see limited adoption even amongst commercial open source organizations that are looking for every revenue opportunity they can find. As clever as the hybrid license might appear as a solution, they come with a significant overhead for buyers and sellers alike, one insufficiently offset by the fact that more source code is visible.
Even if this proves false and hybrid licenses take hold counter to expectations, it’s likely that the future of the commercialization of open source has less do with license models than it does with delivery methods. Commercial open source organizations, therefore, looking to maximize revenue would do well to think about whether improving their conversion rate at the margins is likely to generate a higher return than a business model that is built on the assumption that virtually every user is a paying user.
Licenses are always a tactic, but they’re rarely a strategy.
Disclosure: IBM, MariaDB, MongoDB, Pivotal and Red Hat are RedMonk customers. Cloudera, Cockroach Labs and Sourcegraph are not currently RedMonk customers.
