Community Leadership Summit 2009

More than 200 people gathered at San Jose's McEnery Convention Center on July 18 and 19 for the inaugural Community Leadership Summit (CLS). The event was primarily an unconference, with both days' programs assembled on the fly by the attendees themselves. The majority of those attendees identified themselves as participants in free software or open source communities, but a significant minority came from other realms — closed source companies interested in dealing with their customer communities, web services, and online communities unaffiliated with software altogether. Regardless of the field, of course, many of the issues are the same — from dealing with the tensions within online communities, to grappling with the technical challenges of communication overload, to avoiding burnout.

The CLS was organized in large part by Canonical's Jono Bacon, who explained in the Saturday morning plenary session that he wanted to have an event that dealt with community management issues above the "product" level — thus enabling participation by people from all Linux distributions, desktop environments, languages, and user or development groups. The unconference format facilitated that "open to all" principle; only the opening and closing slots of each day were pre-planned, participants filled out the rest of the schedule by announcing sessions that they themselves were interested in facilitating, then selecting an open time slot and meeting room on the large program board in the hallway. The sessions were round-table discussions, not presentations. In several instances, the person who proposed the session announced at the outset that he or she had no answers and was primarily interested in hearing the thoughts of the others in the room.

Common questions

Over the course of the two days, some recurring themes emerged in multiple sessions led by different facilitators. The mechanics of community management was one such subject; several sessions dealt explicitly with how leaders interacted with their communities: the tools of communication, tools for tracking issues, conflicts, and participation, and the metrics used to measure community health, growth, and participation. From the experiences of the attendees, it is clear that there are no clear-cut solutions in this area. Even in software itself, most community managers are re-using tools created for other purposes, such as bug tracking software and customer relationship management (CRM) systems, with mixed results.

The role of women in online communities was also central to several sessions, including the different communication styles exhibited by men and women and how to adapt to both in the community, and how to respond to conflict and gender bias (both explicit and perceived). The open source community has been addressing the inclusion of women more and more frequently in recent years, both in attracting more participants and in adjusting the male-dominated "engineer" culture that many see as a barrier to entry in open source. The discussion is ongoing, naturally, but one key benefit to addressing the topic at the CLS was the opportunity to learn from the experiences of other online communities, including those that are not majority-male.

Finally, several sessions dealt with the legal issues facing online communities, focusing on open source communities in particular. Specifics included trademark and branding issues, budgeting, fundraising and volunteer compensation, and the details of nonprofit tax exempt foundations. As widespread as open source software is, many groups — particularly smaller ones — still face the same issues and raise the same questions.

The reinvention problem

Danese Cooper of the Open Source Initiative (OSI) led an interesting discussion on the tricky task of reinventing an existing community. She drew from the OSI's recent experiences as it tries to redefine itself and its associated community, but pointed to several other examples as well, including when a community grows up naturally around a vendor product and then must change when the product changes hands or is itself redefined, as has happened with Java. In some cases, redefining the community is not a choice — such as the change that naturally occurs when a product changes or the redefinition following the forking of a large project — but it can also be a conscious decision taken in order to avert obsolescence or burnout.

OSI has learned some valuable lessons through its early attempts and false starts, Cooper said, including the fact that it is not enough to simply gather interested stakeholders together and expect a community to coalesce by virtue of shared values and interests. OSI's attempt to bootstrap a community by "starting with the membership" failed, she said, because of infighting and arguments. The organization has had more success growing a community naturally by starting actual projects, then allowing interested participants to join in the effort voluntarily.

Participants in the discussion related experiences with redefining communities like Java, LiveJournal, and the Open Web Foundation (OWF). The OSI's success with projects as a driving force was an indicator that projects are the "currency" of the OSI community, according to the discussion, but that different groups might find a different currency to be the solution to their own problem. Most agreed that the underlying problem was not one of attracting people, but of redefining the vision for the community that would attract the right people. Especially for communities that involve both companies and outside volunteers, agreeing upon that vision can be a difficult process.

That point led into a discussion on the issue of forking a community when participants disagree over vision or core values. Although, on the surface, forking an existing community sounded like a negative, the group decided that there were sufficiently many examples of positive community forks to conclude that it is sometimes a very good idea. One example was the Ubuntu Linux distribution. Debian is (and always has been) committed to building a completely free Linux distribution. Among others, Mark Shuttleworth felt that the Debian Project was limiting itself (taking too long between releases, etc.), but rather than attempting to change the way the project operated, he created Ubuntu as a derivative with different goals and a different message. The result has been a success for both distributions, whereas attempting to force the Debian Project to change would likely have ended in failure.

Open source communities in the developing world

Perhaps the most challenging session was Nnenna Nwakanma's look at developing open source in the developing world. Nwakanma is a member of the Free Software and Open Source Foundation for Africa (FOSSFA), which promotes open source software across the African continent. Both Nwakanma and Bruno Souza from Brazil spoke about the obstacles facing open source communities in developing countries and, in particular, the ways in which the traditional approaches that have proven successful in North America and Europe fail under the radically different circumstances found in other countries.

Some of the differences are well-known, such as the fact that governments are by far the largest IT spenders in developing countries. Other differences took attendees by surprise, such as the challenges in developing sustainable open source communities. Many of the strategies common in the West do not work as well — or at all — in Africa, Nwakanma said. For example, most open source projects and communities use the Internet as their default (if not their only) means of communicating, organizing, and working. In contrast, the vast majority of the people in Africa do not have Internet access at all, much less in the evening at home, so local user groups that meet in person are the premiere way of spreading and educating about open source. African open source advocates also have significant trouble keeping developers active after they leave college, since so many people have difficultly simply finding paying jobs. FOSSFA has additional difficulties that result from targeting the entire continent of Africa; its initiatives must be equally accessible in all 53 African countries, or else risk fracturing the community along regional lines.

Despite the challenges, Nwakanma did have ideas for building the open source community in Africa, including targeting school age children with open source education and clubs, observing that proprietary software vendors relentlessly pursue lucrative government contracts, but are never interested in investing in school-age children as potential developers. The other attendees shared their ideas as well, such as linking local open source groups in Africa with established Linux user groups (LUGs) in the West in a "sister city"-style program, and publicizing opportunities for visitors to Africa to help local groups by volunteering to speak about open source.

More community leadership

At the closing session on Sunday, the vast majority of attendees said that CLS was valuable and were enthusiastic to see it return next year. Opinion was split about the time and place; this year's event was the weekend immediately preceding the massive O'Reilly Open Source Convention (OSCON), which was a plus for those already planning to attend OSCON but a minus for those who found OSCON too expensive. Bacon promised that CLS would reappear in some form next year, to further the discussions that so many found useful. Managing online communities is a topic that is growing in importance, which should guarantee the continued success of the event. But it is also critically important for the open source movement as a whole, because it depends on healthy and vibrant communities for its survival.

A Belorussian translation has been provided by Patricia Clausnitzer