I have always been passionate about open source because I like the idea of not reinventing the wheel.

Open source was all the rage in the early 2000s, and I remember how much we used to discuss licenses and their role in convincing someone to adopt an open-source project. This is a bit like adopting a certain language—an inherited data and domain model or a workflow that comes with the software.

Even more important, I remember the conversations around how to avoid forks and encouraging every user to return to the official tracks, the modifications, and adaptations. Of course, all this created heated debates on governance: finding the balance between the forces of exit and voice through continuous building loyalty was the priority of many projects, especially the most adopted.

Then, things went pretty quiet on open source for many years: the open source approach became a mere strategic tactic used by numerous platform players looking to dominate industries through economies of complement. Google’s Android makes a good example.

In late 2010, we saw new energy emerge with Crypto and Web3 – a “renaissance” for the open movement.

Web3 promised to build countermeasures to the typical platform trajectory: empower the ecosystem first and then extract value from it.

This time, we had an entirely new design space to leverage—token-based economies and monetary policies—plus mechanisms to create really tangible, open, participatory, and trustless governance, “on-chain,” as someone likes to say. We believed that the possibility of creating really democratic governance structures could create inclusive systems and reduce the need to create one’s own, making it more convenient to join an existing one and participate.

Web3’s ambitions have since then exploded: besides the ICOs and NFTs craze, we also have common smart contract infrastructures such as Ethereum, Solana, or the hyperCosmos, communication protocols (Farcaster, lens), data unions (Dimo), and even so-called Decentralized Physical Infrastructures with projects such as Helium.

But to my surprise, we haven’t seen the key outcome I hoped for through the years. Despite a few interesting experiments, we continued to reinvent the wheel or the protocol, as I should say, despite the critical gains that building applications on top of existing protocols bears: less work on infrastructural elements, inherited network effects, and more.

 

But why do we disagree?

 

In an interview I had on my podcast a few years ago with my friend and internet celebrity Alberto Brandolini (who doesn’t know Brandolini’s law), as we were discussing the role of language in complex contexts such as product organizations, he told me something that I would never forget:

 “Reaching an agreement is one of the most sophisticated and expensive activities of human beings.” 

According to Alberto, reaching consensus in large organizations is a highly underestimated and costly process.

He points out that there’s a risk for teams to over-focus on reaching agreements early, which can stall progress. Instead, visualizing disagreements he advises – for example, through tools like his EventStorming – can save time and create better alignment across the organization.

Besides the implicit complexity of reaching agreements, we also have to factor in the incentives that creating something new brings: first, you can collect capital from people who trust that your idea is better, and then, you can express yourself fully without compromise. You want to create something new and all yours.

 

 

But we will still have to agree to achieve collaborations, build on existing elements, and move forward faster. So how does it happen?

 

First, companies have employed various strategies to drive industry standardization. For instance, as mentioned earlier, Google introduced Android as an open platform. By making it widely accessible, they empowered new players in the market to compete with giants like Nokia and, later, Apple. However, once Android gained dominance, Google began tightening control, linking critical features like access to the Play Store—where most network effects accumulate—only to those who complied with their proprietary ecosystem. This allowed Google to maintain a powerful hold on its adopters, using openness as a means to an end, not as a long-term philosophy.

Amazon’s approach to market standardization with AWS has been all about commoditization and exceptional service delivery. By turning once-complex IT infrastructure into easy-to-access, pay-as-you-go services, they redefined how companies interact with cloud computing. Instead of building and maintaining their own servers, businesses could rely on AWS’s world-class provisioning, instantly scaling up or down with minimal effort. This allowed Amazon to commoditize essential infrastructure, making it affordable and widely available, while their relentless focus on operational excellence kept them ahead of the competition. In doing so, Amazon established itself as the foundational layer for much of the digital economy, creating a powerful lock-in through simplicity, efficiency, and reliability.

In the background, we see the market evolving strongly toward modularity, coupled with easier ways to combine pieces: APIs are all the rage, NoCode automation platforms have become commonplace in business, and AI promises to be a universal duct tape.

Modularity is a way to reduce the burden of cross-party agreements. By breaking down large systems into smaller, independently evolving components, the coordination and tradeoffs required across entities, departments, or systems are less demanding. Plus, you can more easily swap pieces and maintain optionality.

