by Igor Steinmacher (@igorsteinmacher)
Associate Editor: Christoph Treude (@ctreude)
Community-based Open Source Software (OSS) projects leverage contributions from geographically distributed volunteers and require a continuous influx of newcomers for their survival, long-term success, and continuity. Therefore, it is essential to motivate, engage, and retain new developers in a project in order to promote a sustainable number of developers. Furthermore, recent studies report that newcomers are needed to replace older members leaving the project and are a potential source of new ideas and work procedures that the project needs [1].
However, new developers face various barriers when attempting to contribute [2]. In general, newcomers are expected to learn the social and technical aspects of the project on their own. Moreover, since delivering a task to an OSS project is usually a long, multi-step process, some newcomers may lose motivation and even give up contributing if there are too many barriers to overcome during this process. These barriers affect not only those interested in remaining project members, but also those who wish to submit a single contribution (e.g., a bug correction or a new feature). And, as Karl Fogel says in his book Producing Open Source Software: "If the project does not cause a good first impression, newcomers rarely give it a second chance."
To better support newcomers, it is necessary to identify and understand the barriers that prevent newcomers from contributing. With a better understanding of these barriers, it is possible to put effort towards building or improving tools and processes, ultimately leading to more contributions to the project. Therefore, we conducted a study to identify the barriers faced by newcomers [2][3]. We collected data from different sources: systematic literature review; open question responses gathered from OSS project contributors; students contributing to OSS projects; and interviews with experienced members and newcomers in OSS projects. Based on the analysis of this data, we organized 58 barriers into a model with 7 categories. Figure 1 depicts the categories and subcategories of this barriers model.
Figure 1. Barriers Model: Categories and Subcategories
Based on the barriers model, we built FLOSScoach, a portal to support the first steps of newcomers to OSS projects. The portal has been structured to reflect the categories identified in the barriers model. Each category was mapped onto a portal section which contains information and strategies aimed at supporting newcomers in overcoming the identified barriers. To populate the portal, we collected already-existing strategies and information from interviews with experienced members and from manual inspection of the project web pages.
In the portal, newcomers find information on the skills needed to contribute to a project, a step-by-step contribution flow, the location of features (such as source code repository, issue tracker and mailing list), a list of newcomer friendly tasks (if provided by the project) and tips on how to interact with the community. Preliminary studies have shown that FLOSScoach helps newcomers, guiding them in their first steps and making them more confident in their ability to contribute to a project [4]. When we compared students' performance with and without FLOSScoach, we found a significant drop in terms of self-efficacy among students in the control group (not using FLOSScoach) while the self-efficacy of students using the tool remained at a high level. In addition, by analyzing diaries written during the contribution process, we found evidence that FLOSScoach made newcomers feel oriented and more comfortable with the process, while those who did not have access to FLOSScoach repeatedly reported uncertainty and doubt on how to proceed.
Figure 2. FLOSScoach screen showing the contribution flow (How to Start section)
Identifying and organizing the barriers and the development of FLOSScoach are the first steps towards supporting newcomers to OSS projects. A smooth first contribution may increase the total number of successful contributions made by a single contributor and, hopefully, the number of long-term contributors. According to the results of our studies conducted so far, the points that deserve more attention are facilitating local workspace setup and providing ways to find the correct set of artifacts to work on once a task is selected.
You can access newcomer support for a number of OSS projects on the FLOSScoach site at http://www.flosscoach.com.
If you like this article, you might also enjoy reading:
Associate Editor: Christoph Treude (@ctreude)
Community-based Open Source Software (OSS) projects leverage contributions from geographically distributed volunteers and require a continuous influx of newcomers for their survival, long-term success, and continuity. Therefore, it is essential to motivate, engage, and retain new developers in a project in order to promote a sustainable number of developers. Furthermore, recent studies report that newcomers are needed to replace older members leaving the project and are a potential source of new ideas and work procedures that the project needs [1].
However, new developers face various barriers when attempting to contribute [2]. In general, newcomers are expected to learn the social and technical aspects of the project on their own. Moreover, since delivering a task to an OSS project is usually a long, multi-step process, some newcomers may lose motivation and even give up contributing if there are too many barriers to overcome during this process. These barriers affect not only those interested in remaining project members, but also those who wish to submit a single contribution (e.g., a bug correction or a new feature). And, as Karl Fogel says in his book Producing Open Source Software: "If the project does not cause a good first impression, newcomers rarely give it a second chance."
To better support newcomers, it is necessary to identify and understand the barriers that prevent newcomers from contributing. With a better understanding of these barriers, it is possible to put effort towards building or improving tools and processes, ultimately leading to more contributions to the project. Therefore, we conducted a study to identify the barriers faced by newcomers [2][3]. We collected data from different sources: systematic literature review; open question responses gathered from OSS project contributors; students contributing to OSS projects; and interviews with experienced members and newcomers in OSS projects. Based on the analysis of this data, we organized 58 barriers into a model with 7 categories. Figure 1 depicts the categories and subcategories of this barriers model.
Figure 1. Barriers Model: Categories and Subcategories
Based on the barriers model, we built FLOSScoach, a portal to support the first steps of newcomers to OSS projects. The portal has been structured to reflect the categories identified in the barriers model. Each category was mapped onto a portal section which contains information and strategies aimed at supporting newcomers in overcoming the identified barriers. To populate the portal, we collected already-existing strategies and information from interviews with experienced members and from manual inspection of the project web pages.
In the portal, newcomers find information on the skills needed to contribute to a project, a step-by-step contribution flow, the location of features (such as source code repository, issue tracker and mailing list), a list of newcomer friendly tasks (if provided by the project) and tips on how to interact with the community. Preliminary studies have shown that FLOSScoach helps newcomers, guiding them in their first steps and making them more confident in their ability to contribute to a project [4]. When we compared students' performance with and without FLOSScoach, we found a significant drop in terms of self-efficacy among students in the control group (not using FLOSScoach) while the self-efficacy of students using the tool remained at a high level. In addition, by analyzing diaries written during the contribution process, we found evidence that FLOSScoach made newcomers feel oriented and more comfortable with the process, while those who did not have access to FLOSScoach repeatedly reported uncertainty and doubt on how to proceed.
Figure 2. FLOSScoach screen showing the contribution flow (How to Start section)
Identifying and organizing the barriers and the development of FLOSScoach are the first steps towards supporting newcomers to OSS projects. A smooth first contribution may increase the total number of successful contributions made by a single contributor and, hopefully, the number of long-term contributors. According to the results of our studies conducted so far, the points that deserve more attention are facilitating local workspace setup and providing ways to find the correct set of artifacts to work on once a task is selected.
You can access newcomer support for a number of OSS projects on the FLOSScoach site at http://www.flosscoach.com.
References
- R. E. Kraut, M. Burke, J. Riedl, and P. Resnick, “The Challenges of Dealing with Newcomers”, in Building Successful Online Communities: Evidence-Based Social Design, R. E. Kraut and P. Resnick, Eds. MIT Press, 2012, pp. 179–230.
- I. Steinmacher, A. P. Chaves, T. Conte, and M. A. Gerosa, “Preliminary empirical identification of barriers faced by newcomers to Open Source Software projects”, in Proceedings of the 28th Brazilian Symposium on Software Engineering, 2014, pp. 1–10.
- I. Steinmacher, T. Conte, M. A. Gerosa, and D. Redmiles, “Social Barriers Faced by Newcomers Placing Their First Contribution in Open Source Software Projects”, in Proceedings of the 18th ACM Conference on Computer Supported Cooperative Work & Social Computing, 2015, pp. 1379–1392.
- I. Steinmacher, I. S. Wiese, T. Conte, and M. A. Gerosa, “Increasing the self-efficacy of newcomers to Open Source Software projects”, in Proceedings of the 29th Brazilian Symposium on Software Engineering, 2015, pp. 160–169.
If you like this article, you might also enjoy reading:
- F. Fagerholm, A. Sanchez Guinea, J. Borenstein, J. Munch, “Onboarding in Open Source Projects”, in IEEE Software 31, 6, 2014, pp. 54-61.
- M. Aberdour, “Achieving Quality in Open-Source Software”, in IEEE Software 24, 1, 2007, pp. 58-64.
No comments:
Post a Comment