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."
Obviously, standards only emerge when a practice has been agreed upon. Further innovation leads to a development of a new standard.
will slow down progress, yes. Because no matter how forward-thinking the people are who make the standards, there an infinite number of things that they can not anticipate.
But still, working within standards is necessary to bring past inventions and innovations to the masses.
Certainly, if you are working on some cutting edge project in the MIT AI labs, you don't need to worry too much about the RFCs. But ten years later when someone is trying to bring that product to the public, standards become tremendously important.
Lack of standards alowed the web to develop at an enormous rate, but then it was the introduction of standards that actually made it usable by the avergae person.
lysergically yours
We have standards for a reason.
Would you like to buy a cd only to find out that it will only work on X cdplayer? or a device that's only able to run if you're with Z electricity company?
Be you Admins? nay, we are but lusers!
Read http://java.sun.com/people/jag/StandardsPhases/ind ex.html
People and companies do
If you design a website according to spec, you're going to have close to 95% (i.e. IE users) of web browsers incorrectly displaying the website. I HATE this. I am new to web development in general, I've barely got a year of programming behind me and I find it easiest when I can read exactly what I can/can't or should/shouldn't use. I've written pages that render perfectly under Gecko and KHTML but whatever pile of ass that MS is using makes it look horrible, and I must rework.
Ah, but we can choose! If it made a damn bit of difference to the people attached to those web browsers they might complain or outright switch. But the inconvenience or ignorance of switching drives people to stay where they are, comfortably annoying those of us who have a hard enough time learning stuff, let alone learning it correctly then incorrectly.
but they also allow people to work together. What if you had to learn a different TCP/IP stack everytime you changed jobs? Wouldn't be any fun now, would it? Even in the middle ages, people used standards. Stone masons had standard measuring units (don't remember what they were though. Any ideas?) that enabled them to travel across the country and find work. Sure, there will alway be differences, but minor ones. Besides, everything new starts out with not being a standard. Inventors work to create standards so that their product can be used by as many people as possible.
Now, if that makes sense to anyone, could you please explain it to me? I think I've confused myself.
I think one main point of contention is that standards are for integration and only indirectly affects innovation. Sure I could create a new video format, but unless I get to play nice with video players, it's useless to anybody. While it slows down development initially, standards help to speed and ease adoption of new technology later.
Well, there's spam egg sausage and spam, that's not got much spam in it.
Standards are important. Standards make moving from one system to another easier. Standards make understanding a system easier because the general traits relay over.
That is why there are standards. What is the point of innovation to a system which is accepted, and enjoyed?
You could add innovation to coffee pots. Numerous different brands of coffee pots all with gadjets that you must study before using.
Well I just want coffee. I don't care if you can make my coffee in a variety of new an innovative ways. I want to hit a button, walk away, and in a various ammount of time afterwards have coffee.
I want to view a webpage. I want content. I don't want new and innovative ways to view the content, Just give me the webpage.
Once something works, and works well, I could care less about innovation as it concerns changing what works.
If it ain't broke.
http://use.perl.org
Wireless networking had been out for years before 802.11b. To this day, 802.11a and 802.11g are out, but most people are still using B. Why? It works, it works well, and everybody has it.
Working in networking, my job would be 3 times worse if everyone didn't order the wires in a standard way. Can you picture if every network vendor had a different jack? If you want a confusing an annoying time, try buying a circuit breaker. Every manufacturer uses a different style. Some have 2 or 3 styles.
Standards are the building blocks that allow us to have a predicable environment on which true innovation is based. Innovation is not about re-inventing the wheel. It's about slapping and engine on 4 of them, and driving with it.
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
Or you can support multiple standards and talk to any client. Nobody ever said that supporting one standard means that you can't support others at the same time.
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.
Now, let's say that I've written my FTP-like transfer system using low-level sockets, but I don't follow the FTP standard. Does this mean that I've limited my creativity? Absolutely not. I've done this, and to be honest with you, there are a lot of ways to speed up FTP. So while I'm not using the FTP "standard", I am using it as a basis for my own innovative way to transfer data, at a rate that can be 2-3x faster, depending on the network.
Stiffling innovation indeed...
I head your email...
Who is John Galt?
It's not an issue, because something clearly better will emerge due to necesity and break the standard. Always has. Always will.
Deja Moo: The feeling you have heard this bull before
Actually, the gas station thing has happened. When the big shift from leaded to (mandatory) unleaded happened, "they" made the nozzle for the unleaded slightly smaller than the leaded nozzle. They also changed the size of the filler hole to match - so it is impossible to accidentally fill a unleaded car with leaded gas.
Strangely, on my old car ('65 356), the filler hole is damm near big enough to put a coke can in, much less any of the available gas nozzles. Oh well, as long as I don't grab the deisel one by mistake, I'm fine...
Don't blame me, I voted for Kodos
his last point from part 2:
.doc. But, more often than not, the exact opposite happens. 56k modem sales stagnated for a *eay* when they were introduced with two standards--x2 and k56flex. Only the richest (relatively speaking) early adopters bought them for the longest time because there was no way to know if you'd be able to use it in the future. Different ISPs supported different standards at different times, and who knew what woudl happen if your ISP changed preferred technologies, or went under, or got bought, or if you switched ISPs yourself for whatever reason? Most people knew that there would eventually be just one standard in the future and had know way to know if that new standard would be backwards-compatible with x2, k56, neither, or both. Then, along came v.90 and everything was great.
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.
One point he misses--as often than not, its due to greed. Companies want to have *the* standard and as close to 100% as possible of the revenue from that product's market. Look how far MS has gotten with
The best quote I've ever seen on the subject comes from openh323.org's home page: "The aim is to 'commodotisetheprotocol'. 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."
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
they ended up with something so complicated that nobody has ever implemented it fully (X.509*)
Indeed X.509 is a terrible standard (trust me, I've implemented... oh, maybe 20-30% of it, which is about as much as anyone ever does, or can stomach). Part of the problem does come from the lower levels (ASN.1 and DER/BER), which X.509 can't really do anything about. For example, most of the ASN.1 string types are truly insane, designed for use with Minitel or S/360 or something even stranger.
OTOH, I wouldn't necessarily agree that SSL/TLS is that fantastic either, because basically TLS is just SSLv3 with some tweaks, and SSLv3 was basically whatever Netscape & Co thought was a good idea at the time, leading to some (IMO) fairly bone-headed mistakes. Same with SSH - the IETF standard SSH is quite different from the old ssh.com's SSHv2 implementations.
The really good standards (and, as I've always understood it, the typical IETF way of doing RFCs), is to say "We want something to do X", and let three or four really good independent groups take a crack at it. Then pick the best one, stealing any good ideas from the others along the way.
Innovation is exploration, discovering the best solution to specific problems through the various techniques we use: scattershot, imagination, design, etc. This is largely an individual enterprise - innovation by committee is a joke.
Standardization happens later on the curve when the best innovations have been tested in real life (though with a limited audience). Then, a skilled committe will merge several innovations into a standard, and define a basis for dividing-up large problems.
Standards are interfaces between groups working on different aspects of a problem. Innovation allows one to understand what these aspects might be, and later to repeat the same process on smaller problems.
Using the "divide and rule" metaphor, standards are the "divide" and innovation is the "rule". Only it's rule and divide and rule and divide and rule ad infinitum. You really should not try to divide and rule at the same time.
Sig for sale or rent. One previous user. Inquire within.
IEEE, IETF, IANA... These standards groups have been around a long time & have earned major credibility for making crucial decisions at the right time. That's really what it's all about when developing & setting standards and henceforth establishing standards groups, no? The subsequent credibility of a standards group follows the standards the group signs off on. If it had been a proprietary group like Wintel instead of J. Postel back in the early 80s we wouldn't have gotten TCP/IP and the RFC system when we did. Therefore I think standards groups for the standards groups are needed, now more than ever. It's like oversight for oversight. We don't have a lack of standards. Far from it, we have a lack of central, accountable organization bodies made up of counselors or commissioners who transparently decide on standards. With time it is this transparency that will earn respect in the international online standards community, not bags of cash and not closed-door meetings seeking out the highest bidder we've been thru that before it doesn't work for the majority commons.
I returned to Canada after spending 5-1/2 years in the U.S. Naturally, I am comfortable with both metric and English measurement systems, but...
Recently, I went into a shop, got a bunch of stuff and went z. Diet Coke I told the shopkeeper, "I forgot my Coke. Charge me and I'll grab it on the way out." As the shopkeeper knew me, this wasn't odd. But, he had no idea what a 20oz Coke was -- and I didn't realize that it was my use of ounces that was confusing him.
In Canada, soft drinks generally come in 2 litre, one litre, 750 milliliter (well, when the bottles were glass, they used to), bottles; smaller plastic bottles, and cans. The cans are nominally 355 ml (10 oz.) and the small plastic bottles 591 or 600 ml. (20 oz.). Now, no one asks for a 355 ml. soft drink -- they ask for "a can of XXX", the "can" being an implied unit of soft drink volume measurement.
As my only experience with 20 oz soft drink bottles was in the U.S., I didn't think in terms of a 591 (nominally 600) ml. bottle, but rather a 20 oz. bottle -- I figured that the shopkeeper would respond, "Oh, you mean a 600 ml. bottle", and I'd reply, "Duh! I'm back in Canada... yeah, that sounds right." But, instead, he was utterly confused and not indicating that his confusion stemmed from my use of an unfamiliar volume measurement (which would have clued me in).
Now the funny thing is I can still get a proper 20oz pint of beer at the pub! -- none of this 500 ml. shit. As someone with a scientific bent, I appreciate the metric (base-10) system, and usually convert easily, but damn it: beer is meant to be dispensed in pints, yards, and barrels! Booze, of course, is sold in "fifths".
You could've hired me.
Take a look at the select(2) system call. It seems to serve a useful purpose: it allows a single program thread to wait for activity on multiple network connections at once.
Back when select() was created, a process could only have 32 connections open at a time, maximum. So, the guy who invented the call decided that the caller could use 32-bit integers to represent lists of connections. You just set the bits corresponding to the connection numbers you want to watch and leave the other bits as zero. Then, the system alters the list in-place before it returns to indicate which connections are active.
Well, now adays, a program can have a few more than 32 connections open. However, for standards' sake, select() still uses bit fields. In Linux, these bit fields are something like 8k in size. Since they are altered in place when you call select(), you have to set them up fresh every time you call it. Then, the OS has to scan through them all and set up each connection for waiting. This is *slow*.
Much better methods of waiting on multiple connections have been developed. The best methods involve an event queue. You then tell each connection you want to watch to always place an event on the queue when it receives data. This way, the OS doesn't have to set up every connection all over again every single time you wait for activity. FreeBSD has an interface for this called "kernel queues" which is quite nice. Windows has all sorts of convoluted interfaces for it. Linux only just recently came up with a semi-decent interface called "epoll", but it is rather limited in some ways. In any case, all of these interfaces are different.
Unfortunately, select() has stuck because it is a standard. People use it because it works everywhere. It works everywhere because people use it. However, it is, IMO, one of the worst system calls I've ever soon.
This is why my basic opinion on standards is, "Standards are great as long as they don't suck!"
Actually, sadly, we are heading in this direction. Currently the standards are CD Audio and DVD for Video. However, new higher-density discs (DVD's and future blue-laser systems) as well as newer video codecs (think DivX) and audio codecs (MP3/Ogg) and high-definition audio streams (5.1 channel/DTS/Dolby) are about to seriously cause this "my disc doesn't fit in you player" thing again.
There are multiple standards for audio on a DVD disc. And then there is SACD (Super Audio CD) which is compatible with CD players, but now always).
And never mind DVD+-RW/RAM and God know what else. The DVD FAQ has a large compatibility matrix. Check it out and be scared.
With the the advent of blue lasers storage capacities of 25 Gigs per disc now become possible. And there a several competing disc formats to take advantage of this. To quote the DVD FAQ: "There are now at least 5 candidates for high-definition DVD:" (section 6.5).
http://www.dvddemystified.com/dvdfaq.html
Except now for physical disc formats there is also the issue of the logical encoding of media streams on the disc. I cannot remember how many times windows's media player could not find the codec.
OK, fiar enough, there is load of research into videocompression going on right now (even in image compression, witness JPEG2000 which uses wavelets).
Things are going to be worse before they get better for the next 10 years or so.
Interestingly, a friend of my dad has a large collection of old (as in pre-WWII) record and wax cylinder players. Many of those things were not compatible with each other either. Standards wars raged for many years.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
XML isn't necessarily supposed to be simpler or easier, but it is supposed to be "easy enough", and consistent. IT would be nice if all config files in an OS standardized on XML so they all used a single, well understood, well-written shared-library parser. XML is obscenely verbose, and that takes it out of the running for several applications, but as a standard it shines.
My brother had free email access, but attachments were not allowed. He wanted some of his programs emailed to him.
What I did was first write a *very* short program similar to UUENCODE that broke the program into ascii, and another that reassembled it. I did it all in assembler using DOS Debug, so the decoding program was quite short: something like 90 bytes.
I then output it, data wise (d 100-28C) to a stream, collected it, edited the stream to a series of data entry commands (e 80 42 4C 81...),
and posted it on the email. Told him "Clip this, save as myfile.inp, also as decode.com, and then type C>debug decode.com myfile.inp". He did, and he had a reception program. That worked for about 3 files, but on the fourth it choked. Turned out that =20= was a special symbol that didn't transmit. I reprogrammed around it, sent that, and after that we had a nice little way to send and recieve programs via email.
No standards, except for the knowledge that he'd have a version of DOS Debug on his computer, too.
All of which totally misses your point, I know. But it was an interesting exercise.
Correct Horse Battery Staple: 72 bits of entropy. Enter "Correct H" into google. When it generates the phrase, that's
After way too many years dealing with standards, I've learned a couple of things - your milage may, as always, vary... There's no reason why standards must stifle innovation, but they often do. The most common causes I've seen have been: committees of more than three (plus/minus two) are bad places to try to innovate, agendas & innovation often don't mix well, & the number one reason is that all too often, standards are proposed without thinking through the actual implementation. The most effective standards I've seen have been the work of a very small group that shared a technical vision but didn't have a political agenda & that had already implemented something based on their proposal... Perhaps standards are not the best vehicle for innovation...
entropy requires no maintenance
I know of no browser that has completely supported any W3C standard, and I know of no browser that has NOT introduced proprietary solutions. No browser has implemented complete Unicode support yet, and Unicode has been around for like, how many years? Hacks that I had to use in 1996 to write Greek (font face=symbol) don't work in Mozilla but at least you can still count on IE5.5 to read the tag. Today, I have to write Greek in Ascii escaped characters that only partially work in some browsers (not Netscape 4.X). Mac 9/10 won't read sans-serif fonts in IE 5.0, and won't recognize the break tag. It's absolutely crazy that one Standard was not agreed on 5 years ago and implemented by all the browser vendors. The difference comes between Standards Advocates (free, open, liberal) and Browser Vendors (proprietary, closed, conservative).
But I do like Amaya and I use it a lot to check my html. So the W3C has produced some good things. But the Standards roller derby should settle down, quit deprecating useful stuff, and concentrate on creating innovative useful stuff in their new projects and ongoing activities.
Consider the current "advance" from HTML to XHTML proposed by W3C. Is this an advance? At one time, anybody could write a valid HTML page with a text edit using a minimum of tags. If the person happened to use some "proprietary extension," that part of the code was simply not rendered properly in browsers that didn't support that extension. But a person could write a perfectly valid, cross platform web page using a basic set of tags & attributes.
If we look toward XHMTL, the person would not be able to produce a single page but would have to use HTML and a stylesheet, just to reproduce what worked perfectly well with the tag-extension system. Presumably, XHTML will weed out a lot of hobbyists & force the rest to buy increasingly expensive software to manage the development process.
Take a look at the prices for W3C membership. The "standards body" thus becomes dominated by "the industry" (which has reasons for wanting to promote increasingly expensive development tools) & academe (which has reasons for wanting all web page authors to have to enroll in its classes).
Yes, without standards we get stuck in a Tower of Babel. But the trend to increasingly complicated standards & wholesale deprecation of accepted practice reeks of being more than a bit self-serving to those who can afford membership in the "standards bodies"...
Again, my .02. YMMV. WWFD?
"Obviously, I'm not an IBM computer any more than I'm an ashtray" (Bob Dylan)
Microsoft wanted credit for creating standards and being innovative, so they launched an assault of crappy standards at the IETF. In most cases they wound up publishing an informational RFC (as should have happened), but in several instances they published experimental or standards track RFCs. Some of these were good (as MS has some very smart people working for them), but many were bad, showed serious lack of understanding in their design space, duplicated the functions of one or more exisiting protocols, and ignored standard conventions in field placement.
Documents like those mentioned above lead to the complaints I get fairly regularly from marketing in my current job, the complaints are all along the lines of: "you don't support RFC xyz" (where RFC xyz is informational describing a vendor specific extension, or experimental). My reply is that we studied the document, determined the cost of supporting the feature, and decided not to.
This sets off a little firestorm every time. "But it's an RFC and customer blah blah blah is demanding it", not understanding or caring about the diffence in RFC types or the fact that most of our equipment cannot support the extension in question. It has that magic title and we have to support it, despite the fact that there is often another way within existing, proven, and implemented standards to accomplish the task.
[Set Cain on fire and steal his lute.]
Then you're selecting the wrong standards. First thing's first; you can't reasonably expect any browser, letalone all browsers to properly support all bleeding-edge standards. Your best bet is to select a baseline standard you're going to use, be it one, two, or three year old standards and use those. Find the most current set that all major browsers (IE, Mozilla/Gecko, Opera) support to your satisfaction and use it. All the web design I do works just fine between all major (and even most of the minor) browsrs and it all validates with the W3.
BD Phone Home!
Shameless plug. Like you weren't expecting it.