Open Source software is one of the most important and inspiring movement in technology. It is responsible for a great deal of innovation and democratization of the internet and beyond. Open Standards on the other hand, are still very much the domain of big companies and professionals standards experts. There are plenty of good definitions for what constitutes an Open Source project, as well as plenty of well understood (or at least trusted) legal licenses available.
On the other hand, we are still struggling to define what an Open Standard is.
It is extremely tempting to bundle the Open Source and Open Standards together, even though they are two, discrete concepts. In many cases, there is a great deal of overlap between the people writing Open Source code and the people working on specifications covering the same area. Most people try to understand the standards world through their understanding of Open Source, given the human mind’s compulsory need to apply known patterns to new ones.
The problems start when we try to solve Open Standards problems with Open Source tools. On the face of it, it seems like a logical thing to do. They both need to be licensed, and both cover copyrights as well as patent rights. They are both nothing more than a set of instructions, one for machines and the other for people with the purpose of being translated to machines. In addition, many specifications include code, and some are written as pseudo-code.
The most important process in any open project is contributions management. From the way in which a contribution is made, through how it is discussed, approved or rejected, to how it is applied to the final product, the process dictates everything else. Any discussion about creating collaborative specifications or software must start from contributions management – otherwise, it is lacking the most important tool needed to produce a successful end result.
What makes the two so fundamentally different, despite their many similarities, is that Open Source contributions are pieces of code. From start to finish they maintain the same representation of machine-readable information. There are no two ways to understand what a piece of code does. Given a well-defined patent, it is possible to conclude if a piece of code infringes it or not. A code contribution is absolute – you either run it or not, it either uses a patent or not, you either contributed it or not. Any decent source control system can tell exactly were each line of code came from.
On the other hand, a specification contribution is almost always prose. It is an idea expressed in a human language, and as such, it is always open for interpretation. While many people can write functional code (pretty, ugly, efficient, wasteful), very few can write quality prose – prose that is likely to be understood the same way by different people, while at the same time, possess the typical properties desired in prose (elegance, efficiency, cultural sensitivity, correctness). For this reason, there are many layers of indirection between the contribution and the final result.
Regardless of how decisions are made about which contribution to include, the role of a specification editor is very different from the role of a software maintainer. Software changes are atomic updates, and are communicated in terms of differences from the current baseline. For many years, UNIX software updates came in the form of a diff file, applied to the kernel source code, and then compiled on each server. As long as the piece of code does what it is supposed to do and understood by a machine, it is good to go.
A contribution to a specification, however, is often communicated on a mailing list, a blog post, or over lunch, and it rarely applied to the specification as-is. It is the role of the editor to figure out how to accommodate the meaning of the contribution to the existing baseline. It is the role of the editor to ensure a consistent voice throughout the specification, which for code can be completely automated. And when people change words, they almost always change the meaning.
The nature of software contributions is what empowers Open Source, allows reusability, derivative work, incremental improvements, and large scale collaborations. Specifications, on the other hand, would be a pile of goo if directly authored by more than a handful of authors or editors.
Intellectual property rights and anti-trust are complicated areas and unfortunately, an integral part of everything we do. Add to that the desire for transparent government, democratic principles, and pragmatic progress, and the challenge of getting a large group of people to agree can get out of hand. The reason why every effort to change the way standards are created has reached the same conclusion and the same uninspiring, limited freedom, is because they are all based on the same primitive tools of managing contributions.
This must not be where our story ends.
The complexities of writing specifications, at least the contributions management part, should not dictate how specifications are created and used, but instead challenge us to come up with better models and tools. If we can develop new technologies and methodologies for bridging the gap between code and specifications, we will truly open the door to the freedom and democratization of ideas and innovation.
This is not simply a matter of making small adjustments (such as taking a mailing-list software and enhancing it to enforce CLA signatures). It requires rethinking the way in which contributions are made, discussed, and applied. Community-based software was around for a long time, but Open Source only became the force of change we know today when the models of creating it matured beyond the collaborative practices of the past.