After speaking at the IEEE conference on Monday, I headed up to London for some other meetings. While there, I decided to come home a day early so I could travel to a meeting on Thursday, tomorrow. So this morning I flew from London Heathrow to Chicago. The flight left on time, but was an hour late in arriving due to strong headwinds and course changes to try to avoid them, though nothing worked. So I missed my connection home and get rebooked. Upon consideration that I would only end up being home for about 6 and 1/2 hours, including sleep, I decided to fly right from Chicago to my meeting destination. So it means that I won't get to see my family tonight but I also don't have to get up in the morning for a 6am flight. I've been told before that my stress level before such early flights is so high that I might as well go the night before. So maybe I accidently did the right thing anyway. I just sure did it the long way.
I'm writing this on my newly booked flight from Chicago, which managed to leave on time even though it is raining. This is in contrast to my flight to Munich on Sunday. The flight was 4 1/2 hours late leaving and I got to the conference with only 30 minutes to spare. In that case the problem was the inbound flight to Chicago: it had to make an emergency medical stop in Iceland. I can't complain about that obviously because I would certainly want them to do that for me. I did complain a couple of years ago when my flight from Newark to Amsterdam was late because the pilots got caught in traffic (it's called "allowing extra time in case there's traffic"). The airline really didn't seem to care too much, even though almost all of us missed our connections and, in my case, arrived half a day late at our destinations. They even hassled me about sitting in their lounge to wait for the flight they were finally able to get me on. These things add up and I avoid that airline whenever possible.
Multimedia status check: I'm now listening to the Bluesbreakers with Eric Clapton album. I'm late coming to this album even though it is one of those "100 most important albums ever." It's what Clapton did after the Yardbirds and before Cream. My travel book this week is Blue Highways by William Least Heat-Moon. It was written in the late 70s, early 80s, about his circumnavigation of the US on non-highways (the so-called blue highways on maps at that time). Several years ago I read his book River-Horse about his trip across the US by boat (you can't quite do it, but he came close). I recommend both books because they are well written and will let you live vicariously while the author sleeps in his van in the high desert or almost drowns in Lake Erie. They are quite funny at times, but also quite philosophical about what life means when you get out of the normal day-to-day routine.
"Technical neutrality" is a term used these days, usually by government agencies though also in private enterprise, to indicate the commandment "Thou shalt state no preference between open source and proprietary software." When used in the most well-meaning sense, the usual intent is that ideology, politics, economic and market theories, marketshare, and de facto product standardization should not influence your choice of the best software for the intended use, now and in the future.
It is not separate from conditions that might state that the software should fully support open standards, because factors like real, broad interoperability (vs. interoperability with a particular vendor's software) are absolutely part of the criteria in determining what "best software for the intended use" means.
There are some variations to the statement as I've given it that I would like to point out in case you hear them. These are a little over the top to make my point, but I think you will recognize many of the arguments. In any case, I want to make clear that these are all my personal opinions based on my own experiences with customers around the world.
"Thou shalt state no preference between open source and proprietary software"
Variation #1: "Thou shalt state no preference for open source over proprietary software"
This is usually used by critics of open source software, who usually coincide with the group of strict proponents of proprietary software. While seemingly neutral, it nevertheless leaves you with the impression that protection is needed against the open source upstarts. This is remarkable, because in most product categories, proprietary software vendors usually have greatly larger revenue today.
Variation #2: "Thou shalt state no preference for proprietary over open source software"
This one is by the proponents of open source software and attempts to make sure that the new open source model gets a fair consideration vs. the established and installed proprietary software business models. Most people who adopt such statements are explicitly declaring that they are open source advocates and are willing to settle in for a fight.
Variation #3: "Thou shalt state no advantages of open source over proprietary software"
This is the most insidious of all the variations and is a nastier form of #1. Not only should you not prefer open source, you shouldn't even talk about the potential advantages. The reason why this is so troublesome is that it protects the status quo: if the known and incumbent software is proprietary and you are not allowed to do a full comparison with open source, the incumbent will usually win, except in the situation where it must be tossed because it is a complete failure. This amounts to an incumbent controlling the media to not allow a challenger to compete on an informed, level playing field.
Variation #4: "Thou shalt state no advantages of proprietary over open source software"
This is here for completeness, though I have never seen it used in practice. Clearly it is an attempt to booster open source software, but because of the installed base of proprietary software, I doubt it would be effective in practice today. If the roles were reversed, if more open source software was used than proprietary, it would be just as nasty as #3.
To be clear, if you do favor open source or proprietary software, using one of these variations might appeal to you. My point in this entry is to examine what you should look out for if your intent is to be evenhanded with both of them.
Rather than "technical neutrality," I agree with my IBM colleague Ros Docktor that what we need is the idea of "technical inclusiveness." This means that rather than trying to play word games to improve the consideration of either open source or proprietary software, consider the full and explicit technical and economic advantages of each based on what you are trying to accomplish. For example, in the Massachusetts case, the focus is on getting the best products that implement the OASIS OpenDocument format. Because it is an open standard, neither open source nor proprietary software has an advantage, especially since we are still in the early days of implementation of the latest standard. Here the issue is to choose the best piece of software that implements the standard, open source or propietary, and let the best contender win. In fact, support of the standard will allow multiple implementations to co-exist, and this can be a good thing if different groups nned to use different software.
Examine all the features of all the software you have considered, just like you used to do when comparing several proprietary products. Pay particular attention to interoperability features: these will only grow in importance from now on. If a software provider (open source or proprietary) tries to lock you into their offerings via non-standard data formats when standard ones exist, find out when the standard will be implemented and get a commitment. In the case of open source software, perhaps even assist with the implementation of the standard.
My first statement "Thou shalt state no preference between open source and proprietary software" shows far more symmetry than any of the other variations. In the same way, you should understand that many of the considerations when acquiring software are independent of whether the software comes from a proprietary or open source provider.
Finally, the world is becoming more of a hybrid mix between proprietary and open source software every day. You typically don't need to make choices between using all of one or the other. Even products like IBM's WebSphere Application Server contain a mix of proprietary and open source components, though you should not be surprised that much of the latter is there to support the implementation of standards.
Keep an open mind; watch out for nuanced, asymmetrical statements from anyone; and be more than neutral, be inclusive.
I've referenced this before, but since it's been updated, I'll point to it again. David Wheeler has a good, comprehensive essay over at "Why OpenDocument Won (and Microsoft Office Open XML Didn't)"
. One point that you shouldn't miss is around GPL. Microsoft has now said itself that its Office XML license is not compatible with the GPL
. Wheeler's article cites various statistics, but it's clear that more than 50% of all open source projects use the GPL. So Microsoft wants Massachusetts to allow the use of a format (the Microsoft one) that disallows software, particularly competitive open source software? Clearly this is problematic and limits choice, exactly the opposite of what a government should be doing. See the whole essay for more.[Read More
I'm reposting this to make sure that the version with a typo fixed hits the RSS stream.
Dear Mr. Quinn and Ms. Mcllelan:
On behalf of IBM, I am writing in response to your request for feedback on the Enterprise Technical Reference Model v.3.5 - Public Review Draft, which identifies the newly ratified OASIS Open Document Format for office applications to be the standard for all official records the Commonwealth creates and saves.
IBM appreciates the leadership of the Commonwealth of Massachusetts in this area. The exhaustive process you have taken to arrive at this document, engaging all stakeholders and sharing these technical references for comments, can be a model to guide other states and governments in their migrations. IBM was pleased to participate in these discussions and looks forward to continuing to support the Commonwealth in its efforts.
We support the recommended guidelines, especially the technology specifications for the OASIS Open Document Format. We think your target date for implementation, 2007, is aggressive but understand the need to set a stake in the ground to begin this important migration to open standards for the documents that you create and maintain. These are your documents and the technical specifications that you have articulated will help ensure that you maintain control and future use over them, something which will be very important to the citizens of Massachusetts.
Thank you for the opportunity to provide our comments. Please do not hesitate to call on any of us at IBM to respond to any additional concerns.
Dr. Robert S. Sutor
VP, Standards and Open Source, IBM Corporation
I've now had the chance to see the DVD and hear the CD soundtrack to the new documentary No Direction Home. If you are any sort of Dylan fan, these are must haves as they are absolutely terrific. My daughter Katie, one of the world's foremost Bob Dylan fans and scholars, gives these 5 stars out of 5, maybe even 6 out of 5.
She is such a purist that she really dislikes covers of Dylan songs, except possibly if they were done by George Harrison.
It's fairly easy to find the guitar tabs and chords for almost any pop or rock record somewhere on the web. These are usually transcriptions by musicians who have heard the songs and then figured out how they were played. The various sites have a range in quality content, but the best one I have found is Chordie
. A really nice feature is that for songs that have been suitably prepared, you can transpose the song right on the site (let's say if you were tring to avoid B chords ...). Let's say you wanted to find the song, oh, I don't know, "Massachusetts" by the Bee Gees. It's here
. Make sure you behave and respect the appropriate copyright laws.[Read More
The "Roadmap for Open ICT Ecosystems", sponsored by IBM and Oracle, was released this morning. It is a very good read. From the Introduction:
Technology transformative power has always been a source of great expectations and challenges. Today, globalization, fueled by information and communication technologies (ICT), is rapidly changing every society. Our drive towards globalization creates a new set of unique demands on government, business, and our everyday lives. Increasingly, decision makers in all fields are looking to technology to provide solutions and drive desired changes by commingling local, national and global resources in innovative ways.
The fusion of technology and globalization has also produced a new way to adapt, innovate and grow in our changing world. A potent combination of connectivity, collaboration, access and transparency or openness is emerging. Governments and enterprises around the world are embracing it. This openness is helping governments, companies and individuals respond to the increasing requirements of our on-demand, high-speed world. As openness impacts an ICT ecosystem, it becomes a catalyst for unleashing newfound comparative advantage, invention, social development and market opportunities.
The Berkman Center for Internet & Society at Harvard University, with the support of IBM Corporation and Oracle, has facilitated the creation of this ROADMAP FOR OPEN ICT ECOSYSTEMS. Our hope is to provide policymakers, managers and other stakeholders from industry and civil society a user-friendly tool for understanding what open ICT ecosystems are, why they are embraced and how to evolve them. As a result, we hope to change how people see and manage ICT ecosystems and innovation.
Also see the related New York Times article "Plan by 13 Nations Urges Open Technology Standards". From the introduction:
In a report to be presented at the World Bank today, a group that includes senior government officials from 13 countries will urge nations to adopt open-information technology standards as a vital step to accelerate economic growth, efficiency and innovation.
The 33-page report is a road map for creating national policies on open technology standards, and comes at a time when several countries - and some state governments - are pursuing plans to reduce their dependence on proprietary software makers, notably Microsoft, by using more free, open-source software.
I've seen various statements around the web about how "big business doesn't want standards" and so forth. Remember, this was sponsored by IBM and Oracle.[Read More]
With the increasing use of open standards and open source, often brought about because of the transition to service oriented architecture (SOA), it's important to stop and think strategically about your IT systems from the "open" perspective. To me, this means trying to temporarily put aside some of the other factors among the many that concern IT, such as legacy systems, vendor relationships, hardware and software refreshes, and just think about what you need in terms of increased interoperability and better factored components. To that end, I often ask customers these types of questions:
- If you could discard everything and start from scratch, what kind of system would you build to meet your current and long term needs?
- In that ideal system, what would be the role of open standards?
- In that ideal system, what would be the role of open source?
- In that ideal system, what would be the role of your current vendors and service providers? Would you use other vendors or service providers?
- What are you doing to transform your current infrastructure to your ideal system in five to ten years?
To turn around the first sentence above, if you are the midst of transforming your enterprise to an SOA, you should also be changing over to a greater use of technologies built on open standards and, if it is right for you, open source. Web services is here today: you need not wait for the next generation of operating systems or applications to get started today. Anybody who tells you that SOA or web services will only really start with that new operating system or application is speaking with their best interests at heart, not yours. Be willing to mandate support for open standards in the systems that you are buying or having built for you. Use the Harvard Roadmap for Open ICT Ecosystems to measure your current "open maturity" and also use it to understand where your system is heading. If your system will not be more open a year from now, I would assert that you are heading in the wrong direction.[Read More]
Massachusetts just published the final Enterprise Technical Reference Model Version 3.5 and OASIS OpenDocument is still required. Here's the relevant portion of the document
TECHNOLOGY SPECIFICATION: OASIS OPEN DOCUMENT FORMAT FOR OFFICE APPLICATIONS (OPENDOCUMENT)
Description The OASIS Open Document Format for Office Applications (OpenDocument) is a standardized XML-based file format specification suitable for office applications. It covers the features required by text, spreadsheets, charts, and graphical documents. The specification was recently approved by OASIS as an open standard. OASIS has also submitted the standard to ISO for consideration as an international standard for office document formats.
Guidelines The OpenDocument format must be used for office documents such as text documents (.odt), spreadsheets (.ods), and presentations (.odp). The OpenDocument format is currently supported by a variety of office applications including OpenOffice.org, StarOffice, KOffice, and IBM Workplace.
Standards and Specifications
Refer to: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office
- OpenDocument v. 1.0 Defines an XML schema for office applications and its semantics. The schema is suitable for office documents, including text documents, spreadsheets, charts and graphical documents like drawings and presentations, but is not restricted to these kinds of documents.
Migration Given the majority of Executive Department agencies currently use office applications such as MS Office, Lotus Notes and WordPerfect that produce documents in proprietary formats, the magnitude of the migration effort to this new open standard is considerable. Agencies will need to develop phased migration plans allowing them to configure existing applications to save office documents by default in the OpenDocument format with an implementation date of January 1, 2007. Any acquisition of new office applications must support the OpenDocument format natively.
Agencies should begin to evaluate office applications that support the OpenDocument specification to migrate from applications that use proprietary document formats. As of January 1, 2007 all agencies within the Executive Department will be required to:
- Use office applications that provide conformance with the OpenDocument format, and
- Configure the applications to save office documents in OpenDocument format by default.
This is terrific and a very significant milestone is the transition to real open standards.
See "CA Supports IBM's Open Source Patent Pledge as Companies Announce Long-Term Licensing Agreement". From the introduction ...
ISLANDIA, N.Y., Sept. 7 /PRNewswire-FirstCall/ -- Computer Associates International, Inc. (NYSE: CA - News) today pledged open access to key innovations covered by 14 of its U.S. patents -- and counterparts of these patents issued in other countries -- for individuals and groups working on open source software. CA also announced it has reached a long-term, patent cross license agreement with IBM, creating an exchange of license rights and releases between the companies.
In making its patent pledge to the open source community, CA is joining IBM in encouraging other companies to create an industry-wide "patent commons" in which patents are pledged royalty-free to further innovation in areas of broad interest to developers and users of information technology. IBM made a similar pledge earlier this year.
I'll be participating in a panel on Monday at the IEEE Standards for Global Busines Conference
in Munich. The panel is called "Corporate Perspectives on Emerging Trends in European and Global Standardization". If you're at the conference, please stop by and say hello.[Read More
See "Massachusetts set to switch off Microsoft".
To be clear, there is nothing preventing Microsoft and others from implementing and supporting the OASIS OpenDocument format. This should not be looked as "against" anyone but rather "for" real open standards created in a community way in standards organizations.
Lately I feel like a middleman linking to web documents since there is so much good stuff on the web saying why Massachusetts did a really good thing in choosing the OASIS OpenDocument standard for its new enterprise model. There have been whole essays dedicated to the new requirement, the implications to other governments, what Microsoft may or may not do about it, how OpenDocument can support multimedia types, and generally how we have reached a watershed moment when people are saying that open standards created by a community are preferable to proprietary specifications created and maintained by a single vendor.
The latest really good summary is from David Berlind of ZDNet: "Should more public agencies heed Massachusetts' OpenDoc policy?". As to the question regarding if and how Microsoft Word in Office 12 can support the OpenDocument Format, if Microsoft creates a plug-in then perhaps other people can create them too, perhaps superior ones, especially if the plug-in API is published and is freely usable (none of the "except in GPL stuff," however you word it). Any bets on that?
Finally, in my version of Microsoft Word 2002 SP3, twenty-two (22) different file formats are offered when you do a "Save As". Now clearly some of these are more feature-rich than others and you can lose some formatting when going to some of them. That said, the authors of Word know how to write file converters when they want to do so. I'm still looking for a really good reason why they wouldn't do that here that goes beyond "We don't want to because then maybe some people won't use our product all the time." For a spirited discussion on this topic see the Slashdot thread "Massachusetts Explains Legal Concerns for Open Documents".
If you work in IT/ICT in government or have a strong interest in the new and evolving roles of intellectual property and standards in government, I recommend you visit the IBM Government Programs IP & Standards
home page. In addition to a nice picture of my buddy Tim Sheehy, there are lots of good links to position papers including one on open standards in the public sector
. Check it out.[Read More
People stop me all the time and they ask, "Bob, what is an open standard?" And I tell them, well it depends, but if you read my blog you would have an idea of some possible answers. They then look really scared and I never see them again.
All kidding aside, I have tried to force some examination of what the word "open" means and warn against its use as a marketing term. I've also put forth the idea that we should consider "closed" and "open" as two ends of the spectrum. Here "closed" means "it's mine, you can't have it" and "open" means "here take it, do whatever you want with it." Most standards fall somewhere in between, with very few things being all the way at one end or the other. This language is still imprecise, so let's take some time to look at what we might really mean by this use of the word "open" in the extreme sense of "purely open." To be clear, I'm not the only one who has looked at these types of things. In particular, my IBM colleagues Tom Glover and Chris Ferris have thought and written quite a bit about this, so I'll attribute the really good ideas to them and save the bad ideas and mistakes for myself.
I think there are five areas we need to look at:
- Modification by Others
Let's consider them in turn. Remember, this is meant to describe the extreme meaning of "open." After this initial discussion I'll return to some things to be considered when you decide how open you need a standard to be.
Development: A purely open standard is created in a manner that allows anyone who wishes to participate to do so without discrimination. All proceedings and records of proceedings are public and decisions are made by consensus. No one can prevent anything that actually happened during the development of a standard from being recorded in the minutes. There are no secret agreements. No one person or organization can veto a decision.
Maintenance: Once created, a purely open standard is maintained by a community under terms similar to that which developed the standard. In addition, the community has a responsibility to maintain backward compatibility if it decides to do so. That is, openness gives the maintaining community the right to make significant modifications, but since membership is not restricted, the community may get enlarged at times by a sizable group of people who may either want to force the changes or maintain the status quo. (This is just democracy in action: if you get more people to vote for you, you win.) So while significant changes may be made in the evolution of a standard, it is not done at the whim of a single vendor unless that vendor can garner significant independent support. As in the development of a standard, all votes or positions taken during consensus creation are recorded for all to see.
Accession: Anyone who wishes to have a copy of a purely open standard may have one at no cost. When possible, the standard is available online and the document format used to represent the specification is an open document standard (I know this is recursive, but you know what I mean).
Implementation: A purely open standard can be implemented by anyone in any way desired with no payment of royalties.
Modification by Others: A purely open standard can be mined for its good ideas and used in part or in whole in other standards. In particular, a profile can be created that states which parts of multiple standards should be used together to achieve a certain end (for example, a subset of a set of standards for use on mobile phones).
What are some of the problems with these criteria?
- Standards development organizations (SDOs) have expenses. They may need to pay for permanent staff, lawyers, websites, conferences, offices and other ongoing expenses of formal organizations. Where is this money to come from if there are no membership fees or costs for acquiring standards? Perhaps an SDO survives by accepting voluntary donations from participants with a "give if you can and want to" model. Giving more should get you no more privileges than if you give nothing. If this still doesn't generate enough money, then the SDO may go out of business. It also begs the question: if no one is willing to support the effort, why does it exist in the first place?
- If you can't get a copy of the standard for free, how much is too much? If it costs you $5, is that ok? How about $500? What if you have 2000 developers that need a copy? I tend to think free is really the best answer here, at least for an online version.
- Standards efforts need to be sustainable in order to maintain specifications. This brings us back to the funding question, but also makes us think about how one organization might pick up an effort when another decides to no longer pursue it. Note that because of the community nature of purely open standards creation, it is likely that some group can be found to maintain the standard, whereas a closed de facto standard might vanish if the owning vendor goes out business, gets sold, or simply decides it wants to something different.
- If membership is completely open, you have to make sure you have rules that prevent an organization from "stuffing the ballot box," that is, sending many people to vote for or against a proposal.
- Can you really be sure that no one can put up a barrier to implementation of a standard? In a purely open standard, the creators of the standard can presumably be prevented from putting up such roadbloacks, but what about others? Do you allow legal concepts such as reciprocity and defensive termination to be in license agreements for purely open standards? Can they actually help make it purely open?
- In a purely open standard, license agreements do not have tricky or cute language that prevent open source implementations. Should a license just allow implementation of the standard or should it also allow arbitrary derivative works that go beyond the scope and intent of the standard?
- In order to maintain control of a standard it creates, an SDO may copyright the specification and so prevent subsetting or extension. However, certain permissions may be included that liberalize this. Which conditions are acceptable?
- You need to maintain some sense of an official version of a standard, so you don't want to allow such looseness that someone claims to implement a standard if only a small subset is actually handled. You also want to prevent people from unilaterally extending a standard, thereby preventing interoperability and allowing undo advantage to one implementor. Here an open source reference implementation will help and do two things: 1) provide a test case for compatible implementations, and 2) allow people to quickly use a standard without waiting for proprietary implementations.
If you have read this and conclude "ha, we can't really get an open standard so we'll muddle through and do what we want", then you have misunderstood what I am talking about. Since most standards fall between closed and this "purely open" characterization, you need to decide what is important to you. For example, a government may decide that it really cares about Maintennace, Accession, and Implementation and will try to use standards that maximize those characteristics while being willing to concede a bit on Development and Modification by Others.
For some kinds of standards efforts, it may be easy to obtain patronage for the effort that therefore allows anyone interested to join. The nature of the effort may preclude troublemakers from taking advantage of the rules. That said, you need to be careful and precise in the membership and participation rules and always think about how someone might abuse them. To paraphrase Bo Diddley when speaking of the music business: "Trust no one, except your mother. Even then, keep an eye on her." Ideally, standards would be created in an environment of trust. You just sometimes have to legislate trust.
In practice, I think it is probably easiet to tell when a standards effort is less open than you think it should be. Here are some danger signs:
- control by a single vendor,
- overly complicated license agreements,
- license agreements that reserve certain special rights to individuals or vendors,
- license agreements that prevent some kinds of implementations,
- overly complicated procedural rules that can allow people to be less democratic than they should,
- a history of disregard for backward compatibility,
- costs of participation that exclude individuals or small organizations,
- high costs of obtaining copies of the standards,
- standard specifications not being openly available online, and
- for XML-based standards, allowance for proprietary, vendor-specific extensions.
Some of these are worse than others: you will need to decide for yourself how open you need the standards you use to be. As I've suggested in other entries, I hope that we eventually come up with a grading system that allows us to compare two specifications side by side and see which one is more open. I hope that what I've written here is a start on such a system. I believe we're getting more and more open every day. Such a grading system will help you tell whether a particular standard is more open than it was last year and whether it is on a path to be more open next year.
I consider this a work in progress and may update it from time to time. RSS