The WIDI survey had 5600 people respond to their questionnaire. Additional data was collected from the Debian developer database. (Robels, Gregorio, Scheider, Tretkowski & Weber, 2001). However, this choice may have skewed the nationalities in the sample as local or regional distributions will attract local developers. Mandrake, for example, is a popular French distribution and SuSE is popular in Germany. The FLOSS survey reached 2784 developers and included questions on motivations, orientations, and the economic aspects of the Open Source community. Their questionnaire was promulgated through the Internet on sites favored by the Open Source community (Ghosh, et al). The Boston Consulting Group’s (BCG) hacker survey reached 660 top developers selected from the SourceForge database. Additional data was extracted from the SourceForge database (Lakhami, Karim, Wolf, Bates & DiBona, 2002).

Demographics  

Many prejudices that surround [Open Source] Software developers are not true. Although developers in average are indeed young and masculine, most of them have a good education, develop during a reasonable amount of hours a week, and, surprisingly, the number of those, who profited from developing [Open Source] Software, be it professionally or monetarily, is quite high. (Robels, et al)

All the studies found that the developers were primarily male with the mean age in the range of 27 and 30. In the BCG survey, for example, 98% of the respondents were male (Lakhami, et al), which is consistent with the other studies. The age of the developers is older than the popular image of Open Source developers as teenagers. Most of the current developers were born in the 70s. The majority of developers became involved with the Open Source community during the nineties while in their early twenties (Ghosh, et al; Robels, et al; Lakhami, et al). These Generation X-ers are also well educated

All three studies found that Open Source developers were, for the most part, well educated and professionals or students. For example: nearly 70% of the respondents in the FLOSS survey had a college degree and half of those had a Master or Ph.D. (Ghosh, et al). It may not be surprising that the majority of Open Source developers were I.T. professionals. 83% of the total respondents in the FLOSS survey and 73% in the WIDI survey were employed in the I.T. sector. There was also a strong representation by students studying I.T. (Ghosh, et al; Lakhami, et al).

Open Source development is a global activity. Developers are found in almost all nations. However, the surveys showed 80 percent of respondents came from North America and Europe. (Ghosh, et al; Robels, et al; Lakhami, et al). Oceania (Australia and New Zealand) is the third most represented region in the WIDI survey (Robels, et al). Nationality and the residence distribution were similar. Only 10% of the respondents lived in another country than their home country usually the United States(Ghosh, et al; Robels, et al; Lakhami, et al). The surveys, however, appear to be geographically skewed and did not reach Asian developers. There are significant initiatives in Asian countries. Japan, China, and South Korea have formed an alliance to promote Opens Source development (Williams, 2003). This may also indicate that there is limited interaction between the Western and English speaking members of the community and Asian members; or that Asian members were less likely to respond to the survey. The surveys identified members through web sites popular for hosting Open Source projects (SourceForge and Debian) and from there questionnaires were circulated electronically through the community.

English is the language of the Open Source community (Hill, Raymond, 2003). According to the WIDI survey 96% of the respondents speak English either natively or as a second language (Ghosh, et al). 44 percent were native speakers of English.

Open Source would seem to be an avocation for most developers. The WIDI and FLOSS surveys found that most developers spent less than 10 hours per week on projects. 67% and 68% respectively. Only 17% spent more than 20 hours per week (Ghosh, et al; Robels, et al; Lakhami, et al). The Boston Consulting Group, who concentrated on community leaders, showed greater time spent on projects. The BCG survey also broke out the volunteer and paid developers. They found that the mean hours per week on all projects was 14, volunteers worked an average of 13.5 hours per week and paid developers worked an average of 20.9 hours per week. Clearly the number of volunteers significantly exceeded the paid developers.

Why Do Open Source Projects  

Programming is a gift culture: the value of a programmer’s work can only come from sharing it with others, that value is enhanced when the work is more widely shared, and that value is enhanced when the work is more completely shared by showing the source [code]…. (DiBona, Ockman, & Stone)

Developers are motivated by intrinsic rewards. The overriding reason that people join and continue working on open source projects is to expand and share their knowledge (Ghosh, et al; Robels, et al; Lakhami, et al; & Kim). The top five reasons cited in the WIDI and FLOSS surveys for joining and staying in Open Source projects are: to develop or improve skills and knowledge (78%), to share knowledge with others (50%), to participate in a new form of cooperation, to participate in Open Source scene, and to improve Open Source products of other developers (Ghosh, et al; Robels, et al; Lakhami, et al). The overall motivation identified in the BCG study for participating in Open Source was that it is "intellectually stimulating" (44.9). This was followed by improving skills (41.3%). Work functionality was the third most cited reason (33.8%), which may indicate that the leaders are more likely to have a work need for Open Source involvement. 93% said "increasing their personal knowledge base" was a benefit and 43% said it was the most important benefit (Robels, et al). A large number of respondents appealed to the creative nature of open development and freedom from traditional corporate supervision as primary attractions. Open Source developers like to pick the work that interests them, and they like the freedom from time pressures (Green).

The Boston Consulting Group, in their survey, identified four distinct community groups based on attitudes toward Open Source. Only 19% were labeled "true believers" who were motivated by the belief that code should be open and saw hacking (programming) as central to their life style. 27% were hobbyists with non-work needs for the code. They identified with the community and worked on Open Source for intellectual stimulation. The largest group – 29%, many of which were students, were motivated to improve skills. Professionals who needed the code for work or sought to enhance their profession or status in the community comprised 25% of the respondents (Robels, et al). These findings confirm that most of the Open Source community is not motivated purely by ideology, but for the creative and intellectual experience and the personal sense of accomplishment.

