Standards Today

EDITOR'S NOTE:

The Lego Approach to
Consortium Formation

Andrew Updegrove

An ongoing topic area of Standards Today since its inception has been the practical side of consortium formation, participation and management. Many of the Feature Articles on these topics have been compiled into the Essential Guide to Standards section of ConsortiumInfo.org, which comprises a free, book length manual for anyone seeking to launch, operate, evaluate, or participate in such an organization.

The first issue of Standards Today this year continued that trend, providing an overview of the different ways in which the very flexible consortium structure has been adapted across a variety of collaborative efforts. This issue picks up where that one left off, explaining how consortia can best be constructed to support different types of standards related endeavors. The Feature Articles from both issues will later be added to the Essential Guide, which I hope to offer in eBook and printed form later this year.

In this month's Editorial I open by asking whether there are too many consortia in existence already, and note that the real question has more to do with whether the consortia launched in prior years are the right ones to take up the new technical challenges that continue to emerge. If not, then there are by definition too few.

In my Feature Article I carry this line of inquiry further, identifying the reasons why a new consortium should — and as importantly, should not — be created. I then identify particular programs that are needed to support specific goals, and finally match these programmatic modules to a list of typical consortium roles to illustrate what a given consortium should offer to its members in order to efficiently achieve their goals. A Lego approach, if you will, to designing and assembling a new organization destined for success.

Turning to the Standards Blog, I offer two entries this month instead of one. Together, they illustrate the continuing, but slow, evolution of best practices in an area of collaborative activity that is closely associated with standards development in the information technology industry: the creation of open source software. Despite the fact that there are now untold thousands of open source projects, from very large and influential to very small and barely known, the state of the art in designing supporting infrastructure for this increasingly important process has advanced very slowly.

In the first entry, I comment on the impact of the lawsuits launched by the SCO Group against Linux, the most successful of all open source software, and the lessons that have been learned along the way. In the second, I provide my observations on the negative impact of corporate mergers on influential open source projects that are hosted by single companies, rather than controlled by stand alone, legally independent organizations.

The conclusion of the first blog entry is that the open source community and the marketplace ultimately benefited and grew stronger from SCO's attacks. But the central lesson of the second is that the communities and users relying on corporate controlled open source projects would have been better off had they taken advantage of the lessons learned long ago by standards development organizations.

I once again follow with a chapter from my now-completed cybersecurity-focused thriller titled The Alexandria Project. If you enjoy it, there's no need to wait until the next issue of Standards Today to see what happens next, as you can find the following chapters beginning here.

The Consider This essay that as usual closes this issue is timely in a different sense, and focuses on the plummeting standard of civility voters are settling for on the part of those vying for office in the current U.S. Congressional campaign.

As always, I hope you enjoy this issue. But either way, it's always great to hear what you think. Let me know, why don't you? My email address is andrew.updegrove@gesmer.com

The complete series of Consortium Standards Bulletins can be accessed on-line at http://www.consortiuminfo.org/bulletins/. It can also be found in libraries around the world as part of the EBSCO Publishing bibliographic and research databases.

Sign up for a free subscription to Standards Today.

return to top

---

CALL FOR PAPERS:

Have You Written a Standards-Related Article
that Deserves Wider Exposure?

Andrew Updegrove

The Standards MetaLibrary includes categorized abstracts and links to over 1800 scholarly articles relating to standards. It's the largest resource of its kind, and receives tens of thousands of visits a month from all over the world.

If you have an appropriate article that is already hosted on line that deserves more attention, please let me know, and I will be happy to include its abstract and a link at the MetaLibrary.

If you have written an appropriate paper that is not currently available to on-line researchers and have the permission of the publisher to make a copy available on line, please let me know, and I will be happy to host a copy.

I will also be happy to entertain proposals to include appropriate standards related articles in future issues of Standards Today, which is electronically delivered to over 6,000 subscribers around the world, and also included in an EBSCO database found in most academic libraries.

I can be reached at andrew.updegrove@gesmer.com, and by phone at 617/350-6800

Copyright 2010 Andrew Updegrove

Sign up for a free subscription to Standards Today.

return to top

---

EDITORIAL:

Are There too Many Consortia?

Andrew Updegrove

Companies that participate in hundreds of standard setting organizations (SSOs) often bemoan the continuing launch of more and more such organizations. Why, they are wont to ask, are so many new ones being formed all the time? And indeed, the aggregate participation costs for such companies in terms of membership dues and personnel are very high.

Of course, if you read the press releases of the new consortia launched in any given year, you'll see that almost all include some of the same companies among their founding members. So which is the more accurate picture — that there too many consortia, or too few? The best answer to both questions almost certainly is "yes."

How can that be true? Let's look at these questions in reverse order to find out.

First of all, there are never likely to be enough SSOs, in the sense that while the inventory at any point in time will be large, the range of the available stock will rarely be completely comprehensive when compared to the technology landscape at the same instant. This is particularly true with respect to new technologies, where more often than not, no existing SSO will prove to be technically appropriate as well as interested in expanding its mission to fill the gap.

Even if a given organization is both interested and appropriate, it may still be a poor choice, because new technologies usually require more than simply a competent development platform to achieve market acceptance. An existing organization must therefore also stand up to further questioning: is it well respected? Does it already have the right stakeholders as members, or would they have to be recruited? Does it offer all of the supporting functions that success may require, such as promotion, certification, branding and training?

And even if it does, will it be willing to dedicate the necessary resources to aggressively promote the new standard's adoption in the marketplace? The window of opportunity to achieve success may be narrow, and if the existing SSO is not willing to make the development and promotion of the new technology a high priority, then the technology, as well as the standards, may fail.

Viewed from that perspective, it's easy to see why companies placing enormous economic bets on the new types of products and services often opt to found a new consortium, the sole mission of which is to achieve the rapid and wide adoption of its standards.

Not surprisingly, almost all new consortia do support emerging technologies (some of which will compete with existing technologies already supported by other SSOs). Often, several consortia will be formed simultaneously to support multiple new technologies, each competing to take advantage of the same recently identified market opportunity. In some cases, this will be wasteful, but in others it will allow the market to decide which standardized technology it likes the best. Sometimes, as occurred in the wireless space, several winners will emerge, each optimizing its technology and its standards to better address a subset of the originally defined market niche. The result? Faster time to market for more products and services based on more appropriate and competitive technologies.

That said, it's also true that there really are too many SSOs (usually consortia, as compared to traditional SSOs), for three principal reasons: some organizations never should have been formed to begin with. Others support technologies that lose out to other contenders. Finally, some simply don't know when to declare victory and shut down.

The last of these scenarios inevitably solves itself organically. When standards go into their maintenance phase, members lose interest and don't renew. When that happens, revenues fall. If the standards created by the organization are still useful, the SSO will simply find another, healthier organization willing to take them on in exchange for picking up a few new members and whatever cash may be left in the bank account of the original SSO, which then dissolves.

The market verdict on SSOs that never should have been formed is usually delivered more swiftly and painfully. If the founders failed to gauge the level of interest in the marketplace for their new technology or business case, they will fail to attract enough members to complete the development cycle. The founders of other failed SSOs may have had a valid business goal, but either lost out to a competing technology, or did a poor job of structuring, explaining, and/or promoting their vision. Either way, these organizations die quietly in the dark.

The SSO proliferation issue is therefore a red herring: it's not whether there are too many SSOs in existence at any point in time, but whether the right SSOs are available to do the work that needs to be done.

In the high-stakes, fast moving world of technology it's important to realize that we need not only well-respected, well-run, stable SSOs to develop and maintain suites of standards to support technologies that have already found support in the market place, but also new, laser-focused consortia whose mission it is to tackle the difficult task of pulling the marketplace in new directions.

