The open-source community has been roiled for several months, with most of the discussion centered on the economics of who and how we should pay for "free" software. But this isn't just a nerdy squabble; what's at stake here is commercially important for large swaths of the corporate sector.
So, what's the big deal here?
It's helpful to think about what open source means now to get a hold on this. The open-source movement began with the goal of providing alternatives to major software packages. There were a few notable achievements that allowed broad groups of people to participate: in the mid-1990s, I began my first web company with absolutely no funding, thanks to the availability of the Linux operating system, Apache web server, and PHP programming language.
The early promise of open source
The early days were also marked by some wonderful ideas about what it meant to be open source: that anyone could and would review the codebase to find and fix bugs, that people would take code bases and contribute to their advancements, and that there was a profitable business model for creating 'free' software.
Smaller open-source components became easier to exchange and collaborate on thanks to online systems like SourceForge and subsequently GitHub. The Cambrian explosion of open-source software that followed has put some of those basic concepts to the test. In contrast to the focus on creating alternatives to large software packages, there is now a proliferation of open-source software. On the one hand, we have internet behemoths churning out all manner of tools, frameworks, and platforms, while on the other hand, one-dev bands have created small but critical parts that support a vast number of businesses.
Many of the original concepts have been challenged by the multiplicity of open-source projects today. As a result, open-source package codebases are frequently too vast to allow for meaningful analysis. Other packages are given by internet behemoths who have no expectation of others contributing. Other releases are discrete, point releases that may just handle one relatively modest duty but do it so effectively that they've spread over the internet — but they're typically just a passion project for one or two dedicated developers, rather than an active community of maintainers.
Looking at some recent examples of open source's changing economics will help you understand the difficulties this can cause.
Consider ElasticSearch. Elastic modified its license in September 2021, requiring cloud service companies who profit from their efforts to donate back. The open source community was outraged by the alterations, prompting AWS to fork the code and develop a new distribution for their OpenSearch product.
On the other hand, a security flaw in Log4J resulted in what has been labeled the internet's largest bug. Today, the popular open-source logging tool is utilized on a wide range of systems. Its success, however, did not imply that it was maintained by professional staff; instead, it was maintained by volunteers. Throwing money at the problem isn't a viable option here. Many open-source aficionados we know maintain their software on their own, and they have busy professional lives the last thing they want is to be saddled with the obligation of a service-level agreement because they were compensated for their work.
Is it possible for open source to thrive in the future?
Is the open-source dream finally coming to an end?
Many open-source sceptics will undoubtedly see the latest upheaval as proof of a failed strategy. They are completely incorrect.
What we're seeing now is a direct effect of open source software's success. Because of this, there is no one-size-fits-all definition of open source software, nor is there a single economic model for its success.
For internet behemoths such as Facebook and Netflix, the popularity of React or ChaosMonkey is irrelevant. Open-source releases are practically a matter of employer branding for such firms: a method to demonstrate their engineering prowess to prospective workers. The chances of them changing licensing models to generate new revenue streams are low enough that most businesses shouldn't be concerned. Nonetheless, if these open-source tools are an important part of your software stack or development process, you should have a contingency plan in place. You likely have limited control over future advancements, so knowing your risks is important.
That guidance applies to open-source software that is maintained by commercial enterprises. Changes in licensing terms cannot be ruled out in most circumstances because those corporations want to keep their consumers happy but are also under pressure to deliver returns. Again, recognizing the amount to which you're dependent on that software and whether there are alternatives reduces the chance of interruption.
The risks are more uncertain for organizations that have established platforms that include open-source software. This, in our opinion, is consistent with our belief that all firms may benefit from a better understanding of what software is running in their various systems. In such circumstances, we urge businesses to examine how reliant they are on that piece of software: Are there any realistic options? Could you fork the code and maintain it internally in an emergency?
Your options start to diminish if you start looking at critical sections of your software stack where you're depending on amateurs. But if the Log4J uproar has taught us anything, it's that checking what goes into the software that powers your organization is preferable than being caught completely off guard.
