Castle Project‘in (MonoRail, ActiveRecord, vs. gibi faydalı eserler barındıran proje) geliştiricilerinden hammet‘in blogundaki şu kitap açık kodlu ve özgür yazılım geliştirmenin “insani” ve yönetimsel yüzüne ışık tutan bir eser: Producing Open Source Software: How to Run a Successful Free Software Project.
Subversion’ın yazarı Karl Fogel tarafından yazılmış kitap gerçek hayat ve proje yönetimi deneyimlerine dayanıyor. Açık kodlu ve camia tarafından geliştirilen bir projenin teknik altyapısı ile ilgili veren kitap, yazılımcıların nasıl yönetileceği, projenin dışarı bakan yüzü ve kamu ilişkileri ile ilgili kıssadan hisseler içeriyor.
Kitabın “Nip Rudeness in the Bud” bölümünden kısa bir alıntı (vurgular bana ait):
From the very start of your project’s public existence, you should maintain a zero-tolerance policy toward rude or insulting behavior in its forums. Zero-tolerance does not mean technical enforcement per se. You don’t have to remove people from the mailing list when they flame another subscriber, or take away their commit access because they made derogatory comments. (In theory, you might eventually have to resort to such actions, but only after all other avenues have failed?which, by definition, isn’t the case at the start of the project.) Zero-tolerance simply means never letting bad behavior slide by unnoticed. For example, when someone posts a technical comment mixed together with an ad hominem attack on some other developer in the project, it is imperative that your response address the ad hominem attack first, as a separate issue unto itself, and only afterward move on to the technical content.
It is unfortunately very easy, and all too typical, for constructive discussions to lapse into destructive flame wars. People will say things in email that they would never say face-to-face. The topics of discussion only amplify this effect: in technical issues, people often feel there is a single right answer to most questions, and that disagreement with that answer can only be explained by ignorance or stupidity. It’s a short distance from calling someone’s technical proposal stupid to calling the person themselves stupid. In fact, it’s often hard to tell where technical debate leaves off and character attack begins, which is one reason why drastic responses or punishments are not a good idea. Instead, when you think you see it happening, make a post that stresses the importance of keeping the discussion friendly, without accusing anyone of being deliberately poisonous. Such “Nice Police” posts do have an unfortunate tendency to sound like a kindergarten teacher lecturing a class on good behavior.
The overall goal is to make good etiquette be seen as one of the “in-group” behaviors. This helps the project, because developers can be driven away (even from projects they like and want to support) by flame wars. You may not even know that they were driven away; someone might lurk on the mailing list, see that it takes a thick skin to participate in the project, and decide against getting involved at all. Keeping forums friendly is a long-term survival strategy, and it’s easier to do when the project is still small. Once it’s part of the culture, you won’t have to be the only person promoting it. It will be maintained by everyone.