Standards and specs: Early adopters

Follow the pitfalls and perks that come from adopting a standard before it becomes one

Whether a standard will succeed and be widely adopted is ambiguous at first, regardless of who endorses it -- a major player or a fringe element. So why would people put all their eggs in a standards basket when that basket might not exist tomorrow? Join Peter Seebach as he shows the potential advantages of adopting a standard before it becomes one. (Of course, he hasn't forgotten the potential disadvantages, too.)


Peter Seebach, Freelance author,

Peter SeebachAlthough not a de jure standard, Peter Seebach feels he can be considered a de facto one. In other words, go ahead and adopt him.

18 October 2005

Before a standard becomes widely adopted, some ambiguity always exists about whether it will succeed. Even a standard formally endorsed by a major organization might turn out to be simply ignored by the marketplace.

Adopting a standard before it has become fully established has advantages and disadvantages. In some cases, early adopters can have substantial influence over the development of a standard. Being first to market can also provide economic advantages.

If you're going to adopt a standard before it becomes fully established, you should consider a few key factors first. This article looks at early adoption -- who does it, why, and what can go wrong with it.

What users want

Although the focus here is on developer perspectives, the general answer to the question of what developers want is always customers. Early adoption is often pushed very aggressively by users, some of whom are inclined to adopt standards long before they exist, let alone before they are mature.

The success of a standard can depend on the feedback of these early adopters; if the first few users report catastrophic failures, other users will be cautious in adopting the standard -- if they do so at all.

Above all, users want products that work. A product that does not perform its advertised function will be panned by reviewers. A product that only fails erratically might be hit even harder. If my new PDA fails to power on, I may look for a replacement, blaming hardware failure. If it sporadically crashes, losing all data, I will never trust the product or the vendor again.

Interoperability is a significant concern even for early adopters. Commitment to continued interoperability with the "final" standard is a big attraction; no one wants to pay extra to be the first on the block with access to a new device only to have to buy another one anyway when the final standard comes out.

Advertised performance is sometimes more of an issue for early adopters than for other users. Users who get an 802.11g card built into a laptop might not much care whether it really gets 54Mbps or only about 30-some; they will probably never even try to benchmark it. An early adopter spending US$200 on a special, high-performance card will care quite a bit, especially a reviewer.

This highlights the other reason developers might adopt a standard early: A new product or standard might offer significant performance improvements over previous standards. These draw power users, often even when the user has no real need for the new feature. This behavior, sometimes called heatseeking, is the best and worst thing about early adoption. Early adopter users tend to be above average in technical savvy and even more above average in confidence about that savvy.

Getting in on the ground floor

The primary advantages of early adoption include influence on the early standard and competitive advantage over latecomers. If a standard related to your development efforts is forming, you might benefit greatly from involvement in the standards process. For that matter, the standards process is quite likely to benefit from additional input from people with expertise in the field.

Not all of the advantages of standard interfaces and designs apply to early adopters. You can't take advantage of economies of scale right away. Still, the essential points are still there -- better interoperability and reduced design costs.

You can easily overlook the cost of developing a specification solid enough to build products on, but you can hardly miss the comparatively huge cost of trying to debug a product update that is almost compatible when your specification isn't precise enough.

Early adopters gain an additional benefit over competitors, in many cases -- the option of claiming standards compliance. For products, such as wireless cards where interoperability is a key point, this is very significant. My favorite example (mentioned in the first Standards and specs column) is 2.4Ghz, 11Mbps, wireless cards which were not 802.11b. They lived on the store shelf for many months, always slightly above the price of the cheapest 802.11b cards, until they made it to the clearance bin at a price that must have represented a steep loss for the vendor.

Premature adoption

While early adoption has its advantages, you can adopt a standard too early. A standard that is still in development might change enough to render early development effort useless.

A standard that is far from finalized is best seen as a research opportunity, not a basis for a shipping product. Unfortunately, market forces are not always particularly tolerant of delays, leaving hardware designers and software developers alike trapped between a rock and a hard place.

If you are forced to adopt a standard which does not seem to be quite stable yet, remember the crucial basic principles of standardization:

  • Be liberal in what you accept and conservative in what you send.
  • Defensive programming and design are always important, but they come to the forefront in working with immature standards.
  • Try to make sure that your product is robust in the face of half-complete implementations, changes in the specification, and so on.
  • Upgradeable firmware is a definite must in devices that might need to adapt to new changes, but don't stop there.
  • If you've been logging bugs you resolved during development, try to make sure your product would interoperate as well as possible with other products that still had those bugs.

Great minds think alike; hurried developers make similar mistakes.

The danger of hype

A reputation for being "over hyped" might stick with a product long after the initial kinks have been worked out and it really is the best thing since sliced bread. Keeping the early product marketing and spec sheets reasonably close to the final reality is important; there's plenty of time to talk something up once it works.

The early life of Bluetooth was an excellent example of hype; the early promises of an all-singing, all-dancing wireless protocol that would connect everything to everything seamlessly have contributed substantially to user disillusionment with the real-world issues behind some Bluetooth hardware. Less optimistic claims might have been better received.

Hype isn't just a problem for users: developers who wait to solve a problem until an upcoming standard eliminates it might cripple their own products for years. Delays in standardization, failure to live up to early claims, or technical limitations (such as power or regulatory issues) can make a solution useless.

One company that learned this lesson the hard way was Psion, whose PDA line had serious issues with lack of cables for communications devices -- all of which were to be resolved by Bluetooth. In 1998, Psion was responding to user demands for cell phone cables with the explanation that Bluetooth would resolve this.

By the time Bluetooth was really viable, the Psion product line had been discontinued. One of the issues users cited? No way to connect to cell phones. Cables and serial port support would have been good ideas in the intervening years.

Competing standards

Early adoption becomes even more challenging when two standards are competing (such as the UWB standards battles). The risk of picking the wrong standard creates a real reason to adopt a "wait and see" attitude towards new standards. This is often the case where a fairly reserved approach is best -- committing to a losing standard doesn't necessarily help you much.

However, some amount of research and study might pay off; in particular, if you have a strong technical reason to prefer one standard over the other, let the people involved know. Standards people are frequently fairly interested in the technical merits of their proposed standards, and an overwhelming technical advantage could sway the balance of a long-running dispute.

Nonetheless, the basic advice for standards battles is to stay clear. Wait until the dust settles a bit and you can tell what the standard is before adopting one.


I could possibly overstress the importance of rigorous testing on products based on a new standard, but not in a column this short. Testing for interoperability, backwards compatibility (where applicable), and reliability is absolutely crucial to the success of a proposed standard.

The early adopters of a standard are its ambassadors and are obliged to try to make a good impression; if they make a poor impression, the standard might well be scuttled and everyone involved will be out a substantial investment.

The testing that goes into products based on a proposed standard is your best chance to catch critical flaws in the standard before its adoption is widespread. Surely better testing of WEP would have revealed its potential vulnerability to sniffers (see Resources) before millions of dollars of infrastructure were so heavily tied to it.


One of the potential benefits of being one of the first vendors to adopt a new standard is beating competitors to market. Unfortunately, this can result in an attitude of competitiveness that can wreck a potential standard for everybody.

Remember that standardization is about interoperability first and foremost. If competitiveness between prospective partners in a standardization effort sinks the standard, everybody loses.

The early phases of standardization offer a severe temptation to break with the standard to obtain competitive advantage or to make a less-than-sincere effort towards interoperability. This temptation must be resisted. The benefits for everyone, developer and user alike, of interoperability should take precedence over the desire to take a slightly larger market share or exclude competitors from the marketplace.

The users most likely to be early adopters are also disproportionately sensitive to these questions, making them particularly important. Getting a reputation for falsely claiming compliance with a new standard or doing a slapdash job of it will not help you earn customer loyalty. Early adopters will tell their friends to avoid a product that doesn't live up to expectations.

And whatever you do, don't get into a finger-pointing match with your competitor. Be liberal in what you accept: If you know a competitor has an implementation flaw, go ahead and mention it, but develop a workaround on your end. If your product doesn't work and you successfully convince me that it's not your fault on the grounds that you know exactly what's wrong and whose fault it is, you have also convinced me that you know enough that you could produce a workaround if you wanted to.

Boundary conditions

If standardization efforts are ongoing while you're working on a product, be sure to pay close attention to areas under discussion or dispute -- these are likely problem areas for your product; they are the areas where possible changes during the standardization process are most likely.

Backwards compatibility, standard revisions, and other kinds of interoperability are other common sore points. Complaints about 802.11g products have often had to do with compatibility with 802.11b products that they have to interoperate with -- many vendors didn't pay enough attention to this aspect of the product standard.

Don't do all your tests in idealized laboratory conditions. Test your wireless card near a microwave. Have someone with a thick accent try the voice recognition routines. Test your handwriting recognition on a doctor's prescriptions or perhaps on Lewis Carrol's Jabberwocky. (See Resources.) Hardware should be subjected to the usual run of daily assaults, such as sudden power outages, before being declared ready for retail distribution.

If your product has options or configuration settings, test them carefully. One company introduced a wireless router which allowed only the characters 0-9 and A-F in WEP keys, even though it was supposedly accepting ASCII strings.

Options inherent in the standard should be explored, too; USB devices may be attached to USB hubs. Products that claim they cannot be used on a USB hub do not build consumer confidence.

Adopt early, adopt often

Even though early adoption has its pitfalls, it offers the chance to improve the standards process and get better standards adopted sooner. Early experience and feedback, especially based on open cooperation between vendors, can help fix problems with a standard early enough that doing so is cost-effective. Involvement in standardization can give you influence over the process, but it can also give you insight into where the standard is going. That can help you make informed plans.

The cost of experimenting with a standard might seem high if the standard doesn't work out, but that's likely to be a fraction of the cost of trying to develop a viable alternative. Standardization lets you take advantage of work other people are doing. The similarity between this and some of the arguments for open source software is not a coincidence; sharing information often makes businesses more efficient.

Even if a standard you adopt isn't quite ready, it might give you a head start on working with the final standard when it becomes available. The work required to adapt to last-minute changes is likely to be easier than the work of overhauling an entire design. A positive attitude towards interoperability, testing, and cooperation with other vendors and developers can make a standard succeed, which is generally good for everybody.



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into developerWorks

Zone=Multicore acceleration
ArticleTitle=Standards and specs: Early adopters