Channels ▼
RSS

Standard Practice


The impact that technology standards have on the software industry is impossible to overestimate. The Internet and the Web are built upon numerous layers of standards, both old and new alike. These standards provide countless opportunities to build new products and services; but they also dash the hopes of many new ventures.

Although there's nothing new about the concept of standards, lately it seems that the term has taken on a life of its own. In the past decade alone, so many new technology "standards" have emerged (along with new "standards organizations" claiming to develop and promote standards for the betterment of industry), that it has become nearly impossible to find a patch of solid ground on this constantly shifting landscape.

As the host of available standards continues to grow and change rapidly, it becomes increasingly difficult to choose among them. Which standards should we adopt today? Which should we let bake a little longer in hopes of using them tomorrow? And which should we ignore altogether?

Betting On Standards

When building products and services for the Internet or Web, we're forced early in the process to make critical, long-term bets regarding which technologies we'll use. We're asked to choose among various solutions, both proprietary and standardized. And as any software architect can attest, the technology choices you make today can make or break you tomorrow.

In addition to the usual technology-specific issues, we must also consider the short- and long-term legal and business impacts of our choices. License fees related to patents and other intellectual property rights (IPR) are often accompanied by both proprietary and standard technologies. Sometimes these fees are obvious; other times they present hidden dangers. These issues are only the beginning when it comes to adopting any new technology solution.

Although it's important to perform advanced due diligence and take an eyes-wide-open approach when assessing various options, even these steps don't guarantee a smooth ride—as MPEG-4 product vendors can attest.

The MPEG-4 Conundrum

MPEG-4 is an exciting new streaming media standard that's emerging from nearly ten years of research and development by the Moving Picture Experts Group (MPEG). This is the organization that gave us MPEG-1 and MPEG-2, which together ushered in digital video and audio for CD-ROM, DVD, broadcast networks, and MP3.

Although ripe with potential, in addition to having been officially standardized more than three years ago, MPEG-4 is currently embroiled in patent licensing issues. Proposed license terms released in January by MPEG LA (the licensing body for MPEG technologies) have contributed to the delay of several significant product rollouts, including products from such industry heavyweights as Apple Computer.

Under MPEG LA's original plan, vendors would pay a fee of 25 cents for each copy of an MPEG-4enabled product they might distribute (such as a player or an authoring tool), capped at $1 million per year per product. But the plan also specified an uncapped per-minute usage fee that would amount to two cents for every hour of MPEG-4 content delivered. These usage fees, in particular, concerned many vendors—not only because they were high and had no ceiling, but also because they directly impacted the service providers and content distributors who might have used the vendors' products.

Commercial service providers and content distributors would, for example, have had to pay an MPEG-4 license fee for every QuickTime 6 stream they served or distributed. Thus, QuickTime and other MPEG-4 products would be financially impractical when compared to other streaming media solutions.

Pressing Forward

New terms that are under development will likely make MPEG-4 competitive with alternative options, such as the proprietary—yet utterly dominant—Windows Media and RealNetworks streaming media de facto standards. In anticipation of this outcome, Apple has decided to press forth with its MPEG-4 product releases without a firm license in hand, instead of taking a "wait and see" stance like most vendors.

As this issue of New Architect goes to press, Apple has released a preview version of its QuickTime 6 software and announced that it plans to ship the final version in late summer, concurrent with the next major update of Mac OS X. Not coincidentally, late summer is when the final MPEG-4 license is expected from MPEG LA. Although Apple must wait for the final license to arrive before it can be sure of the terms—just as everyone else does, because the MPEG-4 license is nondiscriminatory—it has too much on the line with QuickTime 6 to postpone the product further.

Consequently, Apple stands to reap the rewards of early entry into the emerging MPEG-4 market, while simultaneously risking the possibility that new license terms may not be as favorable as expected. Even worse, they might not change at all. This particular Apple bet follows several years of active participation in the MPEG standards body that's responsible for MPEG-4 (the file format for which is actually based on QuickTime). Thus, Apple's decision is a particularly fine example of an organization accepting both the risks and rewards inherent in adopting any significant standard.

Hidden Fees, Open Alternatives

Standards, of course, aren't the only arena in which patent issues can impact technology adoption. In fact, license fees can actually spur the development of open and freely available alternatives, as many developers familiar with CompuServe GIF and PNG are aware.

In the early days of the Web, the GIF image format was widely adopted by browser and image editing product developers. Often these developers were unaware that Unisys held a patent on GIF's Lempel-Ziv-Welch (LZW) compression method. Many years after GIF was popularized, Unisys began to enforce its right as patent holder and seek license fees for LZW that ranged from thousands to potentially millions of dollars.

