The emerging risks of open source

Remember when open source was all about peace, love, and Linux? When the movement was small but impassioned and fought over GPL versus BSD/Apache, free software versus open source? When seeing Linux or other open source software running in the wild was a big deal, worthy of a blog or Twitter? 

Some might pine for those good old days, but the world has moved on. Open source has become essential to how all software gets built, which comes with great opportunity and risk.

The opportunity may be obvious, but the risk often isn’t. This isn’t a question of open source being more buggy/whatever than proprietary software. It isn’t, and the process behind open source arguably makes it more likely to be secured faster when errors are discovered. No, this is fundamentally about the risk inherent in the new economics of open source, as Thoughtworks’ Ken Mugrage calls out.

Open source has changed

Early on we celebrated a lone hacker such as Linus Torvalds creating a big project like Linux and then growing a community around it. 

Other examples include Dries Buytaert (Drupal), Salvatore Sanfilippo (Redis), and more. Those were the days when hackers built open source projects for fun or as a “creative outlet” like Jens Axboe (Fio) or others. That still happens, of course, but it happens in the midst of a very different open source market.

As Mugrage highlights, early open source often tried to create an open source alternative to a big proprietary software package (think OpenOffice as a replacement for Microsoft Office or GIMP instead of Adobe Photoshop). However, “today there’s a proliferation of open source software.” 

That proliferation takes at least two primary forms: “On one side, we have internet giants churning out all manners of tools, frameworks, and platforms. On the other side, teams using OneDev, an open source software development platform, have created small but critical parts that support a huge number of businesses.”

This is great, right? We have both big and small projects fostering immense innovation. What’s not to like?

The lack of diverse contributors, for one thing, which concentrates risk. True, it has always been the case that open source software (no matter the project) is developed by a small handful of contributors. 

Although we like to mythologize open source as being about large, global communities, it’s much, much more common for it to be the work of one or two people. When community comes, it’s usually after years of success and great personal cost, as Envoy creator and maintainer Matt Klein once described to me. (Open source is a “f—-ing lot of work.”)

So that’s one part of the puzzle. Mugrage argues another point, that often “the code bases for open source packages are simply too large to allow meaningful inspection.” 

The kissing cousin to this problem of BigCo projects is that “other packages are distributed by internet titans that don’t expect anyone else to contribute to them.” The code is “single threaded” to one big entity without the ability for a community to impact development.

On the other hand, “other releases are distinct, targeted releases that may only do one relatively minor task but do it so well that they’ve spread across the internet.” See where this is going? “However, rather than an active community of maintainers, they’re often just one or two committed developers working on a passion project.”

The answer to the BigCo open source problem has tended to be “rage against the corporate open source machine,” which has largely proved futile. 

One response to such projects has been for start-ups to emerge to further support (and monetise) the project, which fixes one aspect of open source largesse with another perceived problem. The answer to independent developers creating essential but unsupported open source infrastructure has been to loudly demand that the BigCos pay to support these independent code artisans.

This suggestion is usually offered by those who simply don’t know any better. Ask people who work for foundations or other orgs designed to fund open source development, and they’ll echo what Mugrage says: “Throwing money at the problem is hardly a solution.” 

Why? Because “many open source enthusiasts who maintain their software personally while leading busy professional lives … [don’t want] the responsibility of a service-level agreement because someone paid them for their creation.”

What to do?

Hedging open source bets

Many enterprises have sought to make their open source lives easier by buying into managed services. It’s a great short-term fix, but it doesn’t solve the long-term issue of sustainability. No, the cloud hyperscalers aren’t strip miners, nefariously preying on the code of unsuspecting developers. 

But too often some teams fail to plan to contribute back to the projects upon which they depend. I stress some, as this tends to not be a corporation-wide issue, no matter the vendor. I’ve detailed this previously. 

Regardless, the companies offering these managed services tend to not have any control over the projects’ road maps. That’s not great for enterprises that want to control risk. Google is a notable exception—it tends to contribute a lot to key projects. 

Nor can they necessarily contribute directly to projects. As Mugrage indicates, for companies like Netflix or Facebook (Meta) that open source big projects, these “open source releases are almost a matter of employer branding—a way to show off their engineering chops to potential employees,” which means “you’re likely to have very little sway over future developments.” They don’t really need your contributions.

What about projects maintained by hobbyists? “Once you start looking at crucial parts of your software stack where you’re reliant on hobbyists, your choices begin to dwindle.” 

Why? Because you’re unlikely to have the time or resources to contribute code, they may not want your cash, and there are significant projects (like Log4J) where you need to rely on their projects, regardless. In this case, Mugrage suggests, just being aware of the risk via an audit of the software you depend on can be helpful.

None of this should be taken as an indication that relying on open source is unwise. Open source is inevitable and is amazingly good. Rather, the advice from Mugrage seems wise: Be aware and thoughtful about the open source you use, and plan accordingly. 

As with cloud services, sometimes the absolute correct strategy for your company is to be “locked-in” to certain services or software. The key is to make this choice with eyes wide open.