The economic evolution of open source


The past few months have seen an unusually high level of unrest in the open source community, largely focused on the economy from whom — and how — should we pay for “free” software. But it’s not just geeky flame warfare, what’s at stake here is business critical for vast swathes of the business world.

So why all the fuss?

To understand this, it helps to consider what open source means today. In its beginnings, the open-source movement was to create alternatives to large software packages. And there have been some remarkable successes that have allowed large groups of people to participate: I started my first web business in the mid-1990s with almost no capital, relying largely on the availability of the system. operating Linux, Apache web server and PHP programming language.

The first promises of open source

The early days were also characterized by fine ideals of what it meant to be open source: that anyone could and wanted to review the codebase to identify and fix bugs, that people would take the codebases and contribute to their progress; that there was a profitable business model for creating “free” software.

Online systems like SourceForge and later GitHub made it easier to share and collaborate on smaller open source components. The ensuing Cambrian explosion of open source software tested some of these original ideas to breaking point. Contrary to the emphasis on creating alternatives to big software packages, today there is a proliferation of open source software, on the one hand we have internet giants producing all kinds of tools, of frameworks and platforms, at the same time, single-developer groups have created small but essential pieces that support a large number of companies.

The diversity of open source projects today has challenged many of the original principles. Thus, in many cases, the code bases of open source packages are simply too large to allow meaningful inspection. Other packages are distributed by internet giants who don’t expect anyone else to contribute. Yet other releases are distinct, point releases that may do only a relatively minor task but do it so well that they have spread across the internet – but rather than an active community of maintainers, they are often only than a passion project for one or two committed developers.

You can appreciate the challenges this can create by looking at some recent examples of the economic evolution of open source.

Take ElasticSearch. In September 2021, Elastic changed its license to require cloud service providers who profit from their work to contribute back. These changes caused a lot of upset in the open source community and prompted AWS to fork the codebase and create a new distribution for their OpenSearch product.

At the other end of the scale, a security snafu in Log4J created what has been dubbed the internet’s biggest bug. The popular open source logging tool is widely used on a multitude of systems today. But his popularity didn’t mean he was backed by a crack maintenance team; it was maintained by amateurs. Here, throwing money at the problem is hardly a solution. We know many open source enthusiasts who personally maintain their software; and they have a busy professional life – the last thing they want is the responsibility of a service level agreement because someone paid them for their creation

Can open source continue to thrive?

So is this the end of the road to the open source dream?

Certainly, many opponents of open source will regard the recent upheaval as evidence of a failed approach. They couldn’t be more wrong.

What we see today is a direct result of the success of open source software. This success means that there is no single description of what open source software is, nor a business model for how it can succeed.

For Internet giants like Facebook or Netflix, the popularity or not of React or ChaosMonkey is not the only question. For these companies, open source releases are almost all about employer branding: a way to show off their engineering capabilities to potential employees. The likelihood of them changing licensing models to create new revenue streams is low enough that most companies don’t have to lose sleep over it. Still, if these open source tools are an essential part of your software stack or development process, you might want some form of contingency plan – you probably have very little influence on future developments, so understand your risk helps.

This advice is true for open source software maintained by commercial entities. In most cases, these companies will want to satisfy their customers, but they are also under pressure to provide feedback, so changes to license terms cannot be ruled out. Again, you reduce the risk of disruption by understanding how dependent you are on this software and if there are alternatives.

For companies that have built platforms containing open source software, the risks are more uncertain. At Thoughtworks, we believe this aligns with our view that all businesses can benefit from having a better understanding of the software running on their various systems. In such cases, we advise companies to determine to what extent they depend on this software: are there viable alternatives? In extreme circumstances, could you fork the code and keep it in-house?

Once you start looking at the crucial parts of your software stack where you depend on hobbyists, your choices start to dwindle. But if the hustle and bustle of Log4J has taught us anything, it’s this: auditing what’s going on in the software that runs your business puts you in a better position than being caught off guard.


About Author

Comments are closed.