Slashdot Mirror
Myth of Linux Hobby Coders Exposed
Eh-Wire writes "Stuart Cohen, CEO of the Open Source Development Labs, does a short piece on the myth of renegade hackers coding in their parent's basements to create the Linux OS. He suggests this hasn't been the case for many years and goes on to claim that of the top 25 core developers, more than 90% of them are fully employed with some of the largest technology companies in the world. Stuart goes on to explode the myth of renegade programmers by saying, 'Sure, it represents a new way to create software, but the actual process looks a lot like how enterprise software has been made for decades.' A short but interesting read."
This 'new finding' was fabricated by choosing the Top 25 Linux Developers (because 25 is the magic number that fits the results they want.)
Truth is, there are hundreds of major, active kernel developers.
you can either get a waiver added to the contract, or just let the evil bastards try to claim ownership, the clause will be found unfair, they cannot claim they own every thought in your head, especially when the only company resource it involves is you, in exactly the same way non compete clauses have no legal power, no matter what you sign.
of the top 25 core developers, more than 90% of them are fully employed
...people that are fully employed usually have more time than those that do it in their spare time.
If the linux team consisted of 25 full-time employees and 10000 volunteers, I'd expect the full-time employees to take the top 25. Doh.
I'm not quite sure what the story here is. Is it that there are any at all, or is it suggesting that most of the linux developers are like that?
Besides, on the whole "how is it organized part", the GPL is a software license, not a development license. If you want to run your code tree like a cathedral, you can. It's simply a matter of what is most efficient, just like for businesses.
Still, I don't see the real news here. Full-time employees do more than volunteers? Huge projects need a review process and managers, both OSS and not? The important part is still what sets them apart, not the similarities. In my opinion, at least.
Kjella
Live today, because you never know what tomorrow brings
They probably did the same thing myself, my friend, and most of the open source coders I know did:
Refuse to sign it.
Just politely explain that that particular clause doesn't work for you, as you do a lot of programming at home for projects unrelated to their business and you want to continue to do so as you feel it helps to hone your programming skills. They will likely agree to strike out the clause. Yes, if you're just starting a new job and the job market is bad, it takes some cajones to do this. But realistically the chances are extremely low they'll simply say, "Oh, okay. Goodbye." and, presuming that they do say that, and you respond by offering to sign the damn waiver, the chances are even lower that they would continue to refuse to employ you. And at that point you can be very sure that they were just planning on using you as a carpet anyway, if the fact that you showed a bit of backbone scares them so much. Realistically, all most companies want is an employee who knows their stuff and works hard.
As a bonus, when you do this, you will likely be remembered as someone who stands up for themselves a bit more. As a result, you're more likely to get better raises and bonuses, simply due to the fact that the bosses don't really want to get into arguments or make a big deal about things most of the time (after all, their time is so valuable *cough*) so they'll give you a little more than most of the other people, since they'll think of you as someone who's more likely to argue about it.
That's been my experience anyway.
Random and weird software I've written.
a) Their copyright.
b) The company's permission to release it under an OSS license on their behalf.
You can have the latter, without having the former. That'd mean the company would be able to make a commercial product with the code, relicense the code, and the coder would not. But if released in a proper fashion, the license is still valid. And he, the person, could make a derivative of what he, the employee, has written under that license.
The only time there could be a problem is if the company has claim to the IP and has not been aware of its use (possibly because the coder thought they had no claim). But these are employed to work on the kernel, and are perfectly aware of it being licensed out.
In short, the only difference is whether the code has any commercial value on its own. If it doesn't make sense except for the specific task in the kernel, it doesn't really matter. The rest is about who can use it in other projects. I'd be more than happy to write OSS code "for hire".
Kjella
Live today, because you never know what tomorrow brings
This goes to show how the metaphors in ESR's The Cathedral and the Bazaar often are not useful in describing software. I know of no software project that can be described as having a 'Bazaar' model, except for projects that consist largely of disconnected components such as CPAN or collections of drivers for OSs (including Linux), but I think these are special cases.
A more apt description is 'Open Cathedral', in my opinion.
Wikipedia is also like a 'Bazaar', but that also falls under the concept of many parts that are not precisely interconnected.
...on the myth of renegade hackers coding in their parent's basements to create the Linux OS. He suggests this hasn't been the case for many years and goes on to claim that of the top 25 core developers, more than 90% of them are fully employed with some of the largest technology companies in the world.
Just because they're fully employed by some of the largest tech companies doesn't mean they don't live in their parent's basements and telecommute.
Set A can always include Set B.
It's like saying that since the wealthiest people in the world are tech geeks, and wealthy people get hot babes, that tech geeks have hot babes.
Perhaps most tech geeks - even those who are wealthy - don't have hot babes (or hunks, whatever) - but most wealthy people (of which tech geeks are a very wealthy subset) do have hot babes/hunks?
Therefore, it's totally possible for them to live in very fancy basements in their parents homes and still be fully employed by big tech firms.
And maybe a few actually own their own homes, but who knows, because the statistics are flawed by virtue of the premise as stated.
Think of it as a Venn diagram in action. Just because top models hang with some economists doesn't make economists party animals and opposite-gender magnets.
-- Tigger warning: This post may contain tiggers! --
WHT are you talking about?, first of all, comunism is a political and economic system, just like your stinking capitalism. Whether you like it or not, it's far more fair than capitalism. Yes, communism has failed just like capitalism, but at least communism is designed to triunf, and with the people in mind. Capitalism is designed to make the rich profit more, so they both failed (actually the human being failed), but capitalism is esentially evil, and communism is esentially utopic. If you choose communism, you may fail because the human being is esentially corruptable and egoist. If you choose capitalism, you will fail because the system is designed to make the richs richer and more powerfull and the poor poorer and defenseless.
About RMS, what are you talking about?, all he owns is his laptop, a few books, no more than 3 t-shirts, and his incredible brain. His life is GNU and the FSF; and is the most honest and generous guy i have ever met.
You should be ashame of yourself for talking about him like this, taking into account all that he has done for you and for me.
WTF am I doing replying to an AC at 5 A.M on a Friday night?
If you get a 2.6 kernel from a distro, they've already applied all sorts of patches to fix bugs like this one. I'm talking only about the stock kernels that are released by Linus et al. And I should not have any mutually exclusive features turned on because I did "make defconfig", which is supposed to be a tested, standardized configuration.
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
How many of those who work for large companies as a "day job" are actually hired to work on the Linux kernel as their "day job"?
How many of them don't work for IBM or some other company that have a huge vested interest in the Linux kernel (SuSE/Novell, RedHat, etc)
How many of these people work on non-OSS for a day job and basically are subsidising OSS through non-OSS work?
If any work for non-OSS companies, how many of those companies know that this is going on?
If any work for non-OSS companies, how many can actually be working in a conflict of interest situation?
My theory has always been that few people actually work and make a living doing OSS. Most work for non-OSS/commercial/proprietary companies and are basically subsidized by these companies. Also, if these people aren't already independently wealthy, they wouldn't be able to feed themselves or their families by their work in OSS.
GPL doesn't apply to something you don't have the right to contribute, so that's not going to work. And if you do release company IP under GPL, they can sue you into the stone age and they'll win.
Second, it's easy to write in exceptions to those contracts. The last one I signed even had a place for you to list previously existing projects that were yours, not the company's. I wrote in "Debian GNU/Linux",
That's they way. Actually, in some states, companies can't claim things you develop on your own time that aren't related to your work. Any stipulation in a contract is invalid. California I believe works that way.
GPL doesn't apply to something you don't have the right to contribute
Yes, of course, but the company doesn't have any other options. They can agree to allow it to be GPL'd, or they can discard it. It's tainted by being a derivative work, so there is no third option. (Well, they could use it internally, but that's not a very exciting choice, unless they actually use the original, unmodified software, in which case, they're probably motivated to release their enhancements under the GPL).
(Note: I am of course, assuming that we're talking about the very common case of a contribution to an existing project. If you create a whole huge public project on your own when your employment contract forbids it, then you're just insanely stupid.)
Anyway, I was mainly trying to point out that you're unlikely to hurt the project by such actions. I agree with you that I may have underemphasised just how badly you can hurt yourself through such actions.
Ah so what your saying is PHBs should relax because a lot of GNU/Linux was written by pot smoking hippies at a good American University.
As compared to professional operating systems based on BSD Unix written by a bunch of pot smoking hippies at a good American University, with some help from a couple of guys at Bell Labs.
There are only two distinct types of code people need to worry about, code written by humans (unpredictable bugs), and code written by machines (predictable bugs). You start worrying too much about what sort of human wrote your code misses the point.
Most people use computers whose source code review, and release management is so strict an entire flight simulator can make it's way into a business product with no one noticing. If we are going to discuss professionalism in software authorship lets start with the software that exhibits the most problems, we might learn more.
You're looking at the wrong part of the system. You're criticising the product based on internal development snapshots, and criticising the release process due to confusing product releases with kernel-developer releases, which are roughly equivalent to the code that would be sent between groups within an enterprise product development team. That's an easy mistake due the public nature of the engineering process.
The vanilla 2.6.0 kernel (vanilla meaning the one from kernel.org) is not intended to mean that the kernel has reached a threshold of quality that you'd compare with a commercially released software product.
It is a quality milestone of sorts, but the main purpose of 2.6.0 was to say "right, this is the point at which we commit to the feature set and are moderately happy to begin tidying the implementation".
In other words, Linux 2.6.0 is comparable with somewhere just before alpha quality release from a QA standpoint. It's not intended for public consumption; it's not considered "ready for beta testers" at that point.
However, so many people took it that way, which is why now we have these silly "sub-point-point" releases: 2.6.11.1, 2.6.11.2, 2.6.11-rc3, 2.6.11-rc3-bk2-aa1 etc. just to make absolutely clear that there are staged releases, which developers need due to the distributed process, but which are not considered ready for widespread testing. We're seeing longer and longer sub-point release cycles, just because there are more people involved who treat the numbers as comparable with classic software product versions. That's fine for some people, but for secondary kernel developers it's a pain.
Linux has a multi-level QA system. The one which corresponds to a "Release" that you mean in an enterprise product is called a "Vendor Kernel" in Linux terminology. You should understand that QA is a very large part of the process of producing a "Vendor Kernel".
In other words, you're looking in the wrong part of the system, and it's an easy mistake because the development process is so welcoming to public participation. For enterprise software style QA, look at the place in the system where that's done: the distributions.
(That's another way the terminology is different. A "distribution" in Linux means something very different from a "distributor" in the enterprise software sense. The larger "Distribution" vendors perform a lot of QA work and also significant development - they are roughly analogous to your enterprise QA, Testing and Release Management teams. "Distributors" typically just sell stuff and provide after-sales support.)
-- Jamie
No, there are no other C compilers that can compile Linux correctly, they just won't work, only GCC.
And. it also needs a build environment that is usualy GNU.
And, besides, the project that created all of this, and that inspired Linux, and inspired berkeley to open their OS, was GNU.
WTF am I doing replying to an AC at 5 A.M on a Friday night?