Transparency and Microsoft
In the past week, there have been considerable discussion in the blogosphere on transparency.
Eric Sink, software entrepreneur, posted a new article out on his Business of Software series, “Tenets of Transparency”. His inspiration came from the increasing openness from the Microsoft developer division, which has introduced community technology previews, the Product Feedback Center and the ubiquitous Microsoft weblogs. He also offers advice to software entrepreneurs on how to become more transparent.
At the same time, the Economist has an article “Chief humanizing officer,” focused on Robert Scoble, but also describes how corporate blogging and Channel 9 are changing public relations at Microsoft and making the company more transparent: “A good blog lets you see the mess; lets you see behind the scenes.” It also explains the origin of the moniker “Channel 9,” which allowed passengers of United Airlines to tune into pilot communications from their plane seat, thereby alleviating the fear of flying. Other articles on the new Microsoft transparency include “Microsoft’s new rules of engagement.”
I attribute some of the new transparency to the efforts of CEO Ballmer. When Ballmer took control of the helm at Microsoft, one on his most important contributions was to shift the company to a customer-centric orientation. Reportedly, employees and managers, at the annual review, are judged partly on their contributions to customer satisfaction. As a result, there’s been an overall openness across the board. I mentioned, for instance, in earlier posts the sharing of source code.
I still think that Microsoft could do a little more in transparency. When I read blogs from Microsoft developers, I realize that much of the inside information they reveal on APIs could be more effectively disseminated to the developer community if Microsoft actually published internal API specifications online during beta or after release. After a product is released, internal specs typically disappear into oblivion (aka backup tape), and many of the obscure details in the spec are essentially lost forever, buried in the minds of a few product team members.
Standard MSDN documentation typically sums up an API call in a few sentences. What’s lost is the backstory—the motivation behind the API call, the various tricky cases, the relationship between that call and other related API calls. For example, you can glimpse the Win32 backstory when reading the posts on Raymond Chen’s blog and Michael Kaplan’s blog is good for understanding the Globalization story in .NET. The Whidbey team have recognized the limitations of the past approach to documentation and are enhanced their Help system to integrate results from KnowledgeBase, MSDN documentation, MSDN online and CodeWise community articles, much like WinFX247.com.
Publishing the API specs might yield a more complete story than any of the above. Typically, specifications treat related API calls together, give the rationale for why the API is needed, and offer a fuller explanation of how the API should work. For example, I never quite understood the reason why GDI+ has both BeginContainer and Save; if I had the specs, I am sure the answer would be clear.
Anyway, I might actually post a suggestion to open up the API specs in the Microsoft Product Feedback Center. In this way, I would use one of Microsoft’s mechanisms of transparency to help it become even more transparent.