Microsoft Developer Made the Most Changes To Linux 3.0 Code

sfcrazy sends this quote from the H: "The 343 changes made by Microsoft developer K. Y. Srinivasan put him at the top of a list, created by LWN.net, of developers who made the most changes in the current development cycle for Linux 3.0. Along with a number of other 'change sets,' Microsoft provided a total of 361 changes, putting it in seventh place on the list of companies and groups that contributed code to the Linux kernel. By comparison, independent developers provided 1,085 change sets to Linux 3.0, while Red Hat provided 1,000 and Intel 839."

Comments

The number itself is entertaining but ...

[shutdown -p now]

... it really is useless trivia. What's more important is what the contributions are, specifically. Per TFA:

This work by Microsoft was to clean up the “Microsoft Hyper-V (HV) driver” so that the Microsoft driver would be included in the mainline Linux kernel. Microsoft originally submitted this set of code changes back in July 2009, but there were a lot of problems with it, and the Linux kernel developers insisted that it be fixed. The Linux community had a long list of issues with Microsoft’s code, but the good news is that Microsoft worked to improve the quality of its code so that it could be accepted into the Linux kernel. Other developers helped Microsoft get their code up to par, too. ( Steve Friedl has some comments about its early technical issues.

and why:

Getting code into the mainline Linux kernel release, instead of just existing as a separate patch, is vitally important for an organization if they want people to use their software (if it needs to be part of the Linux kernel, as this did). A counter-example is that the Xen developers let KVM zoom ahead of them, because the Xen developers failed to set a high priority on getting full support for Xen into the mainline Linux kernel. As Thorsten Leemhuis at The H says, “There are many indications that the Xen developers should have put more effort into merging Xen support into the official kernel earlier. After all, while Xen was giving developers and distribution users a hard time with the old kernel, a new virtualisation star was rising on the open source horizon: KVM (Kernel-based Virtual Machine) In the beginning, KVM could not touch the functional scope and speed of Xen. But soon, open source developers, Linux distributors, and companies such as AMD, Intel and IBM became interested in KVM and contributed a number of improvements, so that KVM quickly caught up and even moved past Xen in some respects.” Xen may do well in the future, but this is still a cautionary tale.

Re:The number itself is entertaining but ...

[Sc4Freak]

So? A contribution is a contribution, even if it is for selfish reasons.

Re:The number itself is entertaining but ...

[shutdown -p now]

I did not imply otherwise. My point is that the contribution and its nature are of more importance than the associated random statistical fluke.

Re:The number itself is entertaining but ...

[shutdown -p now]

You want to expose host's hardware to the guest with as few layers in between as possible. Traditional emulation is rather slow, so instead you set up a fast channel that exposes exactly what is needed in a most efficient way, and write drivers for the guest which use that to work with hardware.

I believe this is also true for scheduling - if host and guest cooperate (which necessarily requires special code running in guest's kernel), they can do much better at it.

Re:The number itself is entertaining but ...

[wrook]

Even more importantly, contributing for selfish reasons creates a win-win situation. Contributing in a way that is detrimental to you, is detrimental for the community. It is important for people and organisations to realise that we want them to succeed in their enterprises.

I think a lot of people misunderstand the driving forces behind free and open source software. They see it as some kind of charity where the group "donating" code is losing out. Instead, groups should understand how they are going to benefit from contributing to a free software project before they do so. Benefit can come in the form of money, it can come in the form of eyeballs (attracting attention to an under serviced area), or it can simply come from the pleasure of contributing. These are all benefits.

Free and open source software allows more than one group to benefit from contributing to a project. You can't control how much benefit another group can get from a project, but the more you do to tie your success to the success of the project, the more you benefit you get from other people's contributions. Ideally, we want companies like MS to make money from the success of free software. The more they do so, the more they will understand the opportunities they are missing. The more they rely on our success, the more everyone benefits.

Re:The number itself is entertaining but ...

[staalmannen]

The whole point (which Linus often stresses) is that open source is all about "scratching your own itch". This means that all contributions are self-serving. I am actually quite surprised that Apple has not tried to push patches to Linux for kernel GCD support yet. That would also have been a self-serving improvement since they want to push the standards of C in that direction.

Re:Community Myth

[Anonymous Coward]

I wish people would get over this myth that "could care less" means that you couldn't care less.

Not Microsoft...

[Anonymous Coward]

He has only been part of Microsoft since february 2011. Until then, he was part of Novel.

This... is stupid.

[Anonymous Coward]

Perhaps they couldn't care less (note the correct usage), what does that matter? So long as they contribute valid code, in compliance with licensing, that addresses a need, I don't care *who* contributes. Hell: Hans, from his jail cell, can contribute, for all of me. If it makes Linux better, and it's not some patent landmine, IJustDon'tGiveADamn.

As for user-driven innovation, yes, it is. For two reasons:

- Solo users still do contribute. Check the numbers.
- Solo users who manage to work for large companies does not mean they still don't adhere to the spirit.

So neener.

Re:changes != LoC

[scromp]

Describing LoC as a "not perfect" metric is an astonishing understatement.

Re:changes != LoC

[maugle]

Describing LoC as a "not perfect" metric is an astonishing understatement.

I
disagree,
using
LoC
as
a
metric
has
made
my
measured
productivity
skyrocket!

Re:Community Myth

[fnj]

No, it's called illiteracy.

Re:Yes let's just get down and dirty in the code

[Bert64]

Interestingly, windows boots a lot faster inside of a vm running on linux than it does on the hative hardware (seriously, give it a try)...
If going the other way round, linux runs somewhat slower inside of a vm running on windows... The performance penalty when running in a vm on linux is much smaller.