From IBM to Microsoft: the regression of openness

Late last month, Microsoft was in the news for being the target of another formal complaint to the European Union for alleged anti-competitive practices. This time the complainants are focusing on the ubiquitous MS Office suite and asking — demanding — that Microsoft be more forthright about disclosing internals that would let other vendors integrate better. How much we’ve regressed in 25 years.

Microsoft provides zero source code visibility to regular customers (so far as I’ve seen in the last two decades), and it opens the kimono only to independent software vendors (ISV) that Microsoft decides are worthy of such a benefit. Although I have no direct experience with being a Microsoft-certified ISV, one can imagine that in exchange for access to programming information, there are some tight contractual terms.

Thus, user organizations as well as ISVs that haven’t been approved for access are flying blind when it comes to having any real understanding of how their key office systems actually operate. Along with that, there is little recourse but to respond passively when things go wrong. Because only Microsoft holds the key to code, most often only Microsoft can help — should it care to.

Microsoft certainly didn’t inherit this approach from the software vendors that came before it. In the days before Microsoft, the approach to visibility was much different — and much better.

In the early 1980s (and earlier), the mainframe ran businesses and IBM ran the mainframe. (In many cases, this statement remains true today.) What’s different is how IBM treated its customers and the army of third-party ISVs that built businesses on filling niche markets too small to warrant IBM’s attention.

Back then, long before the term “open source” was coined, that is what we had. Manuals and documentation made available even to general users — without signing any special agreements with IBM — provided a level of detail unheard of in the Microsoft world.

IBM provided detailed documentation at the source-code level for all its mainframe operating systems — MVS, VSE/VM — as well as major subsystems such as CICS (transactions), VTAM (communications) and VSAM (file storage).

When system problems and crashes occurred, users, in conjunction with their IBM program support representatives — probably now an extinct species — would pore over data dumps using the detailed documentation of control blocks along with program flow documented in logic manuals to figure out what went wrong.

Just as with the open source movement today, customers worked with those responsible for maintaining and improving the code. We could only do this because we had visibility into what was running on our systems.

In addition to true paper manuals, we also had the massive source code for the operating system and subsystems available in microfiche format. We could find out which instruction was causing a system to fail.

My days of being frontline support for major corporate systems are way behind me now. I can tell you, though, that I would not want this burden today in Microsoft’s “nanny” state where only Microsoft knows what is happening on my systems.

It is ironic that when it cost real money to produce hard-copy documents and microfiche and ship it to customers, programming information was readily available, but in today’s world of soft copy and Web searching, Microsoft continues to deny this information to the world.

QuickLink: 067052

–Tolly is president of The Tolly Group, a strategic consulting and independent testing company in Boca Raton, Fla. He can be reached

Related Download
3 reasons why Hyperconverged is the cost-efficient, simplified infrastructure for the modern data center Sponsor: Lenovo
3 reasons why Hyperconverged is the cost-efficient, simplified infrastructure for the modern data center
Find out how Hyperconverged systems can help you meet the challenges of the modern IT department. Click here to find out more.
Register Now