Online systems such as Sourceforge and later GitHub made it easy to share and collaborate on small open-source components. Subsequently, the early and explosive growth of open source software tested some of these original ideas at breaking points.
Unlike in the past the focus was on creating alternatives to larger software packages, today there is a proliferation of open source software. On the one hand, we have Internet giants brainstorming all sorts of tools, frameworks and platforms. On the other hand, teams using the open source software development platform OneDev have created small but complex parts that support a large number of businesses.
The diversity of projects today has challenged many of the early principles of open source. Therefore, in many cases, the codebase for open-source packages is too large to allow meaningful monitoring. Other packages are distributed by Internet Titans who do not expect anyone else to contribute. However, other publications are different, targeted publications that can do only a relatively small task, but do so well that they spread throughout the Internet. However, instead of an active community of maintainers, they are often just one or two committed developers working on a passion project. Looking at some recent examples of the changing economics of open source, one can appreciate the challenges that this could pose.
Elastic Search, for example, changed its licensing terms in 2021, requiring cloud service providers to profit from its work and pay for it by releasing code for any management tools they create. Those changes caused a stir in the open-source community. They encouraged Amazon Web Services, which until the change offered a managed service based on ElasticSearch, to “fork” the codebase and create a new distribution for its OpenSearch product.
At the other end of the scale, after the vulnerability was revealed in December 2021, the security snag at Log4J called it the “biggest mistake on the Internet.” Log4J is an open-source logging tool that is widely used in many systems today. . But, its popularity did not mean that it was supported by a stellar maintenance team – instead, it was maintained by amateurs. Here, throwing money at the problem is hardly a solution. We know of many open-source enthusiasts who personally maintain their software while living a busy business life – the last thing they want is a service-level contract obligation because someone paid them for their creation.
So, is this the end of the road to an open-source dream? Certainly, many open-source naysayers will see the recent upheaval as evidence of a failed approach. They couldn’t be more wrong.
What we are 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 to define open-source software, nor is there an economic model for how it can be successful.
That advice is true for those pieces of open-source software maintained by commercial organizations. In most cases, such companies want to keep customers happy, but they are also under pressure to pay back, so a change in license terms cannot be ruled out. Again, to minimize the risk of disruption, you need to understand the extent to which you rely on that software and whether options are available.
The risks are more uncertain for companies that have built platforms with open source software. This is in line with Thoughtworks’ vision that all businesses can benefit from greater awareness of what software is running on their various systems. In such cases, we advise companies to consider the extent to which they rely on that piece of software: Are there any viable alternatives? In extreme cases, can you fork code and maintain it internally?
Once you start looking at the crucial parts of your software stack where you rely on hobbies, your choices start to wane. But if the case of Log4J has taught us anything, it is this: auditing what goes into the software that runs your business puts you in a better position than to be completely surprised.
This content was created by Thoughtwork. It was not written by the editorial staff of MIT Technology Review.