Standards are unicorns

Penned on the 28st day of October, 2021. It was a Thursday.

I’m done putting up with the obsession about “standards” and it’s finally time to explain why.

Many years ago, Peter Welch wrote a blog post entitled Programming Sucks. One of the things he said in it was, “standards are unicorns”, and “there are more standards than things computers can actually do”. It was a relatively benign comment on the proliferation of protocols, to the point developers cannot really keep up with every standard relevant to their work. Today I’m going to talk about the dark side to standards, and I’m going to do this by separating them from the thing developers actually get out of them: protocols.

I have always maintained a strong distinction between standards and protocols. When most developers speak of standards, in my opinion they are referring to protocols, because protocols are simply the agreements by which we are able to communicate. Standards, on the other hand, are more than this: they are not only a protocol, but a commitment to some kind of universality to that protocol. As the old saying goes, “it’s standard”. This carries a political value that a normal protocol does not, and this is what I take issue with.

Developers are not inherently political creatures. Sure, everyone has their beliefs and opinions, but when it comes to how you connect to another computer over the internet, how was that decided? Was it just an agreement made by whoever was on USENET back when? Was it decided by committee, or some consortium? These days it’s increasingly the latter. Who funds those things? Who manages the board? How do key decisions about how you do what you do get made?

As it turns out, tech corporations like Google, Facebook, and Amazon have a lot of influence. A lot of times these consortiums are merely industry special interest groups, and any service to the well-being of how our software works is incidental to their profit. But all the while, the notion of the standard provides a patent-free soft lock on the technology. The main hold is that developers don’t realise that this is its true purpose.

There are also sporadic but more general forms of fundamentalism afoot that we would all be well-served to do away from. Programming languages and data interchange formats, if ubiquitous enough, can become fixated upon to a counterproductive extent. The bottom line is, protocols are means by which we get the things done. It does not matter that much if everyone on Earth agrees on how to do that, only that the people we need to communicate with either agree or can advertise what methods they can work with.

It’s important that we keep the scope of these things limited to the technical domain. This should not be a political problem, and if we keep paying attention it won’t become one. But if we don’t, or if we let industry groups dominate our language, then they will write all of the rules to be in their favour, taking only enough input from us to make sure what they want works effectively. As Lawrence Lessig says, code is law. So if developers focus more on making effective, workable protocols, and prioritise pragmatism by providing discoverability mechanisms for varieties thereof, we will have very good odds of building a technological future that is fairer for everyone and more considerate of the future.

Until next time,
Άλέξανδερ Νιχολί