Standards Best Practices Blog

Earlier this month ITU-T, the Telecommunication Standardization Sector of ITU, announced that it would it will make its recommendations “available without charge for a trial period.”

This is quite a change, as de jure standards organizations such as ITU, ISO, IEC, and others get a significant portion of their revenues from the sale of their work products; ISO and ANSI each get about half of their revenue in this manner.

The business model of deriving revenue from the sale of documents is one of the biggest differentiators between the accredited or recognized standards organizations and the industry consortia and fora who, with few exceptions, make their work publicly available for free.

What’s driving this experiment? The ITU-T announcement is pretty clear: “There is a general belief that the strategic importance of making on-line access to ITU-T Recommendations free outweighs the costs (in terms of lost revenue) to ITU. This is seen as a way to increase the transparency of ITU-T work and encourage wider participation in ITU-T activities. It is also believed that this policy will help increase developing countries’ awareness of pertinent issues and help to promote the participation of academia in ITU-T work.”

In short, the ITU-T is admitting that the practice of charging for access to the recommendations developed by the organization is an obstacle to participation in and adoption of their work.

The recognized and accredited standards organizations have become increasingly aware over the past several years of the success of consortia, and have been making positive efforts to reach out to those organizations and providing procedures whereby consortia work can be submitted for de jure approval. I see this trial offer of free downloads as a further attempt to become more like the consortia who have shown so much success in recent years.

ITU-T’s making their recommendations available for free should have a positive impact on the adoption of their valuable and important work. Let’s hope that they can solve the rest of the business model so that this trial program can be made permanent while still allowing ITU to continue to thrive.

Following up on a comment to one of my previous posts I looked into the new patent policy developed and recently approved by VITA. The policy requires ex ante declarations, meaning that essential patents which read on the specifications, i.e. patents that would be infringed by any implementation of the specification and for which there is no workaround, must be declared by members of the consortium at the beginning of the specification development process. In addition, those patent holders must declare the FRAND terms under which licensing will be granted and provide a sample of the licensing document. The policy was developed over several years as a means of protecting the consortium and its members from anti-trust and other patent-related issues that have arisen both at VITA and at other organizations ( see for example the Rambus case).

This is an excellent way of doing things, as the workgroup members know up front whether they will be investing time and effort in developing technology that can be legally implemented. Potential implementers of the specification know what patents read on the specification, what licenses are required, and the terms under which licensing may be obtained. The downside is to the owners of the patents, who usually prefer to withhold disclosure of their IP until late in – or after – the specification development and approval process for strategic business reasons.

VITA claims the ex ante requirements to be an innovation in the standards industry; Executive Director Ray Alderman said in his response to a VME Now blog entry  that “VITA’s adoption of ex ante procedures is the most significant change in patent policy in the history of standards development.” Perhaps or perhaps not, as other standards organizations also require patent and licensing declarations before specification development and approval is completed; we developed a similar policy three years ago when I was at OASIS. But VITA’s requirement of declarations at the very beginning of the process, when the workgroup is formed, is sooner than I’ve seen elsewhere.

In anticipation of possible legal issues VITA has taken the proactive step of seeking Department of Justice review and approval of the policy before it was submitted to the VITA consortium membership for their approval. The DoJ issued an opinion last October approving the policy. Alderman is confident that the DoJ review will protect VITA from any lawsuits regarding the policy.

The patent policy has been approved by the VITA membership, and today starts the public review of the policy at ANSI, where compliance with the ANSI patent policy is required given VITA’s status as an accredited standards developer.

A weak point with any organization’s patent disclosure policy is that it binds only the members of the organization, and then only if the organization has a membership agreement binding members to the organization’s policies. But non-member third parties are not bound to disclose, which creates the potential of letting a few submarines through the net to surface once the specification has begun to be implemented. VITA believes that they have covered this possibility by restricting access to the draft specifications to members, and by doing patent searches. Between the member disclosures and the results of patent searches, the members of the workgroup developing a specification should know what patents may read on the technology and can then make the conscious decision whether to integrate them into the specification or to navigate around them.

Will the new patent policy be successful, i.e. will the consortium and its members benefit from it? Alderman thinks so, and claims that VITA has gained several new members since the announcement of the new policy a few months ago. Will it help the consortium accomplish its mission of developing technical specifications for VME? or will it discourage participation by companies who do not wish to share their patent portfolios? Time will tell, but so far Alderman has the backing of his board and a vast majority of his members, who approved the new policy almost unanimously.

