Section 8.1. Open Standards


8.1. Open Standards

A standard can be a specification, a practice, or a reference model. It is used to define an interface between two (or more) entities such that they can interact in some predictable fashion and to ensure certain minimum requirements are met. Standards exist to encourage and enable multiple implementations.

It is important to put some simple perspective on the standards discussions that follow, as books can be written about this seemingly dry subject. We will look at the context for standards defined by their development and use, a process for developing and maintaining standards, and a set of implementation issues such as intellectual property concerns, conformance and certification concerns. Finally, we'll discuss the history of the concept of "open standards."

Standardization efforts are typically divided into various categories, but the classification systems are often orthogonal. For example:

  • Standards can be categorized by the type of development organizatione.g., national or international body, industry and trade associations, and consortia.

  • Standards can be viewed as industry voluntary efforts or government-regulated efforts.

  • Standards can be thought of as formal de juredeveloped specifications, or market-dominant de facto product technologies.

All standards live within a context of development and use. Many formal standards are developed by national bodies or international organizations such as ISO. These standards often define procurement policy for government organizations and large enterprises alike. Industry and trade associations develop standards relevant to their expert and specialized constituencies. In the information technology space, for example, the IEEE has a standards arm, and historically CBEMA (now NCITS) and Ecma International acted as standards development organizations in the U.S. and Europe, respectively, for IT standards. Each of these three organizations was accredited within its national and regional geographies to produce standards that could be later adopted by the relevant nationally or internationally sponsored standards organization to prevent overlapping efforts, and to build on the relevant expertise within different industry groups.

Narrowing the focus even further, consortia of vendors often arise within a specific area of technology within an industry to develop standards and specifications. The consortia often try to build specifications more quickly to expand a particular market, feeling that the more traditional organizations are too slow to deliver standards.

We can categorize standards differently if we bucket them between regulatory versus voluntary standards. Government regulation defines a separate set of concerns over the voluntary work of many organizations within industries. Such government involvement is often driven by economic concerns for the public good (e.g., communications-related standards) or safety issues (e.g., pharmaceutical testing and registration requirements or vehicle safety). Regulatory-based standards will not be discussed further in this chapter because the focus is on the role of standards and open source in market-dynamic areas rather than government-regulated areas.

Another categorization attempts to discuss the difference between de jure standards developed in a consensus-based process and de facto standards. A more accurate statement might be that de facto technology describes a market-dominant product, rather than a specification for interoperability open to all implementers.[2]

[2] As we shall see, Clayton Christensen has proposed a situation that says there is market pressure that can change de facto technologies into de jure standards.

Common examples of voluntary information technology standards across this organizational spectrum include SQL, HTML, TCP/IP, and programming language standards like C/C++ and C#.

Standards act as a yardstick against which multiple competing implementations can be judged in the marketplace to make sure that certain basic requirements are met. Vendors compete on implementation beyond the standard to establish competitive differentiation in the market. Ultimately, customers choose the product that does more than simply meet their base requirements. It is this relationship among specification, implementation, and competitive differentiation that provides basic interoperability among vendors, drives competition, and spurs innovation.

All standards organizations have rules about participation, construction, adoption, and amendment. They establish processes for how meetings are carried out to promote fairness of discourse and prevent anticompetitive practices. Standards development organizations also put in place intellectual property rules to ensure participants are aware of the intellectual property landscape with respect to the standard under development.

Most standards bodies require participating holders of essential patents to announce the existence of such patents, and to make them available on "reasonable and non-discriminatory" (RAND)[3] terms if an implementation of the standard would require a license to the patented technology. Under RAND terms, patent holders cannot discriminate against a particular company or a particular platform. Standards organizations supporting such patent policies ensure that developers interested in delivering standards-based products can do so, while ensuring developers that have invested in a particular invention still have their investment respected.

[3] While each organization's rules are stated somewhat differently and with different levels of formality, a quick look at the governing rules of the IEEE, ISO, IETF, and Ecma International shows a remarkable similarity.

It is important to remember, however, that no standards development organization can speak for the intellectual property of developers that are not participants in that organization. Standards development organizations structure their patent policies this way because they cannot be the policing organizations nor bear the liability for patent infringement cases from nonparticipants. They are neither funded nor set up to do so. Indeed, if they took on this role, they would likely collapse under the fiscal burden and serve no one.

The interesting thing to observe is that while standards exist to encourage multiple implementations, patents are government-enacted legal tools to protect a single implementation. Patents exist to allow the developing company government-enforced, time-limited legal protection of an invention by preventing others from building the invention. It allows the inventing company to recover the costs of bringing an invention to market in return for publishing the idea for future use by the broader market. A patent is in some regards the antithesis of a standard. Standards are to trade agreements as patents are to tariffs. By definition, they serve different purposes in the economic landscape.

Just as standards organizations are not organized or funded to handle intellectual property liability claims, neither are they typically the conformance certifying agencies for implementations for the standards they produce. Conformance requirements in the standards and specifications are typically simple "claim" stylei.e., you provide the functionality required by the standard and claim conformance to the standard. Organizations that care about conformance then take on the fiscal and legal responsibility of verification around the conformance claims. For example, in the government space in the U.S., the National Institute of Standards and Technology (NIST) developed a procurement process (FIPS[4]) and certification testing process for the standards that it cared to use in those procurements. The government was acting appropriately to protect and serve the public good in federal procurement policyessentially putting public tax dollars where its mouth was to improve the return on investment. In a commercial setting, The Open Group (née X/Open) as a market consortium handled conformance claims and liability for its specifications. Beyond the testing requirement, warranties of conformance are required and a brand license is signed which is tied to the trademark usage associated with the standards it produced. Companies that wanted to use the trademark on their products in the market had to pay royalties. The X/Open standards were developed through the organization and a company paid for its seat at the specification setting table through its consortium membership dues. Conformance certification, on the other hand, was funded through the cost of trademark use.

[4] FIPS stands for Federal Information Processing Standards.

If standards act to define a base functionality to encourage multiple implementations, essentially the greatest common denominator for a specific technology, they help create a commodity. This results in a constant, healthy tension among the standards bodies' participants as they work with each other on the standard, while simultaneously vying for market share with their different products.

The term "open" with respect to standards became a mantra in the late 1980s and early 1990s, and was tied to the concept of "open systems." As Cargill observed, "open systems" was marketing-speak for the idea that if all the vendors would just build their computing products to "open" standards, the consumer would be able to build data processing systems by mixing and matching information processing hardware and software modules in much the same way that one could mix and match stereo components to build the desired system.[5] "Open systems" was a description of the architecture the consumer thought should exist. Unfortunately, the complexity of interconnected data processing systems doesn't lend itself so readily to the metaphor of a single-purpose device (i.e., the stereo system) and the ability for plug compatibility between stereo components to solve all the attendant complexity.

[5] Carl Cargill, Open Systems Standardization: A Business Approach (Upper Saddle River, NJ: Prentice Hall 1997), 70-71.

"Openness" became a quality attributed to the standards that would enable open systems. The openness was an attribute of the creation process (the standard was built in some form of public, consensus-based process open to all participants) rather than an attribute of implementations of the standard.

The development model for a standard is unrelated to the development model used for the implementation of that standard. It is equally possible for a standard (open or otherwise) to be implemented in a closed proprietary software product or in an open source software project.



Open Sources 2.0
Open Sources 2.0: The Continuing Evolution
ISBN: 0596008023
EAN: 2147483647
Year: 2004
Pages: 217

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net