Who Wrote, and Paid For, 2.6.20

Corbet writes "LWN.net did some data mining through the kernel source repository and put together an analysis of where the patches came from. It turns out that most kernel code is contributed by people paid to do the work — but the list of companies sponsoring kernel development has a surprise or two." The article's conclusion: "The end result of all this is that a number of the widely-expressed opinions about kernel development turn out to be true. There really are thousands of developers — at least, almost 2,000 who put in at least one patch over the course of the last year. Linus Torvalds is directly responsible for a very small portion of the code which makes it into the kernel. Contemporary kernel development is spread out among a broad group of people, most of whom are paid for the work they do. Overall, the picture is of a broad-based and well-supported development community."

Project Maintainers don't write much code...

[jZnat]

At this point, Linus is the head maintainer of Linux 2.6 [kernel.org], so the majority of the work he does is accepting patches, arguing in the mailing lists [lkml.org], and talking with the other main programmers and "sub-maintainers" (I don't know if they get a special name or anything).

He doesn't need to write code for the kernel to be important at this point. Besides, he contributes code to other things like git (an SCM) [kernel.org] and GNOME [linux.com].

Re:Define "volunteer."

[Anonymous Coward]

They mean "volunteer" in the sense that's completely obvious from the context, not in any sense derived from Pointless Nerd Hairsplitting.

Re:oh noes....

[__aaclcg7560]

IIRC, ftape was for implementing some of the older tape drives. I had a hell of time trying to get a tape drive running under Linux 10 years ago. I think the maximum tape size for that drive was 40MB. Never did get it to work reliably. Back then, you pretty much had to roll your own kernel for everything.

Re:Interesting how much was conributed by paid dev

[morgan_greywolf]

RedHat, Novell and IBM all have dedicated staffs that do nothing but work on the Linux kernel. These are the only companies I know of for sure, but they are also at the top of those contributor lists.

uni

[Anonymous Coward]

dont forget about the university students who submit patches as part of their CS studies.

Re:Fairly Interesting Overview

[HomelessInLaJolla]

I didn't realise how much of the code was contributed by companies

Reading the changelogs, and the files in the source Documentation directory, on a semi-regular basis provides enlightening insight into the diversity and number of people who regularly make contributions to the Linux kernel. It truly is a sign of the success of GNU/FSF mindset.

I was fairly suprised to see broadcom had donated so much code

Many companies have different motivations for donating code. Sometimes a company may donate alpha code in the interest of testing its applicability and integratability. Sometimes a company may donate old code in order to appease a market which sufficiently supports profit margin, indirectly, through use and advertising. Sometimes a company may even donate commercial code for PR or because the open source community holds the largest population percentage of people who will likely work with it.

Corporations are not all bad and neither are they all good. Every move is carefully planned and executed based upon a number of considerations--some of which may even be at odds against each other. Knowing how to appeal to the greatest number of consumers in the greatest number of market sectors is usually a sign of a company which is agile and successful.

Re:Define "volunteer."

[CodeBuster]

Most people donate, volenteer for something because they know it will benifit them in the end

This is what economists call utility [wikipedia.org] whereby actions that result in no clear economic gain for those giving of their resources are explained in that they increase the giver's amount of utility. This is really just a fancy way of saying that people give of their resources (up to a point), despite the fact that they do not directly benefit, because it makes them happy or they derive enjoyment equal to the value of the resources given away in return.

This doesn't mean that its any less noble in the end.

That is a subjective opinion, but most people would look more favorably upon truly selfless giving rather than giving in an attempt to get *something* in return whether that be public approval, loyalty, or future expectation of favor(s).

Re:GPL vs. BSD

[Anonymous Coward]

So they will gladly take any change anybody makes to the application under GPL, but they will license that bunch of code out to anybody who pays *them*. The people who extend and improve MySQL with GPL code don't see a dime, while MySQL makes a nice profit.

This is not strictly true. It would be a violation of copyright law for TrollTech or MySQL AB to take GPL code written by other people and release it under a different license without permission. Therefore, they can't "gladly take any change anyone makes". The law doesn't permit it.

I don't know how Trolltech handle this, but MySQL AB only takes changes where the contributor has specifically, deliberately, explictly, and knowingly signed over their copyright to the company with the deliberate goal of permitting them to profit from it.

Don't like it? You can make any change you like to the program under the GPL, and not sign away your rights - and the company can't touch your changes.

IMHO that isn't really the coolest behavior, which is why I avoid Qt and MySQL.

Well, it's your loss if your ignorance is leading you to mistakenly avoid some decent software.

(Unless you actually take the position that people shouldn't be allowed to knowingly and deliberately choose to sign away their copyright - in which case you might like to give some thought to the meaning of the word "freedom".)

Re:Secretlab?

[gcl]

Hehehe. No, we do embedded Linux projects. Nothing specifically security related.

Regarding ftape

[k8to]

At least I hope it didn't get removed just because the driver was "old" and "buggy"...

It got removed because it was old, buggy, and no one cared. Quite a number of kernel releases went by (6 I believe?) during which ftape never worked. No one wrote in to say this mattered. No one stepped up to fix the subsystem. The users (you included) apparently were completely silent on the matter.

Granted you might not have installed a new linux kernel in the past 6 months (or more?), or might not have actually used your tape writer in the same interval, so might not have been a position to notice the situation. But the fact that no one cared enough to raise the issue spoke volumes. And so it was axed.

I'm sure if someone steps up to the plate and says "I want to forward port the ftapd driver to the current kernel release and continue to maintain it" and provides patches, that they will be accepted. If that hardware is truly valuable to you, please do seek to let the world know.

Most ftape devices are not useful to most people by now, because they are too slow, too unreliable, and too small capacity. Other larger faster formats have become available, and alternatives to tape have become available such that the aging ftape devices are not interesting to most people. Add to this that tape isn't a very good archival format and you quickly see the dwindling market for such devices. But the 2.4 kernel is still maintained. Ftape works there, I believe, so you can continue to back up your data with Linux.

Re:The analysis is broken

[turpie]

That's what the Signed Off tags are for. So that they can tell who actually wrote the patch and who reviewed it and passed it upstream.

Re:Define "volunteer."

[Anonymous Coward]

There in lies the crux of state communism. People can opt out of opensource development if they want to. Under state communism, you are assigned to build a tractor/car/grow wheat, and if you don't like it tough.

People really don't like being forced to cooperate, and with opensource (and small opt-in communes/religous monasteries), they aren't.

Re:The analysis is broken

[bfields]

"These are only the submitters, not necessarily the actual authors of the changes." No, he looked at *both*. And reviewing patches, providing feedback, resolving conflicts, deciding what's ready when, etc., is difficult and valuable work.