Masters Research: Study of the Fedora Project

BETA: An Exploration of Fedora’s Online Open Source Development Community

What you are reading here is a report crafted for the Fedora Community. If you would like to read the full thesis (far more academic than what is provided here) please email me – diana [@] cyber-anthro.com.

Researcher
Diana Harrelson – Masters Candidate in Anthropology at the University of North Texas (graduated MS Aug/2010, PhD May/2016)

Research Purpose
To find out how to maintain, sustain, and grow the Fedora Project’s online open source development community.

Time Period
I entered the community just prior to the Fedora 12 launch and conducted all of the research during the entire Fedora 13 development cycle. November 2009 through May 2010.

This report is divided into 5 sections.
Section One: Getting Started
Section Two: Turnover
Section Three: Collaboration
Section Four: Motivation
Section Five: Community
   

 
 
 
Section One: Getting Started
Getting started in a FLOSS (Free Libre Open Source Software) project, especially your first one, can be an interesting process. One that is filled with new experiences, perspectives, and purposes that are unique to the FLOSS culture. Part of my research focused on just how those who wanted to became contributors and what they thought of the process they went through.

Question: How were you introduced to the Fedora Project?
74% said they were first users of Fedora and then became contributors to the project.

This finding, while not surprising, is significant in that if you want to attract a certain type of contributor, the project should make an attempt to attract them as a user first.  This should be looked at as an integral part of answering the question of how to attract new talent to the project.

So the question then is, how do you attract users that have the potential to be contributors?

As one of the interviewees stated:

“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 is better to attract new users who have the potential to become contributors than just attracting more users.”

Recommendations

• When considering a target audience for Fedora, considerations should also be made that this target user audience is also a target contributor pool

Attracting new contributors, however, is just part of it. What happens after a user gets the itch to become a contributor? How easy is it to move from one context to the next?

Question: How easy was it to get started as a contributor to the Fedora project?
The majority, 44%, said it was somewhat easy to get started, while 28% said extremely easy and 25% said somewhat difficult.

Several people stated that they had some sort of issue trying to get started as a contributor. I didn’t specify a particular step or set of steps in this question because after conducting the interviews everyone had a different idea of what was required to become a contributor.  That meant that this question addressed whatever method or steps the person answering it deemed as necessary and their own conception of the degree of difficulty.

Just a few things contributors had to say:

• A complete set of actions for a user to take in order to get from zero point to the point where he will be actually modifying code/docs/translations is unclear. The path along several different step-by-step manuals with no explanation of the purpose for each step in sight of the whole authorization process seemed daunting for me as for a beginner.
• At the time I first decided to get involved, there wasn’t much information on any wiki or other websites about how things worked.  I was too intimidated to post on the mailing lists (which one?  Am I using proper netiquette?) and ask what Rawhide was. The wiki has been much improved, which is critical for those like myself who have less of a social connection to the internet.
• legal hoops and no mentors. It is a complicated self-starter program.
• Setting up a login, setting up an SSL key, and contributing was a little daunting at first. That process could be simplified.
• I think there is a certain amount of background knowledge that is required to get involved in many areas of the Fedora Project which is the only reason I did not rank this as “Extremely Easy” because beyond the background knowledge that is needed the processes, policies, and procedures are very well documented and the Fedora Community is very helpful in guiding new contributors.
• Existing contributors are helpful but there [are] huge technical things to learn.

Most of the issues mentioned above focus on technical hurdles or simply not knowing where to go or what to do in order to become a contributor.

As is alluded to by the following quotes, ease of entry seems to be determined by whether or not you already know someone within the community, or know how to (or even that you can) find a person within it to help.

• I was lucky to start in Fedora very early and met several people involved in Fedora who worked for Red Hat and who showed me how to get started.
• Since I was already into Free Software projects and development when I started working on Fedora and the fact that I personally knew some Fedora contributors made the learning curve quite easy for me.
• The more experienced members of the community were extremely willing to help out with any questions I had, no matter how ridiculous the questions may have seemed.

A possible solution to any perceived barriers to becoming a contributor could be addressed by providing easy ways of finding and accessing people already within the community who can and want to help.

As an interviewee stated:

“So I think we are pretty bad at having resources where novices can stumble across things on their own and “get into” the community all by themselves. But we’re really good at – when an existing community member meets a new person, they can usually help them get started very well. And that’s the thing – I think that our materials, perhaps, should be more geared towards “find a person to help you through this stuff.” I think they try to be, but they aren’t always clear enough. Because being part of the community is about working with the people.”

