Author: Bruce Byfield
“At the highest level, the community is anyone who wants to be involved with Linux or open source,” says Max Spevack, chairman of the Fedora Board. The statement acknowledges the interaction between many FOSS projects, but, like Ubuntu’s community manager Jono Bacon and openSUSE’s evangelist Martin Lasarsch, for practical purposes, Spevack tends to focus mainly on those involved on a regular basis with his distribution. All give some attention to what Lasarsch calls the passive community members — those who use their distro but don’t contribute to it — but, for practical reasons, all focus mainly on those who code, test, document, and promote.
Traditionally, of course, members of FOSS projects have been developers. Even today, developers tend to be the leaders of these projects because, as Spevack puts it, “it’s a technical exercise that we’re all doing, so the engineering side is most prevalent in terms of how vocal they are. Also, they’re the ones who are ultimately doing a lot of the heavy lifting.” As a result, coders still find a niche in a community more easily than ordinary users. “The challenge is in saying yes to folks who are trying to contribute regardless of their skill set.”
In Ubuntu’s case, Bacon believes that the emphasis on teams — that is, recognized groups within the distribution — is the most important step in encouraging participation from non-coders. Some of Ubuntu’s teams are officially recognized by the project, and others are impromptu, but together they create a range of obvious possibilities for newcomers.
Creating shared values
Like most FOSS projects, Fedora, openSUSE, and Ubuntu consider themselves meritocracies, in which each person’s status depends on his contributions and involvement. Yet, beyond this starting point, each of the three projects has its own particular values that it hopes to preserve as it grows.
For both Fedora and openSUSE, one of the first steps in creating a community was to become independent of the parent communities. For Lasarsch, encouraging that independence meant ensuring that openSUSE was entirely open source. “SUSE was always an open source software company,” he says, “but we had some restrictions. We got rid of all restrictions, and we try to be open as possible.” The only exception, he says, is “software like RealPlayer or Acrobat Reader. SUSE was always a beginner distribution, and we don’t want the user to download this essential stuff from somewhere else.”
Lasarsch also hopes to minimize control from Novell, which markets SUSE commercially. “We don’t want to control the community as long as there is no legal problem,” he says. However, he adds that, “because we are a company, we have really to take care about legal stuff and have some restrictions about what can be included in the distribution. For example, many users want [us] to include video players, but this is a legal minefield.”
Similarly, for Spevack, making Fedora a distinct organization from Red Hat “was a question of creating a vision of where we wanted to go and empowering the community.” An important step in this process was the emergence of leaders within the community with no direct ties to Red Hat. “We try very hard to make sure that the hierarchy is organic,” Spevack says. He is especially proud of the fact that half of the people on the six-month-old Fedora Board are “people who have already been identified as leaders in other parts of the Fedora community based on their contributions.” He describes Fedora Extras, the largely self-governing repository that arose spontaneously within the community to complement the official Fedora Core, as “the model project” for the rest of the community. By contrast, Spevack is cautious of drifting into the “trap” of having Fedora depend too much on Red Hat employees like himself who are paid to contribute to Fedora.
In the coming year, Spevack hopes that, following the upcoming release of Fedora Core 6, the project will not have to be concerned with providing the basis for another release of Red Hat Enterprise Linux for at least a year, and will be able to earn a reputation for innovation. “We can do things that previously needed to wait,” he says. “We were sort of worried that perhaps too much churn in the code base could lead to instability. The early adopter, the leading edge user — what I’d like to see is that sort of person excited by Fedora,” he says.
Other than these general directions, neither Lasarsch or Spevack has attempted to create a deliberate set of values within their projects. “We obviously have standards of common sense for conduct,” Spevack says, but, although unprofessional behavior by community members is lightly policed, his main concern is that all activities are consistent with the project’s technical objectives.
By contrast, Ubuntu has become famous for its Code of Conduct, which has become the guidelines for all interactions between community members. “This document outlines core standards of behavior that are natural to most contributors, but ensures that everyone is clear on our standards of working together,” Bacon says. “To be a member of the project, volunteers agree to the code of conduct, and it has proven successful in keeping the community ticking along nicely.” The code has also been cited as a reason for several prominent defections to Ubuntu from Debian, the distribution from which Ubuntu derives.
“Although the Code of Conduct is key,” Bacon says, “civility in a project is largely driven by how we work together. Factors such as balanced team leaders, respected community members, open processes, ease of getting involved, and an openness to new blood all contributes to keeping people happy. It is all about a balance between sane policies and the freedom to allow people to dig in and make cool things happen.”
As each project grows, its leaders expect to face the problem of scaling while preserving the project’s unique values. The problem, Lasarsch says, “is structures. If your community grows you need more of them. In a small community, everybody knows what the people are doing without documentation or roles. If the community is too big, this is hard.” Already, he expresses concern that as a leader, he can no longer follow everything as closely in openSUSE as he once did. “To avoid getting a buffer overflow in your head, you filter the most important topics,” he says. “For example, I’m not really following the documentation list, only scanning through the topics. Other core members might have no time to follow packaging or the wiki.”
The solution to preserving basic values, Bacon says, “is to always work as a community, and also to have community leaders who advise and direct the community in a sane direction. [Ubuntu] is a meritocracy, and those people who are good often inspire others to make similar inspired decisions. Sometimes, you just need to sit back, take a breather, and have a good honest look at your community and where it can be improved. There is always room for improvement if you are willing to find it.”
Leading FOSS projects
Asked what advice he would give others involved in building FOSS communities, each of the three community leaders agreed that simply creating the infrastructure for coding is not enough. “Offer people something, be part of the community,” Lasarsch says. “Communicate and listen, be open. We think building a community will not work when you just offer the infrastructure.”
Spevack says much the same. “To have the respect of the community (and this also goes for business, whether in the open source community or not),” Spevack says, “You need to let people know why things are happening. Not everyone needs to or even wants to get up and vote, but they do want to know there’s not really any secrets.”
For Spevack, building a FOSS community is similar to project management in general. “The biggest mistake that can be made is having barriers to getting things done that don’t need to be there or that slow things down. You’ve got these people who want to do stuff, and you need to let them. These people will be able to do incredible things more or less on their own, and all you have to do is every now and then give them a bit of a roadmap. You need to trust your community. The more that we can put that trust into action by giving greater ownership to the community, the better results we’re going to see.”
Similarly, Bacon says, “Building communities is partially about leading, partially about understanding. You need to be there in every situation. If you want to build a community, just throw caution to the wind, roll up your sleeves, and dig in. It really is a feel-your-way-in-the-dark kind of science.”
Bruce Byfield is a course designer and instructor, and a computer journalist who writes regularly for NewsForge, Linux.com and IT Manager’s Journal.
Category:
- Open Source
