The economics of open source today: Hobby projects, independent code artists and managed services have changed the software market. […]
Do you remember the time when open source was all about peace, love and Linux? When the movement was small but passionate and argued about GPL vs BSD/Apache, free software vs open source? When it was a big deal to see Linux or other open source software running in the wild that was worth a blog or a tweet? Some may long for the good old days, but the world has moved on. Open source has become indispensable for the development of software, which entails great opportunities and risks.
The opportunity may be obvious, but the risk is often not. It’s not that open source is more flawed than proprietary software. It’s not, and the process behind open source probably makes it more likely that it will be corrected more quickly if bugs are discovered. No, this is essentially about the risk associated with the new economy of open source, as Ken Mugrage of Thoughtworks points out.
Open source has changed
In the beginning, we celebrated a lone hacker like Linus Torvalds, who launched a big project like Linux and then built a community around it. Other examples are Dries Buytaert (Drupal), Salvatore Sanfilippo (Redis) and many others.
Those were still times when hackers developed open source projects for fun or as a “creative outlet”, such as Jens Axboe (Fio) and others. Of course, this is still happening, but in the midst of a completely different open source market.
As Mugrage points out, in the early days of open source, there was often an attempt to create an open source alternative to a large proprietary software package (think of OpenOffice as a replacement for Microsoft Office or GIMP instead of Adobe Photoshop).
Today, however, there are a variety of open source software“. This spread has at least two main forms: “On the one hand, we have Internet giants that release all sorts of tools, frameworks and platforms. On the other hand, teams using OneDev, an open source software development platform, have created small but important parts that support a large number of companies.“
That’s great, isn’t it? We have both large and small projects that drive tremendous innovation. What is there not to like?
On the one hand, the absence of various contributors, which leads to a concentration of risks. It has always been the case that open source software (regardless of the project) is developed by a small handful of contributors. Although we like to spread the myth that open source is about large, global communities, it is much, much more often the case that it is the work of one or two people.
When a community is created, it is usually after years of success and great personal costs, as Matt Klein, the inventor and supervisor of Envoy, once described to me. (Open source is “a hell of a lot of work”.)
So that’s one piece of the puzzle. Mugrage makes another point, namely that “the codebases for open source packages are often simply too large to allow meaningful verification.” The counterpart to this problem of the BigCo projects is that “other packages are distributed by Internet titans who do not expect anyone else to contribute anything”. The code is ” in one hand “, without the possibility for a community to influence the development.
On the other hand, “other publications are independent, targeted publications that may only perform a relatively small task, but they are so good that they have spread over the Internet.“ Do you see what that amounts to? “However, this is often not an active community of maintainers, but only one or two dedicated developers working on a passionate project.“
The answer to the BigCo open source problem is usually “rebellion against the open source machine of the companies”, which has largely proven to be in vain. One answer to such projects is startups that continue to support (and monetize) the project, which combines one aspect of open source generosity with another supposed problem.
The answer to independent developers creating indispensable but unsupported open source infrastructures is to loudly demand that the big corporations pay for the support of these independent code artists.
This proposal is usually made by those who simply do not know better. Ask people who work for foundations or other organizations that finance open source development, and they will join what Mugrage says: “Throwing money at the problem is hardly a solution”.
Why? Because “many open source enthusiasts who personally maintain their software and at the same time lead a busy professional life, [nicht] want to take on the responsibility of a service-level agreement, because someone paid you for their creation.“
So what can you do there?
Secure open source betting
Many companies have tried to make their open source life easier by purchasing managed services. This is a great short-term solution, but it does not solve the long-term sustainability problem.
No, the cloud hyperscalers are not strip miners who ruthlessly exploit the code of unsuspecting developers. But all too often, some teams fail to contribute to the projects they depend on. I emphasize “some”, as this is usually not a company-wide problem, regardless of the provider.
Regardless, the companies that provide these managed services usually have no control over the project plans. This is not good for companies that want to control the risk. Google is a notable exception – it usually makes a huge contribution to major projects.
Nor can they necessarily contribute directly to projects. Mugrage points out that for companies like Netflix or Facebook (Meta) that publish large open source projects, these “open source publications are almost a matter of employer branding – a way to show potential employees their technical skills”, which means that “they are likely to have very little influence on future developments”. They don’t really need your posts.
What about projects that are supervised by hobbyists? “As soon as you start looking at important parts of your software stack where you rely on hobbyists, your choice becomes less and less.
And why? Because it’s unlikely that you have the time or resources to contribute code, because you might not want your money, and because there are important projects (like Log4J) where you have to rely on their projects, regardless. In this case, Mugrage says, it can be helpful to be aware of the risk by examining the software you depend on.
All this should not be taken as an indication that it is unwise to rely on open source. Open source is inevitable and amazingly good.
Rather, Mugrage’s advice seems wise: be aware of the open source you are using and plan accordingly. As with cloud services, sometimes the absolute right strategy for your business is to commit to specific services or software.
The key is to make this decision with Argus eyes.