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!
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.
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.
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?
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.
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!"
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.]