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.

13 thoughts on “on blogging in the corporate open source context”

  1. Los blogs en un contexto corporativo open source Aug 28, 2006 – Show original item Así se titula una notación de Luis Villa (en inglés), que me ha parecido muy interesante, pero no solo en lo que se refiere al tema que describe el título. En primer lugar me ha gustado porque apunta con claridad a defectos en las estrategias de algunas empresas, que pude observar en

  2. planned than the others I’ve heard of to date, here’s hoping the implementation goes as well music video: Junior Senior – ‘Move Your Feet’ (YouTube) – amazing pixel art vid by http://www.shynola.co.uk; I’ve actually seen several snippets of this elsewhere Luis Villa on blogging in the corporate open source context – great post, describing the use of blogs for cluetrain-style PR and vendor-user communication where commercial open source is involved Starfish – ridiculously easy distributed programming with Ruby – a Ruby implementation of MapReduce; missing the

  3. Planet Ubuntu เลย (ผ่านไปหลายวัน Shuttleworth ถึงออกมาแถลงการณ์นิดหน่อยผ่านบล็อกตัวเอง) Luis Villa เขียนบล็อกชี้ประเด็นว่า นี่เป็นกรณีศึกษาที่ดีของการใช้บล็อกร่วมกับการพัฒนาซอฟต์แวร์

  4. Fantastic post, Luis!

    Most of this advice would apply to any bloggers working as part of an open, community-oriented software development team, not just on open source software, I think; although OSS is generally more likely to involve a community than non-OSS code is.

  5. Note that pretty much all the Ubuntu meetings are not purely Canonical staff (you were at the Sydney conference, for example). This isn’t exactly excluding the community. At the Paris sprints, there were attempts to get some VoIP software running so that people who could not come in person could participate (admittedly this didn’t seem to be that effective).

    Furthermore, there is a pretty big difference between getting the developers together every 6 months is quite different to having them in the same office all the time. The rest of the year they are communicating with each other over public channels (mailing lists, IRC, Launchpad).

  6. Los blogs en un contexto corporativo open source…

    Así se titula una notación de Luis Villa (en inglés), que me ha parecido muy interesante, pero no solo en lo que se refiere al tema que describe el título. En primer lugar me ha gustado porque apunta con claridad a defectos……

  7. Justin: The original edit, I think, tried to make it more clear that in the community context blogging is good; in the corporate context blogging is mandatory (assuming you take your responsibility to your investors seriously.) I think maybe the distinction got lost a little in the writing.

    James: I know most of your events are open (like I have said repeatedly all week, Ubuntu is generally a model for this sort of thing) but I did think the sprints were the one exception- my apologies. However you slice it, though, in person is inherently exclusive, and certainly cannot be used as an excuse to forget about communicating with the outside world, whether it is one week a year or fifty-two.

  8. ‘in person is inherently exclusive’

    Agreed, that’s very true. I’ve been working on getting the Spamassassin team to go back to email/IRC meets for important decision-making, rather than the occasional sprints we were doing at Apachecon hackathons. The sprints were fun, but not really productive — and I think they were excluding the developers who couldn’t make it to Apachecon, which includes many of the core team as well as pretty much all the newbies/occasional-hacker contigent, and the latter is a very important part of open source IMO.

  9. There are times that sprints are really unbeatable, productivity-wise. And exclusivity isn’t necessarily bad- there will be different levels of skill and contribution, inevitably, and recognizing and motivating leaders is important too. So I wouldn’t recommend completely canning them. They just have to be done well, so as not to alienate those who aren’t there and create an us/them dichotomy. (Mostly, Ubuntu does this fairly well, I think. But clearly they need to recalibrate the sense of their connection to the outside world while they sprint- sprinting was absolutely not a valid excuse for ignoring community relations during the X fiasco.)

  10. […] case on Planet GNOME shows that there are limits. Much of the rest was due to Luis Villa's essay on blogging in the corporate open source context, but as I wasn't allowed to set assigned reading to the audience I was able to pad out by half an […]

Comments are closed.