An anthropologist's view of an open source community | Opensource.com

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.

Tags

13 Comments

Hi Ruth-- very interesting. I love the observation that gathering a community around a common idea and mission is critical to success. Did she talk more about this recommendation, or was there any discussion in the audience about the Fedora vision/mission or the Four Foundations?

With regards to the common idea, the Fedora Board seems to have invested tremendous energy and time in coming up with a definition for Fedora (or, The Fedora Project) that participants can identify with. It would perhaps be an interesting exercise to see if decisions and discussions that led up to that definition have resonance with the findings in Diana's research.

That comment was really my observation on her conclusion that the community needed to be united behind a definition.

Nobody brought up the foundations... in fact, it's interesting how rarely I heard them mentioned in general at FUDCon. Maybe once, and I think that was humorously in passing between people who clearly knew. But there were several people newer to the community there who might have benefitted from a little Fedora primer session--somebody make a note for next FUDCon!

I didn't think about them when she mentioned that either. But if you read the comments from her interviews, there's clearly a gap in agreement about what this community is. Maybe it's time for another look at the mission?

that's because currently Fedora is driven away from the foundations, making the community very unhappy. at previous FUDCons, the foundations were everywhere... not so now, when we ignore them, trying to become the second Ubuntu.

I tend to believe that the Foundations and the underlying aspects of it need to be held out and discussed at meets where there are new users. In other words, at every meet. Perhaps not in the form of preaching from the pulpit but more in the conversational tack of how it is relevant in decisions - infrastructure, engineering and community.

More than the mission I'd think it is the vision that brings a group together to form a community. A vision allows a sense of trust, goodwill and helpfulness to shape up.

examples about abdications from the foundations:
- free: we at the Design Team are planning the use of SparkleShare, a tool depending on Mono (sorry for the "we", I am currently "on strike" from the team);
- friends: in the last years we have more flames than real work on many places... check the advisory board list; many peoples are disgruntled and leave.
- features: F14 was the release with the least number of features ever; we introduce policies and bureaucracy, features are delayed.
- first: see the item above about policies and bureaucracy.

Indeed. And, these have been brought up on the Advisory Board list and blogs often. However, I think that the part of Diana's work that I find important is using it to find the intersection - of a 'Board', a Project and it's vision and, its 'participants'. Note that at this point I am not using the word community yet. An idea about what would be good to get the cadence amongst a group of like minded folks needs fine tuning and revision. I believe that Diana's work allows that to happen. Or, at least can induce that to start.

I think we are getting a bit off-track for the article. However, I strongly believe that the existence of the Board provides a forum for itself to introspect, solicit comments and take decisions in the best interests of the community. A recent article at http://www.managementexchange.com/blog/moonshot/turn-%22they-should%22-c... had this quote that resonates with me ‎"If the community isn't invited on the journey, it will reject the destination."

I was one of Diana's lab rats and I see some of my own words/ideas even in this very article... it would be interesting to hear the same people now... I, for example, am really disgrounted... we stopped "scratching the itch" and chasing some illusionary targets that don't give any return but make our lives harder.

I haven't used it for years, but have a nagging suspicion that the entire Linux community is permanently disabled by the KDE v. GNOME divide. "A lot" depends on a smooth, predictable, and polished user interface stack. This is really complicated (when not broken), and energies/resources squandered, by advocates on both sides of the desktop wars. "Better is the enemy of good enough" really applies here.

No doubt that it's fun tinkering for many. But I think it's keeping Linux a ghetto.

Vote up!

0

Vote down!

0

Ruth Suehle leads community marketing for Red Hat's Open Source and Standards team, including the Fedora Project and is the moderator of the Life channel here on opensource.com. She's co-author of Raspberry Pi Hacks

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat.

Opensource.com aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. Red Hat and the Shadowman logo are trademarks of Red Hat, Inc., registered in the United States and other countries.