Despite an interesting dynamic that allows some sort of effortless (or less tiring) inheritance of the protocol domains up to the application layer, this doesn’t feel like a significant step forward.

 

 

 

Intentional ontological convergence

 

Almost four hundred years ago, Diogenes lived a life of deprivation, wandering around in a barrel. Still, this stark, self-imposed asceticism was the price he willingly paid to signal his rejection of a corrupt and degenerate society. His rejection of material comforts and societal norms gave him the moral authority to point out the hypocrisy and superficiality of those he encountered and show the way to truth.

Diogenes had to strip himself of all attachments to send a clear, unambiguous message. This bold signal would have been impossible without the price he paid in isolation and discomfort.

This idea of paying a price to carry a signal mirrors concepts from information theory. When a signal encounters noise, the probability of errors increases, meaning the receiver might not understand the message correctly. To counter this noise, the transmitter needs to expend energy. This can be done by Increasing Signal Power or including extra data, known as redundancy, which helps the receiver identify and correct noise-related errors. Another approach could be

More advanced methods, including modulating the signal or Using Better Compression, both of which involve limiting the space of messages that can be exchanged by pre-agreeing on symbols or a shared language.

In a few words, in information theory, sending a clearer signal deals with either spending more energy or reducing the potential of choices in the signals one wants to transmit: in a few words, something has to give.

So, even if there’s an increased tendency to create technologies that can act as middleware and connectors—and LLMs are, of course, very promising in this regard —I guess that we’ll always be left with a limited capability of actual cooperation—even if our systems can connect—if we don’t actually share an underlying ontology.

In a way, I feel we have to go through a process of “agreeing” – which has a cost – to really reap the benefits of a collaboration.

Reaping those benefits means reducing optionality and bearing another intentional tradeoff for a smoother convergence. However, reducing the potential future paths one can take – by converging on a common language- means, to some extent, that all parties involved have to agree to carry a certain shared skin in the game into each other.

It means solidarity, companionship – and, ultimately, shared objectives.

 

 

The Platform Organization

 

With this context in the background, and thanks to this pressure for modularization, in the last 10 years, we’ve seen a new approach to organizing emerge. Ever-lower transaction costs have made it easier for organizations to unbundle and external partners to integrate into their value flows.

Teams and small units have become the organization’s driving force. Consequently, many former internal organizational interfaces have opened up – Bezos has been pioneering this with Amazon. Still, we’re at a point today where you can rent “cloud teams” on a.team, or when people like Sam Altman champion the idea of a one-person unicorn.

The platform organization model already affirms itself in the market in this landscape. It’s an emerging ontology of the modern, adaptive organization, and that’s what we’ve been capturing with the Boundaryless 3EO model, inspired – among others – mainly by Haier’s well-known RenDanHeyi.

It’s rather simple: product-centric organizations have been all the rage in the last decade as an evolution from project-centric ones, and many companies are progressively switching towards seeing themselves as a network of loosely coupled independent units. We call these units micro-enterprises supported by so-called shared services platforms. In such organizations, the objective is to cohere through enabling constraints such as services and rules – rather than to control through top-down management structures – and to facilitate coordination through contracts and agreements.

It’s a kind of subversion of Coase’s theory of the firm, but how could Coase anticipate a market where transaction cost is almost zero?

It’s easy to understand that once complex integrated and bureaucratic siloes disappear in favor of open interfaces and contracts, agreeing on a basic language of organizing and contracting could bear great fruits, effectively helping us overcome the idea of “separated” organization and evolve into ecosystems of value, facilitate search and discovery of capabilities, and easily create dynamic agreements.

Adopting a common organizational model and common service and contract interfaces is an emerging question for our organizations.

Now the question is: our organizations resisted the urge to collaborate on market products and services for decades, leaving players to dominate ecosystems by leveraging network effects.

But now, mounting pressure – due to volatile markets, cascading social issues, and wicked challenges – increasingly requires forming quick-to-form, large-scale, and adaptive alliances. 

Will this be enough to create the urgency to cooperate and share languages? Will such a common language consolidate, at least at the organizational level? Will it only be a language?

These are the questions that all the community has to face now, but I urge you to face them rooted in a deep acknowledgement of the situation and of the lessons we have learned from the last decades of failing at creating shared languages.

Good luck with the most important of the quests.