Recently, I came across an interview on a16z with a very direct theme: Why open networks win. The discussion centers on a real-world proposition: If you want to build a global network, ultimately the issue isn’t performance, but trust.
Christian Catalini is the main speaker in this interview. He was a core member of Libra and is the founder of Lightspark. In the recording, he made a sharp but accurate statement: If you want to reform the monetary system, no one will trust your Corp chain. Corp chain represents control, upgrade rights, and profit-sharing rights still concentrated in a single company or alliance, which also leads outsiders to assume it will serve internal interests.
Many attribute Libra’s failure to regulation, but Christian offers a different “truth.” He points out that regulation indeed has a big impact, but it’s not the only problem. More critically, the market has never believed that a single company can create a “neutral monetary network.” Even if you establish an association to govern it, or if the CEO operates independently, outsiders will still make the same inference: once the main actor leaves, the network will bleed. This inference is not fundamentally about Facebook, but about organizational forms like “enterprise chains.”
Therefore, he increasingly favors Bitcoin. He believes that Bitcoin is not the “most advanced” technical solution; developing on Bitcoin is painful, like building a car in space. But it has an element that companies find hard to replicate: neutrality is validated by history. When the founders disappear, it enters a permissionless state, rules are hard to rewrite unilaterally, and governance is difficult to capture at a single point. Because of this, it can carry high-trust demands like “global value transfer.” This logic shifts the discussion from “Is the code good?” to “Who can be trusted?”
In this discussion, Christian also offers a more commercial judgment: the biggest paradox of enterprise chains is that you can never persuade the “second place” to join your network. For example, if you are the largest payment company, why would the second-largest payment company entrust its core to you? Or, if you are a stablecoin issuer, why would your partners believe you won’t expand downstream and swallow the profit pool? This issue is common in Web2. Once a network can extract profits, controllers are motivated to maximize those profits.
Thus, Christian offers a judgment: in the short term, new closed networks may emerge, and even a phase of “enterprise chain dominance” might occur. But over a longer cycle, money will inevitably flow on open networks.
This discussion also reminded me of a previous essay I wrote titled “Web3 Startup Exploration: Do Crypto Projects Need to Be Open Source?”. In that article, I focused on the tug-of-war between two forces: open source can build trust but also brings copying risks; open source is the cornerstone of Web3, but not all teams can bear the full cost of complete openness. Additionally, I used the cases of Uniswap and SushiSwap to illustrate that copying is common, and that the moat isn’t solely derived from code.
The current a16z discussion provides a deeper supplement, redefining “open source” as a trait similar to neutrality. But in fact, even if a team releases the code, it doesn’t automatically gain neutrality. When the market judges neutrality, it looks not at GitHub, but at control rights.
So what is neutrality, and how to achieve it? Portal Labs simplifies it into three more actionable dimensions:
- Rule Neutrality
Rule neutrality concerns whether key rules can be unilaterally rewritten. Terms like protocol fees, settlement, freezing, permissions, upgrades—if these can be changed by a few, then it’s hard to consider it a public infrastructure. Rule neutrality doesn’t require “completely unchangeable.” It demands that upgrade rights have boundaries, and those boundaries can be externally constrained. This dimension answers the question: “Can you change the rules at any time?”
- Access Neutrality
Access neutrality focuses on whether the ecosystem entry points are open. Does integration require permission? Can interfaces be revoked at any time? Do nodes or validators need approval? Are critical resources only accessible to certain parties? These determine whether the network is a public road or a private enclave. Access neutrality doesn’t mean no barriers; it means barriers aren’t arbitrarily raised by a single party. This dimension answers: “Can others join freely?”
- Profit Neutrality
Profit neutrality concerns whether value distribution can be distorted by control rights. Can you direct transactions to your own products through permissions? Can you change profit-sharing at critical moments? Can you give certain partners special treatment? Can you concentrate ecosystem profits into your company’s cash flow? If the answer is often “yes,” the market will classify you as a platform, not a network. This dimension answers: “Will you turn the network into an ATM?”
In practice, these three standards ultimately boil down to the same Web3 startup judgment: 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 dependability and openness to join. Both can coexist, but their priorities differ. Web3 entrepreneurs need to first determine their positioning, then decide on neutrality and open source strategies accordingly.
To assist with this, Portal Labs suggests using a simple set of questions for self-assessment.
Q1: Does your system allow anyone to integrate and deploy without permission?
If no, you’re closer to a product. This criterion can directly filter out many “pseudo-networks.”
Q2: Do your key rules include unilateral emergency switches, such as freezing, rollback, or forced upgrades?
If yes, you need to explain how these powers are constrained. This directly relates to rule neutrality.
Q3: Does your ecosystem entry depend on your provided interface or ordering?
If yes, you need to admit you’re building a platform. This directly relates to access neutrality.
Q4: Do you allow competitors to earn money on your system without being suppressed by rules?
If no, you cannot be considered a public network. This directly relates to profit neutrality.
Once these questions are answered, open sourcing becomes a more rational engineering decision. Of course, open source itself has levels; it shouldn’t be viewed as a binary choice.
The first level is Verifiable Open Source. The team publicly releases key contracts and security-related code, allowing external audits and reproducibility. This level addresses transparency and can enhance trust, but doesn’t require relinquishing all business control. Many tooling products are suitable for this level. It corresponds to “I want others to believe I haven’t done anything bad.”
The second level is Replaceable Open Source. The team allows third parties to fork and run the code, without locking critical operational rights in-house. This level introduces competitive pressure but also enhances resistance to censorship and sustainability. It corresponds to “I don’t survive solely on monopoly operational rights.”
The third level is Exit Open Source. The team gradually delegates upgrade and governance rights, making itself structurally less important. Bitcoin is an extreme example, but intermediate states exist in the real world. Ethereum still requires coordination and review, but its governance resembles a long-term evolving public process rather than a corporate charter. An open network isn’t without governance; rather, its governance isn’t owned by any single company.
The discussion about open networks, on the surface, is about whether to open source or not, but in essence, it’s about neutrality. Once control rights are concentrated, the second place won’t join, the ecosystem won’t become a public base, and the system can only remain at the product level.
Therefore, for Web3 entrepreneurs, open source is a choice of product form. How much you’re willing to open, what rights you’re willing to give up, and how much uncontrollability you accept determine whether you’re ultimately building a platform product or trying to become an open network.
Understanding this clearly, the question of open sourcing becomes simpler: it’s not about deciding “whether to open source,” but about deciding “whether to become a network.”