In general you would expect a policy like this, one that requires early disclosure of patent holdings, to benefit the smaller participants in the standards process, those who don’t have the huge patent portfolios of some of the larger companies whose names we all know. But Alderman says that he has support from some of the big names as well – obviously they are the more progressive companies when it comes to using patents to benefit the entire industry and not just for strategic advantage to improve their own bottom line. He hopes that patent disclosure policies such as this become more common throughout the standards industry, and even become law.

In previous blog entries (January 9 and January15) and a white paper Reducing the Cost of Standards Activities I’ve discussed the costs of the standards process, and as I pointed out in the white paper the costs associated with the time/participation element are usually much greater than the cost of joining and paying membership dues to the standards organization. Yet it is often just the dues cost which people consider when they talk about the cost of participation.

Quite often a company will join a standards organization but then not participate. This seems strange, but there may be valid reasons for this. Perhaps the member only wants access to the organization’s other members or resources such as early drafts of specifications, or the member simply wants to be associated with the work of the organization and bask in its reflected glory. Additional benefits such as the ability to provide direction and input into the technical work cost extra: the member has to participate.

Members will begin to participate at the point where the benefits of participation are greater than the costs. Taking into account both the costs of joining and the costs of participating we have the following:

Point A in the diagram is where there are sufficient benefits for the company to join the organization, but it is only at point B where there are sufficient benefits for the company to both join and to participate. The standards organization should take this into account for their membership planning: what are the costs of joining, the costs of participating, and the benefits for each? And if the organization has problems recruiting and retaining members, or with not enough members actively participating, this is where they should start.

Some of my favourite Calvin and Hobbes cartoons involve our heroes playing their famous game of Calvinball, apparently some sort of cross between steal the flag, rugby, hide and seek, and croquet. The novelty of the game is that the rules are made up as they go. But while this may be fine for an small boy and his imaginary friend, it wouldn’t go over well with a group of competitive companies sitting around a table developing a standard.

As with any high-stakes activity, the rules of the game need to be defined up front, in advance of the start of the game, and those rules need to be fully understood and agreed upon by all participants. With regards to standards activities, that means that the rules –in this case the standards organization’s policies and procedures – need to be documented and published, developed in consensus with the members, and viewable by all members and prospective members. Further, members should commit themselves, usually in the form of a signed membership agreement, to abide by those rules.

The rules of the game for standards organizations apply at different levels. For the organization, the mission and scope of the organization need to be defined. What is it the organization is working on? What is it trying to accomplish. And just as importantly, what is it not trying to accomplish and what things is it not going to work on?

Membership policies define who can join and participate, and what the members’ rights and responsibilities are. An IPR policy will define the ownership of the organization’s work, how contributions of existing work can be made, how existing IP interests are declared, and what licenses the owners of existing work must grant to implementers.

For the organization’s technical activities, a process document should define how technical committee or work groups are formed, who may join or participate and at what level, how leadership chosen, how work is carried out, how decisions are made, and how the work is advanced and approved.

The technical committee itself needs to have a charter that includes the mission and scope of the committee’s activities. Just as with the organization as a whole, there needs to be an understanding of what the committee is trying to accomplish, what problem is to be solved, what will be produced and delivered, and what is out of scope for the committee’s activities. And finally, how do we know when the committee has completed its work?

Neglecting to define these important policies and procedures for the standards organization will lead to serious problems. Disputes and disagreements are bound to happen with any group of companies competing for a share of the pie. And while you may think that your small group of friends can get along fine without any rules, even a small group of friendly partners can grow to become a larger group of competitors. If the rules of the game aren’t defined in advance there will be disputes that can endanger the organization and its work.

Volunteers are the lifeblood of any standards organization. While the organization will usually have a small number of paid staff, they are usually employed for the purpose of handling the administrative, clerical, or promotional functions at the organizational level. The actual work of pursuing the organization’s mission of developing and approving standards is done by volunteers within the organization’s technical committees or work groups.

These volunteers are usually employees of the organization’s members. They have a personal interest in developing the work, and expertise in the technical domain. So why are they so often required to handle administrative tasks?

Aside from the development of the specification for which the committee is chartered, there’s a lot of administrative and clerical work required to keep the committee running smoothly. Scheduling and conducting meetings and discussions, keeping meeting minutes, managing the specification drafts, conducting ballots, tracking action items, collecting and tracking comments, managing membership records, keeping the email list subscriptions aligned with the membership roster, etc. all take time and effort.

