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.
I don't read this as saying that the ownership of IP is something to worry about. I think the writer's point is that the most important IP is not what SCO and the MAFIAA are suing people about...it's the creators of that IP. This is especially the case with code, since it needs to be maintained for longer periods of time than other kinds of IP. When you have software that is the lifeblood of your company, and the team that wrote it retires or gets hit by a bus, you have big problems.
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
"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
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.
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
"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.
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.