Archive for November, 2009

Another example of community interaction

I’m beginning to see the value of small examples of community interaction as illustrations of good open development practice. Mark Johnson started this off with his tweet about his first contribution to Moodle being accepted, and Mark’s subsequent presentation at the recent OSS Watch Engaging developers with open source projects workshop.So here is the second such interaction.This time it’s between Paul Walk, Technical Manager at UKOLN, who attempted to download and build Simal, a set of tools for building project catalogues from RDF/XML files which is currently led by OSS Watch, and the Simal development Team. The active Simal development team currently consists of Ross, who instigated the project, and Sander, OSS Watch’s newest member, and who spends 50% of his time developing Simal.Paul hit a wall and so raised a ticket in the project’s Google Code ‘forge’. The issue was discussed, explored and resolved, as you can follow on the ticket. There’s no need to understand all the technical details, just look at the interactions and activities. I’m going to pull out the following points.

  • Paul started by creating a ticket. Sometimes on list discussion precedes a ticket being created. This depends on the preferences and confidence or the person raising the issue. It may also depend on the community preferred style or the type of issue being raised.
  • All subsequent discussion was on the ticket. Again this depends on the preferred style of the project or the particular issue. Some projects discuss on the list with outcomes being tracked on the ticket. The advantage of having all discussion on the ticket is there is one place ot refer to.
  • Several members of the team got involved. Here Ross, the most familiar member, gave some informed opinion but left space for Sander to dig into the issue.
  • As a bonus, Ross spotted another issue in the information Paul submitted, and quickly fixed it. Rather than creating another ticket to track the new issue, which would have been appropriate for an issue that required discussion, the revision created when the fix was checked into version control is referenced from this ticket. The checkin comment also references back to this ticket, thus there is an audit trail, both from the ticket system and from the version control system.
  • Sander acknowledged the issue on the ticket and explained he could reproduce it. The ticket life cycle is also used to do this, for example by setting the ticket status to ‘acknowledged’, usually along with an assignment to a particular developer.
  • When he had found the problem, Sander created a solution, explained it in the ticket and supplied a patch. The patch is attached to the ticket. The reason Sander created a patch is that he is not yet a commiter so his contributions are approved and checked in to version control by someone else. Committership is an earned right and recently Sander has been proposed as a committer, using the process dictated by the project’s governance model.
  • Ross then asked Paul to verify the proposed solution, which he did. Note that this did not require Paul to apply the patch himself or use a special test build, as often happens.
  • Finally Ross commited the patch, after making a small adjusted and mentioning it on the ticket. This is a simple form of peer review, a vital part of open development. Review allows experienced members to look for problems and for other members to learn.
  • Note that the revision number that contains the fix is not referenced from the ticket. That would normally be done to give an audit trail. It was actually checked in on r1743 as you can seen in the r1743 commit comment.
  • This fix will eventually find it’s way into a release, as defined by the project’s release process.

So there you have it, a complete community interaction from problem statement to successful resolution. This time it is a little more complex than Mark Jonson’s experience, which I previously de-constructed.You can see Mark Johnson presenting again at our upcoming Building an engaged community workshop, which will provide the opportunity to meet Sander and Ross, and possibly Paul. There are still a few places left.

Developing Communities

When I joined OSS Watch a couple of years ago my role was to enhance the community development work we undertake. I, and the rest of the OSS Watch team, have worked hard to understand how to build viable open source communities in the academic sector. Personally I can attest to having learned a great deal, yet it still surprised me when my colleague, Gabriel, reported on our recent trip to ApacheCon by saying that he observed me bringing community development lessons form my OSS Watch activity to the experts in the ASF.

I guess this is one reason why the ASF board recently approved a resolution to create a new Community Development project and appointing me as Vice President of Community Development. I look forward to this new activity in the ASF allowing me to further cross-fertilise between the ASF and the UK HE/FE sector, whilst the launching of a new EC project focussing on a wider engagement of computer scientists in open source projects will allow us to reach out to other software foundations.

Guest Post: Peter Cudd on the freedoms discovered through open development

