Just as the open source movement has changed attitudes about software and software vendors, so phenomena like RSS may be changing attitudes about the creation and maintenance of industry standards.

For example, the News Standards Summit took place in Philadelphia on 8 December 2003, immediately before the XML 2003 conference. It featured a number of interesting presentations on the apparently overlapping, or competing, XML based standards in what we might call the formal news industry, as well as those used in what we will call, by way of contrast, the informal news industry -- i.e. developers and users of RSS and Atom.

As well as the meeting's stated intention of exploring the diverse pieces of the news standardization puzzle, it had the perhaps more interesting effect of highlighting the contrast between the formal and informal sides of the industry in their approach to standardization.

The formal side of the industry is naturally cautious -- and rightly so. After all, it is betting its business on the choices it makes in respect of technology and standards; and while it may be happy to use RSS for some aspects of its distribution, it may feel the need for formality when fulfilling its mission critical requirements like content creation and delivery of premium services to paying customers.

The informal side of the industry doesn't have these same limitations and is likely to see the slow cautious approach as irrelevant and backward looking. This point of view was evidenced during the closing session by pithy remarks overheard from the enfants terribles of the RSS and weblogging communities, summarized as follows: "We have been sitting here all day to decide whether we should get together again to decide what we should be discussing. I've had enough and am off for a beer."

The issues raised go beyond the news industry. When assessing your need for formality, what does it make sense to look for, and how likely is it that your expectations will be fulfilled? Choosing a standard is like choosing other parts of your technology infrastructure, involving defining your requirements and assessing the suitability of a product and its vendor.

The motivation

Just to revisit the obvious, for a moment, standards are good. Except when they're not relevant to you, of course, when you don't care about them. And except when they are being imposed on you by a dominant vendor, of course, when they are bad.

There are quite a number of agendas for wanting to adopt standards, it all depends on what kind of organization you are, where you sit in the organization and so on.

• You are in purchasing: You don't want to be locked in to your supplier's proprietary format. Standards allow you to switch to new suppliers with greater ease. Your switching costs are lower with standards and you are in a better bargaining position.
• You are in sales/marketing: Your customers are demanding that you supply them using industry standards. Your costs are lower if you are able to deliver your product in one version rather than in several.
• You have live operations. Tools are available that support standards. Using the tools is cheaper than creating your own to do comparable tasks. It is easier to find staff that are already familiar with the standards and tools, and such staff do not require training.
• You are in development. Standards make your life simpler, you benefit from the experience of those that created them and are hence less likely to make mistakes. You can produce things more quickly using standards.

This treatment is of course extremely simplistic, but it does at least identify that before deciding on a standardization program, the organization must assemble and understand its rationales for doing so.

Perhaps of equal importance the organization should understand in what respects implementing standards might be contrary to its interests. Balancing the advantages and disadvantages and formulating a standards strategy will involve all kinds of trade-offs -- Shapiro and Varian's Information Rules contains a masterly and highly readable treatment of this subject.

The requirements

So having decided why it is that adoption of a standard would on balance benefit you, you need to choose between existing candidate standards, or create a new one. Here are some questions that may be relevant when considering potential candidates:

• Suitability: Does it do what you need it to? Of course, to answer this question you need to have previously thought about in sufficient detail what it is that you trying to achieve. If it doesn't do all the things you need it to, is it compatible with something else that complements it? If there are two overlapping standards then can you use the best of both if you need features from both of them? If there are competing standards, how should you choose between them?
• Extensibility: Can it be extended for your specific purposes? If not, in what way will you differentiate yourself from your competition? Using standards is all very well, but organizations that use them still need to differentiate themselves.
• Evolution: Will it evolve to do things that you think you are likely to need to do? In particular do you have a view about how it will fit with potential future business models. Is it designed in a way that is sympathetic to the idea that standards must evolve? Will it still be relevant in the future and how will it track the changing dynamics of your industry sector.
• Progress: Is it a sufficient advance over what you have today? To justify expenditure in implementing a standard, most organizations will require some kind of return from the investment. This might take the form of cost savings, though it might be better if in addition to savings it offers real product benefits over your incumbent technology i.e. where does it allow you to go that you could not have gone otherwise?
• Business: Is it compatible with the way you do business? Does it demand that you change your business model inappropriately, or represent an unacceptable threat to your security? It might not be possible for commercial organizations to use approaches that non-commercial organizations or individuals can. There may be legal, liability, licensing or other impediments to doing so, though attitudes do change. For example many organizations embrace open source today, where previously they thought it was not possible.
• Adoption: The dominant approach is not necessarily the best. i.e. importance is not necessarily measured by weight. In many areas mass market products are not suitable for professionals, who constitute a much smaller but distinct target. Equally, however, lack of adoption is likely to be a signal of problems.

Answering questions like these is extremely similar to a vendor selection process. And just as in a vendor selection process, you are likely to want to assess the viability of the vendor. After all, just as you would not want to select a product from a failing vendor, you would not want to adopt a standard that is moribund, or whose future is not all that bright.

The vendor

Assessing the viability of a commercial vendor is a process that is likely to involve some assessment of their financial position, their market share and a number of other reasonably well understood metrics. Assessing standards organizations is likely to be a rather different proposition.

For a start, though they may fight, standards organizations are not directly in competition in the same way as organizations that sell products. Many of them give away the fruits of their labor in the view that they are doing something pro bono publico. In addition, the standards groups are often composed of delegates from a number of different organizations and the motivations of both the participating delegates and organizations may be quite wide and varied.

The great thing about standards is that anyone can pitch their tent in a field and set themselves up as a standards organization. There's no special training, accreditation, licensing or anything. You just pitch your tent and declare yourself the standard for whatever you choose. Of course, XML does not create this situation, but being a standard with the express purpose of facilitating the creation of other standards, its success is to some extent measured by the arrival of tents in fields.

Just because these are tents in fields is not at all to say that the outcomes from those tents are necessarily trivial or of poor quality. And indeed it would be foolish to ignore the idea of good practice and the unifying force of, for example, OASIS. However, prospective standards users will want to have a view that the organization, community or whatever that is behind the standard is in good standing and capable of acting effectively to increase the likelihood of delivery against their requirements.

Here are some issues they may take into account in considering this:

• Competence: How confident are you that the standards group has appropriate skills and experience to produce useful and valid outcomes? Does the standards group have adequate processes in place to ensure that good quality outcomes are the norm? Are those processes adequately open and able to reconcile the often conflicting interests of the participants? For example its often an objective to be vendor neutral, but at the same time standards groups need usually to consist of a mix of users and vendors.
• Capacity: Like other organizations, standards groups have limited budgets and capabilities. To some extent their ability to keep going depends on the nature of their participating organizations and to what extent their membership is industry dependent and cyclical.
• Your influence: Organizations that are dependent on standards may like to have an influence on the various outcomes. Participation in groups costs money with no guarantee of desired outcome. If you really can't live with an outcome from the standards group, what can you do?
• The future: Does the standards group have a vision or purpose for existence into the future, or is it in existence merely to perpetuate its own existence; a cozy club for the participants to meet periodically?
• Off-the-shelf: In practice, how much do you really care? Is it enough just to get the benefit of someone else's labor?

Technical questions

And finally, you may be concerned about the technical quality of the chosen standard. Sound engineering practice is just as likely to be a guide here as in other activities. Among the considerations are:

• Does it have expressed requirements, or a coherent statement of purpose? Is your intended use of the standard consistent with its purpose?
• What is the quality of the implementation -- is there a consistency of style, are commonly used features concise and easy to use and so on?
• How well does it reconcile the need to be forward looking and hence open ended, yet concise and to the point in meeting present requirements?
• While controlled evolution is a good thing, frequent changes is going to be hard to deal with -- what is the approach to this?
• Are there effective maintenance processes and techniques?
• Is there effective documentation, and are there open source or other tools? Is there an active community from which you can get support?
• Does the standard have dependencies on other standards? Are these dependencies robust or fragile? How much do you have to know about the other standards to use this one?
• Over-engineering can be just as bad as under-engineering, is it as simple as possible while meeting the requirements?

Conclusion

Just as organizations are changing their attitudes to open source, the attitude to formal standards making may also be changing. Do formal standards bodies and standardization processes stand up to scrutiny? Potential users of standards need to assess what they are getting from such organizations, which in turn need to make sure they justify the costs of membership and participation with results that are clearly distinguished from the results of an informal process.

XML.com Copyright © 1998-2006 O'Reilly Media, Inc.