Curing what ails Microsoft

A number of years ago, I wrote a criticism of Richard Stallman that got me into an email argument with both the man himself, and Eric Raymond. At the time, I compared my discussions with them as akin to having a friendly discussion about politics around a table at a restaurant, save for one person, who vents his displeasure by trying to take your eye out with a fork. That person, of course, was Eric.

In spite of a rough beginning, that argument led me to sit down and read Eric Raymond's "The Magic Cauldron," the seminal work on open source development models. As a "rebuttal" of sorts, I wrote this series of four articles (one, two, three and four).

The reason I bring that all up is that, though I expected to disagree with most of what Raymond had to say, I found that I didn't. Raymond has lots of good reasons for his stance on things, and though I would disagree on details (and degrees, such as the percentage of the market that should be open source), the core concepts aren't far off the mark (in my opinion). That also applies to my disagreement with Peter Bright.

Yesterday, I voiced my displeasure at some of his characterization of the Windows family of APIs, in particular, his less than detailed attack on .NET. That doesn't mean, however, that I disagree with everything he had to say in his three-part series.

As noted yesterday, I agree that the low-level native APIs on Windows are as inconsistent as a document which uses hundreds of languages simultaneously (though I disagree with how that supposedly affects development atop the platform). The thing that really caused me to sit up and take notice, however, when I read his articles a few days ago was his description of the lack of consistency in user interfaces atop Windows. Click this link to see an overlay image of various key Microsoft applications, which demonstrates the wild divergence in user interface conventions WITHIN Microsoft, never mind among third party applications.

I've long considered this a problem. A notable anecdote: several years ago, I attended a conference in Las Vegas devoted to development atop Microsoft embedded platforms. In one presentation devoted to the, at the time, new Media Device Feature Pack, the presenter - a programmer who I gathered had been involved in the actual development of the new Windows CE feature, spent a good 20 minutes describing a new user interface package he had designed as part of the pack. I remember exchanging funny looks with my boss, who attended the conference with me.

Microsoft needs another user interface framework like it needs a hole in its collective head. Yet, such frameworks proliferate like mice across the company, a company that extends into an ever more bewildering array of product categories and absorbs ever more developers into its corporate body.

Code duplication is a pandemic throughout Microsoft, a waste of effort that would be put to an immediate end within a smaller company, but thrives within Microsoft because code is power at a company of the scale of the Redmond-based giant.

That is the root cause of the fragmentation Peter Bright rightly identified in his series of articles. Owning a code base is the way you get budget for more developers, more servers, and more testing resources, which constitute the lifeblood for any manager within a software company. Any ambitious manager - and Microsoft as a company is literally bursting with them - will grab hold of any pile of code, however large and / or important, and defend it like their lives depended on it - which from a professional standpoint within Microsoft, is literally quite true.

If Microsoft could find a way to mitigate, if not erase, this perverse incentive, I believe that would improve its strategic position considerably, particularly from a user interface standpoint. Google is rumored to have a corporate policy wherein all code created by teams within the company must be shared with other groups.  The intent in this is to encourage the development of a common and flexible codebase that benefits everyone, opposing the tendency within large companies to ride off in incompatible technology directions as a way to build a politically useful islands that serve as a foundation for mini-empires. This seems natural for Google, a company that is open source-ish (meaning: yes, they use open source and produce plenty of it themselves, but try getting the source code for their search engine or other core products).

I think that such a model could work just as well - if not better - within a company of the size of a Microsoft. No, Microsoft wouldn't release the source code for many products to the wider world beyond the confines of Microsoft, so it wouldn't be "true" open source, but there are 70,000+ people at the company, most of them extremely smart and skillful programmers. An "open source" progam composed of nothing else but internal Microsoft employees would leverage many of the benefits of that development model while maintaining the revenue advantages of proprietary software.

Microsoft is surprisingly bad at sharing code with other parts of Microsoft. To some extent, that is understandable, as code is power, and allowing people to access that code might cause them to fork it in odd directions, growing the result into a product that ends up replacing your own. Furthermore, lots of groups don't want to improve upon or rely on someone else's software stack, as that stack might grow to be more important than your own software, causing your team to lose out in the competition for resources.

