The complicated road to Open Source Sustainability

Remember this xkcd comic?

Over the past couple of years, open source sustainability has been a recurrent theme in discussions with friends and colleagues alike.

Whether it be watching the core-js incident play out during the last week or the left-pad incident in 2016, it is evident that there is a huge sustainability problem in the open source JavaScript community.

But you'd be grossly mistaken if you thought this problem was specific to the JavaScript community alone. The Christmas gift of the log4shell incident in 2021 was my first brush with being personally responsible for rallying troops to mitigate the vulnerability at my workplace. I was employed with a bank at the time and clearly remember the panic and scurrying that ensued after the vulnerability was announced. I also remember how almost all consumers had their bytes and thought pieces ready for promises of support. Has much changed? One look at the project team tells you that we're still staring at a massive imbalance in the consumer/publisher ratio when it comes to open source.

I still don't get it. So what exactly is the problem?

Despite using open source software directly or indirectly in every aspect of our lives, many folks outside the OSS ecosystem have no idea about the enormous efforts behind the scenes to keep the machine well-oiled.

Why do I say that so confidently? Because I was one of those people, too, till 2019. I worked on Linux systems and was responsible for middleware administration for several apps built atop open source software such as Apache, JBoss, etc. Yet, my understanding of open source was limited to it being freely available. I didn't delve further because what was the point? It's not like my employers cared about it much, either.

Not until, of course, some bug affected the software, and all hell would break loose. Efforts would then be rallied to mitigate the bug at our end, and we'd wait until a patch was published to roll it out. All so simple, right? Wrong.

At that point, what was invisible to me were the toil and person hours behind releasing those patches, often at breakneck speed and under extreme pressure.

That's bad. But how does it matter?

The invisible toil & person-hours? They're expended by humans like you and me sitting behind a computer with families to feed and rent to pay.

How many of those folks receive adequate compensation for their contributions?

For context, everyone in the IT industry has used or at least heard of OpenSSL.

If you haven't, here's me quoting Wikipedia directly,

OpenSSL is a software library for applications that provide secure communications over computer networks against eavesdropping or the need to identify the party at the other end. It is widely used by Internet servers, including the majority of HTTPS websites.

From that definition, it looks like a pretty important piece of software, right? Guess how many core developers were maintaining the project during the Heartbleed vulnerability that affected almost everyone using the internet? Four.

One of the core developers, Steven Henson, was the only person working full-time on the project. Additionally, according to this article, the group received just $2000 for the upkeep of the project before the Heartbleed incident.

Overworked maintainers & understaffed projects are the foundations that open source and, thereby, most of your daily drivers are built on.

Why is it MY problem?

I often envision the open source model as a seesaw. That analogy is me dumbing it down because I am still navigating this ecosystem as we speak, and I have a lot to learn!

But if you stick with the analogy, you'll notice that it does play out well from a visualization perspective.

Assume we have the consumers on one side & the maintainers on the other side of the seesaw. It is idealistic to assume that we started at an equilibrium.

However, even if we did, we are currently in a situation where project maintainers are now staring at a massive imbalance with

• More customized demands due to every consumer working off their respective fork.
• Lack of contributors to help with the incoming volume of requests
• Lack of commensurate support and compensation from companies that employ the maintainers and contributors
• Eventual burnout

When that snowballs, it is only human to want to step away. After all, despite loving what they do, there's only so much a person can give before their vessel is empty.

Where does that leave us as an industry? Lesser collaboration, a slowdown in innovation, and a lot of paywalled software. None of the things that we take for granted today will continue to exist.

This may sound a bit dramatic, but it's every bit true as an eventuality if the current situation continues.

The way ahead

In 2021, I wrote a piece for Container Solutions about how corporate open source consumers could be better citizens days before the log4shell vulnerability was discovered. It's been more than a year, yet most of the measures I suggested then are still relevant today.

When I wrote that article, Open Source Program Offices (or OSPOs) had just begun appearing on my radar. I want to attribute that to my lack of knowledge and awareness of the goings-on within the ecosystem.

But I'd also be the first to admit today that there's been quiet a bit of traction in adopting OSPOs across the industry since then. So that's probably one of the things I'd recommend learning more about in the context of your organization if I were to write the article today.

But to sum it all up, Floor Drees, Staff Community Program Manager at Aiven, states it more beautifully than I ever could in this TNS piece,

"Discussions around the sustainability of open source are hard, but they’re necessary. FOSS is ubiquitous, it’s omnipresent, yet we’re still struggling to live with open source in a healthy, safe, and productive way.

As Floor noted, we need to understand the risks and then help open source, well, help open source.