Microsoft Open Source, Standards Chiefs Tout 'Openness'Microsoft Open Source, Standards Chiefs Tout 'Openness'

Microsoft as of late has been championing what it says is the cause of openness. From releasing gobs of protocol documentation and using open source in a management product to increasingly speaking at open source conventions and signing patent cross-licensing deals with other software vendors, the company has plenty of moves to point toward. Customers, competitors and critics meanwhile remain skeptical.

In preparation for the magazine's May 19 lead feature story on whether Microsoft is indeed becoming a more open company, information interviewed two Microsoft executives key to the company's understanding of the open source business models and community as well as interoperability and industry standards.

information: How do you approach people to work out cross-licensing or interoperability deals between Microsoft and the open source community? Take your recent deal with the Samba folks, for example.

Sam Ramji, senior director of platform strategy for Microsoft: About a year ago, I began talking with Jeremy Allison and the Samba team. I attended the SambaXP Conference in Goettingen, Germany in late April (Microsoft went there again this year). Sitting down and having frank, engineer to engineer conversations around the table about what their goals were, what kind of information they'd like to get, what kind of things they'd like to see from Microsoft led us as a company to see that we can have these conversations, we can take down these lists of requests, we can go back and then deliver on those lists. Specifically with the Samba team that list ranged from MSDN licenses for some of their unpaid developers who needed development tools all the way to sending their engineers to their CIFS Conference at Google in September of 2007.

As we delivered on those different requests that they had, they saw that we were present in the conversation, we were good for our commitments, and that let us have another conversation with them in October about what a form of the trade secret copyright agreement would look like for the protocols they were interested in that would really work for their developers and their development model. Fundamentally, the technical engineering conversations are where all of these things start, whether you're looking at Java or PHP or Samba or Linux or MySQL. The difference between the technologists sitting around the table is actually not very big. We all care about the same things: we want users to get great software, we want the software to work well together.

information: How much of this recent public push towards "openness" is about the realities of the Web and of the emergence of open source as a viable model versus something else? The people that you need to convince, they're going to be skeptical.

Tom Robertson, Microsoft's general manager of standards and interoperability: The company's been looking at the issue of interoperability for a long time, and I think over the last three-plus years, the effort has really redoubled because there's a sense of a changing marketplace. More and more customers are saying, 'We've got heterogeneous systems and we expect vendors to work together, regardless of their business model or how the development of their software took place.' We have people who have an always on, always connected expectation and they want to make sure that their software, their systems, the components of their systems work well together, and that their systems work well with or communicate with other systems that are out on the Web or the lines. Our customers are telling us that they want us to look at this issue more and focus our efforts across the company in an expanded way. Regulators are also interested in this.

Ramji: I think that frame is really helpful in how we look at the market, and there are two dimensions. There is the dimension of interoperability, which I think comes based on recognizing that there are a lot of other technologies out there that we really need to work well with. The other dimension is open source, where we've gotten a much more sophisticated understanding of what open source is. It can mean a development model, a sales and marketing model, a licensing model, a collaboration model; it can also get into conversations about what is open participation. There's a lot of open source outreach to run open source on Windows. We can be specific and concrete about where we compete with specific technologies offered by commercial organizations like Red Hat's Enterprise Linux or like Novell's SUSE Linux Enterprise Server.

It is that specification, which is a distinction we now have, that we understand very clearly where do we work and collaborate for compatibility so you've got open source applications running on top of Windows and where do we work to collaborate to get interoperability to have system A and system B talking well to one another when one is Windows and one is Linux. information: Does this openness initiative need some sort of formal structure in order for it to be successful?

Robertson: I'd say that there is, in fact, a formal structure in a few dimensions. There's a cross-group team, Sam's team and many others throughout the company, like me and others, who come together and think about interoperability spanning the entire company. [Microsoft senior VP] Bob Muglia is the executive leader for this effort.

information: Are there certain prescriptions for how Microsoft should approach standards?

Robertson: There are no prescriptive rules on how to approach standards as a company. I think that as a result of our implementations of the Open Interoperability Principles, which includes a principle on open standards, we will have much greater transparency in how we make decisions about which standards to implement in these high volume products, how we implement those standards, how we create extensions to those standards, and then how we work with other major contributors to those standards to achieve interoperability in fact in the marketplace. All of this, the greater transparency into how we implement them, the collaboration with other implementers, I think will deepen our understanding and thinking on when and how to support particular standards in these products. You may well see more refined practices evolve out of that, but that remains to be seen.

information: How do you convince people that Microsoft is no longer just creating de facto standards over time? That's an argument that you've had to make over and over again as recently as Open XML.

Robertson: I would actually say that Open XML is an example of how we're embracing the standards process. Certainly, the opponents of Open XML would have you look at this as somehow proprietary, but in fact, just the opposite is true. ECMA now owns Open XML. It is responsible for the evolution of that standard. When ISO ratifies it, the global community will be in ownership of the evolution of that standard. We've made clear that anyone can use any and all patents we have that are needed to implement all or part of this specification anywhere in the world without any contact, without any payment of royalties or any formalities. We have expended a tremendous amount of effort in supporting standardization in ECMA and supporting ratification in ISO. If that's not embracing the international standards system, then I don't know what is.

Ramji: The other thing that I find that many people are not aware of and that I'd like to focus on for a moment is, that the process of technology development starts with a specification. It proceeds to implementation, maybe multiple implementations, and as the implementers figure out what works and doesn't work, and continues to debug the specification, then maybe it becomes something you want to formalize as a large-scale standard in a body like the IETF or the WC3, etcetera, but the vast majority of software is based on specifications.

