The past several months has seen an unusually high level of commotion in the open source community, largely focused on the economics of who — and how we — should pay for ‘free’ software. But this isn’t just some geeky flame war, what’s at stake here is business critical for vast swathes of the business world.

So what’s all the fuss about?

To get a handle on this, it helps to consider what open source means today. In its earliest days, the open-source movement was all about creating alternatives to large software packages. And there were some outstanding successes which enabled large groups of people to participate: I started my first web company in the mid 90s with almost no capital, based largely on the availability of the Linux operating system, Apache web server, and PHP programming language.

Open source’s early promise

The early days were also characterized by some fine ideals about what it meant to be open source: that anyone could and would review the codebase to identify and fix bugs, that people would take code bases and contribute to their advancements; that there was a profitable business model for building ‘free’ software.

Online systems like SourceForge and later GitHub made it easier to share and collaborate on smaller open-source components. The subsequent Cambrian explosion of open-source software has tested some of those original ideas to breaking point. In contrast to the focus on creating alternatives to large software packages, today there’s a proliferation of open-source software, on one side we have internet giants churning out all manner of tools, frameworks and platforms, at the same time, one-dev bands have created small but critical parts that support a huge number of businesses.

The diversity of open-source projects today has challenged many of the initial principles. So in many instances, the codebases for open-source packages are simply too large to allow for meaningful inspection. Other packages are distributed by internet titans that have no expectation that anyone else will contribute to them. Yet other releases are distinct, point releases that may only do one relatively minor task but do it so well that they’ve spread across the internet — but rather than an active community of maintainers, they’re often just a passion project for one or two committed developers. 

You can appreciate the challenges this can create by looking at some recent examples of open source’s changing economics.

Take ElasticSearch. Back in September 2021, Elastic changed its license to require cloud service providers who profit off their work to contribute back. Those changes caused high dudgeon in the open source community and prompted AWS to fork the code base and create a new distribution for their OpenSearch product.

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

Can open source continue to thrive?

So is this the end of the road for the open-source dream?

Certainly, many of the open-source naysayers will view the recent upheaval as proof of a failed approach. They couldn’t be more wrong.

What we’re seeing today is a direct result of the success of open source software. That success means that there is no one-size-fits-all description of what open source software is, nor one economic model for how it can succeed.

For the internet giants like Facebook or Netflix, the popularity or otherwise of React or ChaosMonkey is besides the point. For such companies, open-source releases are almost a matter of employer brand: a way to show off their engineering chops to potential employees. The likelihood of them altering licensing models to create new revenue streams is small enough that most enterprises need not lose sleep over it. Nonetheless, if these open-source tools form a critical part of your software stack or development process, you might want some form of contingency plan — you likely have very little sway over future developments, so understanding your risks helps. 

That advice holds true for those pieces of open-source software maintained by commercial entities. In most cases, those companies will want to keep customers happy — but they’re also under pressure to deliver returns, so changes in licensing terms cannot be ruled out. Again, you reduce the risk of disruption by understanding the extent to which you’re reliant on that software — and whether there are alternatives.

When it comes to companies that have built platforms that contain open source software, the risks are more uncertain. At Thoughtworks, we think this is in-keeping with our view that all businesses can benefit from a greater awareness of what software is running in their various systems. In such cases, we advise companies to consider the extent to which they’re reliant on that piece of software: Are there viable alternatives? In extreme circumstances, could you fork the code and maintain it internally? 

Once you start looking at crucial parts of your software stack where you’re reliant on hobbyists, your choices begin to dwindle. But if the Log4J commotion has taught us anything it’s this: auditing what goes into the software that runs your business puts you in a better place than being caught by complete surprise.