Slashdot Mirror
Are Standards Groups Stifling Innovation?
cpfeifer writes "Jim Waldo expresses a a controversial viewpoint in his blog: "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. " He also goes on to clarify his position and explain his reasoning."
No agreed-upon standards, no consistent format, no market. That's why North America is just barely getting into HDTV now, when Japan and Germany have had it for a decade.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
RFC 3268 describes the way you should use the Advanced Encryption Standard with SSL/TLS.
My experiences weren't at all like the ones described in the article, even though we certainly weren't codifying existing practice. No one threatened to leave and join a rival standards effort, even though AES over TLS is important for government contracts. Most of the argument was about the minutiae of the protocol. For example there was a long discussion about the padding type and cipher mode of operation.
The problem I had was that the process is horribly slow. There are a few people in the IETF who have a lot of work to do, and you tend to find yourself sitting in a queue for a long time.
That said, I think it was a very worthwhile thing to do. If we hadn't done AES through the IETF, no one could have interoperated. It wouldn't be a case of then codifying existing practice a few years on because it simply wouldn't work. The different TLS implementations need to use the same ciphersuite numbers for example. Much better to sort that out on an IETF mailing list than try to cobble something together in a series of bilateral discussions.
First, a few examples... without ISA and PCI, we wouldn't have any hardware devices that we could just plug in to our computers. Without DirectX, OpenGL, and SDL, we wouldn't have games that could run on multiple platforms. Without TCP, I wouldn't be able to post on slashdot.
Standards are extremely important to computing, but not in the way decried in the article. Standards are not cool for their own sake, they're powerful because they enable modularity and layering, the true holy grails of effective computing. The designer of your network card didn't have to think about what the CPU in your machine was doing, or even whether there's a CPU at all! As long as it handled the specified PCI signals, it will operate correctly in a "standard" PCI system. Likewise, the game developers can use the same OpenGL calls to communicate with many different video cards, because the drivers fulfill the requirements of the standard.
Standards help to erect useful barriers between logical layers of software and hardware. Like anything, they can be misapplied, and using standards "just because they're standards" can often lead to trouble. Still, well-done standards are and will be the foundation just about any successful computing architecture.
He isn't to be taken lightly. Jim developed the first ORB, was the lead architect of Jini and he had prominent role in RMI. However, the most interesting thing about him is that he holds masters in linguistics and philosophy (in addition to his PhD in distributed computing).
I attended a session of his on Jini at the WTC. Hmmm....
This isn't exactly a new view. James Gosling's classic Phase Relationships in the Standardization Process is already 13 years old.
-Tom Duff
The IEEE has a voting system where votes are assigned to individually that have attended 3 consecutive meeting (held about every 2 months). This is supposed to make the standards process more egalitarian. But what really happens is that it is only the large corporations that can afford to send someone to a meeting every 2 months. Lots of the people in this meeting just come, sign the book, get out their laptop and start working on something else. So the standards are strongly corporate driven, and the votes are therefore usually driven by issues other than technical merit.
The "down-selection" process of the IEEE then forces these disparate industrial players to come to some sort of compromise. This either takes the shape of one large block of companies getting behind a single standard and blocking other proposals, or all the standards being wrapped up as options of a single standard. Neither of these will necessarily have any relationship to technical merit, with the second option being a sort of "non-standard" Standard.
As you see, I rather sympathize with the original article, mainly because I don't like the standards process as it stands. The thing is I don't think many people do, but I'm not sure I see how it could be done better.
I disagree though about your negative characterization of SSL. SSLv2 was a bad (unsafe) half-baked protocol thrown together by a Netscape engineer with little cryptography knowledge. SSLv3, however, was a complete redesign done mainly by Paul Kocher, a very knowledgeable cryptographer. SSLv3 was basically sound, so when it came time to make TLS (the RFC-blessed one), very few tweaks were necessary. There are no really "bone-headed" mistakes in SSLv3 or TLS, but there are many in SSLv2.
The SSH standard is indeed quite different from the original SSH.com stuff, but the with the standard now in place (after the technology was developed), it is easy for say OpenSSH and SSH.com to interoperate by following the standard.
Also. the expert bake-off is indeed a good way to make a standard (much better than having a committee design). The AES competition is a very good example of this.
Lets say I wanted to write a client to transfer files via the internet. I could just write my own from scratch, looking at low-level socket communication. Oh! Wait a minute, I ran into a standard, the TCP/IP stack. Nah, I'll use UDP. D'oh! Ran into another standard.
Despite the slashdot headline, his point was not that standards themselves stifle innovation, but that pre-emptively creating standards before technology has a chance to mature stifles innovation.
In the case of TCP/IP and UDP, these became de facto standards not because some panel of experts agreed on them, but because they earned their place by becoming more popular than rival standards (maybe IPX/SPX, etc.).
They were only accepted as de jure standards long after they had were de facto standards.