How should open computing standards, such as the protocols and languages that make up much of the core of the internet, be decided on and handled?
It’s not an easy question to answer. But the answer has vast and potentially severe ramifications for almost every company on the planet (at least if you rely on your website for doing any percentage of your business).
A recent kerfuffle with the World Wide Web Consortium (W3C), the organization responsible for standardizing much of the web that most people use on a daily basis, has caused many to ask for the shut-down of the W3C and the creation of a new standards body. But is that actually a good idea?
Regardless of the answer to that, what should such a standards organization look like? This becomes a big, unwieldy topic in a hurry.
To make this discussion a bit simpler, let’s focus in on one specific piece of technology: HTML. HyperText Markup Language makes up a critical part of the web. It is what makes webpages, well, webpages.
In a perfect world, who should define what HTML is (what it looks like, how it works, etc.)? I’m going to walk through a couple of options to try to get a better understanding of how each would impact individuals, as well as large organizations.
1. Let the free market run free!
The first option, really, is to not have any sort of standards-setting organization at all. Simply let each company do their own thing and work with — or not work with — whatever “standards” they want.
This scenario is, well, utter chaos. This is how we end up in situations where there is one de facto standard (as in “the most popular option”) that nobody but the company who created it can use — at least not without permission and/or licensing issues.
A good example of this problem is exFAT, a successor to the FAT file system made popular by Microsoft back in the MS-DOS days. For better or worse, the exFAT file system became a standard and is heavily used on things such as USB flash drives and SD cards. Because of this, other companies must pay for a license to use this file system. Those that don’t open themselves up to potential legal trouble.
Sometimes companies play nice and make their in-house developed technology available for free to the world. Most of the time… not so much. Companies do like to make money, after all. And licensing fees for already-developed technology is a great way to earn some extra scratch without creating anything new.
All of this makes standardization on one technology much more cumbersome and complicated. Could you imagine if HTML, the very basis for “The Web,” had to be licensed from a single company (for a large sum) in order to simply… build a new tool (such as a web browser) that could display HTML content? Or, even worse, to use it to simply publish a new webpage? That, right there, would kill HTML (and the web) overnight.
2. Loosely knit consortium
To work around the (pretty obvious) shortcomings of having a single company own the rights to critical computing technology, you can create… a consortium.
This is an approach that’s been done many times before. Create an organization that multiple existing companies (or organizations) join. Then, as a group, they define a key piece of technology (such as HTML) and release it for free.
It’s an approach that allows each company to retain a certain level of control over the technology itself, ensuring that their business needs are met. They may not get the opportunity to laser focus that technology on their own business needs, and they may lose the opportunity to charge licensing fees to others, but the increased possibility for adoption will often outweigh those “negatives.”
Having such a consortium has one other critical benefit for these companies: It kills possible competition. WHAT?! How could that be?! Let me show you through an example: HTML.
Let’s say, hypothetically, that HTML was owned by one company. For the sake of this scenario, let’s say it’s Microsoft. Just because.
If you were Google, Apple, Mozilla, or any number of other computer-focused companies, you might be inclined to create a competing technology to HTML. It would be one that frees you from needing to license HTML from Microsoft, while at the same time, gives you the opportunity (if your new tech becomes popular enough) to license what you create to others — possibly even Microsoft.
Plus, if your new HTML competitor becomes more popular than HTML itself, you just might be able to use that to your advantage in other parts of the market.
But if HTML is administered under a consortium that includes all of those organizations I just mentioned, competing with HTML now means you must compete with the combined power of every single company within the consortium. That’s a lot of power, and it is, for both better or worse, stifling to the adoption of new technologies that are not coming from one of the companies within that group.
It also means that while the companies within that consortium must reach some sort of agreement on new technologies, there really isn’t anyone looking out for the public — or for those looking to create something new. The needs of the member companies will always take importance over the needs of the public.
This approach has definite improvements over not having any sort of standards group. But as you can see, there are definite problems. New, big, scary problems.
No easy solution
I’ll be honest, I don’t know of a single solution that works well — one that gives companies (large and small) and individuals the opportunity to utilize existing standards while making the world ripe for the development and implementation of new ones. Both of which help to push computing forward.
Perhaps the solution is in the complete abolishment of computer hardware and software patents, thus removing any need to license an existing standard.
Perhaps we need a completely open, democratic organization where the computer users of the world all get a vote on standards that are made available, freely, by the organization.
I truly don’t know what the ideal solution is. But I do know one thing — what we have now is pretty gosh-darned broken.