There is a lifecycle of specifications and standards. Not all specifications will become standards, but the core that we have to care about is that there's a specification, that we all can read it, we can understand it, we can talk about it, that we can write implementations of that and test their compatibility against each other so that we can get the interoperability we're looking for. That's a common engineering rule, regardless of whether you publish the source or don't publish the source.

information: Are there certain thoughts about, here are the things we develop in an open source model versus a shared source model versus keeping it all proprietary?

Ramji: There are things that are really easy, because Microsoft built its business in the '90's on open APIs, and publishing SDKs, and publishing device drivers, and one of the reasons that I was personally attracted to the platform as a developer was that I could see everything I needed, I could understand the error codes and I could write the software that I needed to get done for the ISVs that I worked in.

When you look at what's happened in the SDK, part of the value at the time for developers was, 'Hey, it just works and I understand how to interact with it.' Now, sample kits, codes that work against the SDK or the SDK itself is a great place to open the source code so that people can do more robust debugging, they can take ownership of it, they can modify it. In general, that's a great place to start.

When we look at our Solution Accelerators, our patterns and practices, ways to build higher-level functionality on top of the Microsoft stack, we find that there's a pretty rich environment. On CodePlex if you look at the patterns and practices team, it developed a lot of very powerful functionality, for example the enterprise library, and other horizontal and vertical building blocks of larger solutions. There's no arbitrary limit, so I don't want to set your mind in thinking that there are places we are excluding. We've taken entire products like [e-learning suite] Class Server into a Shared Source model, and we've started to move the boundary of transparency for that entire product.

information: The EU's top anti-trust representative has said that the release of thousands of pages of protocol documentation doesn't necessarily equate to a change in business practices. Why should I look at that release as part of something larger, rather than a one-off result of regulator demands?

Robertson: It is in fact part of the changing business practices. Just look at the protocols. The first release of protocol specifications relates to client-server protocols and workgroup-server protocols. The commitment made in the interoperability principles has to do with six high volume products that go beyond Windows Client, Windows Server to SharePoint, SQL, Exchange, and Office. Microsoft's step here was to make available documentation that was previously available only under a license and through the payment of a royalty. Now, we have a situation where all of the information and all of the specification documentation is available for anyone with a browser without any need to sign a license or payment of a royalty. That's a huge step. We also committed to developing a patent map on each of the protocols so that people who want that documentation can see exactly where we have technology, and we've committed to making that available on very low royalty rate. Of course, we've extended the pledge not to assert patents against open source development in non-commercial distributions. This is just one of the principles.

Ramji: One really important point that I wasn't able to respond to, but I will just briefly now, is the distinction between popular perception and the reactions of the leaders of various open source communities. In the personal, one on one interactions I've had with the leaders of various communities, including Apache, Mozilla, PHP, and Linux, the leadership conversations say wow, this is significant, this is really good news, I'm optimistic. Where the patent discussion has come up, people have said we can agree to disagree about how intellectual property gets run in software but the transparency that you're offering is commendable, and that's a significant step forward. My personal day-to-day experience is significantly more positive than what I have observed in some of the trade publications.

information: If I call Red Hat, will I get that response?

Ramji: If you talk to a commercial competitor, you're not talking about a community, you're talking about a commercial agenda, and a specific marketing differentiation approach and a whole messaging plan. When you talk to community leaders, you are typically talking to dedicated technologists who care that working, great technology gets built. I think that that's where there's a real distinction in the interaction.

information: So how do you address the "distinction between popular perception and the reactions of leaders of open source communities," as Sam put it? How do you go about changing the minds of those who think Microsoft will always be about 'embrace, extend, extinguish'?

Robertson: Changing perceptions of Microsoft requires being clear as to what we are trying to achieve and how we are going about it, and then delivering results. We have stepped up our activities over the past few years on interoperability and with the Interoperability Principles are taking an even bolder approach. We appreciate that there are skeptics, and know that delivering what we have set out to do is the best way to change minds.

information: I'd like to give Microsoft a chance to respond to something an IBM exec told me: "Microsoft never seems to talk about how people can use Microsoft's protocols and formats to connect arbitrary software together, it's always about using the protocols and formats to talk to Microsoft products. To be more believable about being open, they'll have to transcend this both linguistically as well as in practice." This IBM exec said that Microsoft is really talking about "intraoperability," not interoperability.

Robertson: The steps we're taking will promote interoperability across the board. We've heard from the community that their primary interest is in ensuring that they have the ability to interoperate with popular Microsoft products in the same way that other Microsoft products do. We're addressing that interest through the Interoperability Principles. But we are doing more. We're providing free access to information about how we work with protocols, formats and standards that may help guide how others address similar challenges. We're working through the Document Interoperability Initiative to achieve interoperability between implementations of popular document formats, and we'll work with other major implementers of the standards we support in our high volume products to achieve interoperability between our respective implementations.

information: Does Microsoft need to make its specs explicitly usable with the GPL? Why or why not?

Robertson: We think that our Open Specification Promise is consistent with how others have addressed the royalty free use of patents needed to implement specifications, including IBM. It should give all developers the comfort they want to work with covered specifications.

With respect to the compatibility with the GPL, as far as we're concerned we are happy that the OSP applies to implementers who distribute their code under any copyright license including the GPL. The GPL is a copyright license that is drafted in a way that leaves many issues, not just those related to patent rights, open to many interpretations. Any particular user or implementer should read the GPL carefully and make their own judgment about what it means and requires in accordance with their own circumstances.