Who Invented MQTT? History from Pipelines to IoT

Who invented MQTT? Andy Stanford-Clark of IBM and Arlen Nipper of Arcom Control Systems designed it in 1999 to monitor oil pipelines over expensive satellite links. This article follows MQTT from that industrial niche to an open OASIS and ISO standard and the default protocol of IoT, and explains how the original design goals still shape the way you use it today.

The Problem in 1999: Pipelines, Satellites and Bandwidth

In the late 1990s, oil and gas operators needed to collect telemetry from remote pipeline equipment: pressures, flows, valve positions, pump states. Many sites had no terrestrial network, so data travelled over satellite links that were slow, intermittent and billed by the byte. Existing approaches polled each device on a schedule, wasting bandwidth on unchanged values and struggling whenever the link dropped.

Two engineers approached the problem from different sides:

Andy Stanford-Clark at IBM, who worked on messaging middleware and had a strong interest in pervasive computing.
Arlen Nipper at Arcom Control Systems (later part of Eurotech), who brought deep SCADA and embedded-hardware experience from the field.

Together they designed a protocol that would push data only when it changed, survive unreliable links and run on modest hardware.

The Original Design Goals

The goals they set read like a modern IoT checklist:

Simple to implement on small devices with limited memory and CPU.
Minimal overhead, so every byte over satellite carried useful data.
Publish/subscribe, so remote devices did not need to know who consumed their data.
Quality of service levels so the sender could trade reliability against bandwidth for each message.
Tolerance of intermittent connectivity, including a way to tell everyone when a device dropped off unexpectedly.
Data agnostic, carrying any payload format without the protocol caring.

Each goal maps directly to features you still use: the two-byte minimum fixed header, the broker-centric publish/subscribe model, QoS 0/1/2, keep-alive and Last Will, and opaque payloads.

What Does MQTT Stand For?

The "MQ" came from IBM's MQSeries messaging product family, and the protocol was originally called MQ Telemetry Transport. That name caused years of confusion, because MQTT is not a message queue in the MQSeries sense. When MQTT was standardized, the name became simply "MQTT", no longer officially treated as an acronym.

MQTT History Timeline: Who Invented MQTT and What Came Next

Year	Milestone
1999	Andy Stanford-Clark and Arlen Nipper create the first version for pipeline telemetry
2000s	IBM uses MQTT internally and in its messaging products; adoption grows in industrial and energy settings
Late 2000s	MQTT-S (later MQTT-SN) is specified for non-TCP sensor networks
2010	IBM publishes MQTT 3.1 royalty-free, allowing anyone to implement it
Early 2010s	Open-source clients and brokers appear, including Eclipse Paho and Mosquitto
2013	OASIS forms an MQTT Technical Committee to standardize the protocol
2014	MQTT 3.1.1 becomes an OASIS Standard
2016	MQTT 3.1.1 is published as international standard ISO/IEC 20922
2016 onward	Sparkplug, originated by Cirrus Link (co-founded by Arlen Nipper), adds industrial conventions on top of MQTT and later moves to the Eclipse Foundation
2019	MQTT 5.0 becomes an OASIS Standard, adding reason codes, session expiry, shared subscriptions and more

The specification documents themselves are available from the OASIS committee and summarized on mqtt.org.

From Proprietary to Open: Why 2010 Was the Turning Point

For its first decade MQTT was mainly an IBM technology. Making the 3.1 specification royalty-free in 2010 changed that. Developers could now write clients and brokers without licensing concerns, and they did:

Eclipse Paho provided client libraries in many languages, giving developers a common starting point.
Mosquitto, a lightweight open-source broker, made it trivial to run MQTT on a laptop or a Raspberry Pi.
Hobbyists and startups adopted it for home automation and connected products, often discovering it through Arduino and Linux projects.

That timing matched the rise of cheap Wi-Fi microcontrollers and smartphones. A protocol designed for satellite links turned out to be ideal for battery-powered sensors and mobile apps on flaky cellular networks.

Standardization: OASIS and ISO

Open implementations created momentum, but enterprises wanted a vendor-neutral standard. IBM and others brought MQTT to OASIS, where a technical committee refined version 3.1 into MQTT 3.1.1, clarifying ambiguous areas while keeping it compatible in practice. It became an OASIS Standard in 2014 and was adopted by ISO/IEC as 20922 in 2016.

The committee then tackled lessons learned from large deployments. MQTT 5.0, approved in 2019, kept the core model but added what operators had been missing: reason codes for diagnosing failures, session and message expiry, shared subscriptions for load balancing, topic aliases, user properties and request/response metadata. Our overview of MQTT 5 features explains each addition.

Common Misconceptions About MQTT's Origins

A few myths come up repeatedly in forums and interviews:

"MQTT was built for the internet of things." The term IoT barely existed in 1999. MQTT was built for industrial telemetry and only later became the default IoT protocol.
"MQTT is a message queue." The MQ in the original name refers to a product family, not to queue semantics. Every matching subscriber gets its own copy of a message.
"MQTT was always open." It was proprietary for about a decade before the royalty-free release in 2010.
"MQTT 5 replaced 3.1.1." Both remain in wide use, and most brokers support both side by side.

Why the Original Design Still Matters

Many of today's best practices are the 1999 requirements wearing new clothes:

Keep connections long-lived. MQTT assumes a persistent link and amortizes setup costs across many messages.
Publish on change, not on a timer, when bandwidth or battery is precious.
Use Last Will for presence, exactly the "tell everyone when a device dropped" requirement.
Choose QoS per message type, trading reliability for cost as the designers intended.
Keep the payload format your choice, whether JSON, Protobuf or Sparkplug B.

Understanding this history also explains MQTT's limits. It was not designed as a durable log or a stream-processing platform, which is why production systems pair a broker with databases, historians or stream processors connected as clients.

From Self-Hosted Brokers to Managed MQTT

The early adopters ran their own brokers on their own servers. That is still possible, but it means patching, certificate renewal, monitoring and scaling are your job. A growing share of teams now choose a fully managed MQTT service and spend their time on devices and applications instead.

ConnectMQ is one such MQTT broker in the cloud. It supports both MQTT 3.1.1 and 5.0, offers TLS on 8883 and secure WebSocket on 8084, and includes industrial features that would have pleased the protocol's pipeline-monitoring origins: ISA-95 and Unified Namespace topic detection and Sparkplug B decoding. If you want to experience the protocol the inventors designed with zero setup, connect to the public test broker:

mosquitto_sub -h broker.connectmq.com -p 1883 -i history-sub-e41f \
  -t "connectmq/demo/e41f/pipeline/#" -v

mosquitto_pub -h broker.connectmq.com -p 1883 -i history-pub-e41f \
  -t "connectmq/demo/e41f/pipeline/station7/pressure" -m "42.7" -q 1

A remote station publishes one value, the broker pushes it to every interested subscriber, and nobody polls. That is the 1999 idea in two commands. To go deeper, continue with the MQTT tutorial or see where the protocol is used today in MQTT use cases by industry.

Get Started with ConnectMQ

Experience MQTT the way its inventors intended, without running a server. Sign up at app.connectmq.com, create a free Serverless broker with no credit card, and use ConnectMQ's in-browser client to publish your first message in minutes.

Frequently Asked Questions