Two weeks ago I had the pleasure of meeting Bob Sutor of IBM and sitting on a panel with him at the Open Source Business Conference. Bob strikes me as a very intelligent man, and given the constant level of quality in his blog postings, he is someone who spends time thinking about the industry in which he works rather than just speaking for the sake of it.

Yet, I fear that Bob and I may take opposing views of the same situation at times. Bob's latest posting on "transparency, community, and certainty" is a good example of this. This posting is a good representation of the IBM stump speech and it is highly polished, yet flawed in many ways.

In order to get ahead of many of the comments that will certainly come from this posting - Microsoft is not the "right" and IBM the "wrong." We have our faults and our business model results in realities that may be difficult for some customers. No white hats on either side of this discussion. The real discussion is not about the high ideals of openness, transparency, freedom from evil vendors. The real discussion is one of vendor business models and how any organization will choose to work with vendors to address their computing needs. For now, let's assume that Microsoft represents that archetype of the software business model and IBM the archetype of the consulting business model. [Both companies provide a range of offerings and generate streams of revenue from hardware, software, and services.]

All of the inset quotes below are from Bob's blog entry.

"People are sick of not knowing. Not knowing if code contains security problems because they can’t see it."

There are two assertions here. The first is that transparency of source code increases trust. I completely agree with that and that is why >13,000 organizations in >60 countries are eligible to look at Windows source code. Unfortunately, very few organizations care about source, nor have the expertise to understand what they are looking at even if they care to look. The second assertion is that source code licensed under an OSS license is more secure because of the openness. That has proven to be completely untrue and is damaging to all OSS-based businesses to continue to make. If there was ever an issue where the entire industry should get together and sing kumbayah together, it is security.

1) Source code availability has been shown in both academic studies and in practical issue tracking to have no impact on the rate of generation for new issues nor the identification of vulnerabilities. The quality of the engineering team (people) doing the work, the tools applied, testing rigor, training of the testers, threat models, etc. etc. make all of the difference. Never mind the realities of vendor response rates, tested solutions, automated patch/update systems, or other post-ship concerns. And no amount of source availability matters a bit when it comes to binary implementation, solution integration, process, people training, audit etc.

2) Security also boils down to an issue of confidence in computing. This affects everyone. Every time there is any high-profile vulnerability (I can find headlines about Microsoft, SUN, IBM, Apple...) it erodes confidence. Cracking is all about the quality of the target - not about the technology, and about proving that "I'm smarter than you." The more mission-critical data put on LAMP stack solutions, the more damage someone can do by going after those platforms, the more attractive the hit becomes. Cracking is vandalism or worse - it affects all of us and I have never liked the idea of using it as a marketing measuring stick. Microsoft has improved dramatically over the past 5 years and it is still not enough - the moment we think we have "made it" on security, that means we are no longer doing our job of thinking about what is best for our customers.

"Not knowing what goes on behind the closed doors of certain standards organizations."

Standards bodies are built upon the ideal of consensus-based interaction in order to achieve a result that may be used by anyone under non-discriminatory terms. What most people don't understand is that there is an entire class of "standards" known as Special Interest Groups that are not as "open" because they are essentially made up of a limited (meaning exclusive) group of companies seeking to achieve a particular business goal. They are not obligated to share their toys with anyone they do not wish. This is in start contrast with the more highly formalized industry consortia or even more rigorous national and international standards bodies. Essentially all of them have explicit rules to make sure that access is granted on a uniform and reasonable basis. The fact that a significant minority of the software industry, never mind the cumulative community of those that consume standardized technologies, participate or even read the publicly posted minutes and documents, does not make the standards bodies closed.

"Not knowing if vendors are trying to use trade secrets instead of openness to achieve software interoperability."

