I recently came across an interview on a16z with a very direct theme: Why open networks always win. The interview discusses 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, the main speaker in this interview, 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 corporate chain. Corp chains mean that control, upgrade rights, and profit-sharing rights remain concentrated in the hands of a single company or alliance, leading to the assumption that they serve internal interests. Many attribute Libra's failure to regulation, but Christian offers a different perspective. He points out that while regulation does have a significant impact, it's not the only problem. More importantly, the market has never believed that a single company can create a "neutral monetary network." Even with association governance and an independent CEO, the same conclusion remains: the network will bleed when the leader leaves. This conclusion isn't essentially directed at Facebook, but at the organizational form of "corporate chains." Therefore, he increasingly favors Bitcoin. He believes Bitcoin isn't the "most technologically advanced" solution; development on Bitcoin is painful, like building a car in space. However, it possesses an element that is difficult for other companies to replicate: neutrality is historically validated. Founders disappear, entry is permissionless, rules are difficult to rewrite unilaterally, and governance is difficult to capture from a single point of view. It is precisely because of this that it can support high-trust demands such as "global value transfer." This logic shifts the discussion from "how good the code is" to "who can be trusted." In this discussion, Christian also offered a more commercial assessment: the biggest paradox of enterprise blockchains is that you can never convince the "second-largest" 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 believe 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 judgment: In the short term, new closed networks may emerge, and even a phase of "enterprise chain dominance" may occur. However, in the longer term, money will inevitably flow on open networks. This discussion also reminded me of an essay I wrote before: "Web3 Startup Discussion: 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. This discussion on a16z provides a deeper supplement, redefining the meaning of "open source" as a quality similar to a declaration of neutrality. But in reality, even if a team releases its code, it doesn't automatically acquire neutrality. When the market judges neutrality, it doesn't look at GitHub, but rather at control. So what is neutrality, and how can one achieve neutrality? Portal Labs roughly breaks it down into three more actionable dimensions: Rule neutrality focuses on whether key rules can be unilaterally rewritten. If the terms of fees, liquidation, freezing, permissions, and upgrades in a protocol can be changed by a minority, it's difficult to treat it as public infrastructure. Rule neutrality does not require "complete non-upgradeability." It requires that upgrade rights have boundaries, and these 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 you block the entry point to the ecosystem. Whether integration requires a license, whether interfaces can be revoked at any time, whether nodes or validators need approval, and whether key resources are only open to your own entity—all these determine whether the network is a public road or a private park. Access neutrality does not mean no barriers. Access neutrality means that the barriers cannot be unilaterally raised. This dimension answers the question, "Can others join freely?"
Interest Neutrality
Interest neutrality focuses on whether value distribution will be distorted by control. Can you use permissions 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 classify 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 build 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-assessment. Q1: Does your system allow anyone to integrate and deploy it without permission? If the answer is no, you're closer to the product. This judgment can directly filter out a large number of "pseudo-networks." Q2: Do your key rules have unilateral emergency switches, such as freeze, rollback, or forced upgrade? If the answer is yes, you need to explain how these powers are constrained. This question directly corresponds to rule neutrality. Q3: Does your ecosystem entry point rely on a single interface or unique ordering that you provide? If the answer is yes, you need to admit that you are building a platform. This question directly relates to access neutrality. Q4: Do you allow competitors to earn 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 becomes 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 level is verifiable open source. The team publicly discloses 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 level. This level 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 key operational rights in 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 monopolizing operational rights to survive." The third layer is exitable open source. The team gradually delegates upgrade and governance rights, making themselves structurally less important. Bitcoin is an extreme example, but intermediate states also exist in the real world. Ethereum still requires coordination and oversight, but its governance resembles a long-term, evolving public process rather than a company bylaw. Open networks are not without governance; they simply mean that governance 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 it's essentially about neutrality. Once control is centralized, a second player won't join, the ecosystem won't become a public foundation, and the system will ultimately remain just a product. Therefore, for Web3 entrepreneurs, open source is a choice of product form. The degree of openness you're willing to grant, the power you're willing to relinquish, and the amount of uncontrollability you're willing to accept determine whether you're ultimately building a platform product or attempting to become an open network. Once you understand this, the issue of open source becomes simpler: you're not deciding "whether to open source," you're deciding "whether to become part of the web."