Breaking all the rules

Open Source development will never work! Well, at least if you believe in common wisdom. Let’s take a look at a few examples:

- No monetary rewards: People do OS for fun, for recognition and other motivation factors but seldom for money. That shows very clearly that we human beings of course work for money, because we need food, a warm place to sleep and so on. But there is so much more! I still think this “fun and recognition factors” are a much stronger driving force than money. So all this companies that try to compensate lacking fun with money (or don’t compensate at all), watch out what you are doing and don’t be astound if some competitor will be a lot faster or better than you…
(Update: please don't missinterpret this as money is not an important motivation factor. It really is. It is just not the only one!)

- No fixed long term assignments. In OpenSource people fluctuation is quiet normal and not a huge problem. Because it is a fact, everybody deals with it and it is actually manageable. I think this is one of the reasons in OS projects code quality is so important. It makes change so much easier. So what can we learn from this? Projects can deal with fluctuation easily if they are done right. But you have to deal with the fact front up: you need a lot more conversation, better code quality and so on… For the team members this means: no one is irreplaceable. But this also makes change possible. If done right, no one has to stick with the same projects for years if not wanted..

- No direct interaction/communication: Well I and a lot of other people think communication is one of the most important success factors in software development projects. As direct face to face communication is the most effective form of communication I always try to facilitate face to face communication. In OS projects most people never meet. Almost all communication is done through instant messaging, news groups and email. And it works! Actually having a lot of communication done in newsgroups is a great help, because this gives a great knowledge repository for anyone (see the “no fix assignment” point). So what does this mean for conventional commercial projects? To be honest, I don’t have a clue. Maybe we should do some more discussion in local newsgroups and wikis? Maybe not? What do you think on this one?

- No BDUF: In OpenSource you almost never have detailed requirement specs, big front up design session, a lot of architectural documentation or concepts, nothing like that. And it works like a charm. So this clearly proves the point to me, how soft software actually is, and that the XP guys are right. You can live without BDUF! But you have to keep your software flexible to make this possible. But it is possible. Maybe it is even the best way to do software.

- Huge teams: A funny point about OS projects is there team structure. You often have really huge teams and a small core of developers doing most of the work. This actually resembles pretty much the structure of huge commercial projects (but there all team members invest the same amount of work time). Maybe software development has to be like this. Maybe this is a copy of the Gauss curve of skill sets?

- No developer wants to do bug fixing. If this would be true how could OS projects survive (as everything there is voluntarily). Who would fix the bugs? Obviously this is not true. Actually in OS this is a perfect chance to get on speed as a new developer. The other point is, developers that are proud on what they program can’t stand with a buggy product. So that is also a matter of identification. If developers don’t want to do bug fixing, maybe you have a completely different problem. Maybe you didn’t allow them to do it right from the beginning. Or maybe your product is so bad right now, that no one sees the point in fixing small bugs while not fixing the larger problems your code has?

- The best developer gets the leader: That is not so much the case in normal business or at least it shouldn’t if you would do what the experts recommend. Managing projects and people has a lot less to do with programming than with dealing with people. So usually you promote people with strong leadership and people skills into management. You don’t make the best violinist the conductor of the orchestra. Well in OpenSource projects you often do. But even in OS projects usually the people skill will get more important the huger the project becomes, so there might be not a big difference, nevertheless it’s interesting to watch. And in OS projects you will never find a project manager with no technical expertise. How about commercial projects for this one?


Well I guess before I bore you even more, I better stop here ;-) So obviously OS projects are different. And they are highly successful. So some of the rules how to do software development right, that we all take for granted are not as universal as we sometimes might believe. So let’s watch out and learn from Open Source…