And Now for Something Completely Different

I just spent a relaxing 3 days in Amagansett with friends living well above my rung on the economic ladder (read: multi-million beach house on the dunes) and while basking in the glow of a crackling fire, I succumbed to a sudden obsession with the TV show "24." In a desperate effort to exercise my demons and still pay tribute to our hosts (and video renters) Ken and Susie, I share the latest hot TV commercial from Japan.

Keifer's big in Japan!

Click the photo above and check it out.

Open Standards & RAND

I was asked to write briefly on the connection between open standards and RAND ("reasonable and non-discriminatory" conditions). Here's what I have so far. Anyone care to comment?
______________________________

Open standards are the subject of increasing public attention and debate. But what makes a standard open?

Open standards must be royalty-free, but the discussion does not end there. The harder question is whether open standards can have other conditions if they are “reasonable and non-discriminatory” (known as RAND). Despite its appealing rhetoric, RAND is not an objective benchmark. “Reasonable” is in the eye of the beholder; it is an undefined criteria only a lawyer could love. Worse, RAND can be a wolf in sheep’s clothing, bringing new forms of lock-in under the guise of “openness.”

Standards have degrees of openness, mainly due to restrictions and encumbrances placed upon them by vendors. The fact that a standards organization labels a standard open is not determinative. Its effect in the marketplace is a better guide.

At a minimum, open standards must allow all possible competitors to operate on a basis of equal access to the ability to implement the standard. They should not drive others to follow any specific proprietary path or effectively foreclose any software development model. A standard that in effect blocks open source developers from its implementation is not an open standard.

Any conditions (RAND or otherwise) that have the effect of limiting competition, leaving control in the hands of a single vendor, or hindering interoperability—for example, proprietary extensions of a standard—are incompatible with open standards. Ultimately, open standards must allow for self-directed innovation.

The Empire Strikes Back

Microsoft responded to the European Commission's threat of $2.4 million per day sanctions over its interoperability ruling in an unusually public manner.

Full statement by Microsoft's General Counsel, Brad Smith, is here

The situation shows how true interoperability requires not only the spread of open standards but getting into the "weeds," getting documentation fully disclosed, and preventing conditions that lead to new forms of proprietary lock-in.

Interoperate Until It Hurts

How much does interoperability cost?

About $2.4 million per day, for Microsoft at least.

Here's a BBC story today about the fine levied by the European Commission against Redmond until it provides full interface documentation that will assure broader interoperability with non-MS systems.

Who said getting interoperability is painless?

"Houston, We Have Open Source"

Not to pimp any one company's products (and I have no connection at all with them), but here's a new study, The Growth of Open Source Software in Organizations, that surveyed a large number of organizations in the U.S. -- enterprises and public agencies -- on their use of open source software.

Key findings of the survey:

* A clear majority of U.S. companies and government institutions already use open source software, and bigger companies are even more likely to be open source users. All of the 156 companies surveyed with at least $50 million in annual revenue use open source.

* According to the survey, the main drivers for adoption of open source are: lower costs, faster deployment and better security.

* Key continuing barriers: lack of understanding among decision-makers about benefits of open source; legal/licensing issues; support after installation; and corporate policies that do not create incentives to lower costs of commercial software.

As I have been saying in all my presentations on our Roadmap, an important step in better managing ICT environments is to acknowledge the presence of open source already in your ecosystem.

It's like the first step in AA -- admission.

Or, put another way, "Houston, we have open source."

As this study shows, the vast majority of enterprises and governments already have open source in their ecosystem. From awareness comes wisdom.

Also, here's a new article on public sector use of open source from ComputerWorld Singapore (which includes a nice photo of my friend Tom Rabon from RedHat).

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.

The Politics of ICT

"IT should be apolitical."

So says Peter Quinn, CIO of the Commonwealth of Massachusetts.

In the midst of the furor over open document format, Quinn recently decried the politicization of IT policy, and its potential "chilling effect" on public officials.

Here is the U.S. we assume that ICT is not grist for the political mill. But that is not the case in many, or most, countries. In Europe, ICT policies are highly political, and explicitly so. Political parties take positions on ICT issues. In places like China and Brazil, the main drivers of open source are political considerations.

Is this a bad thing? Often not, especially when ICT policymaking is open for debate. Many technology decisions should be brought to public attention, and not the product of semi-private discussions with vendors.

It can be a painful process, as Peter Quinn can attest. But democracy and other collaborative endeavors are like that. Policymakers and the public should know the stakes involved. They are sometimes big, less about ICT and more about serious issues of public interest.

Document Formats - To the Winner Go the Spoils

Let the market decide. That is Microsoft's view on competing standards for document formats, as described in this recent MacWorld article.

That sounds fine . . . as long as people are clear that ODF and MS's "open" XML standard are not equivalents in terms of openness, control and genuine neutrality for platforms and 3rd party products.

As the Berkman Center's John Palfrey said, echoing some key points in the Open ePolicy Group's Roadmap for Open ICT Ecosystems, it's not about one company verses another. It's about access to the information you create today and tomorrow. It's about who should properly control public information.

