Paid Developers Power the Linux Kernel 191
Hugh Pickens writes "Believe it or not, there is still this illusion that Linux and open-source software is written by counter-culture, C++ programming cultists living in their parents' basements or huddled together in Cambridge, Mass. group-houses. Now CNet reports that the Linux Foundation has found that 'over 70% of all [Linux] kernel development is demonstrably done by developers who are being paid for their work.' That Linux is primarily developed by paid developers should come as no surprise considering that Linux enables many companies — hardware, software, and online services — to be more competitive in their markets and to find new ways to generate revenue. 'What's important about how Linux and open-source software is created isn't the side issues of politics or how its developers are perceived; it's that its fundamental methodology produces better software,' writes Stephen Vaughan-Nichols."
Re:C++ programming cultists? (Score:2, Interesting)
There is a very small part in C++, how ever Linus got alot of critique for that but none the less committed it.
I'm not surprised (Score:5, Interesting)
My employer uses F/OSS extensively - and as the sysadmin, I've started to notice a pattern.
F/OSS products which scratch an individual or a small group of peoples' itch generally get developed to a certain point and then stagnate. If you're lucky, that point is acceptable to you.
The products that do really well - the "best of F/OSS", if you like - are almost invariably the sort which scratches a very common itch. They're usually bankrolled by a number of companies (the Linux kernel falls under this category) or become self-funding when the project leader sets up a company to sell a commercial version with support and possibly extra features.
Re:Not a total non-story (Score:4, Interesting)
Of course opening the code doesn't make it automatic. But closing it often precludes such change or sophistication: when I have professional access to the software base for commercial packages, I'm often _amazed_ at the boneheaded practices I'd pull a release candidate for on the spot, and make the author go back and rewrite it during our code review meetings.
Re:So it works the way Stallman envisioned? (Score:4, Interesting)
The thing is, those other people have to make any of their own improvements available. Compare and contrast that with the BSDs, where there is no obligation to re-release improvements. Lots of expensive, specialist kit is based around a BSD Unix (eg. F5, Juniper). But BSD doesn't have anything like the mindshare in the generic server market.
Re:C++ programming cultists? (Score:5, Interesting)
Re:Not a total non-story (Score:5, Interesting)
If you're making custom software out of your OSS software, you're doing it wrong.
If you're doing it right, you're submitting your changes back upstream -- so the software doesn't "stand dead-still", as you put it, even on those times when you aren't shoveling man-hours into improvements. If you happen to be curious for some examples, google around for patches under my name submitted to open source projects over the last decade. Just about all of those were paid for by my employers -- from the OS X VNC plugin bugfix to the feature enhancements to libvirt to improved cover page generation for HylaFAX.
For the work I did at Dell, we worked together with Red Hat to get as many of the libvirt and qemu improvements we wanted as possible into the RHEL6 release schedule, enabling some of Dell's internal QA tools to work out-of-the-box with RHEL6 (whereas those same tools required heavy tweaking on RHEL5). Sure, we could have gotten the same thing done as a professional services engagement rather than a friendly collaboration between engineering groups... but this way was far easier, cheaper and lower-paperwork (and by building the patches in-house, we made sure that we got exactly what we wanted).
No surprises in this article for me.
I'm one of those paid kernel developers (Score:5, Interesting)
I've been working as an embedded Linux developer for almost a decade now, and yes, most of us kernel hackers are paid for our work. For example, right now I'm working for a major microchip manufacturer that wants to make sure their products are fully supported by Linux. Consequently, they fund teams of open source developers (often hired through big name consulting firms) to port the kernel to their latest CPU's, develop drivers for integrated peripherals, etc. Just look at the email addresses in the submit logs for major open source projects. You will see ibm.com, intel.com, ti.com, redhat.com, windriver.com ..., and many, many more big commercial technology companies. Its been this way for a while, which is why I would always laugh whenever some MS fanboy would try to denigrate Linux programmers as a bunch of basement dwellers. I make a better than average living from Linux coding, with multiple job offers right now, even in this horrid economy.
This is also why I have no worries about Microsoft ever killing off Linux. There are far too many companies making far too much money from Linux based products in market niches that MS has no traction in. The embedded and mobile markets are pretty much owned by Linux, and those are pretty much the only tech sectors seeing strong growth right now. If you haven't yet added Linux skills to your resume, do it.
If anyone wants to ask me about the Linux / embedded / open source consulting world, go ahead and post your questions. I'll check back and answer if I can.
Re:I'm not surprised (Score:5, Interesting)
One real benefit is that if you are a company developing kernel code and contribute it back you will get goodwill and you will enhance the competence of your employees.
Actually, I've long thought it strange that the business/industrial world has an objection to supporting things like an OS kernel, runtime libraries, etc. The obvious parallel comes to mind: Lost of companies farm out part of their operations to subcontractors. They routinely subcontract for cleaning, delivery, electrical services, for example, not to mention their phone, water and sewage systems. They don't seem to be taken aback by the fact that the companies that supply these services also subcontract to "the competition".
The idea of paying a separate company for software development and supports services is also hardly new. That is how IBM has made much of its money, after all. Paying a company like Red Hat doesn't strike me as very different from any of the above. It doesn't take much management genius to understand that paying a contracting firm for software support at the "system" level is a fairly good idea. That way, you can share the cost with all the other companies that hire the same software firm, and everyone can get the benefits from having the software organized by people who (hopefully ;-) know what they're doing.
So why is this even a story? You'd think there would have been enough sensible businessmen all along for lots of Red Hats to prosper.
A related question is all the propaganda against "open" software. Systems such as water, sewage, electrical, etc. all have "open" designs, with everything published and the detailed specs easily available to anyone. Companies don't often buy fleet vehicles without shop manuals, which give the detailed specs for the innards of the vehicles. Why would people classify open software as "hippie" or "communist", when they don't say the same about shop manuals or electrical diagrams? You'd think that sensible managers who approve of open standards for these other things would also want software that follows published standards (e.g., POSIX), and whose specs (i.e., the source code) is easily available to everyone.
But for some unexplained reason, business people keep buying software systems with hidden, "proprietary" innards. They wouldn't do this with delivery vans or electrical wiring; why would they accept it with software? Exactly the same reasoning says that software should be open, standardized, and accessible to anyone with the technical training. And the same reasoning that supports specialized firms to do common tasks should also support specialized firms for software needs.
It may be yet another example of a theory that keeps popping up: Whenever a computer is introduced anywhere, all precedent is forgotten, and people have to relearn from scratch all the things that they knew from before there were computers. I wonder what it is about computers that causes this social amnesia and inability to see parallel situations?