Beyond the process behind the idea of becoming a contributor, the idea of just exactly how to contribute seems to be another barrier to entering the community. Though users may be familiar with the idea of open source from a users perspective, this does not mean they fully understand what it means to be a contributor to an open source project. This is especially true for those who come from traditional leader base backgrounds where someone ‘in charge’ directs their actions.

Survey respondents stated:

• The second barrier was figuring out that I had the authority to do stuff. I kept waiting on people to tell me what to do, which doesn’t work well.
• It’s difficult to find your entry point, no matter how welcoming people can be.
• I’m new here, want to contribute more, but don’t know how.
• Very easy, the hardest part is getting started and helping out.
• Well, I’ve gone from user to contributor (as previously described), and that feels great – I’ve wanted to do it for years, but never figured out how (or was aware that I was “worthy” to do so) until relatively recently.

As the interviewee below states, contributors to open source projects are largely autonomous in that they “pick up” what needs to be done, do it, and then present it back to the community for approval.

“Tasks float by as tickets, as “this might be cool” emails to mailing lists… sometimes they’re detailed tasks, sometimes they’re vague ideas. I pick ’em up by working on them (when I want to) and showing what I’m doing publicly – usually in IRC in realtime, and then on the mailing list as a summary once I’m done with the first frantic sprint.”

The key here, and the large difference between FLOSS development processes and traditional ones is that it’s not the act of doing something that needs approval; instead, it’s the result of the action and quality of the work that must be approved. Again, this is where not only having a mentor program for new contributors is useful, but also making such a program highly visible, transparent, and accessible is important. As a point of observation, the quicker a contributor can jump in and start feeling productive, the more positive their experience and the more valuable their contribution to the effort.

Furthermore, based on my own experiences and observations as well as those I interviewed, there seems to be a window of opportunity for someone to easily jump in as a contributor.

“Right after a release, I think we do a great job. The closer we get to a release, the worse we do. Most of the active participants put a lot of energy into the release and the closer it is to the release the less we have towards outsiders. […]Basically, we need to make it a priority for some group to deal with the initiations and cultural rules so that outsiders and insiders can feel more comfortable where they stand. This is to also give Greg/Max/Paul some room to ‘breath[e]’ as they have been doing a lot of this and others need to help them.”

This opportunity right at the beginning of a new development cycle should be made known to and capitalized upon as much as possible by new contributors who wish to gain entrance and acceptance quickly, though the latter can sometimes still be a little difficult to achieve.

The technical and timing problems aren’t the only potential issues for new contributors to the project. One of the most essential parts of the process is to be accepted by already established contributors. As one interviewee stated, this is a current problem that needs to be addressed:

“We have the bureaucracy down right, and with a good mentor, it’s never a problem to get people set up with working accounts and group memberships. I think the hard part is the acceptance of skilled people into various groups. Confidentially speaking, I think the newcomers can be put off by the prevailing attitudes of established people who aren’t willing to accept them and integrate them. Newcomers really have to give a shit and really produce a lot before they are accepted.”

Other recommendations for new contributors by established ones:

“You have to observe the community for a bit (often this is called “lurking on the mailing list”) and learn about it: the rules, the procedures, the people, the atmosphere. When you talk for the first time it’s useful to mention you are new so people will take you easy and also don’t be arrogant.”

“[I] am constantly reminding [new] people, show success first, then start  making opinions, because otherwise, it’s hard to get them accepted by  the core set-in-their-ways community members.”

Recommendations
To recap, while 28% of those surveyed stated it was extremely easy to become a Fedora contributor, over 50% stated it was somewhat easy to somewhat difficult. Potential barriers include technical difficulties, lack of understanding of how open source projects work, timing, and acceptance by established contributors. Recommendations here include the following:

• State what exactly is the minimum required for people to be able to contribute
• Provide easily accessible step-by-step information on how to go through the technical steps required
  • Include these even if they are optional
• Provide easily accessible information on how to contact people who are willing and able to mentor new contributors
• Provide a timeline stating the best times to join the project
• Reaffirm to the established contributors the benefit of new talent to the project and setting up ways established contributors can easily make newcomers feel welcome

 
  

 
 
 
Section Two: Turnover
One of the many benefits of participating in FLOSS development projects that should be highly promoted is not only the ability to choose the type of projects you want to work on but also the ability to change from one type of development position to another if you so choose. While turnover in any system is usually considered a bad thing, within the FLOSS world, many people seem to consider having been in multiple positions a good thing. This tends to not only give the contributor more breadth and experience when it comes to how and why things get done in FLOSS, but also gives them opportunity to find their niche as well as greater ability to mentor to others coming into the project.

