The Reality of Open Source: More Puppies, Less Beer

We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game. Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups. Follow TNS on your favorite social media networks. Become a TNS follower on LinkedIn. Check out the latest featured and trending stories while you wait for your first TNS newsletter. The aftermath of Bitnami halting its program of maintaining a library of popular open source containers and pulling down its popular Helm charts for those containers has left many teams wondering when the next shoe will drop in open source software. Bitnami’s decision caused significant disruption, compelling the Cloud Native Computing Foundation (CNCF) to publish a blog post noting that Bitnami’s action did not affect the open source status of the Helm project.Bitnami’s move is only the latest major instance of changes to open source availability, packaging and licensing affecting business continuity for users. Elastic, HashiCorp, Redis, Linkerd and Red Hat have all made changes that forced teams to reconsider their use of open source components.The Bitnami episode is another reminder that open source software is more like a free puppy than a free beer. The costs of ownership are significant and should not be ignored.Every organization, platform and security team not only needs to look at making sure their scanners are running and their application security process is rock solid. They also need to look at every open source container they’re running, who maintains it and how much they trust that organization to continue maintaining it. This is also true for all open source packages. And it’s all strictly business.None of this is to say the companies that made these changes didn’t have business reasons. But in each case, users had to react and pivot. Whether we like it or not, every open source component has to be viewed through the lens of business continuity.There’s a persistent myth in the open source world that somehow thousands of projects are maintained purely through the goodwill of passionate developers contributing in their spare time. In rare instances, this myth is true.There are some open source developers maintaining critical projects. They are largely maintaining smaller packages or libraries rather than full products. A similar illusion has existed for organizations generating important open source artifacts, like official container images or packages. Witness what happened with Bitnami.Reality check. Behind virtually every significant open source project or artifact, there’s a company or a foundation. Someone is funding the development. Someone is making the investment. And that someone expects a return.In the rare instances when no return is expected, an individual developer or small team is building something interesting but treading a tenuous path. They might burn out or opt to hand off their project. Or, as a solo developer, they might lack the bandwidth to put in place security measures that a more robust organization might.In the end, as much as we hate to say it, open source is about economics, be it for a business or for an individual. If it no longer makes sense to sustain and maintain, then everyone ends up in pain.When engineers evaluate open source technology, they typically focus on the technology itself. They look at social signals like GitHub stars, forks, pull requests, the strength of the community, the quality of the code and the feature set.Hopefully, they also look at how many maintainers a project has, who those maintainers are, where they work, whether the software is part of a foundation and what the licensing terms are. These factors matter, but they’re insufficient for making a sound business decision about what to depend on.What’s missing? An evaluation of the company, organization or individuals behind the project. Namely, it’s critical to ask: Who’s funding the development? Is it a single company, a consortium, a foundation with diverse backing, or actually just volunteers? If it’s a company, is that company well-funded and stable? How does the business make money?If the open source project you’re depending on doesn’t directly contribute to the sponsoring company’s revenue model, that’s a red flag. When economic conditions tighten or strategy shifts, nonrevenue-generating projects are the first to be cut or monetized aggressively. What’s the governance model? Does a single company control all the keys? Are there multiple organizations with meaningful input? Can the project easily be forked and maintained if the primary sponsor exits?The Bitnami changes, for instance, shouldn’t have surprised anyone paying attention to the business fundamentals. When Broadcom acquired VMware and subsequently changed the way Bitnami was distributed, the writing was already on the wall. Look at how Broadcom makes money. Look at its history with acquisitions. The move to restrict what was “free” was entirely predictable.Bitnami containers and Helm charts are only the top layer of risk. Every open source project depends on dozens or hundreds of other open source projects. Each of those has its own business model, funding source and risk profile. The risk compounds at every layer.Consider the dependencies most teams don’t even think about. Your application uses a popular web framework. That framework depends on a specific SSL library. That library is maintained almost entirely by engineers at a single large tech company. What happens if that company shifts priorities? What happens if there’s a critical vulnerability and no one is maintaining it?This cascading dependency risk means you can’t just evaluate the top-level open source components you’re directly using. You need to understand what’s underneath them, and what’s underneath that. It’s turtles all the way down, and most organizations have no visibility into most of those turtles.The era of adopting open source without thinking deeply about business continuity is over. Here’s what needs to change in how organizations approach open source.To be clear, this does not mean abandoning open source or becoming paralyzed by risk. Open source remains one of the most powerful forces in technology, enabling innovation and collaboration at unprecedented scale. But we need to be clear-eyed about the entire spectrum of business risks open source presents, and what the costs or required steps are of mitigating those risks. Without planning and foresight, those costs can come due suddenly, as anyone scrambling to rebuild or find an alternative source for Bitnami containers can attest.Bitnami’s move merely underscores that open source adoption must also be a strategic business decision, not just a technical one. We have to evaluate not just the code, but the company. Not just the current state, but the likely future trajectory. This is more work. It requires different skills and different processes. But it’s the only way to build on open source with confidence, knowing that the foundation you’re building on will still be there tomorrow. Community created roadmaps, articles, resources and journeys for developers to help you choose your path and grow in your career.