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
A good real-world case study of premature standardization is W3C XForms. I had a discussion back in April with the XFroms community and spec leads on the www-forms@w3.org mailing list that you might wonna check out.
See the threads entitled "Welcome to the Real-World; The Future of XForms" and "The Devil of Good is Perfect", for example.
Another good real-world case study using the "build it first and standarize later" approach is XUL (XML UI Language). Innovation using XML to build UIs is flourishing and slowy a XUL community is emerging. For getting started with XUL check out the XUL Alliance Link-opida and see a replay of the original HTML story in the upcoming XUL browser wars and standardization drive and more.
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.
By giving the stack away, maybe we can stop everyone obsessing over how to format the bits on the wire, and get them writing applications instead.
So very true. Standardizing in one area may slow down innovation in *that* area, but by doing so, speed up innovation in another area that depends on it.
Visit http://ringbreak.dnd.utwente.nl/~mrjb/growingbettersoftware to download your free copy of the book
Artima has been /.-ed, so I can't answer the question in how Jim's using the word in this discussion.
....well, unfortunately, I don't consider them standards body. They tried to get their act together too long after the Web revolution happened, tried to muster the push to make everyone play together, and now they're used as more of a tool by companies trying to prove what THEY'RE doing is the right thing, as opposed to another company, just because of a standard they are pushing throught W3C.
XML syntax is a standard. Agreed upon DTDs might be a standard, but I don't know too many of those.
The Java lanuage itself is a standard.
I would say that CORBA is a standard....And btw, Jim Waldo was one of the originators of that standard, so he knows that the hell he's talking about.
W3C
Design by committee, which I think he's talking about here, is an evil evil thing.
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.
I read the clarification, and soon thought "this guy is talking about Java and .NET, and he is on the Java side". Then I reached the bottom of the page and saw that he is employed by Sun...
Finally! A year of moderation! Ready for 2019?
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.
If it would just stream multiple files across the same connection, it would help tremendously with transfers involving a lot of files. For example, uploading a few hundred HTML files, jpg and png images, etc.
Please consider making an automatic monthly recurring donation to the EFF
Unless you're prepared to duplicate TCP's carefully designed flow control, you're either going to underutilize the path or saturate the slowest link (on an ordinary network without traffic shaping, that amounts to a DoS attack).
Once you solve this problem, you basically have TCP with a very large receive window, which is only an improvement if a selective ACK is dropped while the advertised window is full. In fact waiting until EOF to request retransmissions imposes an idle period on the sender after sending EOF, while TCP can pipeline retransmissions along with new data.
headline
<p>Paragraph one has something to say</p>
<h2>Something is related</h2>
<p>Which is why paragraph two is relevant</p>
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
poll is standard (POSIX.1). select is just an old BSDism.