We are considering changing the name of the Foundation due the confusion, but we haven't decided yet. We will leave the decision to the next Board of Directors.

If you read the article you will see that I am not at Microsoft any more. I left in September to join a new company in Silicon Valley (you can see it here: http://sonoasystems.com/ and our service at http://apigee.com./ The company's product is a Linux-based cloud services controller.

While at Microsoft I focused on promoting open source, and on building interoperability technologies between Windows and Linux, as well as Eclipse and Firefox support and integration.

My work at the CodePlex Foundation is on a volunteer/pro bono basis. To get a better sense of what we are trying to do you may want to consider that our directors and advisors include Monty Widenius, Miguel de Icaza, Stuart Cohen, Larry Augustin, Bob Gobeille, William Rowe and others whose careers demonstrate a strong commitment to open source.

Correct; these drivers were not originally built according to the kernel coding standards. At the time that was not a requirement.

The incredibly cool thing is that kernel community developers submitted over 200 patches to the code. The team (Hank Janssen, Haiyang Zhang, and Hashir Abdi and a small test team) have spent their time integrating and testing the results to ensure that there were no regressions. As an example, the team spent roughly three weeks tracking down a crashing issue in the kernel that turned out to be fixed in the 2.6.31-rc8 release. For a first release and integration with the kernel I am happy with the results, and appreciate the work that Greg KH has put in to accept the changes and educate us on both process and coding style.

With the regressions resolved and testing complete from this initial integration phase, the team is back to dealing with net new issues as well as adding features according to the customer roadmap. One of the top requests we've had is to add SMP (symmetric multiprocessing) support, so that is on the immediate term development list. This is a dedicated, long-term team that is still learning the cadence of kernel development and communication.

Cheers,

Sam
sramji@microsoft.com

This is the only post so far that seems to have gotten it right.

We've done this pragmatically, have identified the reasons in detail, and have nothing to hide. We believe that of the range of open source licensing options for this code, the GPLv2 was the right one. Our decision was not based on any perceived obligations tied to the GPLv2 license.

This was a project we began in October of last year, and which we have been working on ever since.

Our diligent adherence to the standards of the Linux kernel community, including the license used, the process, and the changes we are now seeing we need to make to the coding style of the source code, are driven by our goal of having the code accepted into the kernel. This will make it far easier for any developer who wants to modify their distribution to run on Hyper-V, for solutions providers to modify and support these features, and for customers to obtain Hyper-V support for their Linux distribution of choice. We have been endorsed by both Greg K-H and Jim Zemlin for the approach we've taken, and we believe that this process will be good for Hyper-V's capabilities and customer adoption.

Sam
sramji@microsoft.com

It was specifically talked about. We considered other licenses (like the Clear BSD) which is considered "GPL-compatible" but the best choice was clearly the GPLv2.

This was the gentle advice we got from Greg K-H and we took it seriously. The more we thought about it, the more it made sense to follow Rosen's first law of open source licenses - "use the license of the community that you want to contribute to."

Sam
sramji@microsoft.com

First, the Hyper-V high-level specification is available under the Open Specification Promise; this can be used by 3rd parties to implement Hyper-V compatibility.

Second, we have a roadmap for the drivers that includes improvements to performance and manageability, including features like SMP support. These have been requested by our customers and are part of the engineering plan for these drivers.

Third, our maintenance plan for the drivers includes submitting patches to the kernel maintainers; and the process that Greg K-H and the team follow is designed to ensure that drivers can continue to be compatible with the kernel even if the kernel's model for device drivers changes.

Ultimately it will be the market success of this technology that will ensure its ongoing development by Microsoft - as we do with any product. So far the signs are good.

Sam
sramji@microsoft.com

You are really funny! Actually, I'm the head of Open Source and Linux Strategy for Microsoft Corporation. I'm from Oakland, California.

Sam
sramji@microsoft.com

Our use of the GPLv2 license, as requested by the Linux community, means we will not charge a royalty or assert any patents covering the driver code we are contributing.

Sam
sramji@microsoft.com

We do work with Novell on running Windows Server on Novell SUSE Linux (Xen), as well as Novell SUSE Linux on Microsoft Hyper-V. This work is done by a dedicated engineering and testing staff working for me both in Redmond, WA and in Cambridge, MA. We do joint engineering, low-level white-box testing, and hardware validation and support proof-of-concept work. This lab also does Windows-Samba compatibility testing in concert with Novell and the Samba team.

Cheers,

Sam Ramji
mailto:sramji@microsoft.com

It may be appropriate to reassess what you consider "Microsoft management". I am Microsoft management, and I established the current strategy and approach for engaging with Samba based on discussions with Jeremy Allison, Andrew Tridgell, and team in early 2007. That's why we've been able to get the engineers connected directly.

For more context you can review here: If you're surprised, you're not paying attention.

Sam Ramji
Sr. Director, Platform Strategy
Microsoft Corporation