A summary of John's remarks at yesterday's Open Forum on the Future of Electronic Data Formats for the Commonwealth at the Massachusetts State House is available at his blog.

So where is this competition going?

Will we see other governments take official positions on open document formats?

Avoiding the ICT Stigma

A colleague, Jaap Bloem, shared an interesting perspective on the Roadmap Wiki on why governments and enterprises should consider openness:

The Roadmap for Open ICT Ecosystems is a remarkably strong way of pleading the case for “digital openness”, thanks mainly to the compelling examples and to the Openness Maturity Model. However, it also is my strong feeling that we should push the notions “ICT” and “Ecosystems” a little more in the background; instead putting forward a more crisp, plain, understandable notion as a front-end.

My suggestion would be "Open [i]nvironments." This notion corresponds with the following equation:

Open [i]nvironments = Effective Information Environments =
[i]nfrastructures + [i]ndividuals + [i]ndustries.

In part, Jaap's point is how to more effectively market openness to decision-makers, who often care little about technology. Maybe too much talk of ICT only makes it harder to get their attention.

It also reminds us that openness is not about the technology. Ultimately, introducing openness in ICT is about transforming companies, agencies, economies and people. It's about creating new avenues of innovation and collaboration. Those are the prizes that everyone's eyes should be on.

Open Document Formats

Just saw this article from today's (Dec. 7th) Bangkok Post

As it indicates, and as we highlighted in our Roadmap, the core issues regarding document formats are not technological. The issue is control, and what conditions should exist for access to public information.

Here's my prediction: Within 2 -3 years (or sooner) this whole debate about open document formats will be over. The case is clear and compelling. Open document formats assure future access to public information. As more governments and other customers demand control over their information --- and they will --- open document formats will be the accepted baseline for information formats, and every major vendor and application will support them.

What do you think?

Maturity Models - Too Much of a Good Thing?

Maturity models are certainly proliferating. There are scores of them, evaluating everything from software to enterprise architecture. Many are freely available, some are proprietary. At least three exist for evaluating open source software.

When the Open ePolicy Group was developing the "Roadmap for Open ICT Ecosystems," there was considerable debate over whether we should offer a new maturity model. We saw a gap; we found no maturity model that gauged the openness of an entire ICT ecosystem. Maturity models, like people, tend to work in silos.

Not everyone in the Group, however, wanted to cast yet another maturity model out into the world. In the end, we decided to offer our Openness Maturity Model, not to guide any specific decision (e.g., choosing software) but rather to help policymakers and managers aggregate baseline data and chart a path toward more open ICT ecosystems.

Early feedback seems to validate our decision. People continue to say (most recently during my Roadmap presentation in Brazil last week) that the Openness Maturity Model is the single most useful thing in the Roadmap. People like tools, I guess. Though this one could still benefit from some more work under the hood, and it remains our hope that others will help develop it further using our wiki: http://wiki.openization.org

Open ePolicy Group -- Phase 2

As my take-off to Amsterdam approaches, the issue of what Phase 2 of the OeG will look like is squarely on the table. Interest by companies and individuals is high--just this morning I had a call with Miko Matsumura, who chairs the OASIS committee on service-oriented architecture, to discuss the idea of a governance framework for service-oriented architectures. Both he and Patrick Gannon, OASIS' president, have genuine interest in the OeG's work and collaboration in a Phase 2.

Is a "roadmap" for SOA a big enough topic with high global demand to be the focus on the OeG for Phase 2? That's the question.

Other news: the Roadmap for Open ICT Ecosystems now has a wiki, here at:
http://wiki.openization.org

So now the whole world can join in the dialogue and help the Roadmap evolve.

The Roadmap also exists in portuguese and chinese (both available online). Spanish and thai versions are nearing completion.

With over 50,000 downloads from the Berkman Center's OeG website (See my Links), the word is definitely getting out.

Roadmap Launched in Brazil

1 December 2005
Washington, DC

Just returned from a wonderful and wired trip to Brazil. I was there at the invitation of Instituto CONIP for the launch of the portuguese version of the "Roadmap for Open ICT Ecosystems," the product of the Open ePolicy Group that I founded earlier this year.

It was a whirlwind tour -- 2 days in Brasilia for the CONIP 2005 conference, 2 days in Sao Paulo for a presentation at IBM Brasil and a series of press interviews, and then happily 3 days of pure holiday in Salvador. Thanks to Vagner Diniz of CONIP, Gabi Simionato Klein of TramaWeb, and Florencia Ferrar of e-Strategia Publica for helping make my time in Brazil easy, fun and productive.

Here's a photographic taste of Salvador ...


But only the Pause button has been hit. Sunday evening I'm off to the Netherlands for another round of Roadmap presentations and meetings. It's exhausting and exhilirating at the same time. Ottowa, Portland, Amman, Tunis, Brazil, Amsterdam, Copenhagen . . . and then?