This was particularly troubling for Web sites that used server-side programs to dynamically generate GIF images, such as weather and map sites. One such site purportedly faced license fees upwards of $3 million for generating LZW-compressed GIF images. In addition, those who simply wove premade GIF images into their pages could face contributory infringement charges if the product that created the images wasn't properly licensed.

In response to these and other concerns, the PNG image format soon emerged as a patent-free alternative to GIF. As a de facto standard endorsed by the W3C, PNG is free to implement and use, and is in many ways technologically superior to the GIF format it was intended to replace. Although a painful and expensive lesson for those bitten by a lurking patent license, the GIF debacle served to heighten awareness of IPR issues and promote a "look before you leap" mindset in the Internet and Web development communities. Fortunately, looking in advance of implementation often reveals open alternatives.

Shopping For Standards

Although it's by no means a silver bullet, many companies have successfully invested in established standards. Adopting official and formally recognized industry standards and de facto standards alike can offer competitive advantages through increased interoperability and compatibility. In this sense, standards can pave the road for the commoditization of software and services, in addition to media.

Yet even when you opt to use standards for strategic purposes, deciding which standards to use isn't easy. There are so many to choose from, and every standards organization is unique with respect to how it operates and the types of standards it produces. There is no equivalent to Baskin Robbins in the standards industry, where all of the flavors you could reasonably want are housed under one roof. If you want to consume standards, you have to shop around.

Software standards can generally be categorized into one of two major flavors: official (formal) standards and de facto standards. Official standards are those that are ratified or otherwise recognized or endorsed by a formal standards setting body or institute, such as the International Organization for Standardization (ISO), the International Electrotechnical Commission (IEC), or European Computer Manufacturers Association (ECMA).

Other standards-oriented organizations, such as MPEG and the Web3D Consortium, typically submit their work to a formal body like ISO for the final stages of approval. (MPEG is, in fact, a working group of ISO/IEC.) Thus, the full standardization process can be lengthy, often taking years to complete.

Differences In Policy

To paraphrase ISO, standards are documented agreements that contain technical specifications or other precise criteria used as rules, guidelines, or definitions of characteristics. Standards ensure that materials, products, processes, and services are fit for their purpose. In this way, standards help to make life simpler while increasing the reliability and effectiveness of the goods and services we use.

De facto standards, on the other hand, are not formally recognized or endorsed by official standards organizations, but rather are technologies that have become widely adopted or acknowledged as preferred solutions nonetheless. For example, technologies produced by the W3C aren't official standards, contrary to popular assumption. In fact, W3C doesn't even claim to produce formal standards. It produces "recommendations" in the interest of helping to establish Web standards. Yet several W3C recommendations, such as HTML and XML, are more widely implemented than many official standards.

You can further distinguish official and de facto standards by the degree to which they are (or are not) open. The organizations behind them vary in their stances on issues related to IPR and licensing. Whereas many standards organizations, such as ISO and MPEG, accept technology that is shielded by patents or other forms of IPR protection, others routinely discourage IPR encumbrances, or reject them outright.

W3C and the Web3D Consortium are examples of standards-oriented organizations that either by policy or practice discourage or prohibit inclusion of IPR-encumbered technology into their work in favor of open alternatives. The current policy of both organizations requires members to disclose relevant patent claims (and pending patent claims) early in the development of technologies for which they are involved. Although in practice, both have historically rejected patented contributions whenever possible.

To Protect or Encumber?

The current trend, in cases where standardization efforts are impacted by IPR claims, is to pursue royalty-free licensing terms to whatever extent possible. When royalty-free licensing isn't an option, a common alternative is to arrive at some form of Reasonable and Non-Discriminatory (RAND) license. However, exactly what constitutes a "reasonable" license is open to debate, as evidenced by the spate of controversy surrounding the RAND license proposed for MPEG-4 earlier this year.

Irrespective of any particular standards organization's stance on the issue of IPR in general, the debate often boils down to the fundamental issue of whether patents are good or bad for standards. The question of whether patents protect and advance standards or merely encumber and stall them isn't likely to be resolved soon, if ever.

On one hand, patents and their associated license fees can be viewed as effective barriers to entry that can extend a significant competitive advantage to those willing to pay for the privilege of using them. This complements the notion that the very best technologies are usually patented and don't come for free.

On the other hand, some view patents as a barrier to widespread technology adoption because they encourage for-fee licenses. Many vendors (and especially independent developers) are unwilling—or unable—to accept such licenses, no matter how "reasonable" the terms may be. In some cases, patented technologies can exert a measure of control over licensees above and beyond mere license fees.

