There is a moment so ordinary that we do not notice it at all.

You plug a network cable into a wall socket. The socket comes from a German manufacturer, the cable from Taiwan, the switch beneath it from California, the router behind it from Sweden. And it works. Not because everyone involved is being nice to each other. But because they all adhere to the same set of rules: IEEE 802.3 — Ethernet.

That sounds banal. It is banal. And that is precisely why it is remarkable.

What a standard really is

A standard is not software. Not a device. Not a product. A standard is an agreement. A shared language in which humans and machines communicate without personally knowing each other.

On the smallest scale, this means: plugs fit. On the largest: the internet works. In between lies a world of specifications that define how data is encoded, transmitted, interpreted and confirmed — so that millions of devices that never knew of each other can talk to one another.

Once you understand this, you see the digital world with different eyes. Not as a collection of magical boxes, but as a fabric of agreements that someone, at some point, wrote down.

Without standards, no digital ecosystem

The internet as we know it would be impossible without standards. TCP/IP, defined in the IETF’s RFCs, is the protocol that connects every device to the network. HTTP, likewise specified in RFCs, is the foundation of the World Wide Web. DNS translates names into addresses. TLS encrypts connections. SMTP transports email. BGP routes data packets around the entire globe.

None of these technologies belongs to a company. None is secret. Each is written down, published, readable by anyone, implementable by anyone. Exactly this openness is the reason the internet could grow — not as the product of a single vendor, but as an ecosystem anyone was allowed to join.

Had the internet been built proprietarily, it would never have reached this scale. There would be many small networks that did not speak to each other. That is exactly what the telecommunications world looked like before standards: island solutions that only worked within their own walls.

Who writes the rules

Standards do not fall from the sky. They are made — by institutions whose task is to negotiate agreements that can win a majority.

The IETF (Internet Engineering Task Force) maintains the RFC series. “RFC” stands for Request for Comments — a modest name for the most important document archive on the internet. Anyone can submit an RFC. Anyone can join the discussion. Decisions are not made by majority vote, but by rough consensus. That is slow, sometimes frustrating, and it is the reason RFCs are so robust.

The IEEE (Institute of Electrical and Electronics Engineers) is responsible for standards at the physical layer: Ethernet, Wi-Fi (802.11), Bluetooth-based radio technology. Wherever bits flow through cables or air, an IEEE standard usually governs how.

The ISO (International Organization for Standardization) covers everything from paper formats (the familiar DIN-A4 is an ISO standard) to country codes to process management. The W3C defines how the web is structured — HTML, CSS, XML. The ECMA standardises programming languages like JavaScript. The ITU coordinates international telecommunications.

These institutes are not authorities with power. They are stages on which interest groups negotiate. Manufacturers, researchers, administrators, governments — everyone brings their perspective. The standard that emerges is a compromise. And compromises are never perfect, but often good enough to hold the world together.

The price of standardisation

Standards are laborious. Anyone who has ever read a specification knows this. They are dry, pedantic, full of edge cases and special conditions. That is no accident — it is the consequence of having to consider every conceivable situation before the document is finished.

A standard is not created in weeks. Often it takes years. Committees convene, drafts circulate, comments are gathered, incorporated, commented on again. Disputes over details can tie people up for months — whether a field should be 16 or 32 bits wide, whether a timeout is measured in seconds or milliseconds.

That feels like waste. In the time it takes to negotiate a standard, a company could have thrown three products onto the market. And that is precisely the temptation: be fast, stay proprietary, dominate the field alone.

But whoever succumbs to it pays a different price later.

When standards compete

There is not always the one standard. Often several exist side by side, and the market decides — not always rationally.

Everyone knows the joke: “There are fourteen competing standards. Let’s develop one that unifies them all. Now there are fifteen.” It hits a nerve because it is true. REST versus SOAP. Markdown versus AsciiDoc. YAML versus TOML versus JSON. USB-C versus Lightning versus MagSafe. VHS versus Betamax.

