Are Standards Groups Stifling Innovation? 366
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."
But the great thing about standards... (Score:4, Funny)
Re:But the great thing about standards... (Score:2)
Which is right? Who knows! Let's forget about interoperability!
Re:But the great thing about standards... (Score:5, Interesting)
Re:But the great thing about standards... (Score:4, Insightful)
It's not because there should be the one true standard of everything, but that there should be a purpose behind the standard dictating the goals. Some may be more efficient, some may have been easier to implement, some may have been selected for interoperability. These goals often intersect, but not always.
You might as well ask your grocery store to supply just one do-it-all fruit.
An example to the contrary (Score:5, Insightful)
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.
Re:But the great thing about standards... (Score:4, Funny)
Standards do not stifle innovation (Score:3, Interesting)
Re: Standards do not stifle innovation... (Score:4, Interesting)
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.
Re: Standards do not stifle innovation... (Score:3, Interesting)
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, Mozill
Funny, mine work in all browsers (Score:3, Informative)
<p>Paragraph one has something to say</p>
<h2>Something is related</h2>
<p>Which is why paragraph two is relevant</p>
Standards CAN lead to innovation (Score:4, Interesting)
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...
I actually did this, w/ or w/out standards (Score:3, Interesting)
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 post
Re:Standards CAN lead to innovation (Score:4, Informative)
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.
Re:Standards CAN lead to innovation (Score:3, Insightful)
Yeah, but his point was ridiculous anyhow.
So, apparently he can't think of MPEG-2, or MPEG-4. He can't think
Re:FTP? (Score:3, Informative)
Re:FTP? (Score:3, Insightful)
TCP was designed to give basic delivery guarantees at the protocol level, which is important for a robust, general solution. However, it is never the most efficient way to guarantee delivery. Maximizing efficiency requires application-specific know
Re:FTP? (Score:3, Informative)
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 sendi
Re:Standards do not stifle innovation (Score:5, Insightful)
I'm not ruling out that it one day might change or somwhat evolve into something better or larger standard (TCPv2/IPv6) but because of it's importance the standard becomes de facto "the only way of possible soultion".
For example; the metric system an established and choosen standard im most of the civilised world has become almost impossible to change. And because of market acceptance no one *wants* to change from the standard into something new unless someone manage to create something far better then the existing standard.
The Economist had an article [economist.com] about the 25 years of succses of Ethernet in their latest so called newspaper.
They list 3 reasons why Ethernet succeeded:
-Simplicity.
-Open standard, as opposed to other competing standars.
-Decentralisation.
The later is probanly specific to Ethernet as a network standard, but the two other are probably pretty generic success factors for standars.
Re:Standards do not stifle innovation (Score:3, Insightful)
Not to completely disagree, I do understand your point, but...
IBM PC is not standard because of IBM's power but rather because they opened up the architecture for other companies to clone and produce software for. This pushed the architecture into widespread use and therefore became a standard. Ha
Re:Standards do not stifle innovation (Score:3, Insightful)
Please replace "are too lazy" with "have no reason".
Re:Standards do not stifle innovation (Score:3, Interesting)
I dare say you're looking for "don't know they have a good reason to ... are too lazy to do legwork to look for an alternative."
People will spend weeks deliberating over purchase of items they'll use every day, but will happily plop themselves in front of a PC day in, day out at work and at home alike and never consider that there m
Yes and No. (Score:2, Insightful)
Re:Yes and No. (Score:3, Interesting)
Ahem ... (Score:5, Insightful)
*COUGH* decimal system *COUGH* metric system *COUGH COUGH* posix *COUGH* TCP/IP *COUGH RAAAHHH RAHHH*
Re:Ahem ... (Score:4, Funny)
Re:Ahem ... (Score:4, Insightful)
Funny you should mention this. I'm right in the middle of implementing an OMG standard for describing a certain type of research experiment. Certain journals are starting to tell pharmaceutical companies and universities (our customers) that they won't accept any scientific paper unless the experimental writeup is accompanied with a file in format X, this XML format, so that they can keep the document on record. So our product has to support export and import of this file type. Fine. Standards are good.
Except for this one. It is bloated and labyrinthine. Millions of lines of XML cruft are needlessly repeated- the files are huge (90% XML syntax, only 10% actual stuff). Given any type of information in such an experiment, this standard gives you six different places to put it. Certain fields must be populated with standard values ("ontologies") defined by OMG. Except OMG hasn't gotten around to actually defining what these standard values are, and so people are just making stuff up in the meantime. There are pages and pages of class diagrams, and finding the one or two relevant classes in each one is like a Where's Waldo game. All the rest are fluff.
Certain dialects of the standard are already forming- as in "format X as produced by software from company Y", "format X as produced by hardware from company Z", etc. This is what happens when a standard is bloated- it fragments into less flexible de facto standards. While it's easy to parse a dialect, parsing the format in its general form looks like it will be as hard as parsing a natural language such as English (I don't mean the low level XML parsing, I mean interpreting the bloat into something useful). And in fact, there are several places where the standard gives up and just tells you to put English descriptions of things in certain places. This is an artifact of its origin- it was originally developed by one particular company in the field, and it's essentially an XML serialization of an abstracted UML diagram of the internal data types they use in their own products. If they're weak in a certain area, such as normalization procedures, the standard simply falls back on English text descriptions. If they're strong in an area, that's where the cruft comes in.
Yes, standards are good, but poor standards are horrible.
Re:(speaking of "standards" ) Re:Ahem ... (Score:3, Funny)
I read recently that there is a prion disease where you suffer months of insomnia before dying a slow, agonizing death from neural degeneration. So make sure you bookmark that link. If you ever get that disease, you'll want to print out some OMG standards documents and force yourself to read them. It could save your life someday.
Re:Ahem ... (Score:4, Insightful)
Without standards, innovation would be slowed. If the design of gears was non-standard, mechanical engineering would be a nightmare. How long would it take to develop a clock? If there was no von Neumann machine, complex algorithm development would be a nightmare. If there was no central idea for an operating system...
There is a trade-off, too. Rigid standards can restrict freedom for breathing. Loose, extensible standards are a good way to go, BUT developers will proprietarize their ideas and not document things properly.
I think the best world is one of standardized consumer systems, standardized business systems, free software for almost everything, and a few, non-standard (but interoperable) proprietary systems and software packages for doing very specialized, high-end tasks. Microsoft probably does not agree with my vision.
A bit of balance (Score:5, Insightful)
Re:Ahem ... (Score:4, Insightful)
Note the ALL. Some do, but not all.
I've seen many projects where some manager said something like "You should use XYZZY to send messages". When asked "Why", the answer was always, "Because it's a standard!"
Well, news flash....sending messages between to programs that'll never hook up to anything else doesn't require an existing bloated standard. Sometimes it's better just to use your own messages.
Look at KQML... sure, it's a standard, but hardly any agent systems use it. Too damn bloated, and the agents don't need to talk to other agent systems anyway.
Re:Ahem ... (Score:3, Insightful)
You should use XYZZY to send messages". When asked "Why", the answer was always, "Because it's a standard!"
And the Right Answer to this kind of blind application of a good idea to the wrong problem is...
...to design your application so that a future interface using standard XYZZY is not precluded by your design and would be easy to implement if the need arose for your app to communicate via that standard.
Sure but the benifits are worth it. (Score:5, Insightful)
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.
Re:Sure but the benifits are worth it. (Score:5, Interesting)
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...
working within standards (Score:5, Interesting)
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.
It's more important than that even... (Score:3, Insightful)
Hrmm (Score:5, Interesting)
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?
Re:Hrmm (Score:3, Insightful)
1. "So the next time you are talking to a manager and he or she tells you that you have to use something "because it is a standard", push back. Ask why only standards can be used. Ask if the standard has actually been implemented, or if the standard will really solve the problem under discussion. For that matter, ask if the
Re:Hrmm (Score:5, Funny)
According to the RIAA [slashdot.org] and MPAA [slashdot.org]: Yes.
Re:Hrmm (Score:3, Insightful)
The other thing no one is bringing up is how things make it into a standard. Many standards leave o
Things ARE heading that way though (Score:3, Interesting)
There are multiple standards for audio on a DVD disc. And then there is SACD (Super Audio CD) which is compatible with CD
2 Standards (Score:5, Funny)
0
and
1
Everything else is probably just hype.
You're soft (Score:4, Funny)
Standards can be a PAIN.... BUT!!!! (Score:5, Insightful)
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....
Re:Standards can be a PAIN.... BUT!!!! (Score:5, Insightful)
Your Cell phone example is a perfect example of this, I'm willing to bet cash that every one of those cell phone companies claim their format as a "standard". But isn't the definition of a standard, as something that is widely recognized as being true or correct? So who decides something is standard?
Did you vote on something to make it a standard?
Or do you think some corporate lawyers in a room somewhere decided "Hey if we make a committee of '3rd party represenatives', send them up to the lake and get them some nice things, we'll get them to declair our companies IP as a standard increasing our share-holder confidence! PROFIT!"
See thats where the problem lies, the "standards" aren't really standards and they aren't being established for the good of the people the are being made for the good of the corporations bank accounts.
Re:Standards can be a PAIN.... BUT!!!! (Score:4, Insightful)
For example, I would define something as a standard if two idependent implementations can interoperate reliably. A manufacturer would usually consider something a standard if it is a document that has been produced by an idependent or industry body. Marketing would consider something standard if they were told it was, or if they thought it would sell well. The user considers something standard if thats all they ever use; their de-facto standard.
So it depends. Some things that people would call standard only fall under one of these definitions. Some fall under all of them. Some even manage to fall under none of them and yet people still call them standard.
Its one of those nice poorly-defined fuzzy words that can mean anything you want it too, which is of course a very big problem for the technical crowd in placed like Slashdot where precise definition is everything.
'De facto' versus 'de jure' (Score:5, Insightful)
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?
Re:Standards can be a PAIN.... BUT!!!! (Score:4, Informative)
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.
important for concerted progress (Score:4, Insightful)
Standards get ignored anyway if they do... (Score:5, Insightful)
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....
Re:Standards get ignored anyway if they do... (Score:4, Insightful)
Now, when we talk about interoperability standards, things get a lot trickier. You want to implement a feature not within the standards? Go ahead, but other clients will not be able to use them before they are patched. If you keep your extensions to the standard secret, you will raise ill-will among your fellow developers.
This is, in effect, what the author is referring to. A standard that is constantly developed upon is not a technology which should be standardized. Innovation happens - standards follow. The author is entirely correct in stating that a standards body is bad place in which to develop technologies.
Re:Standards get ignored anyway if they do... (Score:2)
De facto vs. De jure (Score:2, Insightful)
Re:De facto vs. De jure (Score:2)
there's no clear-cut answer to that question.
Re:De facto vs. De jure (Score:2)
It's 'du jour'. Someone should standardize French.
Standard automatically less bad than roll-your-own (Score:5, Insightful)
Yes, do away with standards (Score:2)
I SAID BE QUIET!
design by committee vs. standardize afterwards (Score:5, Insightful)
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)
Re:design by committee vs. standardize afterwards (Score:5, Interesting)
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.
Re:design by committee vs. standardize afterwards (Score:5, Informative)
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.
Re:design by committee vs. standardize afterwards (Score:3)
For one, I think an example that design by commitee can be good is the DVD format. The format went from nothing
Re:design by committee vs. standardize afterwards (Score:3)
The dash version was put into the final standard but a group of manufacturers on that board still decided they had to split and make the plus format, of which there was negligible improvement, if any, over the already existing dash standard.
Lots of history here... (Score:2, Interesting)
HDTV (Score:4, Informative)
Re:HDTV (Score:3, Informative)
Innovate this! (Score:5, Insightful)
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.
Re:Innovate this! (Score:4, Insightful)
[cough]Internet Explorer anyone?
They may stifle innovation, (Score:2, Interesting)
I worked on part of SSL: RFC 3268 (Score:5, Informative)
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 [ietf.org] 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.
Standards promote innovation... (Score:2)
Here are a few of the standards that I'm using right now (and that you're using with me) that are letting us have this discussion:
The English language
QWERTY keyboard layout
PC architecture (made up of countless standards)
HTTP
ADSL and other connectivity technologies
That's not an exhaustive list, but
This guy is being silly (Score:5, Insightful)
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.
Re:This guy is being silly (Score:5, Insightful)
Yes it is, but you are missing his point. A standards body did not come up with the language one day out of the blue. People were speaking the language for a long time before it was standardized officially.
The article is not against standards, but against the idea that a committee is going to come up with a standard technology all on its own.
Or to put it another way (Score:3, Insightful)
Int Please req temp state aware be nunc clause state this temp equiv nunc mod intellectual obj property, and state state temp use nunc act sole mod state standard reflex act mod without state mod proper obj sole state temp payment nunc act of royalties act temp state prosecuted act fut by mad-dog lawye
Re:This guy is being silly (Score:3, Insightful)
To repeat: Point two: A standards body is often a lousy place in which to invent a technology
The supposed counterexample is that invention is enhanced when screws are standardized. That's not a counterexample. You have to read the statement. Point two does not say "Standards bad." It says something very specific that you need to actually read.
He forgets... (Score:3, Insightful)
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.
Common widom... (Score:5, Funny)
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.
continued... (Score:4, Funny)
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.
A 20 oz Coke (Score:3, Interesting)
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 com
XML? (Score:2)
True, but (Score:2, Interesting)
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.
The wrong approach... (Score:5, Informative)
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.
Standards are needed (Score:5, Interesting)
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.
Can you say (Score:2)
"...has no basis in fact or history, and is curtailing innovation and rewarding bad behavior in our industry." not.
Standards are great (Score:2)
Standards are great, but they have to be implemented to be useful. Implemented standards can make or break a project. You can take all of these commodity protocols, data formats, etc.. and use them without royalty in your project to make it a success. This saves a lot of reinventing the wheel with less thought-out designs and implementations.
eg Hibernate (Score:3, Insightful)
"Good standards can provide interoperability and portability. Bad standards can stifle innovation. "supports XXX standard" is not a real user requirement, particulary if XXX was designed by a committee of "experts" who, throughout the entire process, never once ate their own dogfood. The best software is developed by trial, error and experimentation. De facto standards are usually a much better fit to user requirements than a priori ones."
The standard Hibernate deviates from is JDO (Java Data Objects) and the claim here is that it is successful partly because it has departed from the standard which is more complex and difficult to use.
text for "clarify his position" entry (Score:2, Insightful)
When I posted my last entry, I realized that I might be stirring up a hornet's nest. Indeed, I could hear the buzzing just before I pressed the submit button, and almost decided against it. Such good sense has never been my hallmark in the past, however, nor did it overcome my hope that I wouldn't regret the posting. While I don't regret it, it has been instructive to listen to the replies. Some have been well-thought out, others not so much. But the replies did make me realize that I had posted
In a nutshell (Score:5, Informative)
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....
But first ... (Score:4, Insightful)
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?
Re:But first ... (Score:3, Informative)
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
Gosling on Standardization (Score:5, Informative)
Q: What would we be without standards? (Score:3, Insightful)
Seriously, if you're trying to innovate, just go out and do it. Nobody's stopping you. Standards groups are around to prevent total havoc from reigning when you foist your innovation on the unsuspecting public. If your "innovation" requires having thousands of users to really get anywhere, then maybe you'd better publish a paper. Either that or sell it in a black box so your bugs won't perpetuate in later products. If you can't make it to market and you can't make it in the academic circles, then whatever stifling effect the standards group has had is for the public good. I like tinkering with my machines and occasionally watch them break in novel ways, but there are an enormous number of people whose livelihoods and safety depend on reliable operation of these systems, and the standards groups help protect them.
Well, Obviously... (Score:2)
Standards are a good thing for common access points. Should there be a standard bad guy in every video game with the same face? no. Should there be a standard way to draw said bad guy on your screen so youc an shoot him? yes.
one point he missed (Score:4, Interesting)
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."
The Construction Industry? (Score:3, Insightful)
Can you imagine projects of this complexity being accomplished without standards? They have standard wood sizes, standard door sizes (carpentry is riddled with standard sizes for common things, but I'm not a carpenter, so I don't know the details), standard screw & bolt sizes. Then theres the plumbling, the electricty...
All of these details need to fit together in a predictable way and these specialized groups need to communicate in order to minimize conflicts. The lumber yard doesn't have time to cut new sizes of wood for each customer and the door manufacturer can't create special-make a door for each new house.
I don't think anyone can dispute that the software industry is in a similar position-- Teams of software engineers working together on projects, the OS needs to communicate with the software, blah blah blah. Of course we need standards! Some are more necessary than others, but how will we know in a year which web standards will be essential and which won't? Its good that we're drafting standards now so we have something to work with in the future. Maybe some standards will get thrown out, maybe some won't. This might stifle some innovation, but can you really argue its necessity?
Two slices from the same curve (Score:5, Interesting)
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.
You have to define where the "innovation" occurs (Score:3, Insightful)
Examples:
Standard: HTTP and HTML
Innovation: Web Portals
While the progress of HTTP and HTML MAY have been quicker if they weren't tied to a "slow moving/stodgy" standards group this would have meant that things like Web Portals would have been hampered by trying to figure out what transport technology and client technology to embrace. (Heck you probably wouldn't have had a portal in the first place, just more BBS's.
Standard: US Electricity 110 V.
Innovation: Lava lamp. (Yeah, arguable.)
A bit absurd, but the idea here is that you can innovate on the actual lamp rather than worrying about the incoming current and plug shape, etc. A better example may be those replacement flourescent bulbs that you can get now.
So, yeah standards do in fact inhibit innovation in certain areas. The thing is, that innovation does have to be slowed down. You need to have some sort of foundation in which to build the REALLY innovative stuff on top of.
Why I have little respect for standards (Score:5, Interesting)
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!"
Re:man poll (Score:3, Informative)
Java and .NET (Score:3, Informative)
IETF (Score:4, Interesting)
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.
Re:It's all about standards (Score:3, Insightful)