I have now finished reading The Cathedral and the Bazaar by Eric S. Raymond (I have mentioned it here before). I must say that it provides a good insight into the hacker/open source community. I find the parts which describe how communities arise and function around specific project, such as Linux, especially interesting (it wouldn’t hurt with even more of this). These different communities share a tradition of slang, history, and myths. I believe that this is crucial for the communities in order to be able to communicate and work together. This is something quite obvious from a knowledge management perspective. For knowledge to be created and exchanged there has to be a strong culturea shared frame of reference. When there is a strong culture communication becomes much easier, it’s easier for people to understand each other. This is especially important for tacit knowledge. In a company this is essential as well, however in the open source communities the means of communication are quite poor and the people rarely meet face-to-face.
The culture and implicit rules hold the communities together and facilitate the work. But since the participation of the communities is absolutely voluntary there has to be something more. In fact, for a person to be loyal to a community it must be easy to move in to and out from the efforte.g. if it isn’t possible to fork the project people might choose another effort where such possibilities exists. Raymond mentions two main sources of motivation: doing work because you need the outcome/love the challange, and gaining respect of your peers. I don’t know if this kind of freedom is possible or even desirablein companies, at least in small and medium enterprises.
The leaders, or the project owners, are according to Raymond quite humble. It is not regarded positive if a leader takes the credit for the community’s work or even strive for being a leader. The leader should be knowledgeable, sharing and humble. I guess those are nice characteristics for all kinds of leaders.
One thing that is, at least to me, quite controversial is that there are no deadlines. Deadlines are often regarded as something good. I think they are good. Deadlines put some pressure on the developers and provide a sense of urgency. Hopefully they will get some positive stress, and not negative stress. One thing that I really like about XP and Scrum is that they use time-boxing, i.e. regular and firm deadlines. I have problem understanding why this couldn’t be used in open source projects, perhaps it would be considered as an infringement of the freedom.
Raymond also describes different approaches for how companies can embrace open source to different degree. I think that open source could be used by far more companies than presently. But it requires that they change from product orientation to service orientation. There are much more things than the actual software that could be sold. However, there are probably quite many companies that would benefit from not opening the source to their software.
When reading the book my assumption that there is a conflict between the open source community and the software industry (at least the traditional, non-agile) grow stronger. Take for instance JohnDoe: JohnDoe is highly involved in an open source project before he starts working professionally, and get accustomed to that way of working. It is the open source project that JohnDoe is involved in that convinces JohnDoe to engage in a professional career as a programmer. As JohnDoe starts working professionally in a traditional company much of his freedom is lost, and also the passion for programming. The question is where to get in touch with JohnDoeI would really need such people to my master thesis. It would also be interesting to see if there are people who didn’t have any large problems with migrating from an open source community to a software developing company. I guess I will have to start “head-hunting” :-)