Slashdot Mirror
Open Source About the People
An anonymous reader writes "InfoWorld has a nice look at what defines an open source venture. It seems that the main area of interest, and difficulty, rests with the personnel surrounding the project. From the article: 'But the muddier waters are around the personalities and commitment of the engineers who created the code. How long do they intend to stay? What is their level of commitment? These are fuzzy types of questions - but we know from history that when the core team of engineers that best understands the code up and walks out ... it tends to send a company into a death spiral.'"
You're kidding, right? All it says is that if key developers leave a project, the project will struggle. Duh, and obviously that's not unique to open source software, it's true of closed source projects too.
What's not said in the article is that if the core engineers leave a closed source project, the project and the company may fail and leave the customers stranded. If the core people of an open source team leave, they are free to take the code with them and fork the project, so the customers have continuity (Xfree, Mamba etc are examples)
From a company's point of view, that's scary - if you upset your developers, you stand to lose your entire product, as well as the people who built it. For the customers and developers though, it's all good. The company has to keep the developers happy so they'll stay, and the customers know their software will outlast the company.
"I've got more toys than Teruhisa Kitahara."
Proprietary software development companies have found that promoting (or even acknowledging) developers causes a problem where the developers can be hired away. When the most knowlegeable developers disappear, there's a huge learning curve even for the "second tier" that must come to fill the void. It's a well-known risk for proprietary companies to have these "assets" so exposed and open to theft by other HR departments. Even if they aren't hired away, superstar developers mean that they can leverage huge salaries. Proprietary software companies have found that keeping their development staffs unacknowledged and easily replaceable means they keep costs down. They've developed a way to keep the developer a cheap, replaceable asset.
It seems that this article is trying to focus on how this applies to open source software development companies. It's not open source development in general, but companies which profit from open-source as an integral part of their business (admin services, proprietary add-ons, special distributions, etc). Even if the source for a critical part is open, the company will only have a handful of developers who understand the code inside and out on staff. This is a potential liability.
Accountants and capitalists don't want to consider developers as "artists" or "superstars", they'd much rather consider them as sheep to be sheperded. Simple, replaceable, interchangable. The article tries to make the point "Don't assume open source means your paid development staff will become a constantly refillable, always-replaceable, cheap resource." It doesn't change the problems of hiring developers that you had when you considered proprietary software funding.
Let's get beyond the simple binary 'all closed source is bad for customers/users, all open source is good". In an ideal world yes, but open source developers as people have many of the same motivations as closed source developers
Let's not. The simple binary is in fact the right answer, so long as you don't complicate it. Here's what I mean:
A software project can have many attributes that determine how good or bad it is for you. One of these is whether or not it is free software. A free software project is always superior to a non-free project that is otherwise identical (if you're the user). It has been repeatedly shown that this particular attribute is not tied to any of the others - it doesn't determine their values. It may share causes with some of them, but there are many possible causes to choose from, so just knowing whether or not it's free software doesn't tell you anything. So a project can be free but otherwise suck, or it can be proprietary but otherwise good, or any other combinations.
So long as you keep it as that one-bit value, 'free' vs 'non-free', it makes sense. The failure you're referring to lies in assuming that this bit affects any of the others - it doesn't really. Often people confuse 'free software' with 'community-driven', or 'resembles project X', and that's the mistake.
The open source code might *potentially* be resurrected by other developers, but it might not. Leaving customers/ users just as stranded as if it was a closed source project
Looking at this statement in those terms, things become more clear. The free software project can be resurrected by somebody else, the non-free project cannot be resurrected. So it's definitely better to have free software here, because then you've got a chance, instead of having no chance.
Any individual project may be easier or harder to resurrect, and it may be more or less likely to need it. But these things are not determined by whether or not the project is free software. You'll have to look at other aspects of the project to discover them. Better yet, look at the reasons why the project is the way it is, that tells you even more.