The art in such matters, then, arises from having the clarity of vision to know when a new SSO is needed and when it isn't; the experience and skill to structure and promote the new SSO in such a manner as to ensure success; and the objectivity to determine whether the SSO, once mature, should take it's place among other institutionalized SSOs, or declare victory, find a new home for its standards, and dissolve.

Copyright 2010 Andrew Updegrove

Sign up for a free subscription to Standards Today.

return to top

---

FEATURE ARTICLE:

When and How to Launch
a Standards Consortium

Andrew Updegrove

Abstract: The last twenty-five years have been marked by an explosion of consortia formed to develop, promote and/or otherwise support standards enabling information and communications technology. The reasons for forming a new consortium, as compared to adding to the work program of an existing body, include the absence in such organizations of appropriate technical expertise, interest, and/or supporting programs, as well as the benefits to be gained from directing all of the resources and efforts of a new consortium to the achievement of a set of specific objectives. This article reviews the benefits to be obtained from launching a new consortium, the criteria that should be used to determine whether doing so is appropriate, the programs and functionalities available for achieving specific goals, and the stages of institutional maturity at which each function should be added in order to accomplish a new organization's mission.

Introduction: One of the most successful innovations of the past twenty-five years in the area of collaborative development has been the application of the "consortium" concept to the area of standards creation and promotion. Almost overnight, this inherently flexible approach was adopted by scores, and then hundreds, of ad hoc, self-selecting cadres of stakeholders (usually product or service vendors) to develop, promote and maintain thousands of new standards in the fast-paced information and communications technology (ICT) industry. Today, almost all of the standards in key technical areas such as the Internet and the Web are created and supported by consortia. Consortium developed standards also predominate in the information technology sector, and, to a lesser extent, in communications technology as well.

Despite this success, the formation of standards-related consortia remains largely limited to the ICT arena, and to new ICT-related standards development initiatives launched in other industries (e.g., automotive, life sciences, and so on).

This selectivity of application provides an answer to an intriguing question: why form new standards consortia at all, given the hundreds of already-existing traditional standards development organizations (SDOs) and consortia?

In this article, I will review the situations where a new consortium should and — as importantly — should not, be formed. I will also provide a decision tree for determining what activities a new consortium should undertake to increase the likelihood of its success, a description of the infrastructural elements needed to support these activities, and an indication of the stage of an organization's maturity at which the addition of each activity becomes advisable.¹

I    When a New Consortium Makes Sense

Why launch a new consortium at all? While launching and operating a new consortium is a low-cost (in dollars) exercise, it demands a meaningful expenditure of time by at least some of its founders. Moreover, in order to achieve success, it must attract a critical mass of members for multiple purposes: first, since the adoption of most standards is voluntary, potential implementers will pay close attention to which vendors have demonstrated their support through membership to determine whether they should pay attention to the new consortium's efforts at all.

Next, even where the framework for a first specification has been contributed by one or more members, it will usually be necessary for a group of skilled, member-contributed representatives to produce the finally adopted standard. Finally, a standard can only gather momentum through implementation, and the best way for a standard to get off to a fast and successful start is through its members own adoption.

Why, then, would any group of stakeholders undertake the time, cost and risk of launching a new consortium instead of simply taking their project to one of the hundreds of existing standard setting organizations (SSOs) that have already demonstrated their competence and success?

There are four situations that most frequently lead to the formation of a new consortium. In reverse order of frequency, they are as follows:

        Displacement of a market incumbent: During the 1980s and 1990s, many consortia were formed by groups of competitors joining together in an effort to displace an incumbent in the marketplace on platform after platform (e.g., desktop, server, mobile device, etc.). Frequently, that incumbent was Microsoft, and the competitors were seeking to stem the software system vendor's seemingly inexorable march towards dominating both the application software as well as the operating system marketplaces. In some cases, these efforts sought to shore up the position of one or another flavor of UNIX as the operating system of choice before Microsoft's (then) new Windows NT server operating system could become dominant.²

However, most of the consortia formed for this purpose proved to be largely unsuccessful. Today, consortia are rarely launched to pursue such a strategy.

        Support of an existing standard: While, as already noted, most information technology, and to a lesser extent communications technology, standards are now developed by consortia, substantial numbers are still developed and maintained by traditional standards development organizations (SDOs) that are either nationally representative (e.g., DIN, in Germany) or nationally accredited (e.g., the c. 200 individual SSOs accredited in the United States by the American National Standards Institute (ANSI)).

Although a number of ANSI-accredited SDOs engage in a variety of standards promotional activities (often, these are trade associations that also develop standards), others restrict their activities to standards development only. In the case of ICT, a great deal of promotional activity is often needed in order for a standard to achieve a critical mass of adoption in the target industry. If the SDO that develops a standard does not include promotional activities in its work program, such a standard may well be doomed to irrelevance before it is even completed. In other cases, a branding and/or certification program may be essential in order to provide the level of assured interoperability and generate the customer demand necessary to produce success. Once again, if the SDO is not interested in facilitating such programs (and many are not), the standard will suffer.

In such a situation, interested members are left with no alternative but to form an auxiliary organization to provide the type of market support needed to achieve their goals. This phenomenon is well illustrated by the several consortia founded to support standards developed by the 802.11 wireless working group of the Institute of Electrical and Electronics Engineers (IEEE).

In the case of the suite of now-ubiquitous WiFi standards developed by this working group, the supporting organization is the WiFi Alliance, which developed interoperability test suites, a certification program, and a consumer-facing branding program to raise customer awareness of "WiFi" branded, compliant products. The efforts of this consortium were instrumental in ensuring that the technology served by the WiFi standards became dominant instead of any of the several other competing, standards-supported technologies.

Some of these standards, supported by their own consortia (e.g., HomeRF) ultimately failed, while others, such as Blue Tooth, found success in their own discrete application areas.³

The example of the WiFi Alliance was picked up by IEEE members supporting another standard released by the 802.11 working group, the WiMAX medium range, broadband wireless standard, who formed the WiMAX Forum. Indeed, in the case of a standard under development by the IEEE 802.15.3a working group, matters became so contentious that competing working group members incorporated two separate promotional organizations even before the final adoption vote was taken.⁴

        Absence of alternatives: While the ranks of existing SSOs are large, this does not guarantee that there will always be an existing SSO that is "right" for a given purpose. The reasons are several:

• Lack of domain expertise: The ICT industry is constantly giving birth to new technologies, products and services. As a result, no existing SSO may have the technical competence to undertake the new work.
  
  
• Lack of interest: Not surprisingly, existing SSOs must balance their limited resources against the priorities of their members. Unless a sufficiently large number of members expresses an interest in a proposal to launch a new working group, the SSO is unlikely to support it. At the same time, non-member proponents of the new standards proposal may not wish to pay full dues to an organization in a situation where they have an active interest only in the proposed standard.
  
  
• Blocking members: As a standard becomes established, some companies are likely to be more successful than others in garnering large shares of the resulting market for the standardized products or services. Where new standards may challenge existing ones, the members of an otherwise most-appropriate SSO that are doing well supporting the existing standard may have no desire to return to a level playing field where their competitors may meet, or exceed, their own success. Since SSOs are membership organizations, management is unlikely to press for the launch of a new working group proposed by one set of members in the face of strong opposition from another.
  
  
• Focus, speed, and control: With the advent of the Internet, the Web, and now the Cloud, the success or failure of new technologies, products and services has become ever more dependent upon the availability and wide adoption of the interoperability standards essential to allow these technologies to work. While the specific technical architecture to be formalized in some ICT standards may be obvious and non-controversial, very often multiple approaches will be feasible, with each having great strategic significance for one or more individual companies. For this reason, companies that will necessarily risk billions of dollars when they commit to a new technology have great incentives to try to ensure that the standards that are ultimately approved serve their interests best.

