The Paradox of Standardization and Innovation: How Do Web3 Builders Balance the Two?

Written by: Anchor co-founder, Michael Mignano

Compiled by: Rhythm BlockBeats

Standardization is undoubtedly very friendly to both developers and users, whether from the perspective of development costs or adoption costs. This is true in the world of Web2, and it is the same for Web3.

The EVM, a virtual machine with a strong first-mover advantage and the strongest consensus, has become the "standard" for decentralized application development in the Web3 industry.

In the seven years since the Ethereum mainnet went live, the increasing number of Solidity developers has accumulated countless applications for the Ethereum ecosystem and has also built up a large user base. Now, for developers, deploying applications in the EVM ecosystem not only allows them to reach the largest user group but also perfectly utilizes the well-established infrastructure. Most importantly, it enables them to integrate with thousands of EVM applications. For users, they only need one wallet to seamlessly switch RPC and use all applications within the EVM "standard."

However, the EVM also somewhat limits innovation in the Web3 industry. For example, EVM contracts can only define 16 local variables, which greatly restricts the implementation of complex application logic. To achieve complex application logic on the EVM, cross-contract calls are required, which are not only extremely costly but also very unsafe. Of course, we have also seen DeFi applications perfectly implemented on the EVM because the logic within DeFi applications is relatively simple, and the synchronous execution of the EVM is very friendly to financial applications (e.g., flash loans). As for other Web3 applications, they may need to contemplate the paradox between "standardization" and "innovation." The good news is that Alt L1s equipped with other virtual machines like WASM are slowly rising, providing Web3 innovators with other options.

This article comes from Michael Mignano, co-founder of the podcast platform Anchor, who defines "standardization" and elaborates on the advantages and disadvantages it brings, as well as the challenges it poses to innovation. Below is the full translation:

Technical standards, such as the RSS for podcasts, are essential for emerging technologies to spread widely in the information age because only standardized technologies can better integrate into existing ecosystems. However, everything has its two sides; the proliferation of standardization also restricts innovation to some extent—this is why the podcast format has changed almost not at all in its 20-year development history.

The advantage of technical standards is that they can help teams save time and money by providing a common language for products in the market, so developers do not have to build each component from scratch or redefine the way systems communicate. For example, a team building a new email client does not need to redesign the format for transmitting emails between senders and receivers; instead, they can simply adopt SMTP (Simple Mail Transfer Protocol) and focus on enhancing user experience. In other words, people can directly use standards set by predecessors, thus accelerating the product development process; at the same time, products built according to standards often have stronger market adaptability compared to completely proprietary products.

Although standardized products can reach their audience more quickly, the cost is that the lower entry barrier leads to an oversaturation of similar products, resulting in market fragmentation and hindering the pace of innovation. I refer to this phenomenon as the "paradox of standards and innovation," which I will explain in detail below.

Definition of Standards

In simple terms, a standard is a specification for how a technology (hardware or software) interacts with other technologies. Standards are usually developed by communities and approved and maintained by committees, which are typically open to anyone who wants to participate. Some examples of technical standards include: HTTP (for web browsing), SMTP (for email transmission), RSS (for content syndication, such as blogs or podcasts), or SMS (for sending and receiving text messages).

Advantages of Standardization

Let’s understand the benefits that standards bring to product teams through RSS (Really Simple Syndication): RSS has always been the underlying technical standard for podcasts, providing creators with a powerful distribution mechanism that allows them to publish their audio through a single endpoint and quickly aggregate that content across other platforms. Over the past 20 years, RSS has established a common language for podcasts and their applications, facilitating their communication and promoting the flourishing of podcasts on the internet. To publish audio via RSS, creators (or podcast platforms representing creators) must publish podcasts in a specific format and only include parameters defined in the standard, such as the URL link for the podcast cover, episode list, and so on.

I have spent a lot of time dealing with RSS and co-founded Anchor, a podcast creation platform that was acquired by Spotify in 2019. Anchor allows anyone to easily publish podcasts from iOS, Android, or their web browsers without needing professional experience or knowledge. The magic of Anchor for creators is that they can publish their podcasts to all podcast listening platforms via RSS with just one click, which has allowed Anchor to grow rapidly and ultimately become the largest podcast platform in the world.

RSS not only significantly aided Anchor's development in podcast creation but also promoted consumption of podcasts. Almost all podcast applications in the world (such as Apple Podcasts, Spotify, Overcast, and many others) support podcasts under the RSS standard. The benefit of this is that if a podcast application adopts this standard, it can automatically show all podcasts in the world to its users. Similar to the email example mentioned above, this means that these applications can focus on user experience without worrying about the content on their platforms. This is because the content already exists on the open internet and can be easily accessed for users to enjoy.

