As some of you know, I suffer from a classic split brain job.
I spend some part of my time dealing with the world of Open Source and the convoluted paths within large corporations, tossing acronyms like GPL, MPL, LAMP, etc. with frightful glee.
I spend the other part of my time dealing in the world of standards, tossing acronyms like Ecma, ISO, W3C, TC, TG, and their ilk around with frightening abandon.
For the last few weeks, I've been head down into the standards world, and hopefully get to come up for air soon ... please?
Anyway, in spending some time thinking about standards and open source, it seems there are synergies and yet major differences.
While each can support the other, they are different, very different.
To quote from a blog entry I wrote some time back:
Openness can exist in many layers, but for shortness, I'm going to break this into some subsets.
1. Programming Interfaces: By making the communication conduits and language (values) available, programs can implicitly exchange information and interoperate. This does require a level of trust in the implementation, since what the program does is hidden. APIs are usually a one sided affair, changes can occur without regards to impact.
2. Specifications: Often you can find specifications that are available without business restrictions, from which you can build a product to manipulate or interchange. For example, back in 1999, SGI released the specification of XFS to allow developers to understand the technology, as well as develop to it. However, specifications can come in two basic flavors: read-only and read-write. Read-only limits the changes to the originating organization without allowing outside input. Often de facto standards fall into the realm. Read-write allows community input.
3. Standards organizations: The nice thing about standards is there is always one to do what you want. The downside is that there are innumerable standards bodies, from industry, through national to international, covering a multitude of arenas with non-standard ways of determining what and how to create a standard.
4. Open Source: Obviously the most open way of communicating is to determine both the content and the intent of any message. By allowing view (and modification) of source, open source delivers a level of openness found in no other layer. However, standardization in open source is only driven by the will of the community.
Now there are certainly nuances and undercurrents. In fact I even think I've added a fifth category from time to time. But anyway, the controversial part:
Open Source and formal standards are often diametrically opposed. And yet, standards enable open source, and open source implements standards.
A while back, I mentioned this to John (Maddog) Hall, while discussing open source within Adobe. John reacted promptly, asserting that open source certainly builds on standards. Absolutely. But open source does not state standards.
Formal standards are specifications. Open source is implementation. Which one is more important to you?
Well, actually, they are both pretty important. It's hard to conceive that even Linux would exist without a widely adopted hardware standard that enabled the asynchronous development from many people and places. But is not a "standard" in a formal sense, it is a standard in an industry practice sense.
A standard is traditionally a consensus driven specification of they way folks want things to work, and are willing to enforce in some sense. This enforcement can take a number of forms, but for simplicity lets call them "legal enforcement" and "will of the community". BTW, legal doesn't always mean "law", a government passing a bill that requires all purchases to include "foo" is also legal.
With a few exceptions, standards are a long evolved process. They need to be driven for the minimum set to derive goodness and not lock out anyone. That's why anything submitted as an industry specification should be able to point to independent implementations outside of the company's control.
Of course, you can mention standards (especially recently) that are neither by consensus nor have independent implementations. (Discovery is left as an exercise to the reader). At that point it's up to you to enforce the will of the community, and express your thoughts on formal standards. Keep in mind that implementation still matters; it's hard to surf the web with ISO/IEC 15445:2000(E).
Open source is still the best conversation for software.
Join us at MAX 2007