Even where significant competition over the appropriate technical approach to take is not expected, moving markets to buy new products and services takes great effort. This is especially true where value can only be delivered through achieving network effects.⁵ Given the rapid advance of technology, achieving network effects quickly is essential, and requires marshalling the coordinated efforts of many types of stakeholders.

Establishing network effects is not always realistically achievable through existing SSOs, which already have their own priorities, and which may or may not have all of the capabilities that may be necessary to achieve the desired results. With so much riding on quick adoption, it is not surprising that vendors will be more than willing to commit the time and resources needed to launch yet another consortium.

Nor should it be a surprise that the largest volume of consortia continues to be formed year after year to support new products, or that whole new generations of specialized SSOs are periodically launched to develop and promote standards to enable sweeping new markets, such as mobile devices and applications. Indeed, it is common to see as many as a half dozen new consortia announced at a major trade show showcasing a new technology (such as wireless), business segment (like the SmartGrid), or area of increasing interest (e.g., security).

        Unique benefits: advantages of forming a new consortium over taking the work to an existing SSO in such situations include the following:

• Visibility: Nothing in the standards world catches the attention of the marketplace more forcefully than seeing an impressive array of global companies announce a new consortium, because the news signals that the landscape has just shifted for the entire industry. If the founding member list is impressive enough, competitors and customers alike will need to assume that the goals of the new SSO may well be achieved, and that their own decisions must adapt appropriately.
  
  
• Commitment: In a related vein, by forming a new organization the founders signal their commitment to the new technology and its standards in a way that merely announcing a new working group in an existing SSO can not achieve. In other words, the founders are signaling their determination to do whatever it takes to ensure that the standards in question will become widely adopted, once again raising the credibility of their work product.
  
  
• Identity: By its existence and the combined support of its members, a dedicated consortium helps build the brand of the standardized products and services that it helps enable. This is particularly true in B2C (Business to Customer) space, where the name of the standard frequently becomes a commonplace in stores, whether or not the consumer realizes that the word they associate with a product or key product feature is in fact the name of the interoperability standard that allows it to work. Examples include USB, BluRay, Bluetooth, WiFi, and many more.
  
  
• Control: When new working groups are chartered in existing SSOs, it is usual to allow any member to propose the way forward. One, two, or even dozens of approaches may be placed on the table, with the final choice being made through a consensus-based process. In some cases, this can be the result of compromises agreed to "in the hallways" between competing proponents, but ultimately, only a single standard will issue. By forming a new SSO based upon a specification they have already developed, vendors with a stake in taking a particular technical approach can ensure that the standard they make available to the world will reflect their own preference. Whether or not the members will be successful in persuading the marketplace to adopt the standard will in large part be a result not only of the quality of the standard and the appeal of the technology it supports, but of the combined market power of the members committing to implement the standard.
  
  
• Strategic effectiveness: A new consortium can undertake all of the closely tailored projects and efforts that may be needed to achieve success (on which more later), and alter the mix as time, experience and the SSO's fortunes direct.
  
  
• Resource efficiency: 100% of the resources of a new consortium can be used to achieve its mission.
  
  
• Influence: A stand-alone consortium can often form liaison relationships with other SSOs more easily, and through them influence the evolution of other standards and practices in the area of their joint interest. Such collaborative efforts can help avoid unnecessary technical overlap and redundancy in work product, and to increase synergy between the new consortium's standards and those of other SSOs that are likely to be used in common frameworks.

It is these advantages that continue to drive the formation of new consortia as new technologies emerge and old ones evolve. To once more use the wireless marketplace as an example, the rapidly proliferating and diverse range of wireless technologies, and their supporting SSOs, today includes the following organizations (among many others): Near Field Communications, which enables "contactless" communication between cards and readers (NFC Forum); RFID tags for inventory control and other purposes (RFID International Business Alliance), DASH7 long range, low power sensor communications (DASH7 Alliance); Profile, for self-powered monitoring and control of sustainable buildings (EnOcean Alliance); as well as the multiple standards supported by the venerable IEEE.

Today, the formation of consortia focusing on wireless technology continues apace, as new market opportunities emerge in areas such as mesh networks, "Femtocell" networks, SmartGrid applications, and much more.⁶

II    How to Structure a Consortium for Success

Once a decision has been made to launch a new consortium, the question turns to its design. Whether or not the consortium will succeed or fail will depend on how skillfully decisions are made at this point in time. Those decisions fall into two major categories:

Structuring to facilitate recruitment: As already noted, the success or failure of a standard is ultimately determined as much by the membership its supporting SSO attracts as by quality and value of the standard itself. Achieving the "right" membership involves satisfying the following criteria:

        Balance: While a standard can achieve success through adoption by only a small group of companies where those few companies dominate the marketplace, more often the niche in question will be more diverse, and achieving success will therefore require implementation by a large group of companies. Among the criteria that potential implementers will take into account in making their decision will be whether the process that has created the standard and will continue to maintain it is reasonably open and neutral. If the answer is yes, than they will feel secure that the process will not be managed for the benefit of the few at the expense of the many.

On the other hand, if those that found a consortium restrict its membership in a discriminatory fashion, or structure it in such a way as to sequester control in the hands of a single type of company (e.g., semiconductor companies), then other companies (in the former case) or types of companies (in the latter) will justly fear that their interests may be sacrificed, and that implementing the standard may be unwise.

        Value Propositions: The way to ensure a balanced membership is to ensure that the governance structure of an SSO demonstrates equality of access to all types of stakeholders, at all levels of membership, and to tailor membership classes in such a way as to provide a "value proposition" for each type of stakeholder: in other words, a package of benefits that the category of member in question (e.g., vendors, customers, government agencies, academia, and so on) values at a price that it can afford and that seems appropriate to its needs. Often, this will involve scaling fees by revenues, in the case of for-profit companies, and offering dramatically lower fees for the same privileges, in the case of government, academic and non-profit members.

I will not go into further detail in this article on the topics of governance, value propositions, dues structures, and other topics central to the success of an SSO, because I have dealt with them extensively in the Essential Guide to Standards, both from the perspective of the potential member evaluating a given SSO, in the section titled: Participating in Standard Setting Organizations: Value Propositions, Roles and Strategies, and from the founder point of view, in the section titled: Forming a Successful Consortium, Part I — Business Considerations.⁷

Structuring to provide essential functions: It is useful to think of the consortium concept as a flexible participation and governance framework associated with a menu of operational modules (some with sub-modules), each of which is intended to enable the accomplishment of an identifiable goal. "Building" a consortium therefore entails a three part process: definition of goals, identification of the activities needed to achieve those goals, and incorporation of the appropriate programmatic modules into the structure of the new organization.

Using this approach as a construct, it is possible to create an outline that assigns the appropriate modules to the goals most typical of the founders of standards development and other standards-supporting consortia. In each case, the ultimate goal is assumed to be securing the wide-spread adoption and ongoing implementation of an effective, useful standard.

        Standards Development: Many, but far from all, consortia will include as their primary function the development of one or more standards. The submodules of creating a successful development process are as follows:

• Technical Process: An effective process requires rules and procedures to regulate its actions, avoid disputes, and provide guidance to those charged with administering that process. These rules address (among other topics): who may participate; how voting is conducted and when; which governing bodies within the SSO must approve a standard, and in what order, and when; and how a standard is maintained over time. The goal should be to incorporate existing best practices into the process document adopted by a new SSO rather than reinventing the wheel.⁸
  
  
• Intellectual Property Rights Policy: The implementation of many ICT standards may unavoidably entail the possibility of infringing the patent claims of members or third parties (usually referred to as "Necessary" or "Essential" claims). While nothing can be done to require non-members to license such patent claims on "reasonable and non-discriminatory" (RAND) terms, members should be required to at minimum disclose whether or not they have necessary claims, and if so, whether or not they will license them on RAND terms. Some SSOs go further, requiring members of working groups, or even all members, to do so, while others go further still, prohibiting member-owners of necessary claims to charge a royalty or other fee at all. It is essential that a new consortium have a policy regulating such intellectual property rights (IPR); indeed, most large companies will refuse to join until they can review it and find it to be acceptable). It is equally important that the specific terms of such a policy (which will frequently vary by industry and technical area) will be deemed to be acceptable by the companies targeted for membership.⁹

        Implementation facilitation: SSOs often develop other technical work product that can make standards implementation more attractive, risk free, or simple. Those deliverables include the following:

