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.
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
"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)
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.