Disadvantages of Standardization

The use of RSS can save podcast software a lot of time and money by eliminating the need to redesign how their content flows within the podcast ecosystem, which means these applications can easily find their audience. Therefore, since the market was established about 20 years ago, numerous podcast software have emerged within the podcast ecosystem. If you have ever searched for podcast software in the App Store or Google Play Store, you have likely received a plethora of search results. From some perspectives, this phenomenon is good for users because it means they have greater flexibility in choosing what products to use to listen to podcasts. However, at the same time, users can only obtain a singular experience. The reason is that, as mentioned above, the creation of standards is based on consensus, so the underlying language is difficult to change. Next, let’s use a real-life example to better understand the logical relationship here.

The Relationship Between Standards and Innovation

Imagine that you and your partner are vacationing in a country you have never been to for two weeks. Since it’s just the two of you, you can do anything you want during this trip without too many concerns. For example, you can cancel a dinner reservation to go to a concert, or you can cancel a visit to a museum the next day to rent a car and travel to another city.

Now, imagine that on this trip, it’s not just the two of you, but also your children, parents, in-laws, friends, and your brother's family. This would turn into a completely different trip, and all the itineraries would have to be meticulously planned. If you want to adjust a few details, everyone must agree—this is almost impossible. In the end, while you can have an unforgettable experience with your long-lost family, you will inevitably feel a bit bland and uninteresting.

So, this is the same for blogs; any design team that wants to stand out must persuade every stakeholder related to that standard to adopt their ideas; otherwise, their creativity will be ineffective. Moreover, if you insist on going your own way, you won’t even be able to experience the benefits brought by the standard. Going on vacation with friends and family is already quite a headache; imagine dealing with competing companies of varying sizes, the difficulty will only increase—this is the contradiction of building with standards.

The Paradox of Standardization and Innovation

The contradiction between standards and innovation is a problem that teams inevitably face when building new products based on standards: on one hand, there is a broader audience and higher product-market fit, while on the other hand, there is innovative design that deviates from market inertia and consensus standards. If a team decides to break the standard for the sake of innovation without gaining the approval of other stakeholders, they must bear the corresponding consequences. The more stakeholders there are in the ecosystem, the more people need to agree, and the harder it becomes to make changes.

Imagine if a team wants to create a closed-loop proprietary system that is not based on standards; they can build everything from scratch and freely implement and adjust technology without needing the approval of others. Of course, the downside of this approach is that development costs will be higher, and acquiring market positioning may also be more challenging. However, once the product finds its matching market, it can accelerate the innovation process without being constrained by standards.

The Contradiction Between Standards and Innovation

The existence of the contradiction between standards and innovation will force teams to make choices: adopt standards to gain distribution/interoperability advantages similar to other existing products in the large ecosystem (at the cost of long-term innovation), or build everything from scratch to seek greater flexibility and innovative potential (at the cost of existing audiences)?

Before being acquired by Spotify, we faced this issue during the early stages of building Anchor. We could hardly make any innovative changes to the podcast format because it was entirely based on the RSS standard.

For example, suppose we wanted to open a comment section for podcasts and display those comments in the program's RSS feed. Unless we could get hundreds of podcast software to adopt this change, listeners would still be unable to participate in comments. As a result, creators would not only fail to receive any feedback, but we would also have no opportunity to install this feature.

Or, suppose we wanted to create a richer and more flexible podcast analytics system to help creators better understand the performance of their shows, thereby increasing their revenue through advertising. Again, unless we also got other applications to adopt this system, we would be unable to transmit data back to the platform and would ultimately have to abandon this feature.

Over the past 20 years, the existence of RSS has meant that any podcast software can only be crafted according to a completely fixed standard, and any team that wants to create a differentiated product will end up failing.

Communication Software and SMS Standards

This limitation also exists in communication software. The SMS standard for short messages was invented in the 1980s and, after nearly a decade of development, it finally became the first standard adopted by mobile phones and carriers in 1992, gaining support from all major players. After that, anyone anywhere in the world could send text messages to other phones that adopted the SMS standard, regardless of which provider or device they were using.

Then, someone came up with a brilliant idea to add image functionality to communication software. How great would it be if you could send pictures to others? However, since SMS is an open standard, images could not simply be incorporated into the latest software update; the standard itself needed to be adjusted, and every device manufacturer and carrier had to agree to this change. Ultimately, SMS evolved into MMS, and it took about another decade for MMS to finally reach scale.

