Paid Developers Power the Linux Kernel
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."
It's written in C, not C++.
The Linux kernel is written in C, not C++. And haven't there been a number of articles on how IBM, RedHat, Sun etc all have employees who develop Linux? One post in particular... and I know there have been others.
Do even the editors read anymore?
That's not to say some individuals with long hair and others with low personal hygiene standards haven't done their bit, but those attributes don't make you counter-culture.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
If they aren't interested in that, how do you explain all of the companies that pay programmers to work on Open Source?
Most (if not all) of those companies already had programmers on staff to write custom software for the company. They discovered that it was easier and cheaper (and often better) to modify Open Source Software than it was to write their own application from scratch (or to buy such an application from some proprietary vendor).
The truth is that all men having power ought to be mistrusted. James Madison
Typically it's "bankrolling" by assigning some of your people to spend some of their time on making improvements you happen to need and contributing them upstream.
(Contributing improvements upstream means that you won't need to continually maintain your patches, that they'll eventually be included in vendor packages/kernels and thus that you'll later need to do less packaging yourself, and is otherwise a money-saving action. As a somewhat-related aside -- once upon a time I worked in embedded Linux, and you had companies who structured their default contracts for kernel work such that everything was submitted upstream, making each contract effectively a one-time engagement when everything was done right, and others who didn't... ehh... encourage their clients to pursue submitting their code, such that said clients would keep paying in to keep their patch current with newer upstream kernels).