• Reference implementations: Reference implementations (most frequently software) are actual products, or product elements, that can be used by, or incorporated into the products of, members (and often non-members as well). The value of such deliverables often lies not in the avoided costs of development for licensees of the reference implementation, but assurance that inclusion of the software in question will not infringe on the patent claims of members that are not available for license on RAND terms. In such a case, members agree not only to license their necessary claims, but agree that the reference implementation will not result in the infringement of any of their other patent claims, thereby creating an IPR "safe harbor" for implementers (at least to the extent of member patent claims).
  
  
• Certification test software: As discussed in greater detail below, certification can involve a range of procedures. Where the creation of an actual test suite has been funded by the SSO or by one or more of its members, the same test suite can be used to help an implementer debug its implementation, thereby saving time, expense and trouble.
  
  
• Guidance: SSOs often create a variety of deliverables to make it easier and more attractive for members and non-members to implement their standards. These can include implementation guides, responses to frequently asked questions, and training materials.

        Promotion: In situations where a decision is made that a new organization is needed, it will almost always be the case that the market will need to be educated (and often cajoled) into adopting the resulting standards. By forming a consortium, a mechanism is provided whereby multiple members can collaborate on promotional and educational efforts, thereby leveraging their joint efforts to greater effect. It is important to note that the key role of the consortium is to facilitate the efforts of its members rather than to conduct all of the required activities itself, since "industrial strength" global public relations and advertising campaigns lie far beyond the resources of almost all SSOs. Those efforts that a consortium can conduct include the following, and are usually overseen by a Marketing Committee that may in some cases be as active as the Technical Committee:

• Developing messaging: For purposes of promotion, standards are just as much products as are any tangible goods. Before they can be effectively promoted by a consortium and its members, proper messaging should be agreed upon so that the marketplace hears a consistent story, and so that the impact is cumulative. Messaging in incorporated into key deliverables such as talking points, press releases (usually including quotes from influential members), and collateral marketing materials that members are encouraged to distribute.
  
  
• Public relations: Consortia with an adequate budget will usually either hire a third party PR firm, or hire staff able to draft and circulate press releases, arrange speaking dates for consortium representatives, communicate with the press, and assist in the production of marketing materials.
  
  
• Face to face meetings and trade shows: Most consortia hold public meetings at which they seek to communicate not only with members, but also the press. Some go further and invite non-members, or even manage (or partner with others to manage) full fledged trade shows that promote public awareness of the consortium, the products and services that its standards enable, and their positive impact on the marketplace. Consortia frequently send speakers to third party trade shows as well.

        Education: SSOs often create deliverables that raise non-member awareness of the need for and benefits obtainable from the standards the SSO supports. These materials can include White Papers (sometimes commissioned from analysts and other third parties), "success stories" provided by implementers, and market studies.

        Public advocacy: While most SSOs do not engage in actual lobbying, many may allocate some resources to making governments aware of their standards and their benefits. A smaller number engage in more serious efforts to influence legislators for a variety of reasons (e.g., to encourage governments to forego imposing regulations in favor of allowing the SSO to provide such standards as may be necessary to achieve a given purpose).

        Implementer credibility and customer assurance: A standard is able to achieve only as much credibility as the products or services that implement it earn in the marketplace. If, for example, an implementer claims compliance with an interoperability standard and a customer finds that the supposedly compliant product does not "plug and play" with its other compliant devices, then it will be left to wonder whether perhaps it is the standard that is defective rather than the product. The ability to ensure reliable, expected performance can therefore be an invaluable tool to build confidence, and therefore purchasing desire, in potential customers. SSOs provide this function in several ways:

• Product Certification: While certification may be mandatory in many product areas as a precondition to successful entry into global commerce, or in order to meet safety or health regulations, in the ICT industry it is undertaken (when it is undertaken) most frequently as a way to reassure potential customers (business or consumer) that a vendor's products or services comply with the standard being certified, and will therefore perform as advertised in the appropriate respects. Certification norms vary widely in the IT industry, in part because developing the necessary test suites is typically quite expensive, and also because establishing a credible certification program is time consuming and requires ongoing management time to supervise. For this reason, certification programs range from the very light (self-assertion of compliance) to thorough (testing by an SSO-authorized third party test labs).¹⁰
  
  
• Non-Product Certification: Services, security and other non-tangible, standardized processes are often certified as well. Unlike products, which are usually tested once (either individually or by representative lot samples), non-tangible processes often require periodic compliance testing to maintain certification. Instituting such testing may require the SSO to also train, test and certify those third parties (for a fee) that it authorizes to conduct such testing.
  
  
• Branding: Related to, but distinct from, certification is branding, which in the case of SSOs is the building of customer awareness in the value of products or services compliant with a standard, as demonstrated by an easily recognized trademark (usually associated with a logo). In the case of goods sold business to business (B2B), there is typically less interest in investing in the development of a brand, but in the case of B2C goods, the value can be high — WiFi and Bluetooth once again providing excellent examples. Launching an effective branding campaign involves multiple elements, including artistic and PR development of the brand, legal registration and ongoing maintenance (nationally or globally) of the associated trademarks and logos, licensing and policing their use, coordinating member promotion of the brand, and more. After initial startup costs, branding can provide significant additional revenue to an SSO through the payment of trademark licensing fees.¹¹
  
  
• Plugfests: The creation of standards inherently involves balancing the benefits of voluntarily restricting a design at one level while still allowing competitors to compete by building differentiated value above the layer of standardization. In the case of dimensional standards, assuring 100% physical interoperability (e.g., for a light bulb and its socket) is not difficult. In the case of ICT standards, however, there is not only value in making a standard no more restrictive than necessary, but it may be difficult, impossible, or unacceptable to members to achieve such specificity that a compliant product will reliably interoperate with other compliant devices simply by complying with the standard.
  
  A popular way to close this interoperability gap is for an SSO to sponsor "plugfests," at which competitors can test their pre-release products with other compliant products and work out any remaining issues. For obvious reasons, these are carefully controlled events, conducted under strict non-disclosure rules, as vendors have no interest in informing their competitors of the details of their products (or even their existence) before they have been publicly released.

        Training: Often, the availability of various types of training may facilitate the rapid uptake and success of a standard. In the case of individual or process standards that are supported by certification, this is especially so. In some cases, training will be supplied by third party service vendors that take advantage of the market opportunity. In others, the SSO may provide training, which can often supply a welcome source of additional revenues.

        Intersections with the global standards infrastructure: Standards rarely exist in isolation, and in the ICT space, it is rare for a single SSO to develop all of the standards that are needed to serve the needs of a given industry niche. Indeed, with the explosion of mobile devices, a single hand-held product may need to comply with literally hundreds of connector, wireless, chip, audio, video, internet, Web and other standards. Ensuring that all of these standards not only play nicely together on the same device, but that their use is affordable and as simple to implement as possible is no mean feat. SSOs work towards achieving this goal in a several ways:

• Liaison relationships: A typical successful SSO will maintain formal relations with 40 or more other SSOs, with the number varying largely with the organizational density of the relevant market sector(s) that the SSO serves. These liaison relationships are either general or specific, with the former intended to maintain the type of ongoing communications between the two SSOs needed to avoid needless duplication of efforts and maximize the synergy of the output of the partners. Such relationships are usually limited to information sharing, and permitting representatives of the two organizations to attend each others' meetings.
  
  Specific relationships can, however, vary widely, providing for joint development of standards or other work product, collaborating on certification, or otherwise working together on matters of mutual interest or concern.¹²
  
  