iMessage is Apple's proprietary communication software, but it does not adopt the original standard. The widespread use of iMessage is thanks to the iPhone— to use iMessage, you must have an Apple device, such as an iPhone, which is certainly a downside. However, if you choose an Apple device, you can enjoy Apple's high-quality service. Thanks to its proprietary ecosystem, Apple can continuously enhance user experience, leaving any communication software that adopts the SMS standard in the dust.

The Development of Communication Software

Over the years, iMessage has undergone significant changes: in its early days, it was not much different from SMS; but now, its features are very rich—read receipts, photo libraries, filters, custom emojis, app stores, voice memos, and so on. Similarly, Snapchat, Messenger, WhatsApp, and many other communication software have also abandoned the SMS standard, gaining opportunities for innovation and rapid development. However, the cost is that they cannot interact with other software, losing a segment of potential users.

Subscription Platforms and SMTP Standards

Recently, you may have heard of a popular email subscription platform—Substack, where creators can independently build, store, and expand their own newsletter businesses.

The cleverness of Substack lies in its use of an open standard, SMTP, to easily send newsletters to anyone with an email address.

Compared to the podcast example above, any platform adopting RSS can immediately solve supply-side issues, while Substack goes the opposite way: it focuses on the demand side, ensuring that every user can read the newsletter content. This is a very smart strategy that not only accelerates its development but also attracts a large number of well-known writers and paying users.

However, despite the impressive effectiveness of this method of using SMTP to send content to readers instantly, the cost is that as long as emails comply with the SMTP standard, they can only remain static. This means that Substack cannot use emails to deploy any dynamic features, such as optimizing readers' search experiences in real-time within the email client, opening a real-time comment section, or implementing any other types of dynamic features that could enhance user experience. Similarly, if Substack wants to truly implement these innovations, it needs to gain the approval of the development teams of most major email clients online.

Therefore, Substack recently made a clever innovation: it launched an application to optimize the user experience on Substack. The significance of this is that if Substack can successfully promote this application, it can continuously improve its platform user experience without being constrained by the SMTP standard. However, doing so also means giving up the advantages of the open standard, which they initially developed under.

In my view, the contradiction faced by Substack is whether to continue using SMTP to gain a broader audience or to build a proprietary solution to accelerate innovation. The launch of its application already indicates Substack's attitude towards this contradiction; it is clear that it has chosen to gradually move away from the standard.

Breaking the Spell: Achieving Both

Although the contradiction between standards and innovation may confine most companies seeking change, there are indeed ways to resolve this contradiction. In fact, there are now methods that allow teams to reap the benefits of standards while innovatively breaking through their limitations.

Fully Utilizing Existing Systems

Over time, all products that adopt standards will eventually become very similar. This is because standards are deeply rooted and difficult to change, and product development quickly reaches its limits. At the same time, the more products that adopt standards, the greater the market inertia, making it even less likely for standards to change. For various products, market competition will be very fierce, and they will find it difficult to break through successfully through differentiation strategies. Therefore, to achieve breakthroughs, these products must seek opportunities in markets that are not constrained by standards.

Spotify's podcast business is an example. A few years ago, this streaming audio giant was just a music platform, but now it encompasses many other categories of audio content. Given the differences in content and experience between music and podcasts, many people hoped the company would launch a dedicated podcast listening application to distinguish between the two types of audio content. However, if Spotify did this, it would have to enter the competitive podcast platform market, which is constrained by the RSS standard, where all products offer roughly the same features. Therefore, once Spotify ventured into this market, it would face the same challenges as other podcast platforms in overcoming the standard's divide. Instead, Spotify fully utilized its existing music user base to send podcasts to hundreds of millions of users within the existing Spotify application. In this way, Spotify successfully broke the spell.

Providing Backward Compatibility

In fact, users prefer to use products based on standards because these products not only offer diverse choices but also allow for flexible data transfer. Therefore, for products that want to pursue innovation, they must retain the advantages provided by the original standard for users; otherwise, they risk losing users and market share. To achieve this, products can incorporate backward compatibility with standards. We can look at how Apple iMessage operates; if you have ever used iMessage, you have likely sent messages to Android users. When you send a message, the message box turns back to green because iMessage adopts the SMS standard at that moment, allowing you to interact with the recipient via text message. In this way, Apple users can experience all the innovative features on iMessage while still being able to send messages to friends on Android devices.

Conclusion

Although standards may somewhat restrict the pace of innovation, we cannot deny that standardization has brought many benefits to technological development. Therefore, when building new products based on standards, development teams need to weigh multiple factors and carefully consider how to handle the relationship between standards and innovation as their products enter the market.