Question: Have you ever changed roles?
Only 20% of those surveyed stated they had ever changed contributor roles and over 78% of survey respondents have been a part of the project about 2 years or longer (top percentages breakdown: 22% of people have been in the project about 2 years followed by 16% about 3 years, 15% less than a year & 14% since before it was the Fedora Project), it seems people have longer tenures and the project has a higher retention rate than previously suspected.

Transfer of Knowledge
Other considerations when dealing with turnover are whether or not there is an established way to transfer the knowledge from those leaving a position to those coming into it. Due to the fact that there is a large amount of retention within the community, though someone may leave a position, they are still available to share their knowledge with those who need it. Additionally, during the time my research took place, new procedures were put in place to document processes. While both of these options provide opportunity for recording, saving, and sharing information, which are all very much important, none are viewed as strictly necessary due to the fluidity of FLOSS development and the autonomy people are given to do what they feel needs to be done in any given position.

“That way, we pass the bus/raptor test – that is, if any one person gets eaten by a bus or hit by a raptor, the project can continue. That having been said, it’s *also* acceptable to improvise from nothing, especially if you did a quick search for instructions and didn’t find them.

We try sometimes to leave waypoints for the next people (and we don’t know who they might be someday) to pick up on, and we also figure that people will make their own way anyway, so they’ll figure stuff out regardless of what we leave them (it’s just that maybe if we leave them stuff that happens to be useful they may be able to figure it out a little faster)
Generally, once you pick up a task, it’s yours; once you put it down, it’s someone else’s. That helps avoid bottlenecks quite a bit. It’s not perfect, but that’s the cultural expectation we aim for, I think.”

Survey Bias
Something that was not considered in this line of questioning though was targeting how many people currently contribute in more than one way and how often do they tend to contribute to one of their many roles more than the others.  This would not be the same as changing roles; rather it is more about dividing their time amongst several roles and this time among these roles changing throughout the project.  It is my estimation that the “turnover” issue isn’t so much with people changing from one role to another, but rather people becoming overwhelmed by the sheer amount of roles they take on all at once. Having multiple roles creates a possible issue with the contributor not being able to devote as much time and effort as needed to key roles. This could have more of an adverse effect on the community than changing from one role to another.

Recommendations

• Efforts should continue to be made to pass the bus/raptor test with both documentation and retaining access to veterans who recently vacated roles
• Those coming into newly vacated roles should be made aware that though there are documented processes and procedures, they have the freedom to make changes to these as necessary

 
 
 

 
 
 
Section Three: Collaboration
In most cases, contributing to FLOSS projects is a highly collaborative process. This is another feature that sets apart FLOSS development projects from closed development ones.

“While coding remains an essentially solitary activity, the really great hacks come from harnessing the attention and brainpower of entire communities. The developer who uses only his or her own brain in a closed project is going to fall behind the developer who knows how to create an open, evolutionary context in which feedback exploring the design space, code contributions, bug spotting, and other improvements come from hundreds (perhaps thousands) of people” (Raymond 51)

Throughout my research collaboration was referred to as a very important part of the process of developing FLOSS.

“Being able to share ideas (both good and bad, many half-baked, some that get no response – you try a lot of things and a few of them work) with other people riffing on them feels like the difference between solo piano and a jazz jam.”

Question: How often do you collaborate with others on the Fedora Project?
Over half of the survey respondents stated they collaborate with others 50% of the time or more.

Question: Do you collaborate as often as you like?
Almost 60% of respondents stated they wish they could collaborate more often, whereas 40% stated they collaborate often enough.

In both in the interviews and on the survey, respondents were asked to describe the people with whom they work. Most people within the project have a very positive view of their co-developers. One of the reasons for this is as with the other aspects of FLOSS projects, contributors get to pick and choose those people with whom they want to collaborate.

Here are a few ways people chose to describe what it was like to collaborate with others on the Fedora Project:

“Kickass. I don’t really know how else to say it, we just have this amazing community full of intelligent developers and I’m lucky enough to work along with them and I’m able to work with a group that I feel share similar goals that I have. These guys are just simply “kick ass” in every aspect, they are great developers, experienced RPM packagers, and great at communicating which helps us as a group move the workflow forward.”

“Fedora contributors are some of the most amazing people I know, quite frankly. Coming from a [different] environment, I’m mostly exposed to the low end of the “I’m motivated to do cool things” spectrum, in the “I’m here because I have to, and I’m going to make sure you know that” area. Compare that to the “I’m in Fedora and I love it, and I want to _do_something_awesome_!!” feeling that you get from nearly _anyone_ working in Fedora :-)”

“The Fedora Community has among it the smartest, brightest and most thoughtful people I have ever met.  I’m always happy to work with someone from the Fedora Project because I know they will consider me intelligent and thoughtful, much like I will consider them.”