I am not sure I understand the assertions made in this quote. I welcome some clarification. The reality of software is that until 1992 there was no such thing as a software patent. Thus, any sort of direct means of protecting your intellectual property was limited to copyright and trade secret. What is odd about the quote above is the idea of using trade secrets to achieve interop. Publishing APIs, supplying other developers with SDKs and DDKs, documenting your product, designing your product to be easily extended or added on to... these are all ways to enable interop (at a technical level) without sharing source code. In fact, the most commonly noted concern about OSS technology is the lack of all of these higher-level functions to enable rapid application development above and beyond the base level functions. So whether or not source code (read "openness") is available, has little to do with achieving interop with other developers. 

"Not knowing why governments would possibly decide to use proprietary or vendor-dictated specifications when they are clearly against the long-term best interests of the citizens, especially those who are now young and will have to deal with decisions made now once they reach adulthood."

I hope the irony of this statement coming from IBM is not lost on my readers. This one is all about the ODF / Open XML File Format debate but before I comment on that specific issue I think there is a higher-level concern. Governments should be evaluating all solutions (in-house, commercial-off-the-shelf, freeware, shareware, open source, public domain) based on the technical merits and value-for-money they receive from the solution. I wonder if IBM would suggest that governments should no longer consider purchasing proprietary IBM software (approx. $15B revenue stream resulting in more than 30% of IBMs profits) because it may be built upon vendor-dictated specifications and may result in their taxation data, military secrets, etc. be "locked-in" to DB2/Websphere/Notes solutions?

The place where this debate is raging them most is around document formats. There have been numerous standardized formats as well as proprietary formats. Governments have had the ability to save their documents as ANSI (American National Standards Institute) standard text, or even W3C specified HTML in any one of the many Word process products available such from Microsoft, Corel, Adobe, IBM and others. Yet, the overwhelming majority of documents were saved in the proprietary formats because they offered the most compelling feature sets (value). Due to market pressures (customer needs), Office suites offer backwards compatibility, "save as" functionality, and various types of format converters.

Now, it takes little for anyone to see from the PDF, ODF, and Open XML File Format discussions that the market is demanding an even greater commitment to standardization of file formats. Thus, vendors are reacting. Yet, it is a mistake to assume that standardization will be the end-all of interoperability. It is a good starting point, but customers will continue to value the capability of the software that produces the formats. Witness the differences between OpenOffice and IBM's Workplace. Look at the request of OpenOffice users for significant improvements in spreadsheet functionality. Look at the constant improvements in the MS Office products that reach well beyond a format. Also, vendors will need to work with each other outside of the standards fora. Microsoft and Adobe have worked out the details due to customer concerns enabling PDF to be included in O12. There is more on this, but this blog entry is too long already.

I hope this blog entry is the start of a good conversation. IBM is basing their business strategy on the need to grow their consulting business. It represents >50% of their revenue stream and their CEO has spoken at length as to its importance. If your business is consulting, you need to have problems to solve. You need long-term engagements and to make sure that an ever-increasing amount of your customers' knowledge of their business is transferred to you in order to make you more valuable to them and to all other businesses in the same vertical industry. You structure your consulting contracts to retain as much (if not all) of the IP generated in the consulting engagement so that you can turn it over on the next customer for a higher margin. This is not nefarious behavior nor is it immoral. It is simply a business model and one that IBM is the absolute best at.

Microsoft's business strategy is also about earning revenue on its core business. Our model is one of selling software that represents high R&D expense up front that is monetized through the licensing of that software's use over time. Our model depends on a constant cycle of improvement of the software to justify the value of upgrading and remaining with our solution set. The biggest advantage I see in our model is the value proposed to the customer. Well made software should reduce your dependence on expensive consulting engagements by transferring more of the business processes to the shoulders of the technology rather than of the more expensive people resources. Your consulting expenses should be able to be redirected to higher-level value-add solutions rather than core infrastructure work. Again, nothing nefarious in the intent of this model, and many would argue that Microsoft has been pretty good at it.

So, this comes down to a discussion of models. I welcome all feedback and you can be sure I'll continue to blog on the themes touched on above.