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."
C++ programming cultists? (Score:5, Informative)
What? (Score:2, Informative)
Old News (Score:5, Informative)
"Believe it or not" ... I'm a not (Score:4, Informative)
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.
Re:Not a total non-story (Score:4, Informative)
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).
Re:C++ programming cultists? (Score:4, Informative)
Because Bjarne Stroustrup's C with Classes language is merely an early version of C++. I mean modern C has evolved quite a bit since that time, and it would be a shame to have to limit yourself to the C language constructs of 1983.
Re:So it works the way Stallman envisioned? (Score:4, Informative)
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).