On the one hand, code sharing doesn't have to imply lack of control. Linux is controlled from the center by Linus Torvalds and his team of Linux illuminati. It allows third parties to dream up new improvements to Linux independent of the center, but gives them the control that ensures Linux consistency. Within Microsoft, that control would equal power, which is surely a more useful economic dynamic than a simple hive that is completely separate from - and often a duplication of - other hives within the company.

On the other hand, I think a model that truly encouraged cross-discipline contribution to shared code bases would create a more modular approach to design. Though Linux is centrally controlled, lots of the products that extend or run atop Linux are controlled by entirely different teams. I don't see why a module created, say, for IPTV could be controlled by the IPTV team, even if the core product on which it depends is managed by someone else entirely.

This would put to better use the intellectual inheritance that Microsoft has as a company. Microsoft has some of the best developers in the world within its 70,000 employees. Some of the company's leading lights are notable experts in the creation of software platforms. Use them more effectively, and Microsoft will become a more competitive company.

Another thing I wished that Microsoft would do while I was an employee is create a department with a religious devotion to the creation of a single and cohesive platform that spans ALL Microsoft product categories. This department would have the power to seriously bash Microserf heads when some team goes off and reinvents a wheel. Every time a team does that, they detract from the benefits of the Windows platform. This is harmful to Microsoft as a company, and the fact there is no person or group of persons tasked with maintaing this platform birds-eye view makes it hard to coordinate things in a company as distributed as Microsoft.

More central control of the user interface used by individual Microsoft products would also seem wise. There really is no excuse for the ideosyncracies across Microsoft core products identified by Peter Bright (and I agree with him that platform support for Microsoft's new ribbon user interface (inaugurated with Office 2007) is confusing and inconsistent).

Where I may differ with him is whether or not Microsoft should try to exert that central control over third parties the way Apple does. I think Microsoft should do more to encourage design excellence, but a lot of that would happen naturally by serving as a better example. Microsoft is, at the end of the day, a platform company, and one of the benefits of being a platform company is that you get to rely more on the innovations of third parties in ways that Apple purposefully restricts. On the other hand, there are clearly advantages to creating a more consistent look and feel. Microsoft should be providing that by example, making it easy to copy those good ideas by including deep and widespread support for reuse of those technologies in third party user interfaces while trusting that good ideas will defend themselves.

People will deviate, to be sure, but deviation might be beneficial. To use a Microsoft internal example, the Office UI is clearly a great concept, and a rigorous adherence to strict UI conformity would have prevented it from happening. Once discovered, though, it makes sense to use that UI concept throughout Microsoft. Create as much UI consistency as is feasible, while remaining open to new concepts and better ideas.

In my opinion, being a "good guide" would yield Microsoft benefits beyond the realm of user interfaces. My biggest complaint about the Zune was not one of design, so much as the fact that they tried to make a closed system competitor (complete with its own desktop software) to compete with another closed system competitor that had 70%+ of the market for music playback products. That just doesn't make any sense, and really runs counter to what Microsoft as a company is all about.

A better strategy would have been to design and sell the Zune, making sure that EVERY technology was available to third party licensees (that, and make Zune manageable from Media Player...I still can't figure out why they didn't do that). That's being a guide to the marketplace, and if they had chosen that path, I think they would have been further along in their goal to take more share of the market for music players, as they would be leveraging the energies of the market for music players based on Microsoft technology as a whole rather than trying to go up against iPod as a single product category all on its own.

Winding this down, Microsoft became a massive company on the basis of a model of software licensing that better enabled third party innovation. Quite simply, had Microsoft opted to maintain a closed hardware model in the Apple mould (a happy accident, perhaps, as they got their big break when IBM licensed their OS for use in the new desktop computers), the cost reductions that occurred in PC hardware (from which Apple, as an x86 product, now benefits) would not have happened, at least as fast.

Microsoft's approach is a good one, but they need to understand better what it means to be a platform company. Microsoft needs a core ideology rigorously enforced from the center and disseminated to individuals working in the trenches as a constitutional principle that guides instinctive product decisions far removed from Redmond. This requires a lot more sharing WITHIN the company, and a lot more effort to create common codebases that range across product categories.

A Microsoft that adhered to core principles rigorously across all its product lines is a Microsoft that would, in my opinion, do a better job of posing challenges in markets where they have difficulties. Those are the lessons that should be drawn from its competition with both Apple and Linux. If there is a continuum between Apple and Linux, Microsoft should aim to fall somewhere in the middle.