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.'"
So the real gist of the article is "Open Source is interesting - but watch out for the IP issues, and if the original developers leave, you're hosed."
Hardly a glowing recommendation, is it? It shares more in common with the SCO FUD further down the front page than you may realise...
What part of "a well regulated militia" do you not understand?
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.
If you have two or three "superstars" who, when they leave, would leave behind a project with a huge learning curve for new developers, they were no superstars to begin with. Of course, any project, especially as it gets more complex, will imply that it gets harder to get into. But I've been in many open projects for many years, some I've seen whither, some grow and survive after the original creators left or even the generation(s) after them. It all depends on how these developers are creating stuff and from what perspective they work. Many, most if you will, are the so called 80% developers, they love adding new stuff and features, but when it comes to making the code clean for others to understand, finish the glitches, work it better into the system, make documentation, they fail. These systems stabalize and/or die after one or two generations, they become unmaintainable. To survive, a better programmer is required. One that programs with this in mind: if I'm hit by a bus tomorrow, will this code be understood and survive? There will still be a learning curve, but much less steep and much more enjoyable and attractive. Moreover, it produces better code and more thought-out software. The downside: les "quick" success, which is not to be underestimated. Although it was closed software, this story in a nutshell would be the old Netscape Browser. My grandma would be ashamed of the source code, the same speed that produced that code allowed it to grow beyond dreams, and it was their downfall, among others.
A large part of building a sustainable business is to solve this problem and build structures that survive change. Sustainable software is built in layers so that no single team determines the life of the whole.
Of course, a lot of people get this wrong. They manage to build a structure that survives change, but does so because it isn't dependant on the skills of the individuals at all. That sounds good, but it really means that the system cannot benefit from the skills of the current employees - in effect, everybody is reduced to a minimum baseline level, in order to ensure that they can be replaced. This is one of the symptoms of the classic 'big software house' disease. It's not enough to get good people, keep them, and survive after they leave - you've got to do all that without impeding their work.
Very few people manage to build a structure that survives major change and can still benefit from the expertise of the workers. It's really hard.
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.
The larger the corporation you work for the less people matter. I have worked for some large corporation and I have no idea how they kept going. Their products were crap, nobody gave a damn, the workers were treated like shit, the customers worse. Despite all that they kept winning large contracdts and their profits were going up. Their products and services are measurably inferior to the competitions and they cost more but the customers kept choosing them because they were a big company.
A large company build it's own momentum. People buy the products and services because they think a large company will be more reliable or something. It's crazy.
Anyway a programmer no matter how brilliant just does not matter to a large corporation. If anything they are a liability because they will be disruptive to the crappy programmers and will not enjoy using the chosen bondage language (java, c# or VB.NET).
Smart people matter to small companies.
evil is as evil does
"what about semi-open and semi-closed products/projects?"
They are doomed from the start...
It is like being a little bit pregnant...
B.
This is a sig. This is only a sig. Had this been an actual sig you would have been informed where to tune for more sigs.
I can't imagine the world of commodity hardware without FOSS. Billy would have us all by the short and curlies -- face it, if FOSS didn't exist, someone would have to invent it.
I've done quite a bit of closed & open project work. It really doesn't matter. Neither is automatically more prone to success or failure. What matters most is the personalities of those doing the really hard work (is there a good mix?) and whether or not they're willing to go all the way (through documentation and customer support). Closed source projects are usually motivated by cash, and nothing more. FOSS projects, on the other hand, tend to be motivated by ideals and good ideas.
The total "fit and finish" of the end product often reflects the motivations of its creators: do you, as a user, not like it? Chances are pretty good that the development team didn't, either.
Founding member: He-Man Windoze Hater Club
"Let's get beyond the simple binary 'all closed source is bad for customers/users, all open source is good'"
And your end point is that once we go beyond those simple binary assements, if the core developers of a project "resign" due to varied number of reasons, the open source clients are in a worst case scenario no worse that their close source counterparts, and given some not so improbable conditions, they might be better to much better.
Now, I think this clarifies the waters quite a lot.
Open source means you can read the source, much like an "open book exam" means you can read the book. The correct term for software that belongs to the community is Free Software. With Free Software, you are guarenteed to have the four fundamental software freedoms. With "Open Source", there is no such guarentee.
By my definition, even Windows is Open Source. In principle, I can view the source code to Windows. It's difficult and I have to sign a whole bunch of documents but I could do it with sufficient patience. This is why I don't like Open Source as a term; it is far too misleading. In fact, it doesn't actually mean anything other than the fact there is a mechanism by which you can see the source code that doesn't involve getting a court-order.
In contrast, the term Free Software has a very precise meaning and really should be trade-marked by the FSF. Then the FSF could only issue licenses to se the trade-mark where the software is licensed that protects the four freedoms. This way, companies couldn't profit from the name unless they labelled their products correctly.
...impressive as they are, can work slowly and/or sporadically. If most companies that hire most developers are stupid in exactly the same way, there's a good chance they won't feel the ill effects for awhile---they can lumber through as hundreds or thousands of bright, innovative, start-ups do the smart thing, live for awhile, and die, like so many virtual particles. Eventually, perhaps, one of them will either succeed or the information that acting in a particular way will propagate up the food chain by absorption, but until then.....
Free Software doesn't have a coherent set of goals. Ask any three Free Software hackers why they write Free Software and you are likely to get five answers. What Free Software has is an economic model that works.
Take Linux, for instance. What are the chances of an undergraduate student from Finland being allowed to hack on a commercial operating system? None, there is no chance that anyone would have give Linus a shot at meaningful work on a commercial operating system when he first started hacking Linux. Once Linus did write Linux what were the chances of Linux being able to compete with the various and sundry commercial operating systems if Linus charged people money to use it? No one would have paid money for early versions of Linux, and no one in their right mind would have even played with Linux had it not come complete with source code distributed under a permissive license.
Fast forward a few years and Linux is slowly crushing the life out of commercial operating systems, and it continues to do so with hackers that wouldn't have a prayer of getting a shot at meaningful work in the commercial software world. Marcelo Tosatti was maintaining the 2.4 kernel as an 18-year-old high-school student in Brasil. What are the chances of Sun or Microsoft giving that kid a job. Yet Marcelo has been making money writing Linux software since he was 13. He's currently employed by Cyclades. Linus, and most of the other kernel hackers, are also doing far better with Free Software than they would have been had they followed more "normal" career paths. You see, that's the little secret of Free Software, most of the folks writing Free Software get paid to do so. Those that don't get paid directly usually get indirect financial benefits, and they can at least use their Free Software success as a calling card.
The end result is software that is cheaper to write and maintain than conventional software written by folks that get paid to do what they would probably do for free.
The reason that Microsoft comes into the discussion has very little to do with the "goals" of Free Software and everything to do with the fact that Microsoft is doing everything in their power to maintain the status quo. Microsoft has built their business around an economic model that requires huge profit margins, and the Free Software business model is destroying those margins. Microsoft controls the computer market, and they are using their current market dominance to drive their incompatible file formats and incomprehensible protocols. Free Software hackers simply want their software to get used (for a variety of reasons, many of which are economic), and Microsoft stands in the way of this goal.
This isn't saying that there aren't some Linux hackers that don't *hate* Microsoft, but it's not the hate that is driving Free Software adoption, it's the economics.