Regardless of where you might stand personally on the issue of IPR and patents, this usually isn't territory that you should cover solo. Rather than making such decisions in a vacuum, developers and architects should instead consult with the appropriate executives in their company (who, in turn, usually rely on corporate lawyers).

Competing Through Standards

Standards are born and die in a surprisingly competitive environment. Even open standards bodies compete to some degree with one another, in addition to competing with various proprietary efforts, as they attempt to define and develop relevant technology solutions that will stand the test of time. In turn, you can be sure that adopting standards to establish a competitive edge in your own field isn't a trivial exercise. To the contrary, effectively competing at the standards level takes time and effort, not to mention incredible patience.

You can compete through standards either as an early adopter or by waiting until emerging standards enter the mainstream. The most obvious reward for early adopters is being among the first to market. There is also opportunity to directly influence or shape a standard under development, because participating in the process is a key feature of membership in many standards organizations.

On the flip side of these potential rewards are the risks associated with adopting any technology under active development. In particular, the risk of a technology changing direction or shifting form as it passes through the process is high, which translates directly into development dollars. And because license fees for technologies under active development are rarely established in advance, early adopters also risk being bound to unpredictable license terms that emerge well after the adopters have begun work on their products.

As a result, most vendors prefer to wait until a technology emerges from the standardization process. With mainstream adoption, you stand to benefit from, and possibly capitalize on, problems or conflict encountered by early adopters. In addition, you can often avoid potential implementation and license "gotchas" if you closely track a standard as it evolves.

Stay Informed

Although there are several things to consider when competing through standards, chief among these is familiarizing yourself with any license(s) required for the technologies that you plan to adopt. Before implementing any standard, be sure that the license won't conflict with your company's business objectives.

Adopt open (non-encumbered) standards that have little or no barrier to entry in cases where a level playing field works to your advantage or is in your long-term interests. Or, if you want to ensure that you'll be competing on a smaller, more focused field that's restricted to well-heeled organizations, you should adopt those with significant barriers to entry (especially heavy license fees).

If you are an early adopter, you should continually refine and test your products while tracking the emerging technologies they rely upon. Mainstream adopters, on the other hand, can often use prepackaged frameworks or implementation libraries. In addition, mainstream adopters should analyze the successes and failures of the products, services, and business models employed by early adopters to avoid unnecessary pitfalls.

You can track emerging standards of interest by monitoring publicly available discussion forums, industry publications, and industry news sites. Alternatively, you can track emerging standards as a member of the organization that's responsible for them. Private forums, source code, reference implementations, early access development toolkits and materials, members-only meetings, and member newsletters or communiquZs are among the many benefits that your membership dues can bring.

Even if you don't have the interest or time necessary to become an expert on a given standard, your entire team and company can benefit by tracking standards that are of interest, and by competing through the use of standards as they become more mainstream.

The Usual Suspects
Though by no means an exhaustive list, here's a taste of the many official and de facto standards available for the Internet and Web, and the organizations behind them.
Organization Representative Technologies URL
World Wide Web Consortium (W3C) HTTP, HTML, XML, SVG, SMIL, CSS, DOM, PNG (also advancing SOAP and WSDL, and other technologies submitted to the organization) www.w3.org
Web3D Consortium VRML, X3D, geoVRML, VRTP, DIS-Java-VRML, EAI, Humanoid Animation (H-Anim), Universal Media www.web3D.org
Organization for the Advancement of Structured Information Standards (OASIS) ebXML, LegalXML, UBL, SAML, DocBook, RELAX-NG www.oasis-open.org
Internet Engineering Task Force (IETF) IPv6, IPsec, S/MIME, MPLS, LDAP, SNMP, SIP, URN www.ietf.org
Moving Picture Experts Group (MPEG) MPEG-1, MPEG-2, MPEG-4, MPEG-7, MPEG-21 mpeg.telecomitalialab.com
European Computer Manufacturers Association (ECMA) ECMAScript (standardized Javascript), C#, Common Language Infrastructure (CLI) www.ecma.ch
International Organization for Standardization (ISO), International Electrotechnical Commission (IEC) Formally standardizes various technology specifications produced by MPEG, IETF, Web3D Consortium, OASIS, W3C, and others www.iso.ch and www.iec.ch


An international best-selling author, Aaron is active in the standards community and teaches at Boston College. He is also chairman of Mantis Development Corporation. You can reach him at aaron@mantiscorp.com.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video