Competing standards cost resources. Adapters, translators, compatibility layers — all of this exists because the world could not agree on a single solution. In some cases, a standard prevails because it is technically superior. In many cases, because it was timely, cheap or well-marketed. Sometimes a decades-long trench war remains in which both camps exist and nobody truly wins.

Even so: competing standards are still better than none at all. For where a standard exists, interoperability is possible. Where none exists, the monopoly of whoever controls the market reigns.

What sets open standards apart from proprietary ones

A proprietary protocol works — as long as the vendor exists, the licence is paid, and the interest remains. Should the provider disappear, the strategy change, or the price double, what remains is a system that no longer talks to anything.

An open standard, by contrast, belongs to no one and to everyone. It can be implemented by anyone. It outlives companies, eras, technology shifts. SMTP is older than most of today’s firms. HTTP still works, even though the world around it has completely transformed.

This has a side effect that is rarely mentioned: open standards reduce waste. Devices that communicate via open standards can be used longer, combined, repaired. Those dependent on proprietary interfaces throw hardware away as soon as the vendor stops supporting it. Electronic waste is, among other things, a standardisation problem.

The Lock-in Trap

This is where it gets uncomfortable. Because proprietary solutions are rarely accidental — they are often deliberate.

A vendor developing its own protocol is not necessarily acting out of malice. Often it begins pragmatically: a feature the competition lacks, an integration that only works with their own product, a performance optimisation that only kicks in with their own stack. That is legitimate.

What happens afterwards is the problem. Once a customer has migrated to this proprietary system — imported their data, aligned their processes, trained their staff — the encirclement begins. Every further integration works best with their own product. Every extension binds deeper. Every year that passes makes an exit more expensive, slower, riskier.

This is vendor lock-in: the strategic shifting of negotiating power. The customer chooses once — and never decides again. The vendor no longer has to convince, only to retain. Prices can be raised, support tiers consolidated, features moved into higher licensing levels. The customer cannot leave. They can only pay.

Open standards break this logic. Where a standard applies, the vendor can be replaced. Data can be exported, the protocol is understood by everyone, the integration is traceable. The customer stays sovereign — and it is precisely this sovereignty that proprietary business models fear.

It is no coincidence that the most aggressive lobbyists against standardisation invariably come from those with the most to lose: the owners of closed ecosystems. Standardisation means competition. And competition means having to make an effort.

Understanding and debugging

Anyone who operates an infrastructure learns quickly: problems are inevitable. What matters is whether you can understand them.

With an open standard, I can read the specification. I can trace what a packet should contain, what a response must look like, where an error originates. I can capture a connection and see what is happening — because the formats are documented.

With a proprietary protocol, I see bytes. And I see a support contract.

That is not an abstract advantage. It is the difference between an evening on which I solve a problem and a week spent waiting for an answer from someone else’s ticket system.

What this has to do with libcom.de

We at libcom.de have relied on open standards for more than two decades. Not out of loyalty to principles, but out of practice. Systems based on RFCs and IEEE standards can be understood, repaired and further developed — even when the original supplier has long been forgotten.

A good part of our work consists of helping customers escape proprietary dead ends and migrate to standardised, interoperable infrastructures. That sometimes means we are slower than a slick product promise. But it also means that what we build still works in five years — and can be understood by someone else.

If you wonder whether your IT depends too heavily on proprietary solutions, or whether standardising your systems would make sense: write to us at contact@libcom.de. We take an honest inventory — without sales pressure, with a view to what your infrastructure needs in the long term.

Standards are not glamorous. Nobody tells their children they negotiated a compromise over a 32-bit field today. But without these compromises there would be no internet, no web, no email, no telephone network that works across borders.

They are the most boring foundation holding the world together. And perhaps it is exactly right that they are boring — because boring means reliable. And reliable is what infrastructure is supposed to be.