There is a group of Open Source developeers—20% to 30%—who are paid by their employers for work on or with Open Source projects. However, only 29% of those responding to the WIDI survey said they had not profited from Open Source work. There were other perceived benefits such as improving employment opportunities or income by gaining skills or reputation (Ghosh, et al; Robels, et al; Lakhami, et al). It should also be noted that Open Source developers report high job satisfaction. 44% of the respondents to the WIDI survey said they love their jobs and 27% find their jobs interesting (Robels, et al). With a great majority being employed in the field, it would be reasonable to infer that many get less than adequate personal satisfaction and intellectual stimulation on the job (Greene). The surveys showed that employers were usually aware of the employees participation in Open Source and frequently allowed work time to be used for Open Source activities (Robels, et al). Job satisfaction may represent a satisfying balance between unstructure and creative Open Source activities and the highly structured work demands. By not discouraging Open Source, the employer retains a dedicated employee.

Organization and Leadership  

The software development process tends to be controlled by individuals or small teams of developers. (Kim). The number of developers on a project varies greatly

While some products that are very well publicized may attract large numbers of developers, most [Open Source Software] products are developed and maintained by a tiny number of developers. (Krishnamurthy, 2002)

A study of the top 100 projects on SourceForge found the average number of developers to be 4 and the mode to be 1 with some projects having 10 or 15 developers (Krishnamurthy, 2002). The level of general interest or the "how-cool" factor and usefulness of the project along with how well the project is publicized affects the number of volunteers the project will attract. The style of the project founder will also determine how many people are attracted to the project (Kim; & Hill). Beyond the developers there is a large corps of users and casual contributors (Lakhami, et al).

Two significant features of the Open Source Development model are the lack of hierarchy with a distributed network of contributors and that the users, who are frequently the developers, have direct input to the project. Communication through email lists, instant messaging via IRC, web pages, and regular email coordinates efforts and builds commitment (Elliot & Scacchi, 2002). While a slight delay in work occurs while contributors debate issues on IRC, the debates result in reinforcement of cultural beliefs in free software. (Elliot, 2003). Project leaders tend to be active on public forums, but also collaborate on private forums. (Kim). Most communication is between the core developers and the larger project community. There is limited communication between members of the larger community. Overall, Community processes are lightweight, and tend to emerge in response to changing conditions. (Kim).

Most of the developers feature networks that consisted of rather few people. Nevertheless, we found a considerable large group of [Open Source] developers that showed regular contacts to more than 50 other developers and that provided undoubtedly the "professional elite" within the community. (Ghosh, et al)

Two-thirds of the FLOSS sample keeps regular contact with fewer than five members of the community. Leaders are frequently a participant in any dialog and there is a strong correlation between leadership experience and contacts to other members of the community. (Ghosh, et al)

More than a third of the respondents to the FLOSS survey said they have not lead, administered, or coordinated an Open Source project; another third said they have lead one project, 30% had lead between 2 and 5 projects. 2% said they had experience leading more than five projects.

Within a project there is a core team of developers who are the leaders. And while many take leadership of the project they initiated, the project founder is not always the leader (Ghosh, et al; Hill). Projects with few people have a high percentage of leaders while projects with a large community interest have a lower percentage of leaders. For the most part, the Open Source community acts as a meritocracy where leaders earn their positions based on their reputation for quality contributions not on their position (Elliott, 2003).

If we look at what [BCG survey] respondents say they want from leaders in the open source community, we see a picture of something quite unlike corporate project management, and remarkably like the open-source model as it is practiced. That is, there’s a clear desire for “space” for individual creativity and initiative. (Greene)

Peer leadership is preferred. Respondents to the BCG survey were asked their expectations of leaders. They expected leaders to be technically savvy and inspire the team. The stated expectations were:

From the rankings, we can see that many in the community expect that a code base will exist when the project starts, and that the leader will be a communicator. An important condition for a successful project is a visionary, a champion of the product to chart the direction. …at least one person needs to be the arbiter of good taste with respect to the products progress. (Hissam, et al, 2001). The person leading development of an Open Source project must harness the work of fellow developers by making responsible decisions and by responsibly choosing not to make a decision. Direction must be given without being bossy or overbearing (Hill).

Community Expectations  

In the FLOSS survey, when respondents were ask about their expectation of other members of the community and what they assumed the others expected of them, there was a strong degree of coherence. The top expectations where: sharing knowledge and skill, improving Open Source products, and learning new skills (Ghosh, et al). Most members of the Open Source community believe that they receive more benefit from the community than they give (Lakhami, et al). Recognition for work is important. Of survey respondents, 94% mark their software contributions as theirs, and almost 60% even declared that they considered this as very important (Robels, et al). It is important that members of the community show respect to one another and respect the contributions that are made (Ghosh, et al).

Conflict resolution in a virtual world presents unique challenges and advantages because of the text based nature of communications. The persistent recording and public archiving of instant messaging IRC logs, mailing lists, and digests of the logs assists open source developers in their daily work and conflict resolution and serves as a reminder of the philosophy behind Open Source. In general, all issues are given a public hearing. Then either of two approaches is followed. There is a consensus or vote by the active community; or, the project leaders make a decision (Elliot, et al, 2002). More personal or negative communication is handled through personal email by the project leader (Hill). Project leaders engaged in a significant amount of communication which was not done through public forums(Ghosh, et al).

Poorly resolved conflicts can result in members leaving the project community or starting a new project with the code base: a process called forking. In the end the community will decide which path will survive by giving their efforts to the projects they support.