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."
...is having so many to choose from.
Obviously, standards only emerge when a practice has been agreed upon. Further innovation leads to a development of a new standard.
says that the right approach to all problems is to use a standard. This common wisdom has no basis in fact or history
*COUGH* decimal system *COUGH* metric system *COUGH COUGH* posix *COUGH* TCP/IP *COUGH RAAAHHH RAHHH*
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
How many people want to rewire thier houses with a plug system that provides more features or capabilities, but with the added costs of all electronics you purchase at target need an adapter?
Or how about having to worry when you go into the gas station if the nozzle is compatable with your car?
Sure standards slow down innovation, but the costs that the standards provide can be worth it.
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!
I only know of two standards that have ever been of lasting use to me:
0
and
1
Everything else is probably just hype.
Yes standards can be a pain and they can stifle innovation. But there are trade offs. And that is chaos. As much as innovation is a noble goal it has to be traded off with standards.
For example take WiFi. Gee imagine we had ten different WiFi protocols. What would we get? The North American Cellular phone standards where everybody has their own freaken way of doing things.
Yes standards should solve a problem, but standards are required. Imagine everybody deciding by themselves which side of the road to drive on. Or deciding that some people want 40 volts another wants 90 volts, etc.
Why not use defacto standards? Because defacto standards might become out of date standards. This is not to say that they should not be investigated, but if there is a standard that works use it....
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
without standards, innovation takes place in less discrete steps. it is not clear when "the next level" has been reached. perhaps in some cases standards stifle, but they really are necessary in my opinion (and the opinions of others, of course) if concerted progress is to be possible .
I think, if the standards get in the way of innovation, the would-be innovators buck the standard.
Remember the standardized user interface that was one of the early Mac OS's strengths over the other OS's out there? One of the big players back then, I think it was Adobe, "broke" Apple's GUI standards where the designers deemed it to be necessary; neither their product nor the Mac OS suffered as a result.
Standards are good where they are needed, but when they hold things back....
Don't blame Durga. I voted for Centauri.
Standard protocols may suck, but at least they suck in well-known and well-understood ways.
-- Ed Avis ed@membled.com
He's not saying that standards are bad, as much as he's saying that it may be better to take existing useful technology and then standardize it (think SSH and SSL, protocols that were standardized after initial deployment).
In the cases designed by committees, they ended up with something so complicated that nobody has ever implemented it fully (X.509*). In the cases that were implemented and later standardized, deployments with full features are widespread.
(*At first glance, the statements about X.509 seem contradicted by the fact that X.509 is used in SSL. The fact is that SSL stacks use about 1% of the features described in RFC 2459 (X.509v3). This is what I'm talking about: ridiculously overcomplicated committee designs)
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
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.
Oh this is such a pile of shit. Without standards, the person with the best marketing will become the standard... not the best and most useful system.
Sure standards do slow innovation... but so does the the FDA when they ask for proper testing and years of results before millions of people pop that blue pill. Proper testing and analysis of innovations in technology need to occur before we just plaster them across the network only to find out later how gimped it was to begin with.
This is my sig. There are many like it but this one is mine.
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.
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.
Point two: A standards body is often a lousy place in which to invent a technology
No it's not. Standards are there to get the basics out of the way and move forward. For example, you can focus on inventing a time machine without having to figure out if the screws on your machine will fit the holes in your DMC's dashboard, or calculating the power it'll need in gigowatts, instead of number of power-foos that no-one else uses but the power-supply manufacturer you need that precious device from.
Good standards are good. Period. Bad or hard-to-use standards tend to be replaced by better ones. And standards that once were great (like the imperial system) can also be replaced by even better ones (like the metric system). But at any rate, no standards means no communication and no progress. That's a historical fact. Even the language I use to post this reply is a standard.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
There are no standards for standards. Because of this, there's no recursion - when something new is required, it can break from standards, but it must be worthwhile enough to stand on it's own merits - and possibly create a new standard.
Blindly following standards doesn't stifle creativity. The people who are creative recognize standards for what they are, and either conform or don't. If they choose not to conform, they take a risk.
One standard doesn't fit all.
MP3 is not THE standard. It is one of many standards. It may be the most widely used right now but that's because of applications like Napster which propelled it into the limelight overnight. It's all about creativity and how you work with the standards. For instance I know of many amazing web sites which follow web standards to the letter. And what's surprising is that they have used CREATIVITY to develop and mimic sites that use "non-standard" eye candy without ever breaking the rules of standard'ism.
___ Shout Central - Crushes your nuts!
Common wisdom [..] 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.
So true. The world would be a much better place without standards...
Man: Hello shopkeeper, I'd like to buy some cheese please.
Shopkeeper: Fine sir. How much do you want?
Man: 500 grams.
Shopkeeper: Sorry sir. We don't use grams here. We use flogborts.
Man: What's a flogbort?
Shopkeeper: It's our own system. Much better than grams. I'll explain..
Man: Don't bother. How many grams to a flogbort?
Shopkeeper: A6NG8
Man: What?
Shopkeeper: Sorry sir, we don't use decimal either. We have our own system. I have a diagram somewhere...
Man: Listen, just give me one dollars worth.
Shopkeeper: A dollars worth? I'm afraid we don't accept dollars...
etc. etc.
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.
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
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....
I don't mean to be snarky, but can somebody tell me what the word "standard" means in this discussion, plus tell me what is or isn't a standards body?
For example, is XML a standard? Java? CORBA?
Is the W3C a standards body? The JCP folks? ECMA?
Java is the blue pill
Choose the red pill
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?
An excellent example is the mars probe that was (more or less) recently lost due to a problem with units. Or back in the day, when no one could decide on the compression standards for 14.4 modems.
The problem isn't with adopting a standard, the problem is getting mired in a zillion groups formed to decide exactly what that standard is. Since many companies and all governments are monolithic in nature, it takes forever for them to decide what the standards are, and invariably they go to the highest bidder.
This isn't exactly a new view. James Gosling's classic Phase Relationships in the Standardization Process is already 13 years old.
-Tom Duff
What the article talks about is a difference between two kinds of standards. Those that codify existing practice (SMTP, IP, ANSI C, HTTP 0.9, most of the early Internet standards I think) and those which attempt to create a new standard from scratch. He doesn't like the second kind.
I think it's similar to the argument that says you shouldn't set a program's design in stone before it is implemented, because until you have a working implementation you can't know what the best design would be (nor indeed what the requirements will become). And I have a lot of sympathy with that.
But while a few years of anarchy followed by a period of standardization can work well in some cases, you can't seriously suggest that in areas where there are big upfront costs to get into the market it is better to let people waste effort thrashing around with a dozen different formats or protocols until one of them wins 'in the marketplace'. (And we all know that 'the marketplace' is often lousy at picking the best technical solution, worse even than standards committees.) Mobile phones are a great example. You need to have an agreed standard before you start manufacturing, not afterwards.
If new standard creation is politically motivated by companies who have a potential new product to promote, so what? That's surely preferable to having no standard at all, launching several new products with incompatible formats or protocols, and then years later trying to document and standardize whichever random one of them seems to be the winner. Case in point: where is the standards document and process for MS Word file format?
-- Ed Avis ed@membled.com
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.
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.
Shopkeeper: A dollars worth? I'm afraid we don't accept dollars...
Man [Angry]: Dammit! Just give me 4N flogborts of cheese then!
Shopkeeper: Ah. We'll have to order it if you want that much Sir. We could have it for you by Four Uppity One on Snorbsday. Is that ok?
Man slams door leaving cheese shop
Shopkeeper [calling after him]: Whippitydee to you Sir! [Under his breath] Snobblefocker.
Sure, there were lots of designs for gears early on. If we had standardized early, we might have ended up wasting time on substandard gears because the standard was immature. A bit of competition between possible standards is a good thing during the early adoption phase.
Stop the brainwash
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!"
In my day, we didn't have "1", but we got by with 0 factorial just fine!
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.]