“You can’t have high standards without good discipline.” – William Hague
It’s lovely when two partners find each other. They meet at work or at a party, exchange small talk, and find that they have a lot in common. The early attraction turns into something deeper and more meaningful. Before long, they know they’re meant for each other. “Let’s share assets” becomes, “Let’s get married.” Their friends and associates assemble to celebrate the union and the couple lives happily ever after. I get a warm feeling just thinking about it.
So, let’s all raise a glass and toast the happy couple: IPSO and OMA. Both are dropping their maiden names and will soon be filling out forms under their new joint account of OMA SpecWorks. Their hundred-odd children won’t all be living under one roof, though. They’re all too grown-up and too geographically dispersed to make that practical. But it’s one big blended family now, and their future looks bright.
If you weren’t on the guest list, you might not be familiar with either IPSO or OMA. The first was originally the Internet Protocol for Smart Objects group, formerly residing at www.ipso-alliance.org. As the name suggests, IPSO was promoting the idea of using IP for connecting IoT objects, as opposed to competing network protocols. IPSO developed and promotes a collection of “management objects,” software models for various types of IoT devices that allow them to interoperate efficiently. The idea is to package up a device’s capabilities, status, and actions into reusable models that can communicate with other models. It’s a bit like a hardware abstraction layer (HAL) for IoT devices from different manufacturers. IPSO tries to invent as little as possible, relying instead on existing standards (like the IP transport layer) whenever possible.
OMA (Open Mobile Alliance) is the older of the two partners, having come into the world in 2002. Unlike the younger IPSO, OMA started out with a focus on wireless telecom standards, which were all the rage back around that time. It has penned more than 200 relevant standards over the past 15 years, including the hugely popular OMA DM. Like IPSO, OMA concentrated on low-cost, resource-constrained hardware targets, so protocols had to be simple, portable, and energy-efficient.
Before long, it became clear that both organizations were working on similar problems, but at different levels. There wasn’t a lot of overlap in their projects or specifications, but there was a lot of commonality in their goals and aspirations. It was a match made in nerd heaven. Yesterday they officially tied the knot.
On the theory that two can live as cheaply as one, the two bodies merged their headcount, meetings, and management structure. Creating and promulgating standards is tough work that involves a lot of rented meeting rooms, a lot of travel, and a lot of coffee. There’s usually no way to monetize that work, so nearly all the effort is volunteered by engineers and managers with busy day jobs. It made sense to combine the talent pools while cutting the overhead in half.
Marriages like this can trigger other life changes, too, and the newly formed OMA SpecWorks took the opportunity to reflect upon how its offspring enter the world. Before, standards were hashed out among participating engineers meeting in far-flung places and, when the spec was finally complete, published to the world at large. The new standard would then succeed or fail based on… what? Were unpopular standards unsuccessful because they were technically deficient? Were they incomplete? Overly complicated? Or was there some other force at work?
User feedback suggested that OMA and IPSO weren’t promoting their efforts in quite the right way. The problem wasn’t with the technical merits of the standards themselves, but in how they were presented. Posting a 400-page PDF to your website and saying, “There it is; knock yourself out” is not an attitude that encourages adoption. In short, OMA and IPSO weren’t “selling” their work effectively.
The new OMA SpecWorks promises to do better on the evangelism and marketing fronts. It uses GitHub extensively, and it monitors developer feedback. “We think we’re incrementally pushing forward the idea of making specs more approachable,” says general manager Seth Newberry. Standards won’t necessarily be any simpler technically, but they will be packaged up and promoted more effectively. Simply posting a PDF and hoping for the best won’t cut it anymore.
In fact, OMA SpecWorks is so enthusiastic about its new approach that it wants to become the “idea factory” for other industry verticals. Bring us your ideas, the group is saying, and we’ll help you turn them into efficient, useful, and popular standards. OMA SpecWorks is a process as much as a product: a template for other standards-setting bodies, not just a single example of the genre.
OMA SpecWorks’ standards are freely available – just download them from the website – but they’re not always free to implement. Like most standards bodies, OMA SpecWorks (and its antecedents) requires members to declare any proprietary IP they may be contributing to the new spec. The group may or may not incorporate that IP into the standard, but if it is included, it must be made available under a “fair, reasonable, and nondiscriminatory” (FRAND) license. Thus, some OMA SpecWorks standards might require a licensing fee from one of its participating members, in which case, the terms are between you and the licensor. It just depends.
Partnership and collaboration are wonderful things to see.
Good programming is all about reuse. Likewise, usable standards, which keep us from reinventing solutions to already-solved problems. If OMA SpecWorks can keep us from refighting old battles and let us move quickly to higher-value programming, then its union will be a fruitful one.