“That’s the bonus in a free community, you can choose to work with people you like, so I like the people I work with. For a few of them, I even have respect, I acknowledge they are more skilled than me in certain areas. Those I know are usually smart and enthusiastic. […] Why I would want to work with people I don’t like? If only for money, then you get tired and burned fast. Working with people you like does not feel like work, is like having fun with your friends AND producing something useful. Also, when you like and know the people you work with, you have better productivity.”

As is the case with FLOSS development, most development and collaboration efforts occur online through methods such as IRC and email lists.

Question: Which collaboration method do you prefer?
IRC came in first with over 50% and email/ lists came in second with over 35%, whereas phone and video were ranked least preferred.

These methods can be further broken down among the preferences by different roles within the project.

Most preferred methods by Role
(% = Survey respondents who identified with that role)

Though there are several different methods of collaboration it is easy to see the two main staples are IRC and email/lists.

While they didn’t rank very high, face-to-face methods such as Fedora Activity Days (FADs) / Hackfests & FUDCon as well as other face-to-face opportunities were all spoken very highly of by those who had had a chance to attend them.

“It is said that after seeing someone face to face, you are less likely to have a flamewar online, because he is now a person, not just a stranger on the other end of the internet. But there are also people you work with day to day, know how them look from photos and maybe a video, you will be able to recognize their faces in a crowd, but you don’t really know how they are before meeting in person. And, honestly, most of us are geeks, not very good on personal skills, so meeting other geek fellows is good for our social lives.”

“I have some of the most fun in my life interfacing with contributors in Real Life, for example. At the FAD we had more fun than I have had since I went to Camp KDE in January and spent my birthday with some of the most fun and smart people I know on the beach in California. And even now, I’m finding ways to just hang out with contributors on a daily basis.”

“It’s extremely important for building the initial relationship and occasionally refreshing that with people. There are of course people who we never meet and we work well with them. However, something about the in-person relationship building rapidly accelerates the process. People who I have only met once or twice, and often only for a day, have become very beneficial. My first fudcon was a dramatic change in my pattern of participation, it really broke me out of the cycle of staying in my own niche.”

Ideally, the ability to experience both the electronic and face-to-face methods would be very beneficial to contributors.

Improvements
Though most said they liked the tools just as they were, others offered their opinion on ways some of these tools could be improved.

• Mailman list archives could be more usable/searchable
• Meeting bots in IRC could automatically send their minutes to mailing lists (and post them on the wiki), and remind contributors of meeting start times
• Wikis could have collaborative WYSIWYG – imagine the front end of etherpad as an edit interface to MediaWiki. (That having been said, this would be an immense engineering undertaking.)
• We could better document/teach our tools/culture to others – IRC seems natural to me but was extremely foreign when I started. Honestly, a lot of what I’d change is usage habits (“log all conversations to the mailing list!”) not the tool itself.

Other improvements mentioned include capitalizing on more current methods of communicating online that would not only allow more people to participate but also give Fedora the ability to have a more public/searchable face that is not possible today due to the use of IRC and email/mail lists.

“Fedora’s biggest weakness is its failure to exploit social web effects, such as forums. See the strong community ubuntu has built with their forums and brainstorm and launchpad. When I Google Linux problems, the search results are filled with ubuntu links. When is Fedora going to respond? Mailing lists are harmful. If I want to blog about a useful tip I learned in the mailing list, I can’t include a link to the mailing list post until I search for it in the mailing list archive. Ugh! Forums are much better. If a thread is off topic, it can be moved to an appropriate forum and renamed. Can’t do that with mailing lists. The recent “hall monitor” debacle left a bad taste in my mouth. Moving a thread instead of declaring it closed is much more palatable from a freedom perspective. I have a FAS account, so why do I need to create a new account to subscribe to a mailing list. Keep fedora-devel as a mailing list. But create forums for user support. Google doesn’t require separate accounts for Gmail, Calendar, etc. Let’s get on the ball before it is too late. Ubuntu’s expanding mindshare is dwarfing us. I want Fedora to win.”

Recommendations

• Make information as accessible, searchable, and reusable as possible
• Provide more modern methods to collaborate in conjunction with currently used ones allowing the project to be more visible and accessible to outsiders / new contributors

 
 
 

 
 
 
Section Four: Motivation
One of the most interesting questions concerning open source development is why do people volunteer their time to something for which they receive no monetary gain? This is important for contributors so that they find a project that meets their needs as well as for FLOSS projects so they can make sure they do what they can to meet the needs of their contributors.

Throughout my research, I have found that the culture of FLOSS contributors is one in which self-motivation is a key component to becoming a contributor in the first place.

