Open Source Thrives on Contribution, Not Just Consumption
Open source gives freely, but it thrives when users give back. True “open source companies” contribute time, code or care that keep the tools we all depend on strong and sustainable.
Open source is a gift—an open invitation to build on the shoulders of those who came before. It's not free labor. It's not a feature. And it’s not a marketing angle. Companies are welcome to use open source freely, and many do. But when open source becomes an essential part of your business, there’s a degree of responsibility to help sustain what you depend on. A company like CIQ, that supports open source, gives back not just for itself, but for its customers—so they can build with confidence, knowing that the projects they rely on are being cared for.
That doesn’t always mean writing code. It could mean improving documentation, strengthening project governance, or simply showing up and listening. The key is intention: active, consistent engagement that strengthens the community for everyone. I’ve seen firsthand, from my work with cloud giants to startups, what happens when companies rely heavily on open source without contributing back. Eventually, cracks form: trust erodes, critical projects stagnate, and teams are left firefighting issues that could have been prevented with earlier, thoughtful engagement upstream.
This is what I’m passionate about, and this is why CIQ brought me on, to ensure that CIQ is a best-in-class partner with open source.
Why OSPOs Matter (When Done Right)
A structured approach to keeping companies engaged and accountable is through the creation of a well-designed Open Source Program Office (OSPO). For those unfamiliar with the concept, it might sound bureaucratic. But it doesn’t have to be. At its best, an OSPO is the connective tissue between internal engineering efforts and the upstream open source communities those efforts rely on.
The work spans multiple areas—license compliance, community engagement, project health, internal education, and tooling. Some companies see OSPOs as policy-focused, others more on the engineering side. Ideally, it’s both. In my own work, I’ve seen how valuable it is to have upstream contributors embedded directly in the OSPO. It’s a model that allows technical and policy conversations to inform each other, rather than operating in isolation.
When OSPOs are done right, they also serve as an advocate for the community inside the company—ensuring that open source dependencies are maintained, that contributions aren’t delayed by internal bottlenecks, and that engineering teams have what they need to work productively with external collaborators. This creates a positive cycle: the more companies invest upstream, the more resilient the projects become, and the more value customers and developers alike can realize.
Project Health Requires Intention
One of the less visible, but absolutely necessary, parts of this work is understanding project health. That means looking beyond surface-level metrics like GitHub stars or commit counts. Are issues being addressed? Is there a bus factor? Are contributions spread across organizations or centralized around a single vendor? Are releases predictable and well-maintained?
To answer these questions, CIQ OSPO has been standing up tools that provide open source analytics and project health data. These setups aren’t turnkey. They require a fair amount of configuration and ongoing attention. But they help us identify where help is needed and, just as importantly, where things are going well and don’t require attention at the moment.
The truth is, you can’t support what you don’t understand. The Peter Drucker quote I saw repeatedly during the emergence of DevOps still resonates today: “You can't manage what you don't measure.” Companies that invest a little time up front in understanding project health are rewarded with more resilient infrastructure later—helping avoid surprises for themselves and their customers.
Contributing Beyond Code
Contribution takes many forms. Yes, code is part of it. But it’s only part. I’ve worked with teams whose primary contributions were infrastructure, documentation, release engineering or security processes. Those things don’t get as much attention, but they often have more impact.
Recently, we had to build a tool to help manage and publish software security artifacts for a project. That’s not a typical “product feature,” but it matters to the health of the ecosystem. It helps everyone downstream. When companies are willing to take on that kind of work—not because it drives revenue, but because it’s the right thing to do—the entire open source landscape becomes stronger. These are invaluable contributions that help all adopters focus on innovation rather than maintenance worries.
Where Things Get Messy: Licensing and AI
One of the most concerning shifts I’ve seen lately involves licensing changes and how companies communicate (or fail to communicate) them. Recently, when a popular key-value store moved to a source-available license, it created real confusion. I’ve talked to engineers who didn’t even realize the change had happened—months after it went into effect.
That’s a problem. If you’re building infrastructure that developers rely on and you make a major change to your licensing model, it’s your responsibility to communicate that clearly. Not just in legal notices, changelogs or blogs, but in ways that people who use your software every day will actually see.
(Side note: This is why the Kubernetes project has a Contributor Communications team: The project is massive, and the communication team plays a vital role in informing the contributor community and end users about significant changes from all the work happening. I just did a talk on this at KubeCon EU London with the Comms team’s tech lead talking about how we formed, a historical event that proved our worth, and how and why we manage social media the way we do.)
The emergence of generative AI tools has only made the issue of licensing transparency more complicated. When these tools generate code based on training data scraped from public repositories with varying licenses, there’s often no clear path to understanding where the output came from—or how it should be licensed. For those of us responsible for license compliance, that’s a genuine concern—one that’s not going away anytime soon. The open source community must navigate this one together.
The Community Comes First—And That’s the Point
Ultimately, the open source work that matters most isn’t always the work that’s easiest to measure. It’s not always high-visibility. It rarely fits neatly into a sprint.
But if you build on open source, you have a responsibility to the communities making that software possible. That means investing time. It means showing up consistently. It means treating maintainers and contributors as collaborators—not as an extension of your dev team, and definitely not as a marketing bullet point.
An “open source company” makes those investments so that its customers can move faster and innovate more freely, knowing that the projects they depend on are strong, stable and well-supported.
You don’t have to solve every upstream problem. But engaging meaningfully—giving back where you can—ensures that open source remains something all of us can depend on, not just today, but for years to come.
