技术标准化——福兮？祸兮？

诚如Jim Waldo所说，我们生活在一个标准的年代。我们常常不由自主地相信、选择标准。如果一个东西被标准化，我们就认为它开放、稳定、有保障、好用；反之，我们就不敢信任它。

但是，如今的标准也和以前不一样了。在C++和CORBA那里，首先是全世界的人使用它们，他们觉得有彼此兼容的必要，然后为它们订立标准。到了Web Service这里，情况完全倒了个：在看到任何实用价值之前，厂商已经为标准吵翻了天，技术讨论早已变成了政治、商业之争——而作为用户的我们还没用货币投票呢。

太多的标准。我们需要这么多的标准吗？对标准的过度重视甚至依赖是否会损害技术创新和发展？To be standardized or no to be, this is the question.

---

Artima Weblogs

Why Standards?

by Jim Waldo
May 18, 2003

Summary
Common wisdom, especially in distributed computing, says that the right approach to all problems is to use a standard. This common wisdom has no basis in fact or history, and is curtailing innovation and rewarding bad behavior in our industry.

---

We are living in the era of standards. Technology that is a standard is good because it is a standard; if something is blessed as a standard it can be seen as open, non-proprietary, and gets the blessings of the IT managers and the analysts. Something that is not a standard is closed, proprietary, and to be avoided at all costs. This is the received wisdom in our industry; it is so obviously true that we don't even question it, and we seem to get uncomfortable around those who ask why standards should always be used.

This kowtowing to the god of standards is, I believe, doing great damage to our industry, or craft, and our science. It is stifling innovation. It turns technical discussions into political debates. It misunderstands the role that standards have played in the past. Worst of all, it is leading us down absurd technological paths in the quest to follow standards which have never been implemented and aren't the right thing for the problems at hand.

Let's get back to first principles...standards have historically played two roles in our industry. The first role has been to codify what is already common practice in the industry. Such standards are attempts to capture what everyone is already doing, perhaps ironing out some minor inconsistencies along the way. But such a standards effort is at base a descriptive one. The original IP standard was such a beast; so was the ANSI C standard. Neither attempted to invent much of anything; both simply tried to make clear what everyone was already using. The standards being described were already de facto standards; writing them down was a documentation job that either got it right or missed the mark.

This is very different from a standards effort that attempts to invent the standard from the ground up. Such a standards effort is not descriptive, but rather an attempt to invent by committee. There is no common practice to describe; instead the standards group is trying to tell everyone what they should be doing in the future. The ANSI C++ committee, which started out as a descriptive body, became one of these sorts of standards groups when it was decided that they should "improve" the language. Many of the Object Management Group (OMG) Common Object Request Broker Architecture (CORBA) Common Services groups were this sort of standards body. There are lots of others around now; I'm sure you can name many of them so I won't. These are the de jure standards groups, and they are the ruin of our industry.

Those of you who have been part of a de jure standard effort know what I mean when I say that they turn all technical questions into political ones. Discussions may appear to center around the technology, but the real decisions are made either in setting up the requirements (beware the use case, my son) or in meetings outside of the general discussions between subsets of the committee who trade votes like Chicago precinct bosses. The ultimate threat in such organizations is that some of the founding (or important) members will split off and start a competing standards group, which seems to be happening on a weekly basis in some of these discussions. The real goal in all of this, of course, is to get your competitors to (unknowingly) agree to some approach to technology that you and your company already have in a product (either shipping or ready to go). Then what would otherwise be proprietary can now be seen as an "open" standard. Just an open standard that only you have.

What gets lost in all of this, of course, is whether the technology being blessed by the standard actually helps the customer to solve a real problem. Can the standard be implemented? Will the implementation perform adequately? How much will it cost? All of these sorts of questions are not appropriate in the era of de jure standards.

What is also forgotten in all of this is how fragile the de jure standards have been in the past. I can't think of a single standard that was invented by committee that has survived in the marketplace. The long-standing standards are those that were first de facto standards, and were described (no invented) by the standards bodies.

Such standards didn't start out in a standards body. They started out solving problems. Because they solved the problems, people used them. The use drove the standard, not the other way around. This allows innovation, this allows technical progress. Things that work get used by people who are trying to solve problems.

This does take the decision making power out of the hands of the managers, and the IT departments, and the technical analysts. They aren't trying to solve problems in new ways; they are trying to lead parades, or keep their jobs, or show that they have influence. They aren't the engineers that can actually understand the solutions, but they do (for the most part) understand politics. Standards groups cater to their expertise, not the expertise of the engineer.

Of course, this hard dichotomy is something of a caricature. There are substantive discussion of technical merit in standards groups that are trying to invent. But that isn't all that goes on. And certainly there is little evidence that the best technology wins in such groups. Just look around you for evidence of that.

So the next time you are talking to a manager and he or she tells you that you have to use something "because it is a standard", push back. Ask why only standards can be used. Ask if the standard has actually been implemented, or if the standard will really solve the problem under discussion. For that matter, ask if the manager really knows what the standard is. If any of these questions can't be clearly answered, may the standard isn't the way you should approach your problem.

Talk Back!

Have an opinion? Readers have already posted 8 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.

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.

This weblog entry is Copyright © 2003 Jim Waldo. All rights reserved.