“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.”

“Mainly I contribute just to make it work for me.”

“Taking care of my own needs in Fedora (if something gets broken, there might be nobody to fix it unless I report it because it may work for everyone else).”

Scratching an itch is just how they get into it. The real question is, what keeps them motivated?

Question: What motivates you to contribute your time and skills to the Fedora Project?
An in depth analysis was performed on all of the interviews to narrow down possible motivations of project contributors. Those motivations were then provided as possible answers to the survey question listed above. The respondents were asked to rank each of them on a scale of very important to unimportant. Below is the break down of the overall stats for Very Important and Important followed by the motivations that ranked highest by role.

Although none of the motivations mentioned above ranked above 50% on ‘very important’, it is also noteworthy that only one of them ranked below 29% on ‘important’. What is also interesting to note is those motivations that are more ego driven are ranked lowest where those that are more altruistic are ranked highest.

Motivations by Role

Interviewee statements on motivations for being a contributor to FLOSS projects:
Free software is enabling because it encourages you to participate, to make it your own, by adding your own contributions to it. Free software is empowering because it rewards participation. Others use your contribution, which gives you a sense of satisfaction, even better when someone comes along and builds on your contribution. You have tremendous feeling of accomplishment, occasionally even self-actualization when you move past using free software and into participating.

“I enjoy doing something challenging, and doing it hopefully, well. I feel very much a part of the community. I don’t want to let my fellow community members down. I also get a bit of a rush when I show off Fedora and think, “I helped build that” even though it’s an inconsequential piece.”

“I feel that my participation has been helpful for many people I’ll never meet. I look at FOSS partially as a way to collaborate with and learn from very smart people (i.e. a lifetime learning experience), partially as a way to build marketable skills for the future, and partially as a humanitarian pursuit.”

“Happiness. It feels like what I should be doing, if that makes sense. I also get to work with a lot of great people on something that genuinely changes the world, somewhere I can rapidly innovate and try interesting experiments; I get to build my technical skill and constantly have this sense of playing around, having fun, adventuring – in a way that Gets Stuff Done”.

“I feel great. Knowing that my work makes it so schools in haiti, india, and elsewhere are using computers powered by Fedora makes me happy. Even before I was working Red Hat, my drive on Fedora was the feeling of being part of something bigger than myself that makes people live better lives.”

As you can see above, people get just as much out of contributing to Fedora as they put into it.  Not only do they enjoy doing the work they do, but the results of their work also provide a sense of happiness.

Happiness
In her 2008 keynote speech to the SXSW Interactive crowd Jane McGonigal talked about happiness being the new capital to be sought out in life. She conducted in depth peer reviewed research on happiness and came up with four key principles:

• Satisfying work to do
• The experience of being good at something
• Time spent with people we like
• The chance to be a part of something bigger

While she related this to gamers and gaming, I believe that this also seems to fit the context behind the motivations of FLOSS contributors as based on the research presented above.

So the ultimate motivation? Happiness of course!

Recommendations

• Encourage self-motivation among new and tenured contributors by providing ways for them to see how their contributions are making a positive impact in the world.
  • Providing real life examples of how their work makes a difference that they can actually see would be a huge motivating factor.
• Provide more ways for and encourage more contributors to not only collaborate but also socialize with people they like within the community.
  • Playing pool with the contributors at FUDCon Toronto was an amazing experience even for me. Afterward, I enjoyed being a part of the group in the hackroom that put together apps for a design spin.
• Provide ways to help new and tenured contributors find their niche within the project where they are able to contribute the most.
  • Being good at something is a great motivator.
• Setup workshops within the community where thought/technical leaders are able to freely share their skills with others outside of project directives. This provides a motivational point for both sides of the equation – those who want to and can share as well as those who want to learn more.
  • Speaking from personal experience I found Mo’s Inkscape demonstration at FUDCon Toronto very inspiring and motivating.

While there are many positive responses to why people are motivated, the flipside to these are those things that contributors would change if they could.

Question: Have you ever considered ways to change the Fedora Project?
57% of survey respondents said yes, they had considered ways to change the Fedora Project.

Here are a few of the things they had to say:

• Better communication methods. What we have sucks.
• Fedora can increment its user base if it can introduce a commercial option of its releases (boxed version with manual).
• Fedora changes constantly. I find it important for Fedora to lower barriers to contribute which necessarily involves peer increase of visibility e.g. by the means of peer reviews, which in turn imply increased collaboration. Simply put, more people personally responsible for maintenance of a simple package would help tremendously.
• Fedora Community is great but still, there are people who I find really hard to talk to because they don’t understand that there are also non-English native people out there and that communication for us is a bit harder and then they get offended too easy! Also, we need to make women feel more welcome!
• Fedora needs to decide what it is. This nebulous branding means that people all think they Fedora is a democracy, a movement, a monarchy, an anarchy, or just a set of packages.
• Finding ways to reduce the risks to our community posed by people who are constantly negative or otherwise toxic.  We should always allow dissent but it should not become the focus of our work.
• Automating any manual task would help enormously.
• I would abolish the high number of mailing lists. I find them counterproductive. On a similar note, I think that while it’s a nice goal to bring in as many people as possible, we need more controlled entry points and to be more selective on who really has a voice. The idea of what is a contributor is too vague and broad and serves no one. I would also pay to have an outside marketing firm do a proper marketing analysis and determine who the real target audiences are. They would determine where we want to focus our energy on and have them train people to use proper statistics and numbers to define if the community really is a success. Finally, I would remove a lot of the bureaucracy, and have the Board be entirely elected by the community.

Recommendations

• Provide ways for people to offer suggestions and feedback on community-wide changes publicly to the community.
  • Consider providing an anonymous option to garner more participation and feedback
  • If this already exists, make it more publicly accessible / noticeable
• Make it more obvious that people have the power to suggest or make changes themselves.

 
 
 

 
 
 
Section Five: Community
There are several definitions of community or a culture. From an anthropological perspective, the most basic definition is a group of people who share a set of language, artifacts, and beliefs. When considering a community such as the Fedora one the most appropriate dictionary definition is, “a feeling of fellowship with others, as a result of sharing common attitudes, interests, and goals.”

Question: Would you call those who collectively participate in the Fedora Project a community?
Over 75% of survey respondents said yes, the Fedora Project is a community.

Several respondents had very positive comments on community:

• Absolutely fedora’s participants are a community working together to produce something great.  I couldn’t imagine thinking otherwise.
• Everyone’s involved in decision-making, helping others, etc.
• Helping each other, working together, being (mostly) friendly to others, not adding a price tag – the combination of such things makes it pretty much a community.
• It is definitely a community since it’s a group of people with common interests and a common goal
• My understanding of the difference between an arbitrary group of people and “community” is the relationships between the members that enables the individuals to achieve together more than they would achieve each alone (by the means of collaboration). That definitely happens.
• We’re a common group with a common set of values, ideals, and goals. There are subgroups within that have more specific goals that they hold near and dear which spawns the Special Interest Groups but the community at large is still very unified and I think that defines us.

On the importance of community to Fedora:

• Community is the place to hold people together. There are so many FOSS projects to be contributed. Why here? Because the community here is more appealing to me. I think I am not the only one who joined Fedora Project for this.
• Community provides the base to thinking in a collaborative manner with discussing things altogether, its definitely important for success of a project
• I think so – I think that the cost of RHT or any other group going it alone for something the size of the Fedora Project would be cost prohibitive. Additionally, as a volunteer effort the people are passionate about Fedora, and want to do a good job. That passion is rarely found in a company once it gets past the startup phase.
• The community is the driving force behind fedora. Since a lot of contributors see contributing as more of a hobby than a chore, they are more passionate about what they do. Also, most contributors are also end-users, so they themselves benefit from their contributions.
• Without the community we are lost, without the community of common goals and ideals, we would find ourselves in a “herding cats” situation where there would be no common interest or direction. The collaboration that is shared within members of the community the Fedora Project would not be possible.

All of those interviewed agreed that Fedora was a community and a few had a comment or two on the matter:

 “Absolutely. The community *is* the project. The community drives the project, makes the project – without the community, we’ve just got a bunch of (rapidly rotting) bits.”

“Without the community I can’t see a project of this scale succeeding. This is a community that spends a lot of time with one another on the internet, without cooperation and a general feeling of community then there would be too many disagreements and fighting to ever get anything done. Without these common goals and general ideals that we as the community at large share we would never more forward as we would always be pulling in different directions.”

“The community *is* the project. The project isn’t just a bunch of bits but how it comes together.”

“The community is the reason so many are passionate about working on Fedora. Generally speaking the people within the community are so thrilled to work on Fedora it’s infectious. I have found that I am generally far more excited to work on Fedora and F/LOSS in general after I have been around Fedora contributors, particularly in person. You come away with a feeling that what you are doing is important, and that failing to deliver your part is letting down your friends in the community.”

“Some parts of Red Hat don’t realize this yet, but the real value in the project is the community. Without the community, Fedora will fail  – – not that RHT couldn’t toss enough money to continue producing the distribution, but the project would fail to meet it’s mission/goals or stand up for it’s philosophy.”

