Standards, antitrust and Microsoft

Standards, antitrust and Microsoft

Summary: No need to add to the Microsoft - Yahoo speculation frenzy, as plenty of others will do that for the remainder of this week (though if anything pops into mind, I'll certainly talk about it in these pages).  Instead, I'll return to the topic I had planned to write about last Friday, before news of the deal hit the airwaves like a train running through a concrete barrier, which was: what should be Microsoft's stance with respect to standards?

SHARE:

No need to add to the Microsoft - Yahoo speculation frenzy, as plenty of others will do that for the remainder of this week (though if anything pops into mind, I'll certainly talk about it in these pages).  Instead, I'll return to the topic I had planned to write about last Friday, before news of the deal hit the airwaves like a train running through a concrete barrier, which was: what should be Microsoft's stance with respect to standards?

The topic was inspired by something John L. Ries, a longtime talkback participant who rarely agrees with anything I say, noted in a comment to a previous post on the subject of Microsoft antitrust oversight. In response to a question asking what it would take for him to stop being concerned about Microsoft and its business practices, he said:

When the primary selling points of MS software are the price/quality/features/terms of the software, instead of "compatibility with everyone else" or "it's illegal to use competing products", or other forms of fear, uncertainty and doubt (original meanings of those words), then MS will no longer be a threat to the free market and will no longer require court supervision or consumer boycotts to keep them in line.

First things first, though Microsoft did certain things in the early and mid-90s that were questionable, I don't think it has ever been "illegal" to use competing products. Microsoft has never banned third party products installed by consumers (though they did try to use licensing terms to block competing browsers, something they are now constrained from doing by antitrust rulings), and if they did, Firefox would not be constantly eating into Internet Explorer market share, and Intuit wouldn't have run circles around Microsoft's past business software efforts.

Microsoft, in particular, actively encourages third party development. They don't spend all that time making frameworks and APIs for its own exclusive use. Customizability and extensibility has been at the center of the value-add since the company's earliest days.

As for the other bits, as I noted in a previous blog, I believe that Microsoft needs to be a lot more "open." Open, however, does not mean Microsoft should exclusively use internationally-ratified standards, or avoid creating its own. Heck, I don't even think that it is wrong for Microsoft to make extensions to ratified international standards (though we can debate the proper shape such extensions should take).

What they should always do, however, do is document the heck out of those standards (whether home grown or extensions to existing standards), and where sensible, opt to get certain stages in the evolution of those home grown standards "frozen in amber," as it were, by international standards bodies. Interoperability, a natural byproduct of openess, must be a core design criterion, and not just because it is a "nice" thing to do.

Though open source might clamor most for it, theirs is a voice that speaks to a need for more transparency in devices that only grow in importance with every passing year. Constituencies usually have some basis in a real need in politics, and that applies equally to software constituencies, who to my mind are simply at the vanguard of a wider demand for more transparency in the computing products we use on a regular basis (I don't think they created the impulse, though they are instrumental in accelerating change).

I also think it only makes sense for a company that lies as much at the crossroads of computing as Microsoft to value openness. Though it might be acceptable for smaller companies to engage in certain opaque practices (acceptable, not recommended), a large company that has as much control and power as Microsoft shouldn't engage in such things. Besides serving as a barrier to the growth of products going forward (like I said, openness is more important to modern consumers), it breeds resentment and thus invites unwanted government scrutiny. Though I think such scrutiny often oversteps itself (subliminal man says: "EC, EC, EC, EC, EC"), complaining about that overstep is like complaining that trees aren't springy and flexible when you crash your car into them.

But, it's worth reiterating that I think it is perfectly acceptable, and even a GOOD thing, for Microsoft to do what is typical of Microsoft, which is to make its own standards. Firstly, it is more reflective of the fact that Microsoft is a corporation that needs to differentiate its products, a point made repeatedly by Anton Philidor in my last blog post. Standards competition is as important as (and a necessary part of) software competition, in my opinion, and forces standards to evolve to accomodate more features faster than if there is nothing challenging a given standard. Standards, like software, evolve in response to external challenges.

I remember all the blog-based bluster that greeted Microsoft's announcement that they would use home-grown, XML-based XAML as the foundation of their future UI technology instead of basing their efforts on something like XUL (the XML-based user interface language developed originally for the Mozilla / Firefox web browser). Besides the questionable strategy of a company basing its core user interface APIs on a standard largely controlled by an outside body, XUL made no sense within the context of Microsoft's API efforts, as XAML was designed specifically to map to Microsoft's .NET framework (which lies at the heart of those efforts). That's a valid design decision, in my opinion and one that a company with an interest in creating a cohesive and consistent framework should make.

That doesn't mean I think XAML (as an example) should be closed, undocumented, and not available to third parties to implement on their own. Being open means providing the information that enables others to interoperate with your products. It doesn't, however, imply that a company should only use standards made outside the company.

So, what exactly am I saying? Basically, I think Mr. Ries may be placing the hurdle a bit too high, putting it at a level that no private company could ever achieve. Every company needs to give itself an "edge," and that often means developing key technology in-house. Customers (and Ries) are right, however, to expect that that technology is made available to people outside the company, at least when the company is of the size and stature of a Microsoft (I would argue that small companies are wise to follow the restrictions I outlined, though the effect, should they fail to do so, is less pronounced).

As to Ries question as to whether my stance on antitrust has changed over the years, I'll leave that to a later blog post. This one is long enough as it is.

Topics: Enterprise Software, Microsoft, Security, 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.

Talkback

30 comments
Log in or register to join the discussion
  • Did nothing illegal?

    They were convicted by DOJ! Can you say BIASS.
    If the DOJ would have broken the company into OS and Software back then non of
    us would be having this discussion. That was what was needed then and it is still
    what is need now. If that were the case, they could create there own standards and
    everyone would have API's to use them or not, and at a fair price.

    Personally we lost a years worth of work when MS decided to disable their support
    for Netscape plugins and claimed security as the reason. We all know ActiveX is
    way less secure. Was this illegal, no their EULA lets them do anything they want.
    Like taking your car in for an oil change and they remove your radio because of
    security reasons. This would never have happened if the company was split.

    I use to love writing code, now I hate it because of MS. We spend 4 month of every
    year just keeping our stuff running under Windows when we could be spending
    that time adding features. They change things for the sake of change and that only
    benefits MS by selling more stuff.
    LittleGuy
    • There will be Adjustments to the Microsoft Business Model

      It could well be that Clinton is elected. At that point what would have happened if Bush hadn't put Ashcroft in at the head of the DOJ - Ashcrofts political carreer was finance by Microsoft - will happen. Reno, she was a terror on the monopolists.
      mighetto
  • Good post, but clarification please.

    Microsoft provides all the information necessary for outside developers(! developers!! developers!!!) to make their products. The company does recognize the network effect.

    Microsoft also provides interoperability, directly or indirectly when that is a concern of customers who/which might not otherwise buy. Though not to the extent that movement from Microsoft products is facilitated.

    Microsoft does not provide information (willingly) that would allow competitors to match the company's software performance more easily.

    I assume you're not disagreeing with these goals.

    So when I read a paragraph like this...:

    What they should always do, however, do is document the heck out of those standards (whether home grown or extensions to existing standards), and where sensible, opt to get certain stages in the evolution of those home grown standards ?frozen in amber,? as it were, by international standards bodies. Interoperability, a natural byproduct of openess, must be a core design criterion, and not just because it is a ?nice? thing to do.

    ... I'm not certain what you're saying the company should do that it's not doing now. Could developers make good use of information not available now? Wouldn't providing such information be only another example of what Microsoft is already doing?

    Also, I wonder when it would be sensible to lock certain standards in amber when the company might wish to make changes some day. Unless you mean the international standards body recognizies the standard rather than gaining control over it.
    Anton Philidor
    • MS Documentation has been poor or incomplete

      "Microsoft provides all the information necessary for outside developers(!
      developers!! developers!!!) to make their products."

      Simply not true. Significant portions have not been documented, including APIs
      used by MS for some of their software products. Actually spawned a
      "Undocumented Win32" industry.

      Even when it was demanded by the EC, MS documentation still hasn't received
      approval that it is complete (several years now).

      Competition regulators recognise MS has a greater responsibility to publish
      information because of their monopoly market share, a position they have abused
      for profit in the past.

      Thanks JC for a balanced blog, it is important to acknowledge MS past behaviour.

      I've no problem with MS developing, or seeking ratification of their own standards.
      However it should be acknowledged that given their market position, past
      behaviour and the need for interoperability, if competition is desired (I believe it is)
      MS should be required to document these standards to a level that makes them
      useful to others.

      Sadly this has always required regulator intervention in the case of MS. A position I
      don't believe will change, unlike JC.
      Richard Flude
      • Helping vs hurting Microsoft

        I think Microsoft does provide the information necessary for a third party developer to create software for Windows (for instance) which will encourage additional sales of Windows (and, of course, be profitable for the developer).

        I think Microsoft much prefers not to provide information making it easier to replace Windows.

        You're right that Microsoft does a poor job of documentation which might be useful to a competitor, which is what the EC was demanding. (The EC later decided the information was without value as innovation when considering the fees Microsoft might charge.)


        The issue you're raising, as I see it, is whether Microsoft must be forced in principle to release any information which will make efforts easier technically for competitors. (A competitor being defined as any potential or current replacement for Microsoft software. Wine and Samba, for example, are competitors.)

        My view, a competitor developing its own approach unrelated to Microsoft's and providing a superior product is appropriate, and anti-trust regulators should assure that Microsoft tactics do not squelch the product.

        But software which is parasitic on Microsoft's efforts, intended only to replace a piece of Microsoft software with equivalent functionality, is not advancing the field and need not be encouraged by government. Such software should not be prevented, but government by its nature is too coercive to be allowed to manipulate a market in order to damage a company.

        If Microsoft's profitability is to be reduced, let it be as a result of the availability of better software, well marketed.
        Anton Philidor
        • Yep

          Compatibility is property and unauthorized compatibility is stealing. If you want interoperability with the majority you must pay Microsoft for the privilege or be cast out of the computing mainstream as a thief and a robber.

          Anything I'm missing?
          John L. Ries
          • Discussing government actions.

            As an example, when .doc formats were not described completely enough for other word processing software to work with them, people had to work to make those formats available to the competing software.

            Should Microsoft have been ordered by government to supply materials which made that work easier?

            This discussion does not concern interoperability of different pieces of software, but whether competitors should be assisted by government in obtaining information used to replicate functionality of Microsoft software.

            Microsoft cannot be expected to assist others in obviating advantages of the company's software. But neither can Microsoft prevent - by government action or otherwise - appropriate efforts by others to overcome any disadvantage.

            That rejection of government intervention applies to both aspects of the software which improve performance and those Microsoft may have set up to inconvenience the competition.

            Governments should not decide what is a software aspect intended to create artificial barriers and what directly contributes to software performance in order to act against the ploys Microsoft might use against the competition.

            Why? As the EC's odd twists in the licensing protocols situation shows, governments may not be competent to make the decision and may be influenced by biases among the people involved. Better to let people do the necessary work than use government to compel saving them time.
            Anton Philidor
          • Remember

            MS was ordered to provide docs as part of the consent decree in the DOJ (reparations for past illegal conduct); I note that part of the reason why Judge Kollar-Kotelly ordered the extension of the deal was that MS had not complied to the satisfaction of the court. If they thought the demand was unjust, they could have rejected the deal and kept fighting. Footdragging after the deal has been agreed to is simply unacceptable. I think the court would be fully justified in citing MS for contempt.

            Charging royalties for use of MS protocols and their documentation doesn't strike me as adequate reparation for illegal conduct either. The EC was right to reject it. Documentation should be provided at cost with no strings attached.
            John L. Ries
          • Foot-dragging?

            Perhaps incompetence is the better answer. The Court apparently agreed. The agreement accepted by the US Court actually names a Microsoft employee whose continued involvement was considered necessary to completing the job.

            The EC did accept charging royalties for the Microsoft IP which was required to be made public. Until the difficulties for open source became apparent to EC staff, who thereupon decided that the information was without value.

            Perhaps the information did have no other purpose than to make life more difficult for competitors. But the sequence of events makes for the suspicion that the determination was made to advocate open source rather than the result of an objective evaluation.

            To me, that's an example of why government should not be making determinations about innovation/impediment. Regulators are not always objective. This was a case in which the regulators were hostile. In other circumstances, regulators are known to become sympathetic to the industry regulated. Then such decisions are criticized as favorable to the industry against the public. Best to avoid such highly discretionary regulation when possible.
            Anton Philidor
      • Undocumented APIs

        [i]Simply not true. Significant portions have not been documented, including APIs used by MS for some of their software products. Actually spawned a "Undocumented Win32" industry.[/i]

        I ALWAYS have undocumented methods in every program I write. In .NET / Java code, they are easier to keep from the public eye, as I mark them private or internal. In binary / C land, that is a bit harder. Most programs have stacks of exported functions that they have zero intention of making part of their public API, and for good reason. Those bits are likely to change in future, and making it part of the public API implies that they will ALWAYS be there.

        You don't want to do that with every part of your program. Object oriented environments understand that, which is why they provide plenty of tools by which to keep code from the public.

        [i]However it should be acknowledged that given their market position, past behaviour and the need for interoperability, if competition is desired (I believe it is) MS should be required to document these standards to a level that makes them useful to others.[/i]

        I guess the only difference between my opinion and your opinion is that I believe it is in Microsoft's self interest to do what you think governments should force them to do. That's why I think the remedies will be more self-sustaining than not.

        Fair enough: keep regulatory oversight for longer. But, I think you will find Microsoft is not going to be able to walk the closed path the way it could in the mid-90s. That applies to more than just Microsoft. Few companies can afford to make themselves protocol islands anymore.
        John Carroll
        • Undocumented APIs

          John says:

          "I ALWAYS have undocumented methods in every program I write. In .NET / Java code, they are easier to keep from the public eye, as I mark them private or internal. In binary / C land, that is a bit harder. Most programs have stacks of exported functions that they have zero intention of making part of their public API, and for good reason. Those bits are likely to change in future, and making it part of the public API implies that they will ALWAYS be there."

          I would argue that these are support routines not intended to be called externally at all and therefore not part of the API (the key word is "interface"). These are not hidden features intended to give MS' application business an unfair advantage over outsiders.
          John L. Ries
          • Right

            During the development of windows 3, developers would regularly swap between the
            windows and Office development teams. This enabled them to develop a version of
            Office available at windows 3 launch whilst API documentation was substantially
            incomplete.

            Many MS applications have used undocumented APIs, known of course to MS
            developers familiar with someone on the OS team, that can't be reliably used by
            external developers.
            Richard Flude
    • True, but

      [i]Microsoft does not provide information (willingly) that would allow competitors to match the company's software performance more easily.[/i]

      Yes, but I do think that protocols for communication should ALWAYS be documented irrespective of whether antitrust authorities mandate it, especially for a company of the size and stature of a Microsoft.

      There's a lot of difference between a protocol and actual implementation code. HTML is a standard. There is enough difference, however, between even browsers that tout themselves as standards-compliant to show that implementation plays a large role in consistency.

      [i]... I'm not certain what you're saying the company should do that it's not doing now. Could developers make good use of information not available now? Wouldn't providing such information be only another example of what Microsoft is already doing?[/i]

      They are doing it more now, to be sure, but it's not just a question of documenting APIs. They have always done that (and regarding Flude's "undocumented" API comment, there are ALWAYS functions and methods that you don't want to make part of the public API, and for good reason. They are likely to change. That is easier to manage with a runtime like .NET, but in binary land, you will expose lots of functions that you have no intention of making part of the public WIN32-WIN64 API)

      What they haven't always been good about is sharing their data formats / communications protocols. They are getting better, but I think that it is important to be open in that regard. Doing so will grow the market faster given the current state of software and IT than trying to walk the closed path.

      [i]Also, I wonder when it would be sensible to lock certain standards in amber when the company might wish to make changes some day. Unless you mean the international standards body recognizies the standard rather than gaining control over it.[/i]

      Locking a standard in amber doesn't mean changes can't happen. It just means that people can save to THAT version of the standard and know that any software compliant with that standard will understand it. New software can extend the standard, but SHOULD have an option to save to a certain standard version level.

      Evolution still occurs. PDF is still evolving even though they have made standardization checkpoints along the way.
      John Carroll
      • Ah, a modified, limited hang-out then.

        Good clarification, too.

        Just to make two points definite:

        One of the issues asserted by Microsoft when the EC made its demands was that providing the information would allow competitors to discover the improvements in the software that provided the company with an advantage. Without considering the accuracy of that statement, I assume that in principle you agree that the company should be able to redact material that would indirectly give away information of value beyond the protocols / formats themselves.



        Your other point concerns backward compatibility to a given format.

        As No_Ax likes to point out, maintaining full backward compatibility requires effort. I think from appearances that Microsoft is treating backward compatibility more and more like a separate application, a plug-in, rather than being intrinsic to the operating system or application.

        When you write that...:

        Locking a standard in amber doesn't mean changes can't happen. It just means that people can save to THAT version of the standard and know that any software compliant with that standard will understand it. New software can extend the standard, but SHOULD have an option to save to a certain standard version level.

        ... I assume you don't preclude reading and writing to an antique format by means of a plug-in.



        What you advocate as I understand it now seems less like a revolution than extending a courtesy. Not very costly, and with little or no potential to change the market.

        True?
        Anton Philidor
      • API != all methods

        John, come on the whole idea of OOP is to encapsulate functionality and only give the external user access to controlled methods.

        The problem isn't that MS isn't publishing every method it's that the Windows people create a function and the Office people take advantage of it and it's nowhere to be seen in MS's API documentation for Windows.
        Robert Crocker
  • Illegality of competing software

    MS has never made the claim directly, AFAIK, but the very public claims made by Steve Ballmer that the Linux kernel and sundry other free packages violate unspecified MS patents amounts to the same thing. Indeed, I see the whole "patent everything" policy adopted by MS in recent years as primarily an anticompetitive tactic and as an indication that MS has little or no interest in competing on the merits of their software.

    MS hasn't directly threatened users, but claims that Linux users owe MS money do have that implication. Patent lawsuits against end users are rare, but they are possible (shouldn't be, but that's a debate for another day).
    John L. Ries
    • Daylight

      [i]MS hasn't directly threatened users, but claims that Linux users owe MS money do have that implication. Patent lawsuits against end users are rare, but they are possible (shouldn't be, but that's a debate for another day).[/i]

      Well, not publicly. Apparently there are a number of large end-user corporations who have quietly agreed to pay Microsoft royalties on their use of competing software.

      From Microsoft's point of view, this is the best of both worlds: they raise the cost of competitive offerings while avoiding the downside of publicly suing their own customers.
      Yagotta B. Kidding
      • If that's true

        One would thing that the DOJ and the EU would be very interested.

        I've certainly never heard of this before your post, but it sure would be interesting if true.
        j.m.galvin
        • It is true, of both vendors and customers

          Here's a blog about vendors signing up:

          http://blogs.zdnet.com/microsoft/?p=497

          ... and notice the reference to "direct customer patent covenants".

          Also:

          Microsoft currently collects royalties from some companies that use Linux in their computing environments, Gutierrez said. However, he declined to indicate the number, the dollar amount Microsoft receives from those payments, or identify any of the companies by name.

          http://www.informationweek.com/news/showArticle.jhtml?articleID=199501831

          And how would collecting money or signing agreements not to sue for IP violations be an anti-trust issue.
          Anton Philidor
          • "Agreements"

            Anton asks:

            "And how would collecting money or signing agreements not to sue for IP violations be an anti-trust issue."

            For the same reason that it's a crime for your friendly neighborhood mobster to offer "protection" from crime in exchange for financial consideration. The "covenant not to sue" is a protection racket, plain and simple. The intent is to drive up the effective price of competing software so as to make it less attractive and to insure that everyone pays MS for the purpose of using a personal computer, no matter who's software is loaded on it (that was their business model before that aspect of their "agreements" was invalidated by Judge Stanley Sporkin).

            I've said this before: MS' goals haven't changed; only the means employed to attain them. I think both the ends and the means are self-destructive, as well as damaging to the industry as a whole, but that's my opinion.
            John L. Ries