The dirty little secret of open source contributions

“Nobody cares if you contribute.” That’s what a Postgres friend said to me during lunch at KubeCon when I suggested that hiring Postgres contributors could be a selling point for customers. His comment surprised me because for years I’ve believed the open source dogma that contributions somehow qualified developers and vendors to disproportionately profit from projects. This, despite the overwhelming evidence to the contrary.

For example, no one has benefited more from open source than AWS but, relatively speaking, no one has contributed less. AWS has started to change, which I’ve celebrated. But after talking to my friend, I now wonder whether it matters at all. It may make employees feel better that their employer “gives back,” but it doesn’t seem to make the slightest difference to customers. Mostly. It’s worth talking about that “mostly.”

Make it easy

AWS has long billed itself as the best place to run open source software, and its customer success seems to support that statement. Open source has been central to AWS’ rise for nearly 20 years. Indeed, when I used to manage AWS’ open source strategy and marketing team, we ran a survey to uncover what customers cared about most in open source. Was it contributions or something else? Contributions made the list, but the number one determinant of open source “leadership,” according to developer respondents, was making it “easy to deploy my preferred open source software in the cloud.”

AWS

Enterprises, in other words, have a limited amount of time; they prefer vendors who remove the burden of managing their own open source software deployments, regardless of whether those same vendors are active contributors to the projects in question. This particular survey didn’t involve AWS customers and, indeed, I’m sure the results would be the same if you asked developers that use Microsoft Azure, Google Cloud, or any other cloud service. As much as you or I may think contributions to open source matter, customers just want to get stuff done as quickly as possible, for the lowest cost.

And yet there’s still an argument to be made for contributing to open source projects.

Contributions are part of the product

Back to my Postgres friend. Although he said customers may not care that so-and-so maintainer works for his company, having key contributors does enable his company to deliver excellent support to customers. In a community-run project such as Postgres or Linux, that doesn’t mean a particular employer gets to dictate road map, accelerate bug fixes, etc., but it does mean that they influence the road map. More importantly, it means they understand the code and the community around it and are thus better positioned to know how to weave short-term customer fixes into the main project without taking on technical debt. It also means, more simply, that they understand how to support a customer’s use of the code because they know that code intimately, in ways an interloping outsider simply doesn’t.

Additionally, though this happens rarely, should a company see a need to fork the project for long-term customer welfare, having core contributors and maintainers positions them to succeed with a fork. This is one reason AWS has a much greater chance of success with the Redis fork, Valkey. AWS has long employed one of Redis’ core maintainers, Madelyn Olson. Again, forks rarely happen, but contributing to an open source project is a solid insurance policy for a vendor’s customers. Is this something to market to customers? No. It’s behind-the-scenes work that ultimately creates a better product, but “we contribute” isn’t a product feature.