This post is by Peter Cudd BSc PhD, Senior Research Associate and project lead of Maavis at the School of Health and Related Research, University of Sheffield.Our project, Managed Access to Audio, Visual and Information Services (Maavis), is also being guided in its open development journey by OSS Watch. Open development has been a new experience for me and my colleagues, OSS watch’s input has been invaluable in providing insights and giving us a concerted plan to work towards having an active open development community. Our project is at an earlier phase but there have been some real differences to the traditional closed research and development we usually do.First and foremost is being able to talk openly with anyone about the project and what we are doing – this greatly facilitates engagement with new contacts without significant increased workload. This has lead to new partnerships and joint working. For example we have successfully obtained some Knowledge Transfer funding to help create a new version of Maavis and foster the open development community. Starting from the health and social care designed Maavis the goal is to have one suitable for community based Adult Education. In addition the Barnsley Adult Education Services will evolve their own open source development capability.Another significant difference is that the impact of competing similar ideas and technology is less than would be the case for a closed approach to research and development, the open development retains more ‘nett’ validity in pursuing further research and development.Although we have yet to post a Maavis web page – next on the agenda – we are already on the open development road and feel we are making good progress.Thanks OSS Watch.

Enjoying the rewards of open development

We’ve been advising EA Draffan and Seb Skuse at University of Southampton School of Electronics and Computer Science (ECS) on opening up the development of their StudyBar accessibility project. The development of this suit of accessibility tools for learners using the web is being funded by JISC TechDis as a replacement for their current web accessibility toolbar. Technically there are some interesting challenges, particularly the decision to support several browsers on various platforms. These technical complexities, the need for wide testing, and the varied user requirements and experiences are well matched to open development, which allows interested parties to bring resource to the project.

A concern we often hear voiced about open development is that it might involve a lot of extra effort when working with other people. In the case of Study Bar, Seb certainly has his work cut out as sole developer, and EA is busily involved in managing other accessibility projects. So what has been their experience after they took our advice and made initial steps towards open development? Initial steps that involved the introduction of a website (blog), issue tracker and code repository (Google Code) and a mailing list (Google Group).

EA had this to say after several users provided feed back on the the list:

It has been such a good idea having this list and Seb and I were just
saying how useful it will be for any future FAQs that could be made
into a web page

EA then expanded on this:

I really do think the way we have managed to get the group going and all the bug checking has really helped us speed up the process so much. It has been really useful!

This experience is not unusual, as projects find the value added by open development exceeds any extra cost. Providing easy access to code, tickets and project memory in the form of discussions and decisions, enables participants to be fully informed without constant questioning of the project members. This means interactions can be focused on adding value for all parties.

So while setting up and using these community tools is only the first step, the Study Bar team have already see benefits. OSS Watch will continue to guide them along the path towards fully embracing open development. The goal is to maintain a diverse community of users and developers, a community that provides requirements, resource, that encourages innovation and reaches sustainability.

I have been invited to explain the use open development to others at Southampton in a LSL seminar next week and I’m looking forward to helping others make the first steps. We will also be holding a workshop on Dec 7 in Oxford that explores community building in more detail.

More on video interviews at ApacheCon

In this video fragment Bertrand Delacretaz, member of the ASF’s Community Development Project Management Committee talks about the importance of knowing the qualities of the individuals forming an incipient developer community. Betrand’s soccer team analogy is simple but powerful. It captures the key aspects of working collaboratively as a distributed development team: openly communicating one’s abilities and limitations, identifying one’s interests and fostering them to the benefit of the entire group.

YouTube Preview Image

Video interviews with open source leaders

At ApacheCon US 2009 I had the opportunity to initiate a series of video interviews with open source leaders about the importance of community in open source development. On Wednesday I talked with Noirin Shirley, the ASF vice-president for conferences and events, and Doug Cutting, member on the ASF Board of Directors and founder of the Lucene and Hadoop projects, about the importance of community and leadership in open source projects.I hope to make the full videos available online soon, but until then here’s a glimpse of Noirin and Doug.YouTube Preview Image[youtube]http://www.youtube.com/watch?v=v3dP3ldte90[/youtube]

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. 

Apache barcamp – geocaching

Earlier today at Barcamp Apache Ross did a session on geocaching. He briefly explained us what geocaching is, then using his gps he led us through Oakland in search of a cache that was apparently hidden in a public garden.

After about half an hour of navigation we entered … an underground parking, and started to doubt that we are actually on the right track.

However we suddenly emerged in a garden on top of the building

We got closer to the place the gps indicated and started searching.

A few people eating their sandwiches watched us suspiciously, while others continued their lunchtime routine.

Finally Bertrand found the magic container.

He filed in the log that documents the history of the find, then took one object from the container and replaced it with one Ross had collected from another geocaching. Anjana volunteered to use the Oakland item in a geocaching she would do in the UK.

In theory there is a slim chance that one of us will come across this object again in ten or twenty years, in a totally different location. I leave those willing to do the maths to calculate how big these chances really are.

A wonderful session Ross, well done.