While the organization can sometimes provide a limited amount of staffing to help with these functions, any organization with more than just a few committees is going to rely on its volunteers to do the majority of this work. But the volunteers are the technical experts; why assign them to do clerical work?

Let me suggest that the best way to make efficient use of volunteers’ time is for the organization to provide them with the proper tools to do their jobs. The use of modern infrastructure, including electronic collaborative tools, will do much to make efficient use of committee participants’ time.

Email is now being widely used within standards organizations, but there are other tools as well that have not yet been so fully adopted within standards organizations. This would include such tools as collaborative editing platforms, document versioning and management systems, bug/comment tracking tools, calendaring, meeting attendance tracking, electronic balloting, membership roster and eligibility tracking, etc.

All of the above tools should be provided by the organization to its technical committees or workgroups to assist them in their development efforts. These tools will make the work of the committee much more efficient. The organization owes it to its members to help them make the best use of their volunteer time during the development of the specification.

In addition to time savings and increased efficiencies, the use of modern collaborative tools provide beneficial functionality that would otherwise not be available to the organization. Record keeping for long-term archiving greatly increases the accountability of the committee and organization to its members and the industry, with related proofs of openness, balance, and due process, and audits of the technical approval process by accrediting organizations are facilitated.

In my blog entry on January 5th, “What Makes a Good Standard”, I defined a good standard as one that gets adopted, and included in the list of things that promote adoption the standards organization providing additional resources to implementers such as educational or conformance materials.

This is all part of what I call the “complete picture” of standards activities. Simply developing a specification, and approving it as a standard, is not enough. Sure, the organization can put another notch in its gun for having created one more standard, but the job isn’t done yet. When I hear from an organization that they’ve created X number of standards I usually ask how well they have been adopted, and likely as not I get some sort of mumbled response.

So let me suggest a few things that the standards organization should do to help make their standard successful. First, there are things that should be done by the technical committee or working group before starting or early in the development phase:

• Define a problem statement; i.e. what problem are you solving, or what situation do you want to improve, by the development of the specification.
• Define the audience. Who will be using the standard once it is developed and approved?
• Define various use cases. How will the audience be using the standard, in what situations, and using what complementary technologies?

After defining these things, the technical committee or working group is ready to begin development. Work ensures, time passes, a specification is produced, a standard is approved, and everyone gets T-shirts.

But the job’s not done yet. Before everyone heads for the door there’s more work for the technical committee or working group to do, all things that will complete the package that should be offered to potential implementers. This includes such things as

• conformance specifications
• certification tests
• implementation guides and other documentation
• sample implementations
• schedule/planning for maintenance and future updates
• etc.

And of course there are things that the organization should provide to implementers, with input from the technical experts from the technical committee:

• educational seminars or conferences
• promotional activities such as press releases
• publishing the results of the work on the organization’s web page and in the NSSN database
• publishing IPR claims and licensing information
• submission of the work to recognized or accredited standards organizations for de jure approval
• etc.

All of the above are part of the “complete picture”, essential elements in ensuring that the standard is adopted.

Any standards organization is composed of members, whether companies or individuals. The work of the organization is dependent upon those members both for financial support (via membership dues and other sponsorships) and for the volunteer work in the committees or work groups that produce the organization’s output.

Given that members are so important to the success of the organization, the organization should understand the members’ motivations so as to ensure that new members continue to join and existing members continue to participate year after year.

So why do members join and participate in standards organizations?

For many individuals, the motivation is a personal intellectual interest in the technology, though others may be participating on behalf of an employer who is not interested in joining at the company level. Academics may be interested in participating in the development of cutting edge technologies so that they can pass this knowledge on to their students or so they can write and publish papers on the topic. And while for company members some amount of industry altruism may come into play, the primary reason will be the potential of revenues; the ability to control the direction of industry technologies, or the possibility of increasing the company’s licensing revenues from inserting their own technology into the standard are all very powerful motivators. Other companies may simply want to be identified with the new standards, and are more interested in the exposure or publicity that comes from membership and their association with the new standard than they are with the technology.

Admittedly this list of reasons may be a bit simplistic. But there will always be a wide range of motives for various member joining and participating in the organization. There will not be any one motive for all members, or even for all members in any given class. And any one member may have multiple motives.