• Submission of standards to other SSOs: Consortia do not always wish to maintain their standards in the long term, or may wish to have a standard adopted by a more established SSO for purposes of gaining greater credibility. In the first case, the existence of the consortium may be brief, ending when its standard is complete and accepted by another SSO. In other cases, it may be the other SSO that approaches the consortium and expresses interest in adding one of the consortium's standards to its own portfolio. Finally, an ICT consortium may wish to submit a standard to Joint Technical Committee 1 of ISO/IEC for adoption through one of several processes (e.g., the "Fast Track" through ECMA, a European-based SDO with a special relationship with JTC 1, or in its own right through the Publicly Available Standard (PAS) process, after the consortium qualifies as a PAS Submitter). In this case, the standard is reformatted to conform to ISO/IEC requirements and goes through an abbreviated (six months, if all goes well) process that allows comment by eligible JTC 1 national members on the proposed standards Those comments can result in changes prior to final adoption.

III    Putting it all Together

With the above modules in mind, it may be useful to provide some examples of how various types of consortia may be created by assembling the parts relevant to its mission. Over time, this arrangement can, and should, change as the consortium's mission and the marketplace evolve. For purposes of demonstration, I will use the following typical consortium business cases. However, this list is neither complete, nor should the delineations between the examples given below be regarded as always being clear.

