on blogging in the corporate open source context

One of the more interesting sub-threads spun off by my QA posts of the past week happened in the comments of this post, where I glibly tossed off the comment that ‘I assume that at least some developers blog about what they are thinking about/working on, and if no developer blogs about this Very Big Fuckup, then… that ain’t good. :)’

Since then, Tollef and Mark have each blogged about the problem, about 48-72 hours (depending on how you want to count) after it happened. So a key issue (lack of frank, open commentary on the problem from significant, relevant community members) is resolved in this specific case. Each of the posts are detailed, relevant, honest communications that go a long way towards reassuring me as an Ubuntu user that Canonical takes the problem very seriously and is going to make sure it never happens again. [I will return to the substance of the QA problem involved at some other time; it seems Mark, Tollef and others have a solid grasp on the key issues, so it isn’t pressing.]

In this post I’ll turn to the more general question: why do I think paid open source developers should be blogging fairly regularly? What issues are involved?

To start with, open source as a business model only makes sense if your company has an active community which contributes QA, code, sales, or other resources to your company. If you are opening your code without getting contributions back, you have no competitive advantage over a proprietary competitor who has free trial downloads, and likely several disadvantages. Other people who want to grow a community should also do so, of course, but they have no responsibility to do so. Open source companies who aren’t actively investing in creating community are not fulfilling their responsibility to their investors. At this point, Ubuntu/Canonical may be the best example of how to do this, but as last week shows, there are still lessons to be learned by everyone.So… how do you go about creating and fostering community? Basically, you make friends. There are a million ways to do this (being polite in bugzilla, having good mailing lists, etc.) but they mostly boil down to speaking to each other in a human voice. So compare and contrast: official ubuntu problem announce with Tollef’s blog. The official post is good- it speaks to customers, people who aren’t friends and likely won’t be. There is an expectation of a formal tone there. But the community should be composed of your friends, and you communicate with friends differently- you use the tone Mark and Tollef used, ideally in a more timely manner :)
And this is why blogging is so good for open source community development. The mechanism allows for timely delivery of communication- you expect friends to keep in touch regularly, especially when something significant happens that might affect your friendship. The typical style of blogs (and the segmentation from official mechanisms of communication) mean that the tone is usually less formal and more friendly- exactly what you want if you’re trying to create new friends. It is personal, too- it is much easier to make friends with Tollef or Mark than it is with an abstract logo. It is also public, and with comments, can typically be interactive. It is much harder to make new friends if they can’t find you, or if they can’t talk back.

Is blogging perfect, or exclusive? No, of course not- you need a wide variety of tools. But it has quickly become pretty critical, I believe, to creating a functional and healthy and growing community.
Some responses to points from the comments in the last post:

• Obviously blogging takes away from time that could be spent doing other things, like fixing bugs. Valuing blogging is hard- the value isn’t obvious, it is indirect, and it varies from person to person, role to role, and company to company. Good employees and good management identifies things like that, puts a value on them, and tries to do them (or encourages employees to do them) in appropriate levels. This is true of a lot of things, not just blogging- documentation, good bugzilla habits, developing maintainable processes, etc. So if, as a paid open source hacker, you or your management thinks the only valuable thing you do is write code, you’ve likely got bad management. :)
• Relatedly, friendly blogging doesn’t have to take much time. It would have taken about 30 seconds for Mark or someone else to open up a browser, say ‘damn, that sucked; working on it- more details tomorrow’ and hit post, and that would have had a huge impact- way more impact than this verbose, hour-long post will ever have.
• One attempt at justifying Ubuntu’s lag on response was ‘We were in a sprint’- i.e., we were all locked in a room together, working hard. There are of course many ways to interpret this, but here’s one way: ‘we were so busy being cut off from the community that we didn’t have time to stop being cut off from the community.’ As evolution learned the hard way and has spent some time trying to correct, it is more efficient in the short-term to put all the paid people in one place. And it is very, very tempting to do that- you spend less time explaining, less time persuading, more time just doing. Everyone loves JFDI. But long-term, if you start working only with each other, it is very unhealthy for the project. If anything, while in a sprint, Canonical folks should be more sensitive to what is going on outside, and be very careful to not neglect it, else it is very easy to start doing ‘us (Canonical) and them (community)’ instead of ‘us’ (Ubuntu).
• From the same comment: ‘[Blogging] is one of the least efficient ways of talking about things.’ Again, the measurement problem. Are you trying to specifically solve the X problem? Yes, a blog post is a terribly, terribly inefficient way for X developers to talk to each other about how to solve the problem. Face-to-face is undoubtedly the most efficient way to fix the X problem. Are you also trying to build the trust of the community? The number of friends (aka community members) you have? Talking face-to-face, in that case, is completely inefficient- no one knows you did it except the two people involved. Again, you have to find a balance.

Anyway, this has gone on too long so I’ll stop. Bottom line: blogging is a great way to create friends. In open source, friends create better software, albeit usually indirectly. So anyone serious about creating better software needs to figure out how to incorporate good, friendly communication into their workflow. Ubuntu does this way better than most- but still screws it up from time to time, as it did last week, and we should all learn from it.