From IETF to ISO to oneM2M or OASIS, we have many open source projects that provide industrial-grade implementations that anyone can use to evaluate a given standard, or to effectively use it in their commercial solution.
We do believe that open source is key to the adoption of standards, and in a presentation I gave last week at an Open Source Think Tank organized by IEEE, I shared some thoughts on what makes a standard successful, as well as how Eclipse has proved with recent success stories that open source and open communities are a key factor.
The two examples I used in my presentation (see the slides at the end of this post) originate from the Eclipse IoT community.
OMA (Open Mobile Alliance) LWM2M is a standard for doing device management of IoT devices (i.e remotely monitor the device’s health, upgrade its firmware over-the-air, etc.). The first drafts of the standard have been published less than 4 years ago and today, LWM2M is already used in commercial products, and has a thriving community of developers and contributors gathered around two Eclipse open source projects: Eclipse Wakaama, and Eclipse Leshan. I think you will agree that this is the kind of timeline you would like to see for all standards!
The other example is MQTT, a very popular IoT protocol that I’m sure you’ve heard about! In just a few years, it went from a de-facto standard to an actual OASIS and ISO/IEC standard. Having a rich ecosystem of open source MQTT implementations (including Eclipse Paho clients, and the Eclipse Mosquitto server) certainly helped the standards organizations to pin down the issues that need to be fixed in the spec much faster. What’s more, open source projects will also fuel the future of the MQTT specification, as they allow for new ideas to be explored (see e.g this recent work on MQTT-SN).
My hope is that Standards Developing Organizations will start embracing open source initiatives more and more. Open source communities are a great place for innovation, and can host standard implementations that sometimes actually become reference implementation. They also complement very well the role of the SDOs, which are here to enforce some needed processes when it comes to evolving a standard, anticipating incompatibilities or corner cases, etc.
As mentioned above, here are the slides I used during my presentation. I am looking forward to hearing your comments and feedback.