Who does the unsexy but essential work for open source?

Walk into any developer conference and you’ll see a predictable parade of laptop stickers: the cloud-native darlings, the hip new database, the obligatory mascot or two. It’s the developer variation of virtue signalling or calling out one’s tribe. What you won’t see—at least not often—are the logos of the companies that quietly push more code than many of those sticker-friendly startups combined.

That invisibility isn’t accidental; these firms make their money elsewhere and treat open source contributions as foundational for their businesses, not marketing fodder. Yet their real-world impact is anything but quiet.

When the data upends the narrative

Consider the Linux kernel—something you and I use every single hour of every single day. Linux is the project we all depend upon and, perhaps because of that, the companies that stand behind it probably aren’t in your laptop sticker collection. Take Oracle, for example. (Disclosure: I work for Oracle.) In the 6.1 release cycle, Oracle emerged as the top contributor by lines of code changed across the entire kernel. We rightly recognize the Supabases and Neons of the database world for fostering their associated projects, but it’s Oracle that patches memory-management structures and shepherds block-device drivers for the Linux we all use.

Oracle’s kernel work isn’t a one-off either. A few releases earlier, the company topped the “core of the kernel” leaderboard in 5.18, and it hasn’t slowed down since, helping land the Maple Tree data structure and other performance boosters. Those patches power Oracle Cloud Infrastructure (OCI), of course, but they also speed up Ubuntu on your old ThinkPad. Self-interested contributions? Absolutely. Public benefit? Equally absolute.

This isn’t just an Oracle thing. When we widen the lens beyond Oracle, the pattern holds. In 2023, I wrote about Amazon’s “quiet open source revolution,” showing how AWS was suddenly everywhere in GitHub commit logs despite the company’s earlier reticence. (Disclosure: I used to run AWS’ open source strategy and marketing team.) Back in 2017, I argued that cloud vendors were open sourcing code as on-ramps to proprietary services rather than end-products. Both observations remain true, but they miss a larger point: Motives aside, the code flows and the community benefits.

If you care about outcomes, the motives don’t really matter. Or maybe they do: It’s far more sustainable to have companies contributing because it helps them deliver revenue than to contribute out of charity. The former is durable; the latter is not.

Why we misread the map

If these contributions are so large and so fundamentally critical to open source sustainability, why do we consistently overlook them?

They don’t sell stickers. Some companies use open source to drive developer mindshare, which can be essential to their marketing (if developers are a key constituency). But if you look at the Linux 6.15 kernel contributor list (as just one example), the top contributor, as measured by change sets, is Intel. Yes, Intel, President Trump’s latest punching bag. Trump doesn’t care about Intel’s Linux contributions, but you and I do. Another example: Take the last year of contributions to Kubernetes. Google (of course), Red Hat, Microsoft, VMware, and AWS all headline the list. Not because it’s sexy, but because they make billions of dollars selling Kubernetes services.

Their brands feel “proprietary.” Some companies (including mine) sell proprietary software, and so it’s easy to mentally bucket these vendors with license fees or closed cloud services. That bias makes it easy to ignore empirical contribution data, which indicates open source contributions on a grand scale.

Metrics rarely surface in headlines. A flashy keynote can eclipse a year’s worth of pull requests. Journalists and writers (including me) have been far quicker to cover a startup’s logo change than 10,000 lines of kernel housekeeping.

Self-interest is a feature, not a bug

Skeptics argue that corporate contributions somehow taint the purity of open source; they claim that “true” open source resides in some idyllic GitHub repo powered by freedom and love. That’s ridiculous, naive, and false. I’ve been pretty blunt in my criticism of free-riding mega-vendors, but discounting self-interested code is a mistake for two practical reasons, one of which I’ve already called out:

Sustainability: When contribution aligns with revenue, budgets survive bad quarters. Oracle optimizes Linux because every micro-percent of performance advantage lowers OCI’s cost of goods sold. That incentive doesn’t evaporate when the CFO tightens the belt. It’s the same instinct that has AWS increasingly contributing to Postgres: It helps them reduce technical debt and influence project direction.

Scale: Large vendors wield resources that community projects can’t match. The Ampere-based OCI contribution fills a gap that public clouds charge real money for. Kubernetes maintainers get free Arm capacity; developers everywhere get faster pull request workflows. Dig through the Cloud Native Computing Foundation’s contributor data for a wide variety of projects and one common theme emerges: The companies contributing are the bigger, cash-rich vendors. They have a vested interest in these projects, yes, but they also have the resources to invest.

In other words, enlightened self-interest underwrites the boring but vital work—CI hardware, security audits, long-term maintenance—that grassroots volunteers struggle to fund.

Recognizing the unseen builders

So, how should we recalibrate our appreciation?

Follow the commits, not the conferences. DevStats, kernel mailing-list stats, and GitHub’s API rarely lie. The charts routinely feature companies we never applaud on stage. (Well, except when these big companies buy keynote spots at developer events and we’re treated to cringeworthy, self-aggrandizing infomercials. But I digress.)

Reward the housekeeping. A 50-line bug fix in XFS may be less sexy than a new UI framework, but data durability trumps design trends when your payroll depends on it.

Embrace mixed motives. Purist litmus tests (“Is the entire product open source?”) ignore economic reality. The point isn’t sainthood; it’s sustainable, shared innovation. Every company (and really every developer) contributes out of some form of self-interest. That’s the rule, not the exception. Embrace it.

Going forward, we should expect to see even more counterintuitive contributor lists. Generative AI is turbocharging code generation, but someone still has to integrate those patches, write tests, and shepherd them upstream. The companies with the most to lose from brittle infrastructure—cloud providers, database vendors, silicon makers—will foot the bill. If history is a guide, they’ll do so quietly.

That leaves the rest of us with a choice: cling to an outdated narrative of lone-wolf hobbyists (a myth that has never been true or even reasonable) or widen the spotlight to include the enterprises that keep the servers humming. I’ll take the latter. Romance is nice; reliability is nicer.

So, the next time you apt-get, helm install, or docker run, odds are there’s a patch from an “invisible” vendor making that command succeed. You don’t have to love their business model to appreciate the code—but you definitely shouldn’t ignore it.