The challenge for the organization is to identify those motives and to make sure that the organization is doing all that it can to provide the benefits that its members expect. What level of exposure or publicity do members want? How can they participate, make their voices heard, and have their input considered in the technical development process? How can they lead or steer the development and approval process? Who gets to govern the organization? Who gets to speak on behalf of the organization or its work groups?

By understanding its members motives and interests, and providing the means to accomplish those goals through the development of appropriate policies and procedures, the organization can go a long way towards gaining and retaining members.

What differentiates a good standard from a bad one? As with most measures of quality this could be a judgment call, but the best quantifiable measure might be that a good standard is one that is widely adopted. After all, specifications are developed, and then approved as standards, for the purpose of solving technical problems, promoting interoperable solutions, and benefiting society – to say nothing of making money for those participating in the development of the standard. None of these benefits will happen if the standard is not adopted. Hence, a good standard is one that is adopted.

So how do the developers of the standard ensure that their work gets adopted? Let me suggest a few things that ought to be taken into consideration:

• The standard meets a current need, is timely and appropriate. A standard that doesn’t meet a need is a solution looking for a problem. While in some cases cutting edge technology or a new product for a new market can be developed through consensus, i.e. through the standards process, in most cases a standard will be more successful if it meets a current need.
• The standard is fair and balanced, and meets the needs of wide range of users. A very narrowly focused standard may be adopted but not widely. While this is not always a bad thing, the developers of the standard should consider their potential adopters, just as product developers will consider their potential market.
• The standard must be accessible; potential adopters must be able to obtain a copy. If the standard cannot be found, or the price is too high, it is unlikely to be read and used by any but the most dedicated adopter.
• Any required licensing for applicable IP must be available on reasonable terms. If the owner of a patent that applies to the standard refuses to license the patent, or will only provide a license on onerous terms, adopters will be unable to implement the standard.
• The standard must be well written, clear, and understandable. Adopters must be able to clearly understand what is meant, and create implementations without having to make their own interpretations. If this cannot be done then the various implementations will not interoperate, which is what a standard is meant to ensure.
• The organization creating the standard should consider providing additional resources such as educational materials or training sessions, interoperability and conformance tests, sample implementations, etc. to help adopters properly implement the specification.

Strangely enough – or not – most of the above suggestions have exact parallels in product marketing. New products must meet needs (or at least generate demand), must be priced right, targeted at the right audiences, and be available and accessible. Of course the revenue model is very different; for most standards organizations and their participants the real payoff comes from adoption of the standard rather than selling copies of the standard. But a little bit of “product” thinking may be worthwhile.

In the past few years the importance of Intellectual Property Rights (IPR) has become increasingly obvious to standards organizations, and most have implemented IPR policies. IRP policies are intended to make clear who owns what, as it relates to the development of technologies, and who will license these technologies on what basis. As such, a good IPR policy will include such things as:

• a requirement that organization members declare the IPR interests that they have in the specification under development, i.e. what patents they own that apply to the technology;
• what declarations must be made when a member contributes existing work to the committee or working group; and
• a requirement that member owners of patents grant a license to the patent to parties who wish to implement the specification, and under what terms.

Even with a well-written IPR policy these provisions will only apply to members of the organization (and care must be taken that a membership agreement binds them to the policy), so non-members are not covered; there is still the possibility of “submarine patents” coming to surface after the specification is developed.

As common as IPR policies are becoming within standards organizations, many forget to match the policy with the process. Just as the organization’s technical process defines how the organization’s committees or working groups are formed, operate, and approve work, i.e. when and how things happen, an IPR process would define when and how the various provisions of the IPR policy will occur. The IPR process would therefore include provisions for:

• when during the development of the specification that members must declare their IP interests;
• when during the development of the specification that members must state the terms under which their IP interests will be licensed, and whether the committee or working group can then decide whether to accept the terms or to attempt a “work around”;
• how are contributions made to the committee or working group, how they are recorded, and whether the group must formally accept or reject the contribution; and
• if and when members can “opt out” of their IP obligations by ceasing participation in the committee or working group.

Of course care must be taken to ensure that the IPR process meshes with the technical process; you can’t, for example, require the committee or work group to act on things before this body is formed, and decisions regarding contributions of IP must be made before the contribution is integrated into the specification – and certainly before it is approved. The IPR process could be a separate document from the technical process, or the provisions could be merged into the technical process document. But as with all other normative documents used by the organization, including the bylaws and membership policy, etc., the provisions of the IPR policy and IPR process must be fully integrated with the technical process.