A certain distributed project was used as an example. The project itself is not important, more interesting is to look to what obstacles it had during the lifetime of it.
Nominally OSS project
Project can be either OSS or non-OSS. For a brief time it can be both, but not for long time. Both models have their own advantages and disadvantages and people involved need to decide which ones they are going to prefer.
Geeks like to tinker their own things and show them to other geeks. This is why OSS projects can be so successful. People working for companies are usually told what they need to do and when it needs to be ready. Both people can co-exist in same project, but care is required in management. OSS people needs to get involved, respected, listened to and taken part into decision making process. Communication plays very big part and failure to communicate with the community (funny that communicate and community sound so similar) will lead into problems.
Engineers usually know what they’re doing. If they don’t know what they’re doing, they usually can find out what they should be doing. Making decisions high up and making them based on political factors (somebody has invested time and money, somebody has a pet project, and so on) might lead into problems. Technical decisions should be kept separate from political ones, but always it’s not so easy.
Communication is the key with distributed projects. Participants need to know what’s going on, where the project is going, what the goals are and so on. It’s hard to give too much information, but it’s really easy to give not enough information.
Communicating with people you have never met is hard. Good practice is to meet everybody face to face quite early on the project and just spend some time with each other (sauna evenings are great, but they might get tedious after a while).
Note: In Iltalehti, there was a poll “Are you satisfied with leadership skills of your superior?”. 87% answered “No”.