A message format small enough to last

Where it came from

In 1999, Andy Stanford-Clark at IBM and Arlen Nipper at Arcom designed a protocol to carry telemetry from oil pipelines over unreliable satellite links. The constraint was brutal: low bandwidth, high latency, no guarantee the connection would stay up. Their answer was a publish-subscribe messaging protocol with a header that fits in two bytes. The name — Message Queuing Telemetry Transport — describes the problem it was built to solve, not the market it would eventually dominate.

That origin matters for a hardware buyer today. MQTT was not designed around a vendor's product roadmap or a cloud billing model. It was designed around the assumption that the link would fail ↗. A broker sits between devices, holds messages, and delivers them when the subscriber reconnects. There is no hard dependency on any company staying in business.

The protocol was submitted to OASIS, the open standards body, and published as MQTT 3.1.1 in 2014, with MQTT 5.0 following in 2019. Both versions are freely available and have been implemented in software running on hardware ranging from microcontrollers with kilobytes of RAM to full Linux servers.

Why it outlived the hubs

A sensor bought in 2018 still reports to a broker today because the message format did not change in ways that broke older clients.

The smart-home market of the early 2010s was built on proprietary control paths. Hubs authenticated devices against vendor servers; firmware updates could remove features or disable hardware entirely. When Nest acquired Revolv and shut down the Revolv hub's service in 2016, devices that had cost buyers $300 became inert plastic. The dependency was architectural, not accidental.

MQTT is indifferent to that model. A device that publishes temperature readings to a local broker keeps publishing whether or not the manufacturer exists. The broker — Mosquitto, the most widely deployed open-source implementation, maintained under the Eclipse Foundation — runs on a Raspberry Pi and has no subscription fee. Home Assistant, the self-hosted automation platform with millions of active installations, uses MQTT as one of its primary integration paths precisely because it carries no tethering risk. A sensor bought in 2018 still reports to a broker today because the message format did not change in ways that broke older clients.

The contrast with proprietary radio protocols is instructive. Zigbee and Z-Wave outlived many hubs for similar reasons — the radio layer was standardised independently of any one vendor's cloud — but MQTT operates at the application layer, above the radio, and is transport-agnostic: it runs over Wi-Fi, Ethernet, cellular, or whatever the link happens to be.

What it means for residual value

For a buyer evaluating a connected device today, the protocol question is practical. A device that communicates only through a manufacturer's cloud has a lifespan bounded by the manufacturer's business decisions. A device that speaks MQTT to a local broker has a lifespan bounded by the hardware. Those are very different bets.

MQTT 5.0 ↗, published by OASIS in 2019, added message expiry, reason codes, and user properties while keeping the same core publish-subscribe model. That kind of additive, non-breaking versioning is exactly what a long-lived protocol looks like. The European Commission's push for minimum software support windows and the Connectivity Standards Alliance's Matter standard both acknowledge the problem of premature obsolescence, but neither solves it as cleanly as a device that keeps working without any vendor involvement at all.

The lesson from twenty-five years of MQTT deployment is not that open protocols are automatically better. It is that protocols designed around constraint and failure survive longer than protocols designed around convenience and lock-in. A two-byte header outlasted a hundred proprietary hubs. The hardware buyer who asks which message format a device speaks is asking, in a practical way, how long the device is likely to be worth anything at all.