While it is important to see why people think it is a community, it is just as important to understand why 25% of the survey respondents did not think it is a community as that is where we will find opportunities for improvement.

The quotes below are from those who responded “No”:

• I used to believe that it was a community, but it seems more like a grouping of various anarchists and monarchists who think everyone else is like them.
• a gaggle, a cluster-fuck that somehow works kind of in a way
• I don’t feel that they would like to be called 🙁
• More of a super-clique

Cliques
Cliques were also brought up during the interviews and most portrayed them as “anti-community”.

“Open community is critical to forward progress and innovation vs the community is a ghetto that must be managed in small, tightly-controlled elite pockets. This cultural conflict is the one that peeves me most. I’ve seen it coming from the GNOME upstream community. E.g. they literally have a secret #gnome-cabal channel on gimpnet IRC where only the elite old-timers are allowed to join where many decisions are made and discussions had that the majority of the community is not privy to. It’s been in existence for years.”

“There seem to be various cliques that form as people find areas they excel at and areas where they don’t. I don’t think it reaches High School levels, but there are probably times where it does (oh no you can’t let bobby join… he’s a developer…)”

“To my mind the cliques are made up of people who share mutual interests with possibly some sub-division towards language/locality. […] Somewhat is privilege. People who have the fanciest computers hang together because they can compare how many pixels their new toy has and people who are on the other end hang around talking about how much they can get out of an old Pentium 100. In other ways its mutual likes and language. […] And of course, they can be detrimental when someone feels outside of the group but wants acceptance and for whatever reasons the group does not want to accept the outsider. Or when groups clash”

Another not so obvious clique are how developers are viewed versus everyone else:

“Because Fedora places a very high value on code and the whole notion of “providing a patch” if you don’t like the way it is. The sharpest and most outspoken technical people tend to be elected to the leadership positions, not because they would be the *best* leaders, but because they are the most well known and outspoken, and often most opinionated and willing to debate issues to the death by having the last word over email. I have little time or interest for engaging in these unending debates where most people are more interested in giving their own opinion vs. listening to or considering the merits of someone else’s.”

“I think I am part of the community. I am not a developer, but I find that my system administration skills are useful for others.”

The issue with cliques is the exclusivity and lack of transparency with the rest of the community. In the book, ‘Producing Open Source Software’, Karl Fogel states FLOSS projects should avoid private discussion.

“Making important decisions in private is like spraying contributor repellent on your project. No serious volunteer would stick around for long in an environment where a secret council makes all the big decisions. Furthermore, public discussion has beneficial side effects that will last beyond whatever ephemeral technical question was at issue:

• The discussion will help train and educate new developers. You never know how many eyes are watching the conversation; even if most people don’t participate, many may be tracking silently, gleaning information about the software.
• The discussion will train you in the art of explaining technical issues to people who are not as familiar with the software as you are. This is a skill that requires practice, and you can’t get that practice by talking to people who already know what you know.
• The discussion and its conclusions will be available in public archives forever after enabling future discussion to avoid retracing the same steps.”  [Fogel 10]

Recommendations

• Promote SIGs or Special Interest Groups over Cliques.
• Make all discussions public. This serves many interests as stated above.
• Give people the ability to have a voice without being chastised for their opinions thus allowing them the ability to speak in public without feeling they have to go behind closed doors to have their opinion heard.
• Be supportive of opinions that may be very different from your own. It is diversity that helps communities thrive and grow.

Another way to avoid cliques is to help provide unity to the community by having not only a clear mission statement but also a clear view of what the community is about. One of the first points of contention I was privy to was a discussion over what is Fedora.

Question: What is Fedora?
This was an open-ended question asked of both interviewees and survey respondents. I gave no other prompting to this question as to not influence the answer in any way.

Here are a few survey responses:

