Most code in use today is open source. Recent surveys put it at 95% of new code. Despite that, most companies that use open source do not have a strategy for it — and most Open Source Program Offices (OSPOs) are scoped as compliance functions. The result is predictable: the OSPO is treated as a cost center, the open source work generates no measurable financial benefit, and the company's open source posture remains tactical even when its dependence on open source is total.
The fix is not more compliance. It is connecting open source activity to the company's revenue model. Unless the OSPO can name specific metrics that show how the company financially benefits from its open source participation, the rest of the organization will continue to treat open source as overhead, no matter how well-run the compliance program is.
What Open Source Actually Does for a Business
Open source produces five plausible business outcomes: it provides a platform that lets engineering focus on differentiating work; it reduces vendor lock-in and the long-term risks that come with it; it generates mindshare and developer-marketing leverage; it makes recruiting and retention of senior engineers significantly easier; and it lowers the marginal cost of delivering many products and services. Each of these is real. None of them is automatic.
The question for any company is which of these outcomes it is actually trying to capture, and which metrics will show whether it is succeeding. A company that says "we participate in open source to attract talent" should be measuring offer-acceptance rates among senior developers and tracking which contributors convert to employees. A company that says "we use open source to commoditize our complements" should be tracking whether the strategy is moving margins in the products that benefit from the commoditization. Strategy without metrics is mood music.
The Maturity Question
Corporate open source engagement falls into roughly four levels. Level 0 is unmanaged use — the company depends on open source but doesn't know how much, where, or under what terms. Level 1 is compliance: the company has license review, supply-chain controls, and a basic SBOM practice. Level 2 is contribution: the company contributes back, usually starting with bug fixes and ergonomic improvements to projects it depends on. Level 3 is strategic: the company uses open source as a deliberate part of its IP and product portfolio, often shaping or stewarding projects that matter to its business.
Most companies stall between Levels 1 and 2. The reason is not technical. The reason is that the transition requires the open source program to make a financial case that justifies the headcount and time required to contribute, rather than just consume. That case is not impossible to make — but it cannot be made by an OSPO scoped only to compliance.
Five Models for Open Source Revenue
Companies that successfully build commercial businesses on or around open source generally use one of five models, often in combination.
The Ketchup Model monetizes brand and quality control around an otherwise-commodity open source product. Red Hat is the canonical example: the source code is freely available, but enterprises pay for Red Hat's brand, support, and assurance.
The Dual License Model offers the same software under both an open source license (typically a strong copyleft like the GPL or AGPL) and a commercial license. Customers who do not want the obligations of the copyleft license pay for the commercial one. MySQL, MongoDB, and MinIO have all used variants of this model. It is effective at extracting revenue but fragile in its relationship with the surrounding community, because the structure positions the company as the only participant who can convert contributions into proprietary revenue.
The Proprietary Crust Model (often called "open core") keeps a base of open source software and layers proprietary features on top — typically the features enterprises pay for, like access controls, SSO, audit logging, and high-availability tooling. Redis Labs and GitLab have both used variants of this model.
The Infrastructure Model monetizes the operation of open source software rather than the software itself. AWS-managed databases and Confluent Cloud are infrastructure-model businesses: the customer pays for the running, not the bits. This is the most economically attractive model for most software because SaaS revenue is recurring and predictable, but it requires the company to actually run infrastructure well — which is itself a substantial business.
The Adjacency Model sells products or services that complement the open source software without directly monetizing it. Hardware companies that ship open source-based platforms (Arista with Linux-based switches), service companies built on open source ecosystems, and any business deliberately commoditizing its complements via open source are using this model. Joel Spolsky's "commoditize your complements" essay is the canonical statement of the strategic logic.
Most successful open source companies use parts of more than one of these. The point is not to pick a model and adhere to it doctrinally; the point is to be able to articulate which model the company is using, what it is monetizing, and why customers are willing to pay for that thing rather than the parts that are free.
Your Code Is Not Your Differentiator
The single most useful exercise for any company building on open source is to identify, honestly, which parts of its product actually drive purchase decisions. The answer is rarely "all of it." Most products are 80% commodity and 20% differentiating, and the 20% is usually closer to product, brand, distribution, data, or ecosystem than to any specific code.
Once a company can name what actually drives sales, the open source strategy follows. Differentiating components get protective treatment — proprietary code, patents where appropriate, contractual constraints. Commodity components get cooperative treatment — open source contribution, shared maintenance with peers, deliberate use of upstream projects to lower the cost of running the parts of the system that don't drive growth. The companies that get this wrong are usually the ones treating commodity infrastructure as if it were differentiating IP, which costs them in maintenance burden, recruiting, and ecosystem leverage without producing any revenue benefit. This is not a philosophical question about openness. It is a question about where a company's competitive moat actually lives, and whether its software development practices are aligned with that.
Working With Process Mechanics
Most of my open source work falls into one of three buckets: helping companies design open source strategies that connect to revenue rather than only to compliance; advising on license selection, conflict resolution, and the harder questions in modern open source (model licenses, source-available licenses, network reciprocity, foundation governance); and counsel on contribution policy, foundation participation, and the questions that arise when a company's open source posture starts mattering externally.
For day-to-day OSPO operations — license clearance, vulnerability response, SBOM practice, contribution review — see OSPOCO, the OSPO-as-a-service practice I run with a team that handles the operational side at scale.