In a recent working session with the leadership team of a large European services group, a senior product executive said something I did not expect from a company whose revenue leans – among other things in the stack – on proprietary software: “a pure piece of software is no more an advantage. You can build it with agents.”
Nobody in the room disagreed. And the sentence, which would have sounded like provocation just two years ago, now reads like mundane accounting and is welcomed with a series of nods. But what follows if we take this seriously?
A strategy that used to be a luxury
Twenty years before the AI technological shift that is making the pattern urgent now, Joel Spolsky, in “Strategy Letter V” (2002), gave the pattern its clearest formulation: smart companies work to commoditize their products’ complements. When the complement of your product gets cheap, demand for your product grows. That was a time when commoditizing a complement often meant paying an army of engineers to write software you would then give away. What was, back then, a strategy for those who could burn capital is now everyone’s strategic playbook. Gwern’s “Laws of Tech: Commoditize Your Complement” (2018) remains the most systematic modern treatment of the pattern.
The industrial implementation arrived six years later. When Google released Android (2008), the open-source project was the most visible half of the move: the other half was the compatibility test suite and the anti-fragmentation agreement, which decided who could call their device compatible and, through that, who got access to the proprietary services layer where, not accidentally, the real money lived for Google (search, play and more). The strategic architecture was: open the grammar of the ecosystem, keep the engine closed and govern the gate between the two. Certification was the hinge of the whole architecture.
For two decades this remained a hyperscaler’s play, because developing software in order to give it away was among the most expensive of the strategies.
What survives when code stops being scarce
If any competitor can generate a plausible copy of your product’s software layers in months, the strategic question on your table inverts the default of the last twenty years. For years we have been used to building proprietary software and defending it; now the strategic challenge is to understand what cannot be easily generated and still conserves a non-commoditizable advantage.
Sangeet Paul Choudary has given the general form of this question its clearest recent statement: strategy is organized around scarcity, and when technology changes what is scarce, it changes where power, advantage, and value can accumulate. His example is Hollywood, which read streaming just as a new channel for the same content and missed that what had actually been destroyed was the scarcity of the prime-time slot. Once thousands of titles could coexist without competing for Thursday at nine, narrower genres became viable, serialization replaced the self-contained episode, and the bargaining power of talent moved. Read that way, the useful question in front of an incumbent today is: what is the new scarcity now that software is not? And how does it change the landscape? From my practice at Boundaryless, it seems that, remarkably across industries, three legs may survive the collapse.
The first is the physical and institutional layer: all assets that exist in the world rather than in a github repo. A logistics network built over decades, an operation that carries regulatory accountability, contractual relationships with thousands of counterparties, licenses and certifications that take years to earn. No agent can generate these, and their value as anchors of competitive advantage rises as everything around them becomes faster to copy.
The second is everything that accumulates value differentiation through use and adoption. At Boundaryless, we have characterized them as flywheels as they have a self-reinforcing nature. First, there are what we call Technical Defensibility Flywheels (TDF): flywheels that are rooted in technological adoption – here the idea is to create mechanisms that improve the technology solution through usage, or data capture mechanisms that provide advantages for optimization, spotting issues, or similar value drivers based on accumulating data. On the other hand, Core Network Effects Flywheels are the two basic core flywheels tied to the nature of the network, both direct (as in social/communication networks) or indirect (as in marketplaces), growing with the growth of the accounts, integrations, partners, and developers who build on top of your product’s interfaces. Ultimately, there are the Core Defensibility Flywheels: the traditional reinforcing flywheels of economies of scale (spreading fixed costs) and brand. All of them are produced by having run the product, which is exactly what a competitor copying your software does not inherit. The Android precedent shows all three working together: many tried to fork the open-source project, but none of them ever rebuilt the unique Google attraction, brand, and services layer. That layer was never code to be copied.
The third leg is at the core of this newsletter’s thesis: ontologies and published languages have become essential for strategic positioning. In a market where software agents increasingly do the composing, the shared language through which an ecosystem describes offerings, contracts, and data becomes the coordination substrate itself, and whoever shapes the grammar shapes the market. As I had the chance to say in the first issue of this newsletter, I believe that the productive logic of AI selects for commons at the language layer, but open grammars can support proprietary engines of value.
The engineering literature has been converging on the same point from the other side. Unmesh Joshi recently argued that language models become reliable collaborators when they work through a domain-specific language rather than against open-ended natural language: the narrower the surface, the smaller the space of syntactically valid but meaningless output, and the less room the model has to hallucinate. The enduring asset is the semantic model, the generated code is a disposable projection of something much more durable: a grammar accepted by an ecosystem raises significance from a single codebase to a whole market.
When we speak of opening up language, we also need to take extra care to understand its various facets: in one of my current engagements, when we went looking for the “language” to open, we found, in reality, a stack of elements spanning four different aspects. What the organization first framed as a semantics layer was in reality a fused set of things:
the grammar itself (the schemas, the vocabulary, the published specifications),
the intelligence that runs on it and can deliver value (correlation, derivation, the compounding that improves with volume),
the actual transactional machinery (execution, billing, settlement),
and the layer of trust (consent, identity, provenance).
Only the first is a candidate for the Commons: the second and third can be a monetization engine on top of the open core, and the fourth is the expensive, institutional element that cuts across both and can represent a substantial advantage to protect.
Without understanding how the full stack is made, “open the language” may be a costly error. Finding the careful cut around your non-commoditizable advantage is the first concrete act of the open-core move.
The fear in the room
Every sane, vertically integrated company would – at this point – raise the same objection: we earn most of our money with the integrated service, so cracking it open looks like voluntary cannibalism, and the open core strategy appears to give part of the margin away.
First: nobody touches the installed base and full-stack offering. Customers who buy the integrated offer would likely keep buying it because they pay for the end-to-end experience and the accountability that, when something breaks, means you will be there to answer. Opening the commodity layer does not change their calculus. Open core aims at disrupting the market you do not yet have access to: for example, the long tail of smaller customers no direct sales force reaches viably, the one customer that has a part of the stack and will not change to yours for any reason, those small competitors which compose their own solutions and are struggling to invest in innovation and would leverage someone else’s platform.
The second: the defense is already mandatory. If AI has commoditized your software layer, someone is likely already building a software-native attack on your margin, from the top, with a cost base that assumes code is nearly free. The commoditization proceeds with or without the incumbent. Becoming the one that embraces and creates the open stack not only buys you the ability to set its terms, but would also powerfully commoditize any attacker’s move that only makes cheap software.
Where the profits go
Clayton Christensen, in The Innovator’s Solution (2003), formulated what he called the law of conservation of attractive profits: when a layer of the value chain commoditizes and attractive profits disappear from it, the opportunity for attractive profits emerges at an adjacent stage, wherever the new bottleneck demands integration. Profits do not evaporate. They migrate toward whoever re-bundles in the right place.
Apply the law to the open-core architecture: if the software layer commoditizes, value re-pools in the stages code cannot generate and where, ideally, you have a defensible control point:
a quality assurance layer,
accountable outputs depending on some form of capital-intensive capabilities (logistics, research, and the like),
a form of network effects on brand or scale,
a liquid aggregated network where you have brought in partners or where service providers meet demand,
some form of certification of compatibility with the open layer.
In the case of Android, it was largely Google Search.
The pattern is not confined to software companies, which is what makes it interesting for industrial incumbents. Tesla opened its patents in 2014 and, in 2022, published its charging connector as the North American Charging Standard; when Ford and General Motors adopted it in 2023, SAE (Society of Automotive Engineers) standardized it within months and most of the industry followed. Tesla gave away the grammar of charging and kept the engine: the Supercharger network, the capital-intensive physical asset that no published specification can copy, plus the position of having defined the interface everyone else now builds against.
You need a portfolio capability to recapture value
This migration of profits is also why open-core strategies only work for companies that sport a portfolio strategy, and here the argument connects to everything this newsletter has said about composability. Unbundling and rebundling are two halves of one movement, but they are visible from different altitudes. Opening part of a value proposition requires a recapture capability that often happens at an adjacent layer. Re-pooling profits may sit in another unit, end up in another P&L, and may require a capability that is currently running as a cost center (because it was previously fully integrated and nobody cared about separating it and making it autonomous), or you to make an acquisition nobody in the product room has yet connected to the move.
A company that opens up without a portfolio capability is making half the move: it gives away the commodity and lets the re-pooling happen by accident, possibly by someone else. The deliberate dance between decoupling for exploration and recoupling for coherence and profit capture is what we described in “The Four Archetypes of Platform Organizations” and, seen from here, is the mechanism by which the conserved profits get caught.
So in a few words: re-capture is an organizational capability, and, sadly, most incumbents do not have the muscles it runs on.
Such a capability to hunt and recapture adjacent profits looks increasingly more like a venture partner than a well-managed internal product manager: migrated profits often reappear as opportunity-driven deals before they become a generalizable market for a product, and they typically graduate along a path from project to repeatable solution. In this context, the ability to quickly stand small, accountable teams on emergent opportunities that can compose existing organizational capabilities is key, and it needs to sit on top of quick-to-use contractual frameworks that can get all the parties involved.
External partners, investors, and other platform elements need to be mobilized quickly: all internal teams and nodes must expose clear service catalogs (starting from core platform capabilities), and the company should not have to go back to the lawyer drawer every time a joint venture or a revenue-sharing agreement needs to be drafted. Connecting the edge (the market) back into the platform core needs to be easy: origination, pods, graduation, payback. Rinse and repeat.
Building the flywheels requires internal connectivity
In this process of recapturing value through control points, often through flywheels, these core differentiating properties are also rarely easy to use, latent and waiting to be discovered. Building flywheels, for example, often requires crossing organizational boundaries, and they spin only if the agreements make it worth feeding for everybody involved. Without easy-to-outline collaborations, building the chains of capabilities needed to differentiate the customer experience hardly materializes. This also makes something the Android case teaches very clear: Google was ready with its core defensible and value-added services before it open-sourced the system; the complements existed before the core opened.
An incumbent adopting the open-core architecture must build its monetizable complements right before conceding the software margin. Opening a layer while the adjacent pools are still hypothetical or (possibly, even resisting the change because the other units do not see their slice of the cake) makes it impossible to go through such a market-reshaping path.
An ambitious strategy requires an organization where nodes can conspire, connect, and collaborate.
Three tensions that are not easy to close
The first is whether the gate to joining the open ecosystem is priced or given away: in the Android model, the certification and assets are free, and the monetization happens downstream, in services; an industrial incumbent that wants to protect real margins on an integrated offer may have the instinct to run the other way. One of the most convincing resolutions I have seen emerging from my collaborations came from my friends at Bosch MPS. It reframed the question of monetizing a portfolio through a lens based on a four-lever pricing grammar that also mimics how business model evolution is happening in the market: from Access, to Usage, from Transaction, to Outcomes (they call it the AUTO framework). In such a frame, the open language and the open core of the offering may simply be the access lever: you do not price the access – because it is what carries counterparties into the ecosystem – but then the pricing needs to concentrate on the levers above it. Whether that discipline holds when the quarterly pressure arrives is, to me, still an open empirical question.
Second, who pays for maintaining the access layer? The grammar and the open core? These Commons are living: they rot without curation, drift without governance, and fragment without someone doing the unglamorous institutional labor of keeping it coherent. Elinor Ostrom (1990) gave us design principles for governing commons of the physical kind; whether they transfer to semantic commons, and who funds the stewardship when the beneficiaries include your partners (they may have slightly different ideas) and potentially your competitors (!!), is a question I am now directly experiencing in building the O2A (Open Organization Alliance) with the first partners peeking in to cooperate on the development of the standard.
Bill Gurley, reading the same move from the venture side, makes the governance question concrete: whoever referees the standard decides whom the openness pays off for. Google could keep the Open Handset Alliance under its own roof for two reasons: its money sat in search advertising, a layer no handset maker could occupy, and the partners it recruited were challengers rather than peers, who accept asymmetric terms because they have no position to protect. Kubernetes had neither condition, and a standard aimed at Amazon is worth nothing unless Amazon can trust it, so Google gave it to a foundation. Abiding by a referee is the price of getting your equals to adopt. If your first adopters are smaller than you and your revenue sits where they cannot reach, you may not have to pay it.
The case for going first
The growing importance of open-core strategies in the market introduces tensions, of course, and a reader sitting on an incumbent’s strategy board could take them as an argument for waiting. I read them otherwise, rather as a driver for acting.
The opening of the layer is not a decision sitting on your table. The commoditization of the software tier proceeds on its own schedule, and the grammar of your industry will be written by somebody: a challenger with a cost base that assumes code is free, a consortium, a regulator, or a hyperscaler that would like your sector as a tenant. What is actually on your table is whether that grammar carries your assumptions: whoever publishes first decides which data model everyone else translates into, and which behaviors sit inside the standard rather than bolted onto it afterward.
One of my preferred writers, Matt Brown, once said that “Your data model is your destiny” (2025), so the question is: do you want to take the chance of authoring it first and get your ecosystem to converge?
Furthermore, an incumbent brings to this move a set of things a software-native challenger cannot generate on demand: the three legs above. A challenger who opens a competing grammar has to earn all of it after the fact, in public, while you start with a window in which you can choose the sequence, build the complements first, and concede the open layer second.
None of this dissolves the tensions; rather, it turns them from reasons to hesitate into the content of the work: what to price and what to give, who stewards the grammar and on whose money, and how to adapt your operating model to capture the layers above. All that is difficult, certainly more difficult than sitting there waiting to see how the layer opens without you and what roles remain available then.
Curated Links
From Open Source Software to Open Source Strategy
Six cases of open source moves ended up in coalitions rather than being run by single firms, and the governance question underneath all of them.
Intelligence wants to be free.
An economist’s version of this issue’s opening claim: models have stopped being the defensible product, and what stays defensible sits in harnesses, domain data, verification, and expertise.
DSLs Enable Reliable Use of LLMs
An engineering case for the third leg: constrain the language and the model stops hallucinating, and the semantic model outlasts every line of code generated from it. This is exactly why we believe O2A is part of a DSL for organizational development and operability: a machine-readable structure (aka minimum viable structure), and this piece shows you why at the level of code.
Agentic AI, Harness Engineering and Organisational Architecture
The cleanest available statement that the harness is not where value sits: contracts, offerings, and node definitions are the coherent substrate agents need, and no amount of harness engineering compensates for their absence.
Meta-Design: A Capability Gap Emerging from Our Work
This field guide names the capability that context interfaces demand: designing the constraints within which machine systems enter human situations, rather than scripting the interactions themselves. It is the most concrete articulation I’ve seen of the move from process design to context design - an essential capability as context becomes a key organizational attractor. The distinction between finite pre-authored interaction and generative constraint-based structure is unfolding.
Scarcity and strategy - Misreading AI the way Hollywood misread streaming
A caution against reading AI’s economics through the wrong analogy: Hollywood misjudged streaming by mistaking where scarcity and value would relocate, and the piece argues we risk the same error with AI.
Callbacks
Check back on TTB 5, “Modularity, Recombination & What Comes Next” for the recombination economics this piece builds on; and TTB 1 for my research question number 5 (“What should be common and what proprietary?”); also, check “The Four Archetypes of Platform Organizations” on the Boundaryless blog, for better understanding the dance between the decoupling and recoupling cycle that happens through platform and portfolio strategies - a key argument of the piece.
Work Updates
We’re about to release the first official update to the O2A (Open Organization Alliance), based on learnings we’ve gained from working with some of our customers lately, especially a Fortune 500 organization and a pioneering Social Enterprise Group. The latest weeks brought some insights on how offerings can compose in solutions (in different ways), and how the offering nature concept carries the dependencies that constitute a portfolio’s taxonomy: for example, by declaring that if you sell an (offering nature) platform, any (offering nature) extension has a dependency as a prerequisite. We believe that the O2A is shaping up to provide a good basis for companies that need a ready abstraction of what Dorsey called a “company world model”: why reinvent it if you have it ready to use?
This is where the “open grammar” half of this piece’s argument lives in practice: a shared, open language for describing an organization’s units, contracts, offerings, and value flows. Check out the current release in the meantime!
What to do next?
If you are living a version of this strategic challenge, with a software-driven upstart peeking at commoditizing part of your business, or working to shape an ecosystem with a huge number of partners, and you are arguing internally to decide what to open and what to defend, I would genuinely be interested in working on this with you.
One question: if code is no longer scarce, does scarcity really move to physical or accumulated assets, or to the ability to make those assets *count*? Infrastructure, data, network effects and even standards don’t become strategic on their own. What feels (and will feel, hopefully) genuinely scarce is the institutional capacity to produce meaning, legitimacy and coordination around them to get an ecosystem to agree on what matters, what things mean, and ultimately how the game is played.