Why your open-source project definitely should not be the next Kubernetes

There is no one-size-fits-all definition of success in open-source projects.

Everyone is into open source these days. Microsoft just released its 3D Movie Maker software under an open source license. Spotify has a slew of projects it has released and to which it contributes, and just announced a fund to support maintainers of projects. There’s even game engine code from the Middle Ages (1998) being open sourced.

SEE: Hiring kit: Back-end Developer (TechRepublic Premium)

With these projects, and millions of others available, it’s a fair question to ask … why? Or rather, why do the vast majority of these projects matter, and to whom? Most projects, after all, are never going to be Kubernetes.

After more than two decades in open source, however, I’m starting to realize this is the wrong question.

The Firecracker example

Take Firecracker, an open-source, micro-virtualization project that AWS released in 2018. Firecracker was almost universally hailed as cool technology … and then mostly disappeared from public view. I wrote about some early community success, but even that (Weave Ignite to improve Firecracker’s ease-of-use, among other things) came from a close AWS partner. To give Firecracker more community heft, I suggested that AWS follow Google and open up governance around Firecracker, not just its code.

AWS didn’t listen but, not for the first time, my opinion didn’t seem to matter. (That’s a polite way of saying maybe I was wrong.)

Fast forward to 2022, and Firecracker is quietly getting used in lots of cool places. I say “quietly” because, well, why would anyone shout their infrastructure from the rooftops? But when I asked, some interesting users surfaced, like Stripe, Fly.io, System Initiative and more. Of course, it’s still true that most contributors to Firecracker are employed by AWS.

But even if Firecracker would have remained a community of one (AWS), it arguably would have been worth it. In fact, that’s essentially what I argued while I worked for AWS, indicating that there were clear customer-oriented reasons to open-source Firecracker, regardless of community involvement. Open source ensured Firecracker would play nicely with the Linux community and enabled tighter “compounded product gains” for customers.

Millions of Firecrackers

Now play out this Firecracker example times the hundred million-plus GitHub (and other open source) repositories. It’s not about being the next Kubernetes. For each open-source project, it’s about meeting the needs of the individual developer, a company or a broader community.

Sometimes those needs might be big. In a conversation I had with Lyft engineering lead and Envoy founder Matt Klein, he stressed that, “For most people who open source something, it’s actually a net negative” because “if they don’t invest in it, if they don’t do all of these things [like PR, marketing, and hiring], they’re just going to throw something over the wall.” For Klein, getting significant, industry-wide involvement in Envoy helped make the project worth the investment he (and, by extension, Lyft) had made.

SEE: 40+ open source and Linux terms you need to know (TechRepublic Premium)

But arguably not everyone needs to get that sort of return. In the case of Firecracker, open sourcing the code and just having customers collaborate would have been enough, as I reasoned. For Google, by contrast, which was arguably trying to advance a multicloud reality through Kubernetes, it had to go big. Every project will have different needs and different measures of success.

So you’re not the next Kubernetes? That’s fine. Nor are you the next Firecracker? Also fine. For open source developers, the key is to figure out what a healthy project means for your particular needs, and not get distracted by others’ definitions of success.

Disclosure: I work for MongoDB but the views expressed herein are mine.