In the first session of FUDCon talks this past weekend, Diana Harrelson reported on her anthropological study of the Fedora community, which she used to find ways to sustain and grow an open source development community. She studied the group from the Fedora 12 launch through the Fedora 13 development cycle while she was a master's candidate at the University of North Texas. (She now has that degree and is working towards a PhD in human computer interaction.) Here's are a few of her findings, much of which certainly apply across open source communities, not just to Fedora.
What's a community?
Diana noted that while 75% of the survey respondents in the study agreed that the contributors make up a community, she was more curious what the other 25% thought. Mairin Duffy, a member of the audience, suggested it might be that some think of Fedora "as more of a distro than as a community first." Someone else in the audience asked Diana if she defined community for these questions. She answered that the definition was up to the individual respondent, and that she had also asked them each what their definitions were. She also had some answers from that other 25%:
- Language is a barrier and splits the community. The LATAM contributions are large, but sometimes don't feel included because of cultural barriers.
- Some are split in disagreements over things like desktop environments--KDE vs. Gnome.
- Cliques arise between groups, e.g., developers and everyone else, newer contributors and older ones, or by those with access to certain levels of equipment.
74% of those who became Fedora contributors were users first
This isn't particularly surprising. In fact, I'd be interested in knowing what got that other 26% involved. But it is important, as it confirms that getting more contributors means you have to get more users first. One contributor summed it up:
"I started having doubts that attracting new users should be the ultimate goal in FLOSS even if the cost is making existing users uncomfortable. I think attracting contributors is a more important goal, so it's better to attract new users who have the potential to become contributors than just attracting more users."
Over half described the community as "somewhat easy" to "somewhat difficult" to get involved with
Respondents generally had different ideas of what was required to be a contributor, but the consensus was that regardless of the definition, it wasn't entirely simple. She repeatedly heard in interviews that the contributors had trouble getting started, which surely indicates that there were others who gave up.
"Setting up a login, setting up an SSL key, and contributing was a little daunting at first. That process could be simplified," said one interviewee.
Diana found that the ease of joining the community in many cases was directly linked to whether the prospective member knew an existing community member.
Collaboration
As you would expect, collaboration came up as highly important to the community. More than 50% said that they collaborate with others more than half the time, but a majority also said they wished they could collaborate more often.
Preference for method of collaboration was dependent on the person's role, e.g., designers tend to prefer email over IRC because of the time required and ease of send attachments, whereas packagers tend to prefer IRC for speed.
Why they do it
"My entire research was just to find out why you guys do it," Diana said in her talk. Motivation may seem more obvious to those within communities, but from the outside, it looks more like doing a lot of hard work for no pay.
High on the list of reasons were learning for the joy of learning and collaborating with interesting and smart people. Motivations for personal gain, like networking or career benefits, were low on the list. Self motivation, however, is important, as seen in comments from multiple contributors who said things like, "Mainly I contribute just to make it work for me." Or as another put it:
“It goes back to an age old idiom that programmers develop software to 'scratch an itch,' and it breaks out to 'a group of developers with a similar itch' so they write code to 'scratch' or satisfy that itch.”
Recommendations
These are just a few of Diana's recommendations based on her results:
- Gather community recommendations based on their reactions to this research
- Research ways to make becoming a contributor easier
- Look into ways to educate new contributors on contributing to open source projects
- Investigate the effects on contributors
- Examine further contributor motivations and how to better provide these
- Consider the effects
- Look in to special interest groups to combat cliques
I think her most useful recommendation, however, was to find ways to unify the community behind one common definition of Fedora. She found disagreement over things like whether it's a distro or a community, and who it's meant for. Gathering a community around a common idea and mission are critical to its success.
If you're interested in seeing more detail about the study, you can read Diana's longer report on her blog, where she writes about the anthropology of gaming, blogging, social networking, and online communities.
13 Comments