I recently came across an interview on a16z with a very direct theme: Why open networks always win. The interview discussed a real-world issue: if you want to build a global network, the ultimate problem you need to solve is not performance, but trust.
Christian Catalini is the subject of this interview. He was a core member of Libra and the founder of Lightspark. In the recording, he makes a harsh but accurate statement: "If you want to reform the monetary system, no one will trust your Corp chain." A Corp chain means that the control, upgrade rights, and profit-sharing rights of the network are still concentrated in the hands of a certain company or alliance, which leads outsiders to assume that it serves internal interests.
Many attribute Libra's failure to regulation, but Christian offers a different "truth." He points out that while regulation certainly had a significant impact, it wasn't the only problem. More crucially, the market has never believed that a single company can create a "neutral monetary network." Even with an association for governance and an independent CEO, the same conclusion will still be drawn: the network will bleed if the leader leaves. This conclusion isn't essentially directed at Facebook, but rather at organizational structures like "enterprise blockchains."
Therefore, he became increasingly fond of Bitcoin. He believed that Bitcoin was not the "most technologically advanced" solution, and that developing on Bitcoin was painful, like building a car in space. However, it possessed an element that was difficult for other companies to replicate: its neutrality was historically validated. The founders could disappear, entry was permissionless, the rules were difficult to rewrite unilaterally, and governance was difficult to capture from a single point of view. It was precisely because of this that it could support high-trust demands such as "global value transfer." This logic shifted the discussion from "how good the code is" to "who can be trusted."
In this discussion, Christian also offered a more commercial perspective: the biggest paradox of enterprise blockchains is that you can never convince the "second-largest" player to join your network. For example, if you are the largest payment company, why would the second-largest payment company entrust its lifeline to you? Or, if you are a stablecoin issuer, why should your partners trust that you won't expand downstream and devour the profit pool? This problem is frequently seen in Web2. Once the network can extract profits, the controller has an incentive to maximize those profits.
Therefore, Christian makes the following assessment: In the short term, new closed networks may emerge, and there may even be a phase of "enterprise blockchain dominance." However, in the longer term, money will inevitably flow on open networks.
This discussion also reminded me of a previous essay I wrote , "A Discussion on Web3 Startups: Do Encrypted Projects Really Need to Be Open Source?" In that article, I focused on the tug-of-war between two forces: open source can build trust, but it also brings the risk of copying; open source is the cornerstone of Web3, but not all teams can afford the cost of complete openness. Furthermore, I used the examples of Uniswap and SushiSwap to illustrate that copying is not uncommon, and competitive advantages don't only come from code.
The discussion at a16z offers a deeper perspective, redefining "open source" as a quality akin to a declaration of neutrality. However, in reality, releasing code doesn't automatically grant neutrality. The market judges neutrality not by GitHub, but by control.
So what is neutrality, and how do we achieve neutrality? Portal Labs breaks it down into three more actionable dimensions:
Rule neutrality
Rule neutrality focuses on whether key rules can be unilaterally rewritten. If clauses regarding fees, liquidation, freezing, permissions, and escalation can be altered by a minority, it's difficult to consider it a public infrastructure. Rule neutrality doesn't require "complete non-escalability." It requires that escalation rights have boundaries, and these boundaries can be externally constrained. This dimension answers the question, "Can you change the rules at any time?"
Neutrality of Access
Access neutrality focuses on whether you block access to the ecosystem. Whether integration requires a license, whether interfaces can be revoked at any time, whether nodes or validators require approval, and whether key resources are only accessible to your own entity—all these factors determine whether the network is a public road or a private park. Access neutrality does not mean no barriers at all. It means that barriers cannot be unilaterally raised. This dimension answers the question, "Can others join freely?"
neutral interests
Profit neutrality focuses on whether value distribution will be distorted by control. Can you use your authority to direct transactions to your own products? Can you change profit sharing at crucial moments? Can you grant special treatment to certain partners? Can you concentrate ecosystem profits into the company's cash flow? If the answer is frequently "yes," the market will categorize you as a platform, not a network. This dimension answers the question, "Will you turn the network into an ATM?"
In practice, these three standards ultimately boil down to the same judgment for Web3 startups: are you building a "decentralized product" or trying to establish a "decentralized network"? The goal of a product is efficiency and controllability. The goal of a network is dependency and joinability. They can coexist, but their priorities differ. What Web3 entrepreneurs really need to do is first determine their positioning, and then decide whether to adopt a neutral or open-source strategy.
Portal Labs suggests using a set of simple questions for self-testing.
Q1: Does your system allow anyone to integrate and deploy it without a license?
If the answer is no, you are closer to the product. This judgment can directly filter out a large number of "pseudo-networks".
Q2: Do your critical rules have unilateral emergency switches, such as freeze, rollback, or forced upgrade?
If the answer is yes, then you need to explain how these powers are constrained. This question directly relates to rule neutrality.
Q3: Does your ecosystem entry point depend on a unique interface or unique ordering that you provide?
If the answer is yes, then you need to admit that you are building a platform. This question directly relates to access neutrality.
Q4: Do you allow competitors to make money on your system without being suppressed by your rules?
If the answer is no, you cannot become a public network. This question directly relates to interest neutrality.
Once these questions are answered, open source will become a more rational engineering decision. Of course, open source itself has levels, and it shouldn't be written as an either-or choice.
The first layer is verifiable open source . The team publishes key contracts and security-related code, allowing external auditing and reproduction. This layer addresses transparency and enhances trust, but it doesn't require relinquishing complete business control. Many tool-based products are suitable for this layer. This layer corresponds to "I want others to believe I haven't done anything wrong."
The second layer is alternative open source . The team allows third parties to fork and run the code, without locking critical operational rights into their own hands. This layer brings competitive pressure, but also stronger resistance to censorship and sustainability. This layer corresponds to "I don't rely on monopolistic operational rights to survive."
The third layer is the option to exit open source . Teams gradually delegate upgrade and governance authority, making themselves structurally less important. Bitcoin is an extreme example, but intermediate states also exist in the real world. Ethereum still requires coordination and auditing, but its governance is more like a long-term, evolving public process than a company bylaw. Open networks are not without governance; it's just that the governance of open networks doesn't belong to any single company.
The discussion about open networks, on the surface, is a debate about whether or not to open source, but in essence, it's about neutrality. Once control is centralized, a second player won't join, the ecosystem won't become a common foundation, and the system will ultimately remain just a product.
Therefore, for Web3 entrepreneurs, open source is a choice of product form. The extent to which you are willing to open up, what rights you are willing to relinquish, and how much uncontrollability you are willing to accept determines whether you are ultimately building a platform product or trying to become an open network.
Once you understand this, the issue of open source becomes simple: you're not deciding "whether to open source," you're deciding "whether to become part of the network."
