tecosystems

Taking Open Source for Granted

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

Particularly for those who have been in the industry long enough to remember when it was compared to cancer, we live in a veritable golden age for open source software. Once a bizarre, improbable model for generating commercial returns if not building software, it is increasingly and overwhelmingly the default approach. As Cloudera’s Mike Olson famously said five years ago, “You can no longer win with a closed-source platform.”

This reality is evident anywhere you look. The key building blocks for next generation infrastructure are all open source. Where once companies abstracted their workloads from underlying platforms using proprietary software such as WebLogic or WebSphere, for example, today they’re more than likely leveraging open source containers managed by Kubernetes. The fastest growing databases, for their part, are and have been for years open source. From established projects such as Git and Jenkins to emerging projects such as Envoy, Istio and Vitess, open source is no longer the exception, it’s the rule.

Open source has been so successful, in fact, that the industry increasingly seems to take its success for granted. It assumes that because open source is today the indisputable victor over the approaches that preceded it, that this will be the case indefinitely. Which may well be true, because open source is a software development model that has become engrained in an entire generation of software engineers.

But the challenge of building successful businesses around open source remains, and this presents risks for open source communities moving forward.

The current state of open source licensing is suggestive here. On the one hand, open source licensing has never been more widely understood, and the industry as a whole is moving away from a copyleft dominated landscape towards a more balanced distribution of permissive and reciprocal adoption. But on the other, friction around commercialization, the threat of hyperscale cloud providers or both is leading many to drift or at least consider drifting away from standard, accepted open source models.

The most obvious public evidence of this are the so-called “hybrid licenses” employed by Cockroach, MariaDB and others which make source code available under licenses that do not comply with the OSI’s principles for open source licenses. These licenses are an attempt to extract the collaborative benefits of open source and combine them with the simplified commercialization of the resulting source code. And while this type of licensing approach has, somewhat predictably, not showed mainstream interest or traction, privately, inquiries to RedMonk about either modifying existing open source licenses to make them more restrictive or to combine open and closed source code in ways that clearly violate the spirit of open source have accelerated dramatically. Historically, most businesses have chosen to accept the operating constraints and commercial inefficiencies of open source licenses and mitigate these with go to market mechanisms that minimized their impact such as open core or more successfully, as-a-Service implementations. Relatively recently, however, the willingness to seek ways to bend, if not break, the principles concerning open source software has increased noticeably.

The reasons for this, as mentioned, are twofold.

  • First, because many take what Mike Olson went on to add in the piece linked to above, that “you can’t build a successful stand-alone company purely on open source” – as a given. And indeed, exceptions to that assertion are rare and typically come with caveats, as with Red Hat and its once closed source Network product.
  • Second, and more importantly, there is a growing awareness that, as RedMonk has been arguing for a number of years, that the cloud represents an opportunity for open source software and those who would commercialize it, yes, but a potentially existential threat as well.

Open source has won over the industry, at least in part, because it was more convenient to adopt than proprietary software. Instead of developers waiting on permission and budget to acquire the software resources they needed, open source could be leveraged without reference to or permission from anyone. The problem for open source is that the cloud is that much more convenient than open source software, in most cases. If downloading software and installing it is easier than having to go through a salesperson, not downloading and installing anything or requiring hardware but having it spun up for you in seconds is that much more so. In a world which puts an enormous premium on convenience, this gives the cloud a significant competitive advantage.

Many will point out that open source is both a critical on ramp for public clouds today, of course, and that the companies behind said clouds have themselves released enormously popular open source projects such as Kubernetes. All of which is true – today. But again, timescales matter. Open source is currently being leveraged as a tactic to acquire and ramp up customers to hyper-scale clouds.

Which begs obvious questions: what happens once customers come on board using open source services? And what happens when a majority of customers are already on one of the major clouds, and customer retention and expansion begins to be equally prioritized alongside acquisition?

The answer to the first question is clear: it is in most cloud providers self-interest to lock customers into adjacent proprietary services after they begin their lifecycle using open source software. Shapiro and Varian’s math on the relationship between profits and switching costs has changed little, if at all, in the cloud age. The answer to the second question is more complicated, but it seems clear that at a point in which a majority of businesses are already on the cloud at least for some portion of their workloads, while a given cloud provider’s managed open source implementations will persist as product offerings, external participation and recruitment via open source would potentially become less strategically significant. The priority instead would become differentiating between cloud providers with services unique to a given platform, which is to say not open source software.

To be clear, when discussing a potentially dystopic future for open source, it’s necessary to emphasize both modifiers – potential and future. The present, commercialization friction or no, is a veritable paradise compared to the landscape a decade ago let alone two.

But just as many in the United States have had a wakeup call about taking the stability of our civic institutions for granted, those with an interest in seeing open source remain a vital and robust model moving forward should remember that the price of freedom is high. It always has been.