On 7 December 2009 OSS Watch hosted a mini conference in Oxford, at the University Club. There were two workshops running concurrently, one on Open Source, Open Development and Open Innovation, which we wrote about last month, and the other on Building an Engaged Community, which is the subject of this article. During the workshops we ran a live blog for remote attendees; you can see a transcript here. Amir Nettler of OSS Watch covered the morning sessions and I picked up the reins for the afternoon.
The workshop was introduced by Steve Lee, who gave a high-level overview of the topic, focussing on the open development model and what a strong community looks like, as distinct from the open source code that they may be working on. The need for a wide and diverse community of contributors was stressed: not just programmers but contributors with all skills are important, including artwork, marketing, testing, documentation, etc. A good community should be able to sustain itself and cope with people leaving and new people joining. The key to this has to be transparency: all the history and previous decisions should be open for new contributors to review, which will prevent settled issues from being re-raised by people who missed the original discussion.
The licensing and legal considerations of an open project are very important for the community. Contributors need to be sure they have the legal right to give their contributions to the project and if necessary modify the terms of non-disclosure agreements or contracts of employment that could otherwise cause problems down the line. Some projects have contributor license agreements to protect the provenance of contributions; this is something a new project should seriously consider. To provide more information on this OSS Watch has produced a briefing paper on contributor licence agreements.
There is a wide range of free and open source tools for managing a distributed community-based open development project. Most community projects have some kind of shared communication system such as a mailing list or forum; critical to this is the history or mailing list archive being publicly available to new contributors. If the code is open but the communications are closed, the community will struggle to grow. A version control system should be used right from the start of a project to track who contributed which bits of code. A structured system distinct from the project communication system is used for tracking bugs.
Sebastian Brännström of Symbian treated us to a beautifully designed set of slides for his presentation, on how Symbian is moving from a very closed platform to an open development model. Sebastian has written open source software to run on Symbian and now works in delivery management for the Symbian foundation. In terms of governance, the foundation is set up as an independent not-for-profit organisation, which facilitates development but doesn’t actually do development as part of its activities. The foundation started with 12 member organisations, which has now risen to about 180, and has 90 employees. In order to give structure to the governance of such a large project it created four councils to control different aspects of the platform: features and roadmap; user interface; architecture; release management. An interesting aspect was the deliberate selection of structures that make it easy for anyone to influence the direction of the project, not just the larger members such as handset manufacturers.
Sander van der Waal told us about his work with the Apache Felix project. Apache Felix is an implementation of a standard framework called OSGi which defines a modular system for Java applications which amongst other things allows parts of a system to be updated whilst it is running, a powerful feature for highly reliable applications. When Sander got involved in Apache Felix it was in the Apache Incubator, which is a part of the Apache project where young projects are guided through the community building process. His project team started by reading and following the mailing lists for some time before joining in. They found it important to keep all communication on the list. This included communication between colleagues, even where a direct communication option was available, as it was better to keep it to the list so that the information could be shared and archived. Sander went on to explain how the integration of an issue tracker and revision control system is used in conjunction with a mailing list, allowing visibility of who contributed each line of code and which issue each change addresses.
Mark Johnson of Taunton’s College gave a talk on getting started in joining a community from a development perspective. Mark started contributing bug fixes to the Moodle virtual learning environment and took us on an introspective tour of the sequence of events as he progressed from using and administering a Moodle installation to being a part of the community that produces it. Collaboration is an important aspect of open dev, and Mark thinks, if done properly, a collaborative development process produces the best results. As well as raising his personal profile, Mark has benefited from the quality checking and motivation that working with others provides. Mark went on to warn of the dangers of over-collaboration: soliciting opinions from too many people leads to confusion, and bad design. He suggested limiting how widely you consult in discussion phase, produce a prototype/proposal and then have that critiqued; the existence of a tangible contribution limits how widely people’s suggestions can range. You don’t need to please everyone all the time, the objective is writing great software and some healthy disagreement and debate is a part of this.
Steve Lee then kicked off a session on evaluating the openness and sustainability of open source projects using an online form developed by OSS Watch.
This was an audience participation activity, which gave me a bit of a break from the live blogging and a chance to take a quick photo of the audience as they gathered in clusters around an assortment of laptops. I counted three Macbooks, four running some kind of Linux, and three on Windows. Everything points to a more diverse computing landscape over the next few years, with different devices talking to each other using open standard protocols and formats.
I found the results of the activity very interesting in that the audience had no problems choosing projects they were working on or in their own specialist area of interest. Nobody attempted to evaluate the projects with the broadest appeal, such as Firefox and OpenOffice.org. I think this, and the range of resulting scores, points to the evaluation having good practical value for the OSS Watch sector.
The event closed with a panel session in each room, I will pick out a few topics that were covered; there is more in the transcript. The first questions were “Should a project accept all contributions” and “does it matter if a contribution is ignored?” All the panel members stressed the importance of managing contributions and responding to contributors; if a contribution is not used it is critical to provide feedback so that the next contribution meets the required standards for acceptance. Sebastian Brännström said that taking contributions seriously was critical to keeping users and the community happy.
The discussion moved on to the issues faced by smaller projects with a team of core contributors. In order to increase the number of active contributors projects should focus first on increasing the number of non-contributing users and lower the barriers to new contributors, helping users progress to being contributors.
The final question was “What pub are we going to?” the answer to which turned out to be the “Far From the Madding Crowd” where discussions continued into the evening.
0 Responses to “Building an Engaged Community”