Open Source vs. Open Standard

I’ve been an active FHISO volunteer for a little over a month and it has been a marvellous journey in every way. When I first visited fhiso.org last autumn it had looked to me to be both dead and exclusive, but a random comment during a rootsdev hangout led to my attending a FHISO organizers meeting and I realized that that initial impression could not have been more wrong. The amount of energy, thought, and time that the other FHISO volunteers bring to the behind-the-scenes work of getting something as monumental as FHISO running is impressive, and their willingness to let me join them has been delightful.

I hope to write several posts here over time describing my perspective on the goals, process, and vision of FHISO. In this post I offer my perspective on the word open and what open standards are (and are not). In particular, how are open source and open standard related?

For clarity, this post represents my opinion and my opinion only. I appreciate FHISO allowing me to post it on their blog but take personal responsibility for any inaccuracies it contains.

A standard is neither software nor source code. The equivalent of this observation in other fields is obvious: for example, a FIFA standard association football is spherical and 71 cm in circumference‒that’s (part of) the FIFA standard; the standard isn’t a particular ball, nor a particular tool that creates balls. A standards organisation might create a prototype for illustrative purposes, such as the World Wide Web Consortium’s Amaya web browser, but it’s generally just that: a prototype, not intended for major use. To reiterate, standards describe characteristics that products need to meet to be interoperable with other products; source code is one particular product.

Open standards also differ from (the common version of) open source both legally and culturally.

Legally, most (though not all) open source code is based on some contagious license: anyone can use the program and anyone can change it, but any change must be released under the same license. For standards that’s not generally an acceptable model. Most companies want to add a few elements to the standard to support their tool’s unique features and they generally don’t want to have to publish those extensions for all their competitors to see. You may or may not believe that companies should publish their extensions, but either way requiring them to do so will cause some of them to shy away from the standard.

Culturally, open source projects are often (though not always) part of some kind of open-ended open-participation development process. Larger projects have some kind of release cycle and a limited set of committers, but the product is still in more-or-less continual flux, often with fairly ad-hoc direction. This culture enables the rapid addition of new features, an asset in developing code but unacceptable in working with standards. Standards must be stable to be useful, with each release’s lifetime measured in years or even decades. They should also be subject to broad consensus before they are published, having been reviewed by a diverse set of impacted parties and not just one or two committers.

Standards can be both open and community-owned. Standards can be developed by the community, where community means some mix of volunteers (like myself) and industry leaders—i.e., the people and corporations whose tools impact the most users. The development process can also be open to the public, in that the general process is made visible to, and may be commented on by, anyone. This publicity does not reach the level of every meeting being streamed live nor every email being a matter of public record: that level of visibility can reduce every conversation into meaningless publicity soundbites. But it does mean that all participants are committed to making their work as public as they reasonably can, using principles such as those outlined by OpenStand to ensure that the process remains open, transparent, balanced, and subject to broad consensus.

As a testament to its open and community-owned vision, FHISO is very open to people. The call for papers is open to anyone who has an idea about what should be standardised or how such a standard might work. Other involvement is also welcome in myriad ways, although responses to queries might not always be immediate given how many things the existing organisers and volunteers are juggling. Don’t believe me? Send me an email (ltychonievich at fhiso) and I’ll do my best to help you discover how you can be part of this open, community effort.

—Luther Tychonievich, FHISO volunteer.