• Single product standard, transitory consortium (SPST): Typically formed for a specific need with either no desire, or with the express intent, not to become institutionalized. As a result, this type of consortium will hand off the standard not long after its development is completed.
  
  
• Single product standard, ongoing consortium (SPSO): Same situation, except the members wish to continue to maintain and promote the standard.
  
  
• Single product standard promotional consortium (SPSP): The consortium has been formed to support the work of another organization that does not provide services other than standards development.
  
  
• Multi-product standard, ongoing B2B consortium (MPSO): Typically formed to support a new market niche or product type.
  
  
• Single or Multi-product Brand standard, ongoing B2C consortium (S/MPBSO): Typically formed to not only develop, but also brand standardized products.
  
  
• Process standard consortium (PS): In this case, the standard(s) involved are for intangible attributes that are not tied to a single standard (e.g., effective security, which can be achieved through a variety of means of the user's choice).
  
  
• Individual or business standard consortium (IS): Often involving skills certification. Usually, the SSO will be a trade association providing multiple other services to members not addressed in this article.

Applicability of Functionalities: The tables below indicate what types of activities these consortium types would be most likely to undertake, and the degree to which these activities would typically be necessary or otherwise. In the table below:

• E indicates that the function would usually be essential to meet the needs of the business case
  
  
• T means that the function would typically but not always be supported
  
  
• O means that the function is an option that might or might not be found in a consortium of this type, depending upon the particular realities of its mission, marketplace, members, and so on
  
  
• N means that this function would rarely, if ever, be found in a consortium of this type

In the case of any given SSO, the actual range of functions can be expected to vary, so the table below should be regarded as illustrative rather than dispositive.

Table 1: Standards Development and Implementation Facilitation

Consortium Type	Technical Committee	IPR Policy	Reference Implemen.	Certification. Test SW	Guidance
SPST	E	E	N	N	N
SPSO	E	E	O	O	O
SPSP	N*	N*	O	O	O
MPSO	E	E	O	T*	T
S/MBPSO	E	E	O	E	T
PS	E	E	N	N	T
IS	E**	T***	N	N	E

* M, if the consortium manages a certification and branding campaign
**"Standards Committee" would be a more appropriate name in this case
***The IPR Policy would usually relate only to copyright and trademark, and not patent, matters

Table 2: Promotion, Education and Advocacy

Consortium Type	Marketing Committee Functions				Education	Advocacy
	Messaging	PR	Meetings	Trade Shows
SPST	O	N	O	N	N	N
SPSO	E	E	E	O	O	N
SPSP	E	E	E	O	E	O
MPSO	E	E	E	O	T	O
S/MPBSO	E	E	E	O	E	O
PS	E	E	E	O	E	O
IS	E	E	E	E	E	O

Table 3: Implementer Credibility and Customer Assurance

Consortium Type	Product Certif.	Non-Prod. Certif.	Branding	Plug- fests	Train-ing	Liaisons	Submis- sions
SPST	N	N	N	N	N	N	E
SPSO	T	T	O	O	O	T	N/A
SPSP	T	T	T	O	T	T	N/A
MPSO	T	T	O	O	O	E	O
S/MPSO	E	E	E	T	T	E	O
PS	N/A	T	O	N/A	O	E	O
IS	N/A	E	E	N/A	E	O	O

Timing: Happily, not all of the functions described above need be launched simultaneously with the formation of a new consortium. Indeed, many would be irrelevant until a later point in the process, while others would necessarily follow in time due to dependencies on the prior completion of other work product or activities. The following table illustrates a typical roll out, and in some cases termination, of activities for consortia generally. The table correlates to the following development phases of a typical consortium:

• Pre-Standard Release: From date of public launch until the date the consortium's first (or only) standard is publicly released.
  
  
• Post-Standard Release: From the date of public announcement until the standard has (hopefully) begun to become widely adopted.
  
  
• Maturity: The ongoing, stable period of operations during which standards are maintained, new work is chartered, and a variety of supporting functions are conducted to maintain the health of the standardized ecosystem the consortium was created to create and/or serve.
  
  
• Wind-down: The period during which it may become apparent that a given consortium's mission has been completed, its standard(s) have ceased to be relevant, or the rationale for the continuing existence of an independent SSO for maintenance purposes is no longer cost-effective.

Table 4: Commencement and Termination of Functions

Function	Pre-Standard Release	Post-Standard Release	Maturity	Wind-down
Standards Development	X	X	X	Phase out
Standards Maintenance	X	X	X	Phase out
Implementation Facilitation		X	X
Promotion		X	X
Education	X	X	X
Public Advocacy	X	X	X
Certification/Branding		X	X
Training		X	X
Liaisons		X	X
Submissions to other SSOs			X	X

IV    Summary

Over the past 25 years a great deal of experimentation, emulation, and evolution has occurred in the area of consortium formation. Today, the state of the art continues to develop, both through refinement of existing practices as well as in response to changing market realities. The result is that it is far easier today to know when it is (and is not) appropriate to form a new consortium, as well as how to go about structuring one that will be effective and successful.

That said, the modular approach described above has necessarily been presented in a superficial way, and does not explore all of the criteria that should go into designing a new organization, the relative importance of given functions to achieve particular missions, nor all of the constraints (e.g., budgetary) that may bear upon the ability of a given new initiative to realistically maximize its efforts.

As a result, it is very important that the would-be founders of any new consortium enter into a deliberative exploration and planning exercise that carefully defines and scopes its mission, segments the pool of potential members needed to achieve success, assesses their level of interest, lists the functionalities needed to achieve the initiative's goals, and projects the budget needed to support those functions. Only then can the viability of the initiative be realistically assessed, and a workable plan for moving forward be developed.

Happily, consortia of all sizes — from a handful of members to thousands — and budgets — from $10,000 to $10 million a year — continue to be launched on a weekly basis. With proper planning and a real mission, there's always room for one more.

Copyright 2010 Andrew Updegrove

Sign up for a free subscription to Standards Today.

---

End Notes

¹ The observations in this article are primarily based upon my experience over the past 22 years in forming and representing over 100 consortia developing, promoting and supporting ICT standards. A complete list of these organizations can be found at:
http://66.223.107.171/practice_areas/consortium.php#CLIENTLIST

² Those consortia included 88open, supporting the Motorola 88000 RISC chip and associated operating system; SPARC International, supporting a similar combo developed by Sun Microsystems; and PowerOPEN, supporting yet another combination, this time based upon a chip design supported by IBM, Motorola and Apple. While each of the chips involved achieved varying degrees of success in embedded applications, none of them achieved significant success in the desktop or server markets, which had been the highest priority targets of the joint efforts.

³ The proliferation of consortia in the wireless space may seem at first glance to illustrate either a destructive standards war, or an exercise in wasted corporate resources. I have contended in a prior article that it instead illustrates the way in which consortia can help new technologies enter the marketplace more swiftly and productively, because multiple technologies can vie in parallel rather than sequence, with the best technologies ultimately finding success in the most appropriate niches. See, Standards Wars: Situations, Strategies and Outcomes, ConsortiumInfo.org, Standards Today, Vol. V, No. 3, March 2006, at http://www.consortiuminfo.org/bulletins/mar06.php#feature. Note, however, that short range wireless networks, which at first seemed to represent a single market opportunity, in fact contained multiple niches demanding multiple standards-based solutions, depending upon technical constraints such as range, data transmission speed, and power constraints, allowing for multiple ultimate winners. Had there been fewer contenders, fewer viable solutions for more specialized uses would have emerged in the same time frame. Wireless telephony, in contrast, by definition provided the opportunity for a true standards war. European regulators avoided that result by requiring a single standards-based solution, while the United States permitted multiple technologies to vie for supremacy. Economists were thus provided with a perfect opportunity to assess the comparative benefits of each approach, but have not as productively explored the example provided by the first generation of short range wireless standards.

⁴ The result was that while many competing proposals eventually merged into these two final alternatives, neither succeeded in securing the necessary 75% vote to become an IEEE standard. As a result, IEEE disbanded the working group, and the two groups of competing companies took their specifications — and consortia — into the marketplace to battle for supremacy.

⁵ The "network effect" describes the increasing value that a network provides to its users as more and more individuals and/or businesses connect. More obviously, the challenge to achieving a network effect for a product can be described by noting that it is much easier to sell the millionth telephone than the first. The same challenge applied to the first railways, gas stations, and so on down to the iPhone App Store and Facebook of today.

⁶ For a much more extensive list of SSOs active in the wireless industry, see the Wireless and Mobile sublist of the Standards Setting Organizations and Standards List at the author's ConsortiumInfo.org Web site, at: http://www.consortiuminfo.org/links/

⁷ The section of the Essential Guide titled Forming a Successful Consortium, Part II: Legal Considerations, as well as other chapters mentioned below, will also be of interest to those forming a consortium.

⁸ For further guidance, see the Essential Guide section titled Creating a Successful SSO Training Process.

⁹ For further guidance, see the Essential Guide section titled Intellectual Property Rights and Standard Setting.

¹⁰ For further guidance, see the Essential Guide section titled Certification Testing and Branding.

¹¹ Ibid.

¹² Liaison relationships are typically formalized under a short "Memorandum of Understanding" (MOU) that is high level, often non-binding, and typically terminable without cause by either party on short notice.

return to top

---

STANDARDS BLOG X2:

Looking Back at SCO:
What did it All Mean?

Andrew Updegrove

"ORDERED that SCO's Renewed Motion for Judgment as a Matter of Law or, in the Alternative, for a New Trial is DENIED."

So ends the ruling of District Judge Ted Stewart. And so also, perhaps, ends the seemingly endless quest of SCO to tax or kill Linux.

Given SCO's well-demonstrated tenacity and unwillingness to face reality, it may seem unwise to assume we have indeed seen the end of the road. But, as with the Black Knight in Monty Python and the Holy Grail, once someone who has lost touch with reality loses their last limb, it's easy to just walk away and leave them alone with their delusions. Presumably, that's what SCO's trustee in bankruptcy will now do, forbidding any funds to be spent pursuing SCO's suit against IBM, or anyone else.

Assuming that's the case, this isn't a bad time to ask the question, "What did it all mean?"

Of course, it meant a lot of things, some of which may not be learned for years to come, either because history will have to show us what the impact of the suits had on the uptake of Linux, or because facts will become public that are not now known (e.g., who may have been supporting, or even directing, SCO's litigation decisions behind the scenes).

But today I think we can identify a number of things that, paradoxically, represent very positive impacts that were certainly never intended by SCO. Here are those that I would say top the list:

    1. Best practices for producing open source came of age. Back in 2003, when SCO first started rattling its sabers, there weren't nearly as many open source software, or as many open source projects, as there are today.  The SCO suit made everyone, from individual developers up to corporations, more aware of the fact that the creation of code needs to be properly documented in order to avoid future problems.  There's nothing like litigation to focus the mind, and minds of all types were indeed focused by the SCO suits.  Today, the process of open source projects is much tighter and appropriate, providing a better legal foundation for developers and users alike.

    2. The commitment of major corporations to open source was conclusively proven. In 2000, IBM announced that it would dedicate $1 billion in assets to the development of open source software.  Open Source Development Labs (OSDL) was formed the same year by IBM and other major corporations.  When the SCO suits arose, the litigation provided another visible way in which technology vendors could demonstrate their support for open source software in general, and Linux in particular.  Members of OSDL created a legal defense fund within that organization to defend Linus Torvalds, the principal architect of Linux, and other kernel developers as necessary.  That legal defense mission continues today through OSDL's successor, the Linux Foundation, which exists to protect, promote and standardize Linux.  The result is that customers know that commercial Linux vendors are solidly committed to supporting not only the commercial development, but also the legal defense, of Linux.

    3. The SCO suits provided a rallying point for open source software (OSS) and free and open source software (FOSS) supporters alike to join together to support Linux.  It's easy to forget that in 2003 there was a much wider separation between corporations and developers than there is today.  Developers worried that the suits would co-opt their code, and corporate managers worried that the independence of developers might make FOSS development unreliable or unstable. That gap could have easily widened.  Instead, it has narrowed, as both camps have worked together against a common threat. In the process, each side has gotten to know the other better, and each has become more comfortable in that partnership.  This was in no small measure facilitated by the great work performed by Pamela Jones and her contributors at Groklaw, which became the major legal resource for corporations and developers, customers and journalists.  PJ made the law understandable and available to the developer community, and the culture of FOSS accessible and understandable to corporate types and journalists.

    4. The customer has been both educated and comforted.  Free and open source software is new enough that most potential users and commercial customers had little accurate knowledge about it when the SCO suits began.  The SCO litigation gave incentives to corporate and law firm lawyers to learn what FOSS/OSS licenses are all about, and also to see the impressive level of effort that the commercial and developer communities will bring to defending them.  The law suits also provided incentives to vendors such as Red Hat and Novell to provide the type of warranty protection that reassured customers.  And with every loss suffered by SCO, the perceived risk level of using FOSS/OSS continued to fall.

Perversely, SCO's suicidal mission against Linux therefore ultimately served to strengthen the role of the Linux operating system kernel it tried to encumber rather than the opposite.  Today, the reality of FOSS/OSS is far stronger than it likely would have been had not SCO destroyed itself in its vain quest.

While it would go too far to thank SCO for what it has done for FOSS/OSS, the saga that hopefully ended yesterday does serve to prove the wisdom once again of that old adage, "Something good comes of all."

Now it's time for FOSS/OSS to move onward and upward, battle-tested, confident and ready for anything.

Bookmark the Standards Blog at http://www.consortiuminfo.org/newsblog/ or set
up an RSS feed at http://www.consortiuminfo.org/rss/

Copyright 2010 Andrew Updegrove

Sign up for a free subscription to Standards Today.

return to top

---

STANDARDS BLOG:

The Oxymoron of Corporate Controlled
"Community" Projects

Andrew Updegrove

This morning brought the significant — and long overdue — announcement of the launch of an independent foundation to host development of the open source, ODF-compliant OpenOffice productivity suite. The good news of that lost decade is that under Sun's ownership and control, the OpenOffice suite became the most successful and widely implemented alternative to Microsoft's Office, providing at least some degree of competition in a niche where it had been missing for far too long.

The bad news is that in the same time period the OpenOffice suite could have become so much more.  As with other single-company controlled efforts in the past (e.g., the Eclipse Foundation, before IBM spun it out into an independent organization), other companies that could have, and would have, made significant contributions of personnel, funding and promotion stood aside.

Why?  Because Sun maintained too much control.  This reality has played out over and over during the past 20 years — when one or a few companies maintain too much control, others stay away, because they can't be sure that the project will be managed for everyone's benefit.

Knowing that an organization is "safe" to join, and will be managed for the benefit of the many and not of the privileged few, is one of the key attributes and assurances of "openness."

But there's another risk, which is even greater.  Recently, we have seen Oracle acquire companies with properties of great community significance (e.g., MySQL, OpenOffice, Java, and more), and Novell, custodian of OpenSuse and vendor of Novell Linux (one of the three most successful Linux distributions), has been put in play by a private equity firm.  What this highlights is the reality that even companies with good credentials as stewards for open source projects cannot control the future of these not so public after all projects when they are themselves acquired.

Standards developers realized this danger over 100 years ago.  That's when companies first started setting up independent, incorporated membership organizations to host, maintain, and protect standards.  In the last 25 years, as many as 1,000 standards development and promotional consortia have been set up, often for as little as $10,000.  It's easy to do, there are plenty of models to follow, and everyone understands everyone else's rights.

In the world of open source, however, this model has only rarely been followed, in part as a result of the light, fast moving, virtual culture of FOSS development, in part because of lack of familiarity with the legal structures used by standards consortia, and in part because FOSS projects launched by the community typically have no funding at all.

Some progress has been made.  For example, both the Apache and Eclipse Foundations regularly take on new open source projects, thereby providing the legal structure needed to protect these new initiatives.  But they can only take on so many.

Here's what the world of FOSS and open source needs from a legal perspective in order to protect community efforts and ensure the greatest participation in those efforts:

1. Open source forges need to provide a light-weight, free (or very inexpensive), turnkey, legal identity for small projects lacking economic support.

2. For projects that are likely to become broadly important, we need more foundations like Apache and Eclipse that can provide a more full service, nurturing legal as well as development environment.

3. Most importantly, corporations that wish to encourage wide participation by the development community must spin their projects out as independent legal entities.  Only by doing so can they guarantee to those they encourage to participate that their efforts will not later be subverted or financially abandoned.  Knowing that open source software can be forked is not the same as knowing that the project you spent years of your life building can suddenly be abandoned or redirected in a fashion that was never intended.

If these recommendations are followed, everyone, at every level, from individual developers to the corporations that in the past have provided most of the funding and developers for projects like OpenOffice, will ultimately be safer and better rewarded.

Bookmark the Standards Blog at http://www.consortiuminfo.org/newsblog/ or set
up an RSS feed at http://www.consortiuminfo.org/rss/

Copyright 2010 Andrew Updegrove

Sign up for a free subscription to Standards Today.

return to top

---

THE ALEXANDRIA PROJECT:

Chapter 3: I Just HATE it
When that Happens!

Andrew Updegrove

The complete Alexandria Project can be found on line here.

Monday morning Frank arrived at work early.  He scooped up the office copies of the daily newspapers from the pavement outside the staff door of the Library of Congress and noticed that the Washington Times was missing.  No need to wonder who arrived first today — that would be Rick — the only employee that wouldn't bother to bring a paper in for anyone but himself.

Sure enough, as Frank strode up the half-lit, half-high walls of the LoC's Cube Town, he saw Rick, coffee cup in hand.  His face lit up as soon as he saw Frank.  "Morning, Frank," he called out.  "Recovered from your big Saturday night yet?"  He raised his coffee cup in a mock toast and leaned casually against his cube so Frank could barely squeeze past.

But to Rick's surprise, Frank gave him a hearty welcome as he passed by.  "Great to see you, Rick, 'ole fella!  Only 70 more security-filled days you're your big deadline, huh?"  Rick's smile evaporated. Frank wondered just how long it would be before Rick showed up at his cube, shamefaced, to ask for help.  A week, tops.

Frank's own smug smile faded when he snapped on his cubicle lights and saw the note waiting for him: "See me ASAP — George."

George didn't turn around when Frank appeared in the doorway.  He was clearly lost in thought, staring at the whiteboard in his office.  Frank realized that George had sketched out the LoC's IT system at a high level, noting the particulars of the security defenses that stood between the jungle that was the Internet and the data resources of the LoC.

Frank suddenly thought of the scene in Tracy Kidder's The Soul of a New Machine where Tom West, the legendary Data General project manager, sat alone in an office opening off of a darkened room of computer work and test benches.  West's career was on the line.  His future depended on whether the "Whiz Kids" he had hired out of college would be able to debug the new computer he'd convinced management to let him design and build.  Things weren't looking good at that point, but West knew that all he could do was let things run their course without interfering and hope for the best.

His boss looked old, Frank thought.  George was getting old, Frank realized with mild surprise — probably past retirement age, now that Frank thought of it.  And the members of the IT staff at the LoC weren't whiz kids, either.  George was probably worried that this project might come to a bad end, making him look bad, too.  Well, that wasn't Frank's problem, now was it?

Frank was raising his knuckles to tap on the open door when George spoke.

"Hi, Frank," he said, without turning around. "Close the door and have a seat. I'll be with you in a moment."

Frank sat down, wondering for how long George had been aware of his presence.

A few moments later, George swiveled his chair around.  He leaned forward, both elbows on his desk and folded his hands together.  He looked Frank straight in the eye as he spoke.

"You know, this isn't a game, Frank.  I didn't appreciate your email on Sunday, and if you want to keep working here, that's the last email like that you'll ever send me.  Understood?"

Frank was taken aback; this wasn't what he had expected.  "OK, George, no problem.  I just wasn't sure what you expected me to say.  Who the hell has ever seen something like that before?"

"Like what?"  George snapped back.

Now Frank was really confused.  "Well, like that fiery screen, and the logo?  And what the heck is the Alexandria Project, anyway?"

George didn't say anything, but slid his Blackberry across the desk to Frank.

Frank picked it up and looked at the screen.  The email he had answered was open on its screen.  What was it he was missing? "It's the email you sent to me.  What's your point?"

Then he noticed something that he'd missed before: the email wasn't addressed to just him, but to "All Personnel" in the LoC.

Frank looked up and saw that George was watching him closely.  "Would it surprise you, Frank, to learn that you were the only one who replied to my email message?"  Frank said nothing.  "And what exactly were you looking for on a weekend in that particular directory, anyway?"

Frank was annoyed rather than flustered.  "For Pete's sake, George, I was looking for the draft of the security project outline I'd been working on — that's all."

"Looking for it, or deleting it out of spite?  And how about the other files in that directory?  Did you want to make it that much more difficult for Rick to get started?"

"What files?" Frank responded, "Are others missing as well?"

"Of course!" George barked.  "Two of them.  And one of them was Rick's project outline — involuntarily ‘contributed' to the Alexandria Project, whatever that is."

Now Frank was alarmed.  "Wait a minute, George!  Yes, I was ripped at Rick on Saturday night, but no — I'd ever pull a stunt like that!  And before you say anything, I know that the backup file for my outline is gone, too — probably yours and Ricks as well.  But I didn't do that, either.  And I also know that it doesn't look like there's else missing, or at least not much, if there is.  We had almost the same gross storage numbers Sunday morning as we did the night before."

"I know that!" snapped George.  "Do you think you're the only guy around here that has a brain?  I've already run a complete scan, and there were only three files deleted anywhere in the entire system that night.

George leaned back.  "Frank, are you aware that you and I are the only two people in the entire Library of Congress that have access to other people's material in that directory?"

Frank shook his head slowly from side to side.

George gave him a humorless smile.  "You should be a bit disappointed in yourself, Frank.  Maybe you're not such a security hotshot after all."

Frank couldn't listen any longer.  "Can the crap, George!  We've known each other for more than 20 years.  I know this looks like some kind of silly stunt on my part, but it's not.  What would I gain by deleting documents?  And hey — I'm no scholar of ancient Greek — I can't even speak a modern language other than English.  If it wasn't for Google Translate I wouldn't have a clue what that inscription said."

George was looking less certain, so Frank pressed on.  "And anyway, how could I come up with something like that screen overnight — with all that fancy flash animation?"  Frank was feeling more confident now.  He sat back and waited.

"Okay, Frank.  Nice points," George said at last.  "But this isn't over yet.  If you didn't delete those files, then we've got a real problem here.  You've got the security clearances to know that the CIA security hotshots use the LoC as a low public-profile testbed to stress test new security protocols before they roll them out in the Pentagon, the White House, and all the other Level 1 security government agencies.

"That means that if someone could hack your files, they could hack anything anywhere."  George looked at Frank, but Frank couldn't think what he might be waiting for Frank to say.

"I'm going to have to ask the CIA to check this out," George said at last.  "You and I may have known each other for twenty years, but to them, you're nothing.  They'll be asking you a lot of questions, and if I were you, I wouldn't get cute with my answers. Do you get it, Frank?"

Frank nodded.  "I get it."

"That's all then." George swung back to his whiteboard.  Frank stood up to go, but then had a thought.

"George…you said that there were three files deleted in all.  What was the last one?"

George replied without turning around.  "The last one was my security folder."  Then he did turn around.  "I really would watch my step for a while, if I were you."

Frank closed George's door softly and walked back towards his cubicle in a daze.  He barely noticed when Rick jumped up, obviously alarmed, as Frank passed by.

"Hey Frank! Frank! Can I check something out with you?  I just saw the damnedest thing on a computer screen I've every seen in my life!"

Read the next chapter.

Start at the beginning.

Copyright 2010 Andrew Updegrove

Sign up for a free subscription to Standards Today.

return to top

---

CONSIDER THIS:

#64 Standards of Political Civility
and Darwin's Finches

Andrew Updegrove

Heaven help us all (all us Americans, anyway) — it's election time again. That means we're once again descending into a morass of partisan invective, not to mention lies, damn lies, and (of course) statistics. Except that this election year it seems that everyone is behaving even worse than last time, when everyone acted even worse than the time before, when, well, do you sense a trend here?

One hallmark of this year's political "discourse" (to abuse a term) has been the number of astonishingly angry and ill-informed accusations made by some candidates against their opponents (and others). Nothing unusual about that, sad to say. But what is different is the degree of acceptance, and even approval, exhibited by many voters that in earlier years might have rejected these candidates as well as their statements.

There are obvious reasons for this tolerance: the public itself is in an ill-tempered mood, born of an ongoing, dire recession and Congress's refusal to exhibit even a pretense of bipartisanship in response. Then there's the fact that the cable and radio waves are not only once again full of invective from the right, but this time around the left can find over the top commentators at MSNBC as well. And stirring the whole sorry stew we have the amorphous but strident Tea Party, which in addition to showcasing their anger on the nightly news has scored victories in primaries supporting candidates whose "anything but the status quo" credibility far outweighs their credentials to govern.

With such a record , one has to wonder and worry — is this trend irreversible? Have standards for political civility sunk so low as to become meaningless?

Happily, I suggest that the answer is "no." And my logic can be found at the intersection of the standard setting process and Charles Darwin's Galapagian finches.

Let's look at the standards angle first.

Standards are formed in many ways, both structured and unstructured. At the most formal end of the spectrum, representative, consensus-based organizations called "governments" develop standards we refer to as laws and regulations. Next over are the variously representative and hierarchical bodies called religious faiths, which develop and maintain standards of conduct with names like "morality" and "ethics."

In the middle we also find representative, consensus-based bodies called "standard setting organizations" (e.g., ISO, IEC, ITU, national standards bodies, and consortia) that develop specifications the industries they serve call "standards."

And finally, at the populist end of the spectrum we find a much less structured consensus-based process that offers direct, rather than representative, participation at the local and national level by all of the stakeholders affected. These stakeholders, and the quotidian process in which they participate, we refer to as "society." It is therefore everyday citizens, plus the media, that organically generate those standards of behavior that regulate what a political candidate can, and can't say on the stump without garnering negative consequences.

The fact that the social standards development process is unstructured does not mean that it is not worthy of respect. Indeed, at the convention that yielded the American Constitution, George Mason acknowledged the supremacy of what he famously referred to as "the genius of the people." As he went on to caution, that genius must be "consulted" or the efforts of politicians will be doomed to fail.

This lack of structure does impose some limitations that are atypical of more formal standards development processes, both ancient and modern. Public opinion, for example, has been historically incapable of delivering the comforting precision of either the Ten Commandments or a modern technical standard. And social standards don't conform to the formal release cycles common to ecumenical counsels (creeds and statements of faith), legislatures (laws) and standards bodies (new versions of outstanding specifications).

Instead, standards regulating the acceptability of political civility and social conduct are in a constant state of flux. So it is that the bad behavior we are witnessing today does not arise from the release of a major new version of some non-existent ANS: Standards for Political Conduct, but from a recent morphing of the zeitgeist of the American voter.

Which brings us at last to the observations of the remarkably perceptive Mr. Darwin. Like so much else, the evolution of social standards recapitulates the evolution of the species. Social standards, like physical features, evolve in real time just as do the beaks of Darwin's finches. In each case, the process can proceed slowly or quickly, depending on the environmental pressures applied. And, as observed by former Speaker of the House Tipp O'Neil as well as by Charles Darwin, evolution is invariably local (the great revelation for Darwin, you'll recall, was that the shapes of the beaks borne by Galapagos finches varied from island to adjacent island).

So what might Darwin's finches have to tell us about the future of political civility in America?

Not long ago, a talented research group returned to the Galapagos Islands to see what Darwin's finches had been up to lately. Over the course of their long term study, they came to a remarkable conclusion: the beaks of Darwin's finches were continuing to change at a rate measurable across the span of only a few years. When hard to open seeds became more available than softer provender, the finches' beaks grew thicker and stronger. When soft food became more plentiful than seeds, the trend reversed. Overall, though, the birds' beaks had remained within the range of size and shape recorded by Darwin in 1835.

That's where the cause for optimism arises as election day nears. You see, the rapid evolution observed by the scientists was not the result of new genetic mutations that would lead to dramatic, permanent changes. Instead, they were witnessing the impact of a shift in the survivability of birds with beaks within the normal range of existing gene expression. Absent a macro change in global thermodynamics capable of favoring more profound changes born of new genetic mutations, the pendulum of beak dimensions continues to simply swing endlessly back and forth within the epicycles powered by normal climactic variation.

Absent the sort of societal disaster that can equate to a species-destroying comet impact, we can therefore expect to see the pendulum of expected political civility some day swing back, hopefully sooner rather than later. Or at least Darwin's finches so suggest.

If history can be relied upon, the Glenn Becks and Keith Obermans of today should therefore prove to be no more than a run of civil bad weather — a more than usually annoying political El Nino, if you will. If so, then life as we know it — and the standards of political civility and conduct we are willing to tolerate — will in the end return to what we used to regard as normal.

Here's hoping.

Copyright 2010 Andrew Updegrove

Read more Consider This… entries at: http://www.consortiuminfo.org/blog/

return to top

---