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.'"
The anonymous submitter was apparently too cowardly to submit a link to the article. I think that's the one he wanted.
The link that post contained pointed to what may well be the most informative, insightful, and entertaining read I've had all year.
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?
After finding the article and reading it this is what it really seems to say: open source is great, since so many more people understand your code you are that much cheaper to fire after you have done the creative work and replace with someone cheaper. I love open source, but if companies are really thinking like this it would be a good reason to make your projects closed source, as sad as that sounds.
Philosophy.
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.
Of course the people are key to any business, not just software, and not just open source. 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. Individual projects will die if their key developers leave but the whole can keep running.
The article seems mainly aimed at VCs involved in the new boom in Silicon Valley - open source - and is warning them, "buy the developers, not the software".
Good advice but hardly profound.
My blog
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.
"The code without the people is worth nothing," according to Phillipe Cases, partner at VC firm Partech International. "A million lines of code is like a million problems that you have to solve. So the risk on any open source investment project is that the 2-3 guys that created it and maintain it could leave. The commitment of the developers is often the IP -- not the code itself."
I don't think this is unique to open source... or software development in general. Of course, once VC is involved we're not talking about FOSS in the *strictest* sense - these guys want to make money. Ok, it may be that the revenue stems from support, but that's the same for nearly *all* software projects. (No, I don't mean just fixing bugs - that's a flawed business model to start with... Oh, wait)
Just to give an example - and to prove the quote above from TFA is wrong (sometimes, anyway):
Back in the early 80's I was asked to look at a program which required some adjustments. It was written in FORTRAN and it was a *mess*! "Spaghetti code" didn't even begin to describe it - it had GOTOs to GOTOs, looped out code, redundant variables by the dozen - you name it, it had it. It didn't have anything in the way of provenance. It took me two days to trace out how to implement a trivial change. The weirdest thing was there was no way I could really document what I'd done because that would need a framework - and there wasn't one. And, you know what? The company didn't care. They had paid a junior programmer for two days to implement something they needed RIGHT NOW. They didn't need to keep on the original developers (and God knows how many preceded me), nor did they need to insist on adequate documentation. If they needed to make a change in the future, they would just do the same (albeit with a younger and cheaper programmer). They wouldn't employ me to look at it - I'm too expensive.
My point is that it isn't the software that gets too expensive - it's the developers themselves. Who among us hasn't used a project to enhance their Kudos and desirability in the market?
So VC's are looking at FOSS in the wrong way. We don't really do it for money (though that's nice), we do it for the satisfaction of getting it right and being able to point to something and say "I did/helped_with that".
Anyone disagree?
(Ducks)
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 and the reason they leave a project may be similar - they might be bored with what they are doing, get a better job offer somewhere else, and *not support the software any more*.
/resources to do anything themselves. Just look at sourceforge and see the number of dead projects.
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, particularly smaller users who do not have the money
I've had my share of both.
I've been working for a large German corporation where I was supposed to develop software. Mostly I developed reports, but that's a different matter.
Schedules were tight, burnout was running rampart and in the 9 months I worked there, the AVERAGE stay time for a team member was about 3-4 months. With one month being the time necessary to give the person an idea of what the heck's going on in the (very badly written) code.
That's closed source, ladies and gentlemen.
It can be the same with open source. With a few very interesting differences.
With OS, it's no problem to give your applicants the code instead of having to wait 'til you decided for one of them. There is no NDA to sign. You can already base your interview on the question "did they understand the code?". You start with a team member that already knows the basics of your code and knows what is going to come. He already knows if he WANTS the job, since he knows what kind of beast he's going to be pitted against.
The average stay time will be first of all longer, and more importantly, your new team member has a head start. He already knows the basics of the code, he is getting productive in less time.
That's open source, ladies and gentlemen.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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
Well, in this point, I must say he's right. FOSS projects tend to have poor design documentation, and sometimes it's really hard for new devers to commit code in a relatively short period of time if at all.
yes I know, if programmers usually don't like to document code, how can you imagine they will document on design when they're not even told so ?. if that changes someday it will be a pretty good play for FOSS projects expansion and lifetime, don't you think ?
From N3P:
N3P offers a two-year college level training in how to become a successful Project Entrepreneur in Open Source. Our students will learn not only the technical possibilities, but also how to exploit new business opportunities, manage profitable ideas, and create flourishing businesses.
The typical student is between 20 and 30 years old, driven by one of three motivations; 1) the desire for prosperity, 2) independency or 3) to radically innovate. N3P will carefully screen the applicants for doers, not talkers, while persistence, passion and the ever so important ability to sell, are other important criteria.
The future will show a great demand for individuals that have the ability to implement necessary changes. They should be entrepreneurs, fluent in new technology, project management and marketing. They also should excel in sales and development of new products and businesses. N3P identifies them as "Project Entreprenerus".
Most of our students will form their own business before graduating, and it is our expectation that many will be very successful.
...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.....