Curing what ails Microsoft

Curing what ails Microsoft

Summary: Microsoft's biggest problem lies in its inability to maintain consistency across product categories, both from a user interface standpoint, and increasingly, from an API and technology standpoint. What Microsoft needs is more sharing within Microsoft combined with a more concerted effort from the center to impose discipline, from an API and user interface standpoint, across its product lines.


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.

Topics: CXO, Linux, Microsoft, Open Source, Operating Systems, Software

John Carroll

About John Carroll

John Carroll has delivered his opinion on ZDNet since the last millennium. Since May 2008, he is no longer a Microsoft employee. He is currently working at a unified messaging-related startup.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • What you describe... inherent in any large organization (look at the US Government), but your suggestions are good ones, nonetheless. Any plans to fight unnecessary code duplication and API proliferation, however, must be imposed from the top and must be a high priority with senior management. From all appearances, Steve Ballmer neither understands the issue nor cares (but he's not a techie). Bill Gates would understand and likely care, but he's only working for MS part time now, so his his influence is not what it once was. He could champion such an effort from his position as chairman, leaving the details to full-time execs. Ray Ozzie holds the title of Chief Software Architect, would understand the issue, and it would surely be his job to implement any policies, but I don't know if he cares enough or that Ballmer would back him. In any case, corporate culture is hard to change, so this would have to be a major undertaking with modest expectations, at least in the short run. Is MS up to it? You know much better than I possibly could.

    I have noted in the past that Eric Raymond is the free software movement's most outspoken MS-critic (far more so than is Richard Stallman). I see that you now have first-hand experience with his attitude on the subject. From what I know of both of you, however, I would be surprised if you didn't agree on a lot of other things.
    John L. Ries
    • But Microsoft WANTS api proliferation. That locks people to their platform

      Sure, it is a double edged sword though. It is all getting so complicated and the platforms are getting too bloated. But, what else can they do????
  • Did anyone ever tell you that you look a little

    like Tucker Carlson on MSNBC fromerly CNN?

    Pagan jim
    James Quinn
    • You are the first

      John Carroll
  • An example from the past

    In the late 80's to early 90's, the Commodore Amiga was the "best" personal computer around. Commodore dominated Europe with its C64, and those customers naturally upgraded to the Amiga.

    But lets not compare the abilities of the Amiga to Windoze/PC - that's not what I'm here to do.

    When you speak of user interfaces - and how they proliferate, I am reminded of a parallel that the Amiga went through.

    Commodore refused to set the standards for 24bit graphics, so everyone and their brother created their own (incompatible) 24bit graphics "solutions". Each one had its own way of handling the user interface. The marketplace certainly worked as Adam Smith would have liked - each product competing for customers and creating winners and losers. The demand was FIERCE - there were many graphic designers and video people that wanted/needed this capability.

    In the end, those 24bit wars doomed Commodore. You see, everyone wanted to create 24bit graphical GAMES - which could have put the Amiga squarely in the lead (it already had 12bit color which was better than B&W Macs and 8bit color Win95), but the lack of standards and lack of anyone CARING about standards forked the user base.

    Commodore was run by buffoons, and the user community had taken Amiga design into their own hands. The Amiga was defeated by much less capable products because of elitist users that fought among themselves for 24bit bragging rights.
    Roger Ramjet
    • Standards are good

      And it does behoove developers to set some (alone, or in groups) from time to time in an effort to prevent these sorts of struggles.

      This is actually one area where centralized control of the sort exerted by proprietary OS vendors has an advantage over the decentralized approach we've seen in Linux and other free software efforts, which do indeed work in much the way Adam Smith would have expected (not that I'm asking for creation of a central Linux authority).
      John L. Ries
      • There is a Linux standards base...

        ... being developed to assure compatibility among Linux distributions, as you observed in another post.

        Here's an article from 2005 about it:,1000000121,39192273,00.htm

        How's that different from the "central Linux authority" you're not asking to see?
        Anton Philidor
        • There is...

          ...but distributors are free to ignore aspects of it if they want ("they're more like guidelines", to quote a famous movie). Slackware Linux (what I use on my employer-owned Linux machine at home), for example, insists on using its traditional tarball based package manager instead of the RPM prescribed by LSB.
          John L. Ries
  • Linus only controls the kernel

    While Linus Torvalds is the editor in chief of the Linux kernel and has the final say over what code is and is not included, he has no direct control over any other component of the typical Linux system, and I suspect that his influence is rather minor outside his narrow specialty. More important to interoperability between different Linux distros and the UNIX world at large are the existence of published standards, including the Linux Standard Base, POSIX, X-Windows, and sundry networking protocols; and a widely used set of open source libraries, most important of which is glibc, which is included in every modern Linux system.

    Probably, Linux kernel, and other free software developers realized a long time ago that compatibility problems don't really help them, which makes them more willing to cooperate with each other than are their proprietary "siblings"; many of whom still believe that incompatibility with the competition (to include, in the case of MS and other large companies, their competitors on the other side of the building) is their friend. I'm not sure how/if the problem will be overcome, but it doesn't hurt to keep trying.

    Of course, egoless programming is a wonderful ideal (I believe in it), but it's a lot harder to practice than it is to preach, and I suspect that in practice, egotist programmers are far more often rewarded than are egoless ones.
    John L. Ries
    • Software developers...

      are the the same whether they work on open source projects or proprietary software. Egotism is, unfortunately, quite common. I would argue though that working for a company that makes a living selling software dampens that attitude because it's a matter of survival for the company. I think that what John Carroll describes happens mostly in companies fairly big and without real financial problems. In that situation some engineers start working on what they like and not on what is good for the company. As soon as financial troubles hit the company those pet projects are the first to go.

      I should add that that type of behavior or tendency on the engineers part is not always due to egotism. Software engineers usually love what they do and are often driven. They, sometimes, start treating their work like a very pleasant hobby free of business and financial pressures but more often than not those pressures bring them back to reality .
  • While I'm sure you know the answer to this...

    but what products/licenses are you refering to when you say "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)"?
  • RE: Curing what ails Microsoft

    [i]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.[/i]

    Maybe Judge Jackson was doing Microsoft a favor by pushing it in a direction no one within the company has the 'nads to take it.

    none none
  • Why MS stays inconsistent

    MS needs to embrace, extend and extinguish. That's why every product has their own GUI controls. They need to mimic competitor functionality.

    There are also a couple other reasons for this:
    1. In the ars.technica thread, someone pointed out MS Office's control can't be used by ANYBODY else, even inside MS. This does help control social engineering type hacks.
    2. Different interfaces hasn't seemed to hurt MS in the past and help Apple now. Users adjust easily and developers have to follow the users. Is Apple doing better now? Yes, but not because of consistency. They use several themes internally, also.
  • Reinventing the wheel...

    ... can sometimes produce a better wheel. Sometimes a company can find a way to provide a long-established function more efficiently, at least for its own products. (Such innovation is less likely with the open source collaboration used to save money on staff, of course.)

    In Microsoft, cointinuously adjusting a code base for many different projects could be pains-taking, while wheel re-invention can produce improvement.

    There should be a way to determine that any effort is not worth pursuing, this sort included, but the possibility of developing a product with some independence shgould remain open.
    Anton Philidor
  • You know, what you are describing = a MS breakup.

    If you had a "Windows" company that focused on Windows exclusively to make it the best OS available we would not have near the issues we have today. The same could be said for the Office folks.

    I will give you an example. We were building an add-in to Office 07 and ran into issues with security and the ribbon for "All Users" on a given PC. We spoke with the appropiate Office PM and were directed to talk to the VSTO folks. Talked with them and were told to talk to the Windows (Vista) security folks. Talked to them and we were sent to the .NET folks. Talked to them and were told to talk to the Office folks. It literally took weeks to schedule a conf. call with someone from each group to get together and address the issue.

    Oh, as an FYI: The outcome was that we simply can not install a .NET COM based add-in for all users of a PC. Each and every user must do it themselves.
    • What a pity therefore...

      That Microsoft appealed the breakup remedy that Judge Jackson wanted to implement. Ah well...
    • don't go extremist on us...

      the argument is that MS is large enough to be its own community. If all code trees were open to each member of the community, and a policy to accept 'third-party' code was actually enforced, the law of less effort would lead to code re-use. Efficient management of said code sharing would entail said code to be built into its own module, changing slightly on each new re-use - removing unneeded features, adding useful ones, or breaking huge monoliths into smaller, more manageable elements that could be scrapped and changed with a new, publicly compatible but internally radically different one.
      You know,a bit like happened in the UNIX world where compilers replaced each others, libraries, startup scripts, shells, graphical interfaces, TCP/IP stacks, device drivers etc. come and go.
      The point this post leads to is that MS should STOP being internally fragmented; breaking it up into smaller parts would actually mean making internal rifts, real ones.
      Mitch 74
  • Have cross company groups

    If MS doesn't already do this, I think it should have cross company groups that proliferate throughout the entire company. E.g. I think the company should have a design organization that has members in every product group, to ensure that each product group adheres to the company's overall design standards, and that there is sufficient coherency among related products' designs. E.g. there could be a hierarchy of designers assigned to MS Office who ensure that the there is a high degree of coherency in the design of Office products, and that these products have an acceptable level of usability and polish. This group of course would belong to the overall design organization within MS. When it comes to customer facing APIs, MS could create an API coherency group with members belonging to all product groups that have publicly available APIs, and this group would be charged with ensuring that there is a high degree of coherency among all customer facing APIs. There could even be an ad group that is charged with placing ads into certain desktop, mobile, and other products.
    P. Douglas
  • Bright is Right

    Peter Bright's article contained passion for development.
    He both spoke of it and exhibited it.

    One conclusion, is that there are obviously advantages and
    virtues to both Microsoft's approach and Apple's. The
    difference between the two break down predictable lines
    however. Like Apple's marketing, it's business model, and
    it's products, the dev environment is meant to diverge and differentiate itself. It is a system designed to exist within
    an arena that contains other systems. In other words, it's
    designed to compete. The Microsoft model and .Net, by
    contrast, is designed to assimilate.

    If the future is indeed a multi platform future, things will
    change. If the old model was a single platform and a
    monopoly, and the new model is an open market and
    competitive, which player is going to require the larger
    adjustment? Who's model now best suits the market.

    The larger issue here, is not which technology suits
    developers needs, but which developers suit users needs.
    If consumers of clock cycles embrace a more open and
    heterogeneous tech market (and they are), they make a
    choice first, for choice itself. Only then is the choice for a
    platform made. Even then, the choice will often be for
    both. They understand intuitively that this is no longer a
    war between a passive tech platforms where one will
    inevitably emerge victorious, and pity the rube who
    chooses the wrong one. What this is is a evolving and
    expanding landscape of active technology, that needs to
    have the prospect of choice maintained, before, during and
    after one of many choices. Technology is too important to
    be consolidated within a small and limited set of interests,
    and a false and feudal Microsoft economy was doing that.

    Peter Bright described a dev environment designed to
    leverage aspects of platform. Not a huge platform? So
    what. It's not meant to be the only one. Doe eyed
    admiration of Microsoft market share has no place in this
    discussion. It's as circumstantial as a fickle market's
    whims. A market that's very respiration is driven by cycles
    of change. To tie an argument to circumstance is to have
    your "opinion" changed when it changes.

    Peter described some forward thinking and good decisions
    from Apple. It should be seen as a welcome addition to
    technology. As often as not, it's seen as a threat to a
    Windows economy. One that provides good livings to
    many. The same thing that gave Microsoft an unreasonable
    market share, is the same things that sparks irrational and
    unreasonable defense. It is rarely the pure defense of
    technology, but rather the defense of the false economy
    around it.

    Looking ahead, the tech economy clearly needs the larger
    gene pool that an open marketplace provides. It needs not
    only Apple and Microsoft, but also other players to provide
    competition and diversity.
    Harry Bardal
  • RE: Curing what ails Microsoft

    Microsoft is managed by the olde guard, they haven't much chance of doing any 21st century thinking with their current leadership.

    They are afraid that they won't make money if they deviate from their model. I'm afraid they won't stay in business if they don't.

    Love it or hate it, Open Source has a lot to offer to the economy and the community. Free as in speech does not always mean Free as in Beer. That said I don't always see eye to eye with OSS people, the "free as in beer" beer crowd can go off and write their own software for all I care.