Open-source evangelist and all-round ubergeek Eric S. Raymond
by Prudential Securities investors, who peppered him with questions on open source development and Linux. Evan Kirchhoff
and I have been debating/commiserating about the software development process; a great deal of what Eric says is relevant to our conversation:
Brent Thill: So when you talk about the coordination of the open-source community, you know, you've mentioned that it's developed into a world class operating system. Linux has been developed by part time hacking by several thousand developers. One of the biggest misperceptions I think in the community right now is how do you manage a process like that? And when you talk to Red Hat, they can't even tell you when the 2.6 kernel is coming. So how do you manage the opposite end consumption expectations of when these features are going to come?
Eric Raymond: Well, let's dispose of an illusion first. There's a false comparison here. When people say, how do you manage open-source software, they're implicitly assuming that closed-source software can be managed. This is a belief that is actually false. Things take as long as they take. You can set deadlines in closed-source software, but our record at being able to fix both deadlines and a ship date is very, very poor.
There's a folk theorem that over 70% of projects fail either during their development phase or are not accepted by customers after delivery. That's a really shocking failure rate. And what it goes back to is this inability that any development system, whether closed source or open source has to simultaneously set deadlines and ship dates for anything as complex as software.
So that's one background fact to keep in mind when you ask, how do we get open-source software produced on a deadline? The reality is we can't get closed-source software produced on a deadline. When you try, generally what you get is a pile of crap that falls apart the moment somebody pokes it. So that's one thing to bear in mind.
When you ask, how do you manage open-source software, I'll continue that thread by saying that you manage it rationally the same way you manage closed-source software, which is to accept that you can set one of two things. You can either prioritize features and set a ship date and say, we'll take the features that are done by this ship date, or you can say, this is a set of features that I need, wake me when it's done. And open-source and closed-source software rationally are both managed by the same rule, which is: pick one of those.