• *The* Linux distribution for developers.
• A fantastic community of diverse people who work together to spread the word of freedom and open source via its primary product, the Fedora distribution.
• A group of people and a project striving to build a Linux distribution serving various purposes.
• A Linux distribution which applies the FOSS philosophy to innovated technology. A FOSS community which focus on doing the real work (not the fancy eye candies) to improve Linux usability and functionality.
• A linux project and distribution that always leads and never follows which not only means in technical terms but also in terms of user experience and how the community is organized and works. Always trying something new, being first even if once in a while it’s a bit much of a bleeding edge. Focuses on being friends with others like fellow contributors, upstream, downstream but also competitors. Of course all in the name of freedom!
• An average linux distribution that could be great if we were more focused
• Fedora is .. a project that explores and pushes the boundaries of Linux and open source, staying true to its origins while looking ahead at the “what if”.  It is reminiscent of the old Linux but in a package that streamlines old-school annoyances so you can get to the “next level”.
• The distro that used to be focused on server side deployment. Now the distro is unfortunately more focusing on the desktop experience than on the bottom layers and special apps.
• There are a lot of Fedora’s, but when I hear Fedora, I think of the Fedora Project.  The Fedora distro is great, but it isn’t as unique as the Project, when compared to other distros.  The Project, tho, is this amazing group of very smart people, committed to each other and to the success of the Project.  They not only believe, but they live the four F’s, which makes it quite a magical environment to contribute.
• Two years ago, i said Fedora is a workbench where any tinkerer can come along, pick up a project and start playing with it. Two years wiser, i would say it’s a community of people all looking to achieve their own goals with no idea of what the community is anymore.
• We are Fedora, you are Fedora, and I am Fedora. Fedora is, and always will be, an open source collaborative effort to enhance the open source software movement by empowering a community that empowers itself. It is the living, breathing, moving ideal of the open source software movement. Fedora as a community collaborates outside the bounds of geographic constraint, outside of language barriers, and outside of the shackles of closed source development. Fedora is the future of computing.

The diversity among these responses isn’t necessarily an issue as most community members have a personal view on Fedora, which is to be expected in a community of volunteers who all participate for their own reasons. However, the fact that they are all different is also a clue as to how focused the Fedora Project appears not only to insiders, but likely to outsiders, potential users and contributors as well. Though these are important things to review and consider as a community, there is also the danger of becoming to inward focus. As one interviewee said:

“Fedora’s greatest weakness these days is its navel-gazing.  The biggest topic within the Fedora community *is* the Fedora community.”

Recommendations for further study:
Here is where I usually provide paths that would be helpful to study further, however, I think given the participatory and exploratory nature of this research project it is up to you the community to decide after reviewing this report what you think would be worthwhile to study and delve into further.

Here is your chance to respond! What did you think of the results presented here? Have you found anything insightful or useful? If so, what and how? Do you have questions? Please let me know. You can either reply to the post on my blog where you found this report, or you can email me directly: Diana [@] cyber-anthro.com. I look forward to hearing from you!

Appendix A  Methods and Demographics

Methods Used
Participant Observation

• Attended FUDCon Toronto, participating in hackfests, spin designs, attending panels, and just general hanging out
• Visited and participating in multiple IRC channels
• Read blogs and blogged about Fedora

Semi-Structured Open Ended Interviews

• Qualitative
  • Performed to elicit information in an exploratory manner about the community
  • Call for participants occurred via:
    • Blog (on Planet Fedora)
    • IRC (multiple channels)
    • Email (via lists and contacts)
    • Contacts made at FUDCon (contacted via email / IRC)
    • Word of mouth from other participants (FAD particpants)
  • Information gathered here was analyzed via Atlas.ti (qualitative analysis software) and used to create the community wide survey
  • 15 interviews were initiated
    • 13 of 15 Responded in some form
    • 11 of 15 Responded to the extended question / answer session
  • Most were conducted over email
    • One was very successfully conducted over IRC

  Fedora Contributor Survey

  • Quantitative
    • Based on the qualitative data gathered during the interview phase
    • Allows the ability to test the data gathered during the qualitative phase so that it can be generalized across a broader sample and be more representative of the community
  • Survey was provided to the community during the final two weeks of the Fedora 13 launch
    • May 10th – 21st 2010
  • Created using LimeSurvey a FLOSS survey tool
  • 103 usable responses
    • Responses were exported from LimeSurvey into PASW/SPSS (quantitative analysis software) for analysis.

  About the Participants
  Participant Observation
  FUDCon / IRC

  • All ages
  • From all over the world
  • Red Hat and non Red Hat employees
  • Men and Women
  • New and tenured contributors
  • Spanned multiple roles

  Interviews

  • Age from 18 to 40+
  • US and European
  • Red Hat and non Red Hat employees
  • Men and Women
  • New and tenured contributors
  • Spanned multiple roles

  Survey

  • Age from 18 to 55+
    • Majority 25-34
  • From 30 different countries
    • Only 32% from the US
  • Red Hat and on Red Hat employees
  • Men and Women
  • New and tenured contributors
  • Spanned multiple roles
    • Design                                                        08%
    • Development                                                23%
    • Documentation                                             15%
    • Infrastructure                                                09%
    • Mark/Promo/Amb                                        40%
    • Packaging                                                    45%
    • Project Management                                    08%
    • Quality Assurance                                         22%
    • System Administration                                  07%
    • No Specific Role                                          08%
    • Other: Bug Tracking                                     05%
    • Other: Translation                                         07%

  ---

  Appendix B  References (Coming Soon)