My last post has driven some great discussion around what an open standard means. Heck, I think I was writing about “open” issues back in March of 2005. One could almost say it has become thematic.

Given the comments from my last post, I thought it would be useful to write out the analogy that was used to help my over-ripe grapefruit of a brain to understand the basics on standards. That way we’re all talking about the same thing. Here is how a very, very, very smart lady (thanks Michele) made a complex system into a simple analogy (paraphrasing of course).

The Warehouse

Think of standards organizations like a warehouse. There is a front door, interior workspace with many tables distributed around, and a loading doc at the back. People who want to work in this warehouse walk in the front door and find the table that interests them. Some of the people walking in the door have buckets full of ideas. Those buckets get brought in and dumped on the appropriate table and the people at that table use the contents of the bucket, plus their own ideas, as the basis for a discussion that ultimately ends up in a specification…a stack of paper that describes a technology. Once the spec is ready, it gets sent to the loading doc where anyone can drive up to the loading doc, pick up the spec and drive away to go build the technology (finally resulting in some software).

In this picture, the “warehouse” is really a legal framework that protects all parties in the process. The people walking in the door who want to participate, the people bringing contributions, the parties involved with the creation of the spec, and the people coming to the loading doc who want to implement. The framework creates a trust model that encourages contribution, participation, implementation, and long-term improvement of the specification. The warehouse allows competitors to work together and to feel comfortable that they are protected from the ideas shared being used against them, enables them to work together without running afoul of anti-trust laws, and creates the mechanisms of trust that encourage the implementers to implement as they are dealt within a uniform and consistent way by the contributors.

Every warehouse is different (lots and lots of standards orgs out there), some have strict rules, some more lax. But they all (in theory) have rules and restrictions designed to foster an environment where standards work happens.

Yeah?–So What

The point I was making in my last post is that this idealized “warehouse” works best when in balance. People seem to be very wrapped up in the discussion of royalties, but they make up only a part of this discussion. The analogy I used in my last post about limitation of scope is critical to this. The same is true for defensive suspension.

To dig deeper on that point, (I’m not a lawyer), my understanding of defensive suspension is that it creates a disincentive for litigation. Which is a good thing. But it is also a mechanism where the contributor (if sued) can revoke rights to the covered IP. So that breaks the idea of “open standards” = no limitations on IP.

The warehouse will work best when it is full of people, rather than when the front door is only opened to a few people. As I said in my last post, I think Rick was right to argue for the fact that standards orgs are better off with more participation. More people around the table, more interested parties willing to put their resources toward working on interoperability. More opportunities for people to go build great solutions thus leading to those standards having greater marketplace relevance.

The “so what” here is that the structure of the warehouses we all work in matter. If you only look through the lens of implementers, the system becomes hostile to contributors. If you only look through the lens of contributors, you end up with standards that no one uses, and the implementers will find other ways to solve their problems (probably with a good deal less interoperability). Microsoft is both contributor to and implementer of hundreds and hundreds of standards. The same is true for many software firms. It is better for everyone if both sides are considered when thinking about the future of standardization.

For the past 8 years the entire software industry has been moving to the middle on the hybridization of business and development models as everyone continues to look for the…dare I say…balance…between core assets, complementary assets, services, and the advantages of community. One of the more interesting (for industry wonks like me) by-products of that process is a clash between traditional standardization models and the modern meme of collaborative development.