There is no single definition of success in open source projects.
Everyone loves open source these days. Microsoft just released its 3D Movie Maker software under an open source license. Spotify has released a whole bunch of projects and to which it contributes, and has just announced a fund to support project managers. There’s even game engine code from the Middle Ages (1998) being open source†
SEE: Hiring Kit: Back-end Developer (Tech Republic Premium)
Of these projects, and millions of others available, it’s a fair question to ask…why? Or rather: why are the vast majority of these projects important, and for whom? After all, most projects will never be there Kubernetes†
However, after more than two decades in open source, I’m starting to realize this is the wrong question.
The example of Firecracker
Take Firecracker, an open-source microvirtualization project that AWS released in 2018† Firecracker was almost universal praised as cool technology… and then largely disappeared from view. l wrote about early success in the communitybut even that (Weaving Ignite to improve the ease of use of Firecracker among other things) came from a close AWS partner. To give Firecracker more community power, I suggested that: AWS follows Google and opens firecracker governancenot just the code.
AWS wasn’t listening, but, not for the first time, my opinion didn’t seem to matter. (That’s a polite way of saying I was wrong.)
Fast forward to 2022, and Firecracker is quietly getting used to a lot of cool places. I say “quiet” because, well, why would anyone be shouting their infrastructure from the rooftops? But when I earlysome interesting users came up like Stripe† fly.io† System Initiative and Lake† Of course it is still true that most contributors to Firecracker are employed by AWS.
But even if Firecracker had remained a community of one (AWS), arguably it would have been worth it. In fact, that’s essentially what I claimed when I worked for AWS, indicating that there were clear customer-centric reasons for open source Firecrackerregardless of community involvement. Open source allowed Firecracker to play well with the Linux community and provided tighter “composite product gains” for customers.
Millions of fireworks
Now play this Firecracker example times the over a hundred million GitHub (and other open source) repositories. It’s not about being the next Kubernetes. Any open source project is about meeting the needs of the individual developer, a company or a wider community.
Sometimes those needs can be great. In a conversation I had with Lyft engineering lead and Envoy founder Matt Kleinhe emphasized, “For most people who make something open source, it’s actually a net negative” because “if they don’t invest in it, if they don’t do all these things [like PR, marketing, and hiring], they’re just going to throw something over the wall.” For Klein, getting significant, industry-wide involvement with Envoy helped make the project worth the investment he (and by extension, Lyft) made.
SEE: 40+ Open Source and Linux Terms You Should Know (Tech Republic Premium)
But maybe not everyone needs to get that kind of return. In Firecracker’s case, it would have been enough to make the code open source and only allow clients to collaborate, as I reasoned. For Google, on the other hand, which was arguably trying to advance a multicloud reality through Kubernetes, it had to go big. Every project has different needs and different measures of success.
So you’re not the next Kubernetes? That’s fine. Aren’t you the next Firecracker too? Also fine. For open source developers, the key is to find out what a healthy project means for your specific needs, and not get distracted by others’ definitions of success.
Disclosure: I work for MongoDB, but the views expressed herein are mine†
