Designing open standards with the minority rule

Nassim Taleb has a great anecdote about why all the food in the grocery store is kosher: it costs almost nothing for a company to make their food kosher and thus gain the Jewish customer segment, and for non-Jews it costs nothing to eat kosher food. Over time, companies realize it’s in everyone’s interest to simply make all of their food kosher.

It occurred to me that RSS has followed the same path. It’s an easy protocol to implement, and there are a ton of libraries that create RSS feeds automatically, so it costs almost zero development time to add it to a website. WordPress has it built in, as I would expect all blogging software. It’s also easy to convert existing content into an RSS feed: for example, NewsBlur.com has a feature that converts email newsletters into RSS feeds.

Thus the minority of the population that reads news via RSS is driving the majority of the publishers to provide RSS feeds. This has allowed RSS to survive through the dark ages of social media.

The minority rule is related to Richard Gabriel’s Worse is Better idea, but it includes network effects. NNT explains that the rise of Islam is due in part to the fact that you can convert to Islam (via marriage, or willful conversion, or simply being born into the religion), but you cannot leave it: apostasy is considered a crime punishable by death, according to some Islamic scholars. This simple asymmetry, over a long period of time, leads to more people entering the religion than leaving it.

What if we used this minority rule to design open tech standards? If we check off the right boxes, then we can ensure that companies will be incentivized to use open standards instead of designing proprietary protocols. As far as I can tell, there are only two things you need: cost asymmetry, and a renormalizing group.

Cost asymmetry

The cost of using a standard must be much lower than the cost of not using it. I think XMPP has failed as a widely-used standard because it is very difficult to implement. Google and Facebook chat eventually stopped supporting the standard because it was easier to develop and maintain a proprietary protocol that had custom features for all of their apps. On the other hand, HTML is succeeding because it works everywhere, is relatively easy to work with, and all of the tooling is open source, i.e. costs nothing to adopt.

The cost of switching to a platform must be much lower than the cost of leaving said platform (importing should be much easier than exporting). Facebook actually exhibited this characteristic early on: it was easy to post stuff to Facebook, but the export function (if it even existed) was buried deep in the settings menu. And even if you did export your data, what would you do with it? You would presumably have to write a custom program to parse and reorganize the data in a way that is useful to you.

Renormalization

After establishing a cost asymmetry for your standard, you need a group that only uses that standard to renormalize the rest of the population. That is, you need a stubborn, early-adopter group. It doesn’t matter so much how evangelizing this group is, they mostly need to be a participant in the wider ecosystem. As long as you have more people switching to the standard/platform than you have leaving it, over time the minority group will renormalize the rest.

However, the renormalizing group cannot be a silo. Bitcoin really gained widespread adoption when it became easy to acquire bitcoin through GDAX/Coinbase and other exchanges. I think Secure Scuttlebutt is missing the boat (pun intended) on this because it is impossible to view SSB content without their “patchwork” program, and I don’t believe they interoperate with other platforms like email or Twitter or WordPress. Even just the ability to publish a static webpage, powered by SSB, would greatly improve their chances of success.

There is some math describing renormalization groups in physics that probably applies here too.


Posted

in

by

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *