Author Archive for Elena Blanco

Guest post: Paul Anderson interviews Jono Bacon

This post is by Paul Anderson, EPSRC Computer Science Writer of the Year 2007.

Jono Bacon is the community manager for Ubuntu, a popular distribution of GNU-Linux. Based on his experience Jono has just written a book, published by O’Reilly but available under a Creative Commons Licence, about community and open source. Originally from England, these days he is based near Berkeley, California. Paul Anderson from Intelligent Content caught up with him on a recent visit to London.

Q: You’ve just published a new book, The Art of Community, what’s the key message you are hoping to get across?

The Art of Community essentially teaches the reader how to build a productive and enjoyable open source community. It starts with a bird’s eye view of the social science behind the concept of ‘community’ and then gets into how to build a strategy for a particular community. The book then delves into each of the elements that go into the delivery of that strategy such as processes, governance, tools, running events, dealing with conflict, and how to hire a community manager.

Q: So why is the idea of community so important for open source?

I think that there are ethical benefits and there are pragmatic benefits. The ethical benefits of working through a community seem fairly obvious to me. They are things like it helps to reduce elitism, providing an opportunity for everyone to get involved, and it provides opportunities for people to gain experience. On the pragmatic side, a community that has been harnessed effectively can deliver some really interesting things. For example, on one of the projects I worked on we decided to open it up for translations [of the documentation] and within two weeks we had 17 languages.

Q: In the book you argue that a ’sense of belonging’ is important.

Yes. The way we build community is to create a sense of belonging. When people feel that sense of belonging in the community then they feel like they are part of something, they feel it is their ‘place’, their home. And when they have that they feel like contributing back to the community.

Meritocracy is very important part of this. This is where people build up reputations based on the merit of what they actually do. It is the only way that a distributed community can really work. When anyone is in a meritocratic environment they fundamentally feel a sense of principles and they really treasure the premise of equality.

Q: Ubuntu operates a code of conduct. This seems to be an important thing to get right.

When you build a community the first thing you need to do is build a set of principles. You need to say this is the culture that I want to instil and for open source software that means a culture of openness and transparency with freedom to contribute. You want people to be respectful and polite but not too restricted in their communications with each other.

The Code of Conduct we have in the Ubuntu community is essentially to provide a charter of reasonable interactions. So what it does is say: ‘every contributor to Ubuntu should follow this conduct’. It is a very basic set of ‘don’t be an idiot’ instructions. I believe that documents like this can hold tremendous value and it is held in very high regard in the Ubuntu world. This kind of thing helps build a sense of belonging.

Q: This raises the issue of managing the community, or as you describe it in the book, ‘Governance’.

Governance is having some kind of official structure that takes decisions on behalf of the community, like a Management Board or a Council. One of the mistakes that a lot of communities make is to believe that they need an explicit and very expansive governance structure in place, otherwise they are not real community. And this is not true.

Ubuntu has quite an expansive governance structure in place. We have a community Council and a tech Board at the top, and then various team councils that report to them. But this is because the Ubuntu community is huge and we need this to deal with the scale of what we’re doing. If you’re a smaller project you just don’t need that.

Q: You also talk at length about process workflows and tools.

Yes, I think it’s really important to get this right. On the workflow side of things the focus is on identifying ways in which people can work together on common problems, for example bug tracking. How do you handle bugs? How does the team triage them when they come in? Who fixes them? All these are part of the community workflow, they are really important and the book has a lot of ‘hands on’ stuff about these issues.

I think that tools need to be applicable to do the job. One of the problems for a lot of communities is that they want to have something like a public website, so what they’ll do is agree that they need a website, but then have a long and drawn out debate about which content management system they should use. What happens is that they spend more time bickering about tools than actually doing something good like having a basic project website and actually getting people to visit it.

What I recommend in the book is that they just pick something, it doesn’t matter too much what that is. In a year’s time they will want something different. The first six months of a community is the most critical time and a team needs to be built - a sense of excitement, a sense of belonging needs to be built up. You don’t get that by spending the time bickering about tools like a CMS.

Q. Widening things out a little, where do you see the general situation with open source today?

I think we are in good shape. What we are doing is building a new IT industry with open source, building a new approach to software and I think we have made tremendous progress. Just look at Linux. I first got involved in 1998 and we have made so much progress in the intervening years. I look back to those days when I actually needed a soldering iron and a steady hand to get Linux working on my PC! We have made huge progress in terms of writing software, making it useful and integrating it with systems.

This week is Ubuntu Open week which includes a series of tuition sessions and the whole ubuntu community is joining in. If you’re interested in getting a taste of what’s involved, now is the time to see for yourself. 

Feast or famine

Sometimes you could be forgiven for thinking that OSS Watch publication production line has stalled. It can seem like we haven’t published any of our own material on the website  for a while even though we have been blogging.  And then a few articles pop out in quick succession. Take the last four weeks for example.  We have published a case study on EduApps, a case study on TexGen, a substantial article on the open development method, and a report from an OSSWatch workshop looking at business and sustainability models around free and open source software. Why has there been a recent flurry of publications?

Very early on in OSS Watch’s history we decided that we would take the quality of our written outputs very seriously, perhaps more seriously than anyone expected us to.  All documents that we write adhere to a stringent authoring and publication workflow that has been designed to offer the best quality assurance that we can muster.  Some of our documents are drafted by one individual, others are written collaboratively from the start.  Some others are commissioned from external authors.  However all documents move to final draft status collaboratively, all members of the team comment on the first draft and the document is refined iteratively until consensus is achieved.  And this is where the process takes as long as it takes and, as a result, you may observe a famine if several documents are moving through this iterative process.  We believe that this process really does need to take as long as it takes as we use it to iron out not only factual issues but also to come to team consensus on matters like bias and advocacy.  Settling these big issues using argument and counter argument can take time, changing a view or position through discussion often requires a period of reflection.  However, we feel (and hope) that this process makes our documents better.  And because this process is not artificially bounded several documents may appear at the other end in quick succession.  A publication feast.

Once a document is published our workflow doesn’t stop there.  The Web is littered with “write once, review never” information.  You know the sort of thing, a topical article written three years ago that still turns up in a Google search and gives outdated information because no-one has ever updated the information within it.  Since OSS Watch strives to be an authoritative source of information on matters relating to open source, we don’t think that outdated information is acceptable, particularly if other organizations and services rely on it.  So all our documents are reviewed every six months.  We check not only facts and links but we also check for relevancy and for missing content, ie has something happened since the last review that should be mentioned.  Sometimes we retire a document that is no longer relevant and this is then preserved in an archived state.  Sometimes we completely rewrite a document. However most times we tweak and refine each document at each review and we often add new information.  This review process is time consuming and all OSS Watch staff are involved in reviewing documents each and every month.  Is it worth all the effort? We think it is.

And finally, we don’t want our documents to be the result of a collaborative process involving just the members of OSS Watch.  We welcome comment and feedback from you.  We often develop documents in the OSS Watch wiki, a public resource where all collaboration is welcome to get the document to its first draft and and where you can see the status of all wiki documents being developed for publication on the website.  Even, and perhaps especially, when a document has entered the formal QA process and has subsequently been published on the website we welcome comments, just drop us a line at info@oss-watch.ac.uk.

Richard Stallman talks to OSS Watch

Sometimes you get a bit of luck and last month OSS Watch certainly got a bit of luck in that we managed to secure an interview with Richard Stallman, President of the Free Software Foundation and commonly regarded as the Father of Free Software.  Stallman was speaking at a couple of events in Manchester at the beginning of May and Paul Anderson of Intelligent Content was able to catch Stallman between engagements for an interview on OSS Watch’s behalf.  Paul has worked with OSS Watch on a number of projects to date and his credentials as EPSRC’s Computer Science Writer of the Year for 2007 made us hopeful that we would be able to draw out Richard Stallman’s views on areas of interest to us and our community. We weren’t disappointed.

Check out Richard Stallman on the road less travelled to find out Richard Stallman’s thoughts on the use of free software in education, the responsibilities incumbent on institutions producing software, and the current move towards Web 2.0 and Software as a Service.