Please Don’t Confuse Standards with Open Source Software

While standards and FOSS may overlap, they can’t be merged into one mega concept

Some people want to merge the idea of free and open source software with standards, and indeed open the discussion into one of “open standards.” This confuses two ideas that are very different once you get beyond the idea they both involve collaboration in a technology community.

First, they serve very different economic purposes in the marketplace. Standards exist to enable and encourage multiple implementations that can interoperate across the defined boundary of the standard’s specification. A standard with only one implementation, regardless of the imprimatur of a standards organization, is a failure. FOSS projects are by their very nature single collaboratively developed implementations of a technology whether they implement a standard or not.

Formal standards are developed by standards development organizations (SDO) that can be national (e.g. ISO, BSI, ANSI, AFNOR, DIN), industry based (e.g. IEEE), or technology based (e.g. W3C, IETF, OASIS). Each SDO adheres to various rigorous processes for specification development, balloting, maintenance, and retirement. FOSS projects can be developed in formal processes if managed and sponsored by a foundation (e.g. Eclipse or CodePlex Foundation), but are often very informal meritocracies or benevolent dictatorships.

The culture of SDO is very different as well. At their heart they must function as committees, regardless of the community of common interest they represent. Many of the experts that participate are employees of large vendors. It's a game of technology diplomacy, and in the end, after the meetings are over, the job as with all diplomats is to expand one's area of economic influence and defend sovereign territory. The collaboration culture inherent in FOSS projects is about sharing the common costs involved developing a component all can use.

There is a place where standards and FOSS overlap beautifully. If you have one true FOSS implementation that runs universally then you don’t need a standard specification. FOSS can however provide the reference model around which a new standard is created. Standards typically occur when a vendor technology matures and the incumbent starts to over deliver on features consumers don’t want to buy. Consumers begin to complain about price and competitors begin to discuss a specification at an appropriate layer of abstraction. Good standards are based on existing practice and experience. The starting point chosen for a standard is generally a technology base with which all the participants have experimented. When competitors chased the DEC minicomputer market, they did so with the UNIX specification. Everybody had a UNIX variant, and the licensing landscape was well understood. At this point in history, vendors can choose a FOSS project as the starting point for specification, and indeed that is what happened with the Open Document Format (ODF) specification and its ties back to the OpenOffice project.

Standards and FOSS projects serve different economic roles in the marketplace. They are quite different but can complement one another quite well. The other place they overlap is that they are both susceptible to patent abuses, but that is a column for another day.

• economics
• FOSS
• open source
• standards