Open Tech Today - Top Stories

Monday, December 19, 2005

Economic Impact of Open Standards

To date, there has been little analysis of the economic impact of open standards. In fact, there has been scant attention to the economics of standards generally. Worse still, most public agencies are unaware of the economic effects of their procurement policies and practices -- which not only impact government but can have anti-competitive, downstream effects in the marketplace.

Fortunately, a new report, An Economic Basis for Open Standards, by the FLOSS Project at the University of Maastricht examines open standards from an economic perspective.

A few key points from the report:

* Open standards must allow all possible competitors to operate on a basis of equal access to the ability to implement the standard.

* The public sector should never require citizens to purchase systems from specific vendors in order to access public services.

Its key policy guidelines on standards and interoperability are:

1. Open standards should be defined in terms of a desired economic effect: supporting full competition in the market for suppliers of a technology and related products and services, even when a natural monopoly arises in the technology itself.

2. Open standards for software markets should be defined in order to be compatible with FLOSS licenses, to achieve this economic effect.

3. Compatibility with proprietary technologies should be explicitly excluded from public procurement criteria and replaced by interoperability with products from multiple vendors.

4. Open standards should be mandatory for eGovernment services and preferred for all other public procurement of software and software services.

A few comments of my own:

Any argument that a covenant not to sue helps show that a standard is "open" is totally specious, especially if it does not apply to all future versions or extensions of the standard.

Open standards are a spectrum; standards can have degrees of openness, mainly due to the existence of anti-competitive controls, conditions and encumbrances placed upon them. Royalty-free licensing is necessary but not sufficient for an open standard. And complicated covenants, encumbrances and licenses are a sure sign that a standard will not be very open on the open standards spectrum.

Open standards should allow for self-directed innovation. They should not drive others to follow any one technology path, especially one that effectively binds innovation to a single proprietary system.

The FLOSS report puts it nicely:
If the holder of rights covering a standard is also a supplier of products and services based on the standard, it has strong incentives to set licensing conditions that disadvantage the strongest potential competing suppliers. Thus, the natural monopoly that the standard creates in terms of technology may come along with competition in the market for products and services, but this competition may be limited by the control by rights-holders of the access to the standard technology.

Go back to the tsunami story that opens the Open ePolicy Group's Roadmap for Open ICT Ecosystems.

In a crisis, what encumbrances do you want on the standards for data and systems related to emergency relief operations? Answering that question will help indicate the proper starting point for public policy on standards.

1 comment:

Sam said...

Just like the Roadmap document, this post mixes the practical and theoretical in an elegant way that's easy to follow.

The criteria for openness from the Maastricht document mirror John Palfrey's short list in his remarks on Beacon Hill on Dec 14, which were:

(1) Interoperability
(2) Access & Control
(3) Choice & Cost
(4) Innovation

I hope these can become standardized in some way -- perhaps through consistent repetition or explicitly in the Roadmap doc.

I think the one issue which may violate most all of those criteria is the proprietary extentions. On that one alone, we may effectively be able to distinguish significant degrees of openness.

The covenant would remain a problem, but out of its native complexity it's a difficult one to focus on and be understood by common folk -- with it we are necessarily over-explaining.