Summary
Having whacked the hornet's nest once, I take another swing, trying to clarify what I was trying to say originally. Is that a buzzing I hear?

When I posted my last entry, I realized that I might be stirring up a hornet's nest. Indeed, I could hear the buzzing just before I pressed the submit button, and almost decided against it. Such good sense has never been my hallmark in the past, however, nor did it overcome my hope that I wouldn't regret the posting. While I don't regret it, it has been instructive to listen to the replies. Some have been well-thought out, others not so much. But the replies did make me realize that I had posted in haste in one respect, since the main points I was trying to make have not seemed to have come through clearly.

So I'll try again. I'm hoping that the second time will be the charm. Either I will make my points more clearly, or I'll realize that they can't be made. So here goes...

Point one: Just because something is called a standard doesn't make it open; and something that isn't a standard is not, because of that, proprietary. The standard/non-standard and open/proprietary dimensions are orthogonal. Certainly, there are lots of technologies that are standards and are also open, but there is no causal connection between the two properties. Just look at the controversy in a number of standards groups right now as to the granting of intellectual property when contributing to a standard. If being a standard made something open, there would be no such controversy. In the same way, there are things that aren't standards that are quite open...look at most of the open or community software that hasn't been formally standardized. The source code is free for the taking; the reuse of that code is determined by more or less restrictive licenses. There are plenty that are very open, even though they are not standard.

The real point here is that whether something is open or proprietary depends on things like the licensing model, the intellectual property grants, and other sorts of legal notions around the technology. Whether or not something is a standard depends on acceptance by some standards group. Barring some connection between the two (which, by the way, a number of standards groups are trying to construct), there is no connection between the two. A simple point, but one that often gets lost.

Point two: A standards body is often a lousy place in which to invent a technology. This is the essence of what I was trying to get at by distinguishing between de facto and de jure standards. Technology, I would claim, is best invented or designed by one person or a small group of people, working together for a common goal that all of them understand and agree to. While there can be a standards group that meets this description, it is rarely the case that standards groups do. More generally, such groups are made up of a rather large group, each member of which is pushing for the good of his or her own company or interest group. Such a group can actually be a good thing if you are trying to determine which of a group of existing technologies will get the widest adoption, but they tend to be bad at creating a coherent, efficient, and elegant design from whole cloth.

This doesn't mean that such a group can't ever produce a good technology. There is no logical impossibility that is meant to be implied here. And while I would be surprised, I could be convinced that a good technology had actually been created by such a diverse group. But I don't personally know of any examples.

Notice, by the way, that there can be a small group of people with a common goal who work together towards an understood and agreed to end that calls itself a standards group. Many of the IETF's early working groups were just such organizations. But once a standard is seen as commercially important, it is much less likely that the standards group will be made up of such technologists. Again, this is a personal observation, not a logical truth.

Point three: The previous posting was not a veiled (thinly or otherwise) attack on any particular standards group or collection of standards groups. I was not trying to pick on J2EE, or XML, or SOAP, or W3C, or IETF, or... I actually don't watch the standards groups closely enough these days to want to pick on any particular group. There is blame enough to go around in this area. I do remember, about a year ago, when I was paying enough attention to notice that there was a new standards effort starting up on average of once a week, and a new standards organization starting up on average of once a month. Many of these groups and organizations were trying to standardize the same activities. Which leads me to...

Point four: If there are multiple groups competing to write a standard for the same thing, it is probably a safe bet that the technology being standardized isn't ready for standardization. This is the point I was really trying to make, but didn't state explicitly. But this is the one that I think is important for all of us who are trying to produce and use technology to understand.

It is unfortunate that many technology businesses have decided that it is a good competitive strategy to declare their own solution to some problem a standard, and label other approaches to that problem proprietary. Often this is done by creating a standards group which will give that company (or some small set of companies) enough cover that they can claim that the standard is in fact independent. Recently, this has gone even a step further, as companies start us standards groups to create a standard technology.

There is no one company that is doing this sort of thing; indeed, this is another area where there is plenty of blame to go around. But it doesn't matter what company or group of companies is doing it; it is a bad thing for innovation. The whole point of this exercise is to try to pre-empt any innovation in an area, and instead negotiate some solution that will advantage the founding companies in an attempt to force the industry into adopting that solution. The adoption is driven not by the technical excellence of the approach, but because it is a standard. This is the sort of thing that I find objectionable, and the sort of thing that I believe hurts the industry.

Once again (re-read point three), I'm not trying to single out any particular standardization effort. If you are involved in some standards group and think I'm talking about you, then perhaps I am, but not about you only. There are lots of examples, and when I'm writing this I really don't have any particular example that I am talking about.

What I'm really talking about, I'm afraid, is an industry that has lost the courage to actually innovate on the belief that a better solution will win in the marketplace. Instead we now have an industry that seems driven by the hope that the marketing noise made around establishing a fake standard will make our customers forget that there is little of value that we are providing. Such an industry is ripe for harvesting by some company (probably a small one) taking over by introducing something that is really innovative. We can all think of examples of where this happened in the past. I don't think things have changed so much that it won't happen again in the future.

Talk Back!

Have an opinion? Readers have already posted 11 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Jim Waldo adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Jim Waldo is a Distinguished Engineer with Sun Microsystems, where he is the lead architect for Jini, a distributed programming system based on Java. Prior to Jini, Jim worked in JavaSoft and Sun Microsystems Laboratories, where he did research in the areas of object-oriented programming and systems, distributed computing, and user environments. Before joining Sun, Jim spent eight years at Apollo Computer and Hewlett Packard working in the areas of distributed object systems, user interfaces, class libraries, text and internationalization. While at HP, he led the design and development of the first Object Request Broker, and was instrumental in getting that technology incorporated into the first OMG CORBA specification.