ArticlePDF Available

Onboarding in Open Source Projects

Authors:

Abstract and Figures

In today’s world, many companies turn to open source projects as a source for increased productivity and innovation. A major challenge with managing this kind of development is the onboarding of new developers into virtual teams which drive such projects. However, there is little guidance on how to arrange the initiation of new members into such teams and how to overcome the learning curve. This case study on Open Source Software projects shows that mentoring can have a significant impact on onboarding new members into virtual software development teams.
Content may be subject to copyright.
!
!
!
!
!











1
Onboarding in Open Source Projects
Fabian Fagerholm
Department of Computer Science
University of Helsinki
P.O. Box 68
FI-00014 University of Helsinki
Finland
fabian.fagerholm@helsinki.fi
Alejandro Sanchez Guinea
Department of Co mputer Science
University o f Helsinki
P.O. Box 68
FI-00014 University of Helsinki
Finland
azsanche@cs.he lsinki.fi
Jay Borenstein
Jürgen Münch
Department of Co mputer Science
University o f Helsinki
P.O. Box 68
FI-00014 University of Helsinki
Finland
Department of Co mputer
Science
Stanford University
353 Serra Mall
Stanford, CA 94305 USA
Facebook
1601 Willow
Road
Menlo Park, CA
94025 USA
borenstein@cs.stanford.edu
juergen.mue nch@cs.helsinki.fi
Abstract
In today’s world, many companies turn to open source projects as a source fo r incre ased
productivity and inno vation. A major cha llenge with managing this kind of develop ment is the
onboarding of new developers into virtual teams which drive such projects. However, there is
little guidance on how to arrange the initiation of new members into suc h teams and how to
overcome the learning curve. This case study on Open Source Software projects shows that
mentoring can have a significant impact on onboarding new members into virtual software
development teams.
Keywords
onboarding; open source software projects; virtual teams; mentoring; global software
development; distributed software development; case study
2
Imagine working for a software company that has decided to make one o f its projects go open
source. Yo u expect to be nefit from an influx of new talent, enabling you to grow your product
beyond the capabilities of a single organization. Your continuous concern will be to involve new
developers in your virtual team, but time is scarce and you risk slowing down progress by adding
mo re people. In 1975, Fred Brooks observed that adding people to a late software project makes
it later [1] an observation that has become known as Brooks' Law. To this day, almost 40 years
later, software project managers struggle with questio ns on how and when to introduce new
people intoso ftware projects. Although Brooks acknowledged that the “law” is a n “outrageous
simplification”, heobserved two main factorsthat impede the introductionof newcomers:the
ramp-up time it takes for them to learn eno ugh about the technical content to become productive,
and the increased communication overhead that results from more people having to coordinate
work.
THE NEED FOR CONTINUOUS ONBOARDING
The general problem of introducing new people into an existing organization is especially
prono unced in distributed settings with virtual teams. Virtua l teams are small, often temporary
groups of knowledge workers, separated by geographical, temporal, and cultural distances which
add to the communication challenges involved in getting them to work effectively [2 ]. Today,
Open Source Software (OSS) projects are among the most distributed kinds of projects carried
out by humans. They rely exclusively on virtual teams, whose me mbers can be placed on a
continuum ranging from more pe rmanent core developers to more temporary peripheral
developers. In many application do mains, engagement with open source is an inevitable part of
the computing b usiness. To gain market share, companies may have no choice but to participate
in an existing open source ecosystem. The possibilities for low-cost innovation, access to large-
scale project capabilities, and opportunities for recruiting proven talent are among the factors
driving companies towards open source. OSS also plays an important role in government IT and
the open source approach is often considered an enabler for technology and knowledge transfer
to developing countries. Simultaneously, open source deve lopment presents several challenges to
organizations that are used to a more traditio nal workfo rce, with opaque organizational
3
boundaries, hierarchical management, and relatively long-term employment. The flexibility
provided by virtual teams in open source p rojects requires rethinking resource management and
integration of new project members.
Onboarding, or organizational socialization, is a process that helps newcome rs become
integrated members of their organization. As part of onboarding, new members learn the
knowledge, skills, and behavior they need to succeed and be prod uctive in their work [3].
Onboarding is well explored in the organizational management literature. In software
engineering research, there are some case studies concerning the process of onboarding (e.g. [4,
5]). However, there is little research or advice on onboarding for open source projects with
virtual teams. The literature does not provide evidence-based guidance that wo uld he lp project
managers successfully involve developers in such scenarios. In this article, we p resent findings
that complement an earlier study on onboarding in open source projects [6, 7]. We previously
sho wed the general e ffect o f onboarding support on newcomer activity [6, 7] and the moderating
effect of project characteristics, such as age, number of contributo rs, and appeal, on the speed o f
the onboarding process [7]. This article continues the analysis by examining developer activity
during onboarding more closely, assessing the potential cost of mentoring in terms of lost
productivity, and suggesting guidelines for using mentoring as an onboarding support
mechanism. Rather tha n focusing on developer retention, we focus on the very initial stage of
integrating newco mers, i.e. climbing the learning c urve in virtual teams. This particular concern
is especially rele vant for virtual teams in an open source context, where developers join and
leave at a rapid rate, and onboarding is needed on a continuous basis.
ELEMENTS FOR ONBOARDING IN OPEN SOURCE
The precise practices and actions involved in onboarding differ depending on context. In this
case, the context was a large-scale collaboration pro gra m with multiple universities and open
source projects (see sidebar). The onboarding procedures co nsisted of two elements: a co- located
Hackathon e vent, and mentoring by e xperienced open source developers. At a three-day
Hackatho n e vent at Facebook’s headquarters in Palo Alto, California, student developer tea ms
met face to face to start working on their respective OSS projects. A mentor from the pro ject was
assigned to each team. Three days o f intensive coding and socialization allowed developers to
4
get to kno w each other and their mentors, and provided an immersive introduction to the world
of distributed OSS development. Part of the activities o f the Hackathon included familiarization
with the code base, tools, and procedures used in the proje ct.
Mentors were tasked with recommending and detailing tasks, explaining the software
architecture, and assisting in technical development deta ils. With the exception of the
Hackathon, all interactions between mentors and developers took place in the regular channels
used in each OSS project, including mailing lists, discussion forums, blogs, social networks, and
internet relay chat (IRC).
Developers were free to work on any tasks relevant to their projects. Initially, mentors would
typically direct them to small tasks suitable for novices. They were assumed to gradually start
taking the initiative and tackle tasks of greater complexity. Most tasks involved programming,
ranging from small b ug fixes to complicated new features. Other tasks included writing test
cases, creating new issues in tracking systems when new b ugs were found, a nd improving some
no n-functional aspect of the software, taking into account maintainability, performance, and user
experience.
The developers were integrated into each open source project and community through its regular
procedures. They were exposed to the norms and implicit policies of each community. In
addition, they received support from their mentors, from their local and remote team members,
as well as any support provided by their home organizations. In company settings, similar
suppo rt structures can realistically be enacted both to enable entry into external open source
projects as well as to enable third parties to enter projects driven by the company itself.
DOES MENTORING HELP?
To assess the impact of mentoring support on developers, we use a compound metric called
activity. This is the sum of basic metrics that can be directly obtained from GitHub, a web-based
hub for software development where mo st of the development took place. Thus, activity is
defined here as the total number of commits, pull requests, and interactions by the developers
considered.
5
A commit is a sub mission of source code changes to a version control system. A pull request is a
notification that a proposed set of commits is available for integration into the main code branch.
The changes can be reviewed and potential required mod ifications discussed before a final
decisio n is made to integrate o r reject the pull request. The amount of pull requests reflects the
group work that occurs between developers, since they involve discussions and code reviews in
which more than one developer is involved. Finally, we define an interactio n as a single message
posted by a developer in a GitHub discussion forum. Discussions are usually linked to commits
or pull requests. They may concern source code modifications, messages justifying submitted
modifications, or general messages related to the current development o f a pull request or
commit. The number of interactions corresponds to the amount of communication and group
work between developers. Each component in the activity metric has an associated time stamp.
This allows us to calc ulate the activity over a certain period of time for a certain set of
developers.
We assess whether mentoring positively influences the performance of developers by comparing
the activity of developers receiving mentoring support with the activity of developers that
haven’t received such support. The non-mentored gro up was randomly selected among
developers who particip ate in the corresponding OSS project but are not part of the core
development group, since being a core developer implies not only successful project
involvement, but a level of expertise which cannot be expected from a newcomer.
To make a comparison over time, we defined a time-series sampling strategy. We sampled the
weekly activity of each developer for 16 weeks. For the mentored gro up, we selected the initial
week of the collaboration as the starting point. For the non-mentored group, we defined the
starting point as one week before the first activity found for each developer. The weeks are thus
relative to when the developer began their o nboarding process.
Figure 1 shows the accumulated activity over time of developers with onboarding support
compared to the non-supported de velopers. Initia lly, the progression of both groups is similar.
However, as the onboarding process unfolds, activity among supported developers increases
significantly compared to the activity registered by non- mentored developers. The level of
activity in the supported group then continues to rise in a more or less constant fashion
throughout the whole time period.
6
Fi g. 1. Accumulated activity over time of mentored and non-me nt ore d de vel ope rs . Ment ore d de ve l opers
pe r fo r m s i g ni fi c an tl y h i g he r t h an n on -me ntore d de vel oper s. Pe rf or mance bu mps a nd pl ate aus lik el y r efl ec t a
human le arning effect. The linear regres si on trendlines display a high goodness of fit (R2) and illus trate the
di f fe r en ce i n ac t i vit y o ve r ti me m or e c le arl y.
The bumps that appear in Figure 1 likely reflect the nature of human learning. When
encountering a previously unknown task, we expect that developers e ngage in learning activities
suc h as gathering and interpreting information to clarify the task and understand the software
they are about to modify. Once they have accumulated enough kno wledge and have reached a
satisfactory level of understanding, they can begin to perform actual visible work.
y = 37,241x - 23,55
R² = 0,922
y = 18,165x - 41,275
R² = 0,9196
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Activity
Weeks
Mentor ed
Non-Mentored
7
The supported developers surpass the performance of the ones without support. We assume that
the positive results with increased activity are related to the support given by the mentor
throughout the duration of the program. Thus, the effect of mentoring is refle cted as a n inc rease
in the activity and participation of a developer in an OSS project. For instance, if a mentor
provides suggestions for suitab le tasks that a developer could perform, this could have a positive
impact on the number of commits by mak ing developers focus on appropriate activities and
reduce time wasted on other activities. S imilarly, the amount of collaborative activities between
developers could be affected by having the mentor mediate discussions and collaborative work.
In our interpretation, the higher degree of activity amo ng supported developers is, in part, a
consequence of the mentoring support provided to the team.
THE RELEVANCE OF INTERACTION
The aggregation of the activity metric can hide relevant patters which would be visib le with
more refined metrics. Such patterns can help understand the way in which developers contribute
to their projects. For this reason, we ana lyze each component of activity separately.
Figure 2 shows the time series for each of the compo nents of the activity metric for the
developers that received onboarding support. The peaks reflect the learning effect shown in
Figure 1. The figure shows that the largest portio n of the activity metric stems from interactions
with other developers, which seems natural for a group of newcomers who are still learning the
processes and practices of a distributed project. Also, the interactions themselves may be
valuable, as they may contain important informatio n that spurs new ideas and inno vation in the
projects.
Since open source development relies on trust relationships built and maintained by developers
themselves, it is important to prepare newcomers to interact according to the project culture. The
same applies to other kinds of distributed projects with virtua l teams. Project managers should
emphasize the importance of informal communications, as it may increase the chances that new
developers build trust and gain deeper access to important project members more quickly.
8
Fi g. 2. Detaile d acti vi ty patterns of newco mers during the onbo arding pr ocess. The amou nt of inter acti ons
reflects the coordination required to accomplish actual technical tasks.
DOES MENTORING PAY OFF?
It appears to be highly beneficial to utilize experienced developers to help newcomers become
successfully involved in OSS projects. However, a potential problem may arise: the mentor
needs to be engaged in support activities for some time, during which regular duties may suffer.
It is important to consider the impact of the mentoring task on the performance of the mentor.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Magnitude
Weeks
Commits
Pulls
Interactions
9
To gain a coarse- gra ined understanding of the amount of work involved in mentoring besides
other duties, we observed mentors’ own development contributions to their respective OSS
project over time. Figure 3 shows the development contributions by each mentor during a period
of 13 months. The highlighted areas indicate the Open Academy program. Regardless of the
differences in contribution patterns between each mentor, the amount of contrib utions is reduced
while they are performing mentoring duties. This difference is seen more clearly in F igure 4,
whic hcompares the me nto rs’ average contr ibut io nper week while performing mentoring tasks
(“during mentoring) and while performing regularly (regular development). However, in all
Fi g. 3. Mentor contributions over a time span of 13 months. Mentors are visibly less productive while engaged
in mentoring tasks during the Open Academy Program (months three to six).
10
cases, me ntors continued to contribute to their projects throughout the program. While the
performance drop can be significant, it can be justified by the fact that it is limited to the
onboarding period and its potential impact on increased productivity and increased innovation
that may be gained from new project members. In practice, this opportunity cost must be
evaluated on a case-by case basis. In many situations, the cost o f mentoring is overshadowed by
the potential benefits of gaining new me mbers, even if they are te mporary.
Fi g. 4. Comparison of average mentor contribution per week during mentoring and non -men t ori ng
pe ri o ds . Me nt o ri n g a ct i vi t ies r edu ce me n to r pr o du c ti vi t y, bu t c o n tr i bu ti o ns d o c on t in ue e ve n du ri n g th e
ment oring per io d.
0
5
10
15
20
25
30
35
40
Ruby on Rails
Kotlin
Phabricator
Socket.IO
Average contribution per week
During mentoring
Regular Development
11
The onboarding process in the Open Academy program resulted in better performance than
what would have been expected from the usual joining procedures in the participating OSS
projects. O ur interpretation is that the support given to developers did influence their onboarding
process, allowing them to become more active. The results indicate that mentoring increases the
chance of developers being exposed to, selecting, and performing tasks in a proactive and self-
directed manner in open source projects. We assume that this applies in other kinds of settings
where development is conducted by virtual teams.
The results presented here will inevitably vary depending on the particular context in which
projects take place and depend on validity limitations of the study. Onboa rding is a complex
construct with multiple impact and context factors that ma y limit the applicability o f the results.
The analysis presented here cannot distinguish between mentoring and other onboarding support
factors. Other contextual factors may play a role. For example, developers in the gro up receiving
onboarding support may be more involved and spend more time more regularly with the project.
Also, the Hackathon e vent may be another factor impacting the results. A further limitat ion is
that we have not examined whether developers in the non-supported group have received any
treatment during the observed period o f time that would impact the results.
An interesting question is whether the effect of onboarding support is permanent after mentoring
activities are removed. Since our focus was on newcomer initiation and not retention, and on
rather temporary virtual teams, we did not examine this issue further. Future work could a ssess
what is required to increase the likelihood of retaining p roject members after onboard ing in
highly volatile tea m environments.
In summary, mentoring is a viab le support activity for onboarding, helping to rapidly integrate
new members into OSS projects. Directly engaging with an open source project thro ugh an
experienced mentor gives better results than having no mentor. Furthermore, improved
onboarding performa nce seems to justify the cost of mentoring in ma ny cases.
Our results have direct relevance for leading and managing virtual teams in an open source
context. In light of our results, we have the following recommendations for project leaders and
managers.
12
Identify core developers who can spend a limited time on intensive mentoring. Provide
direct incentives for mentoring. For example, the opportunity to get help for pending
tasks can be attractive for potential mentors. Clearly limiting the duration of mentoring
reduces the negat ive effect o n the me ntor’s performa nce in other project tasks and can
reduce some of the resistance to participate.
Organize or sponsor collocated events, such as Hackathons, and use them to kick off the
mentoring period. Face-to- face events can help team members and mentors to focus on
problems which are difficult to overcome in a d istributed setting, and can further boost
the success o f o nboarding new members into virtual teams. Many open source projects
already arrange periodic collocated events and welcome participation by newcomers.
Engaging with these provides direct access to the project community.
Expect considerable variation in performance increases over time. Assessing the cost and
outcomes of mentoring requires understanding onboarding as a learning process which
does not proceed linearly. Some o nboarding activity will not be publicly visible. Engage
directly with mentors and newcomers to gain insight of how onboarding is progressing.
Adapt the onboarding program to project characteristics and culture and be prepared to
provide different kinds of support to mentors in different kinds of projects. Take the
maturity of the target project and its e xisting onboarding practices into account. Lo w-
maturity p rojects may require more support to instill a productive mentoring culture,
while mature projects may already have an e xisting culture of integrating new developers
and may be ready for tailoring towards more specific inclusio n ta rgets. Consider taking
on an expert with knowledge of open source projects and software engineering pedagogy
to guide the mentors so that their expertise is transferred most effectively.
13
REFERENCES
1.FrederickP. Brooks,Jr.“TheMythicalMan-Month”.Addison-Wesley, 1975.
2. Nader, A. E., Shamsuddin, A., Zahari, T. “Virtual R & D teams in small and medium
enterprises: A literaturereview”.Sc ie ntific Researcha nd Essays,pp. 1575-1590, Vol. 4, No. 13,
2009.
3. Bauer,  T. N. Erdogan, B. “Organizational socialization: The effective onboarding of new
employees” in S. Zedeck (Ed.), APA Handbook of industrial and organizational p sychology,
Vol. 3, pp. 51-64. Washingto n, DC, USA, 2011, American Psychological Association.
4. Steinmac he r, I., W iese, I., Chaves, A.P., Gerosa, M.A., “Why do newco mers abando n ope n
source soft ware projects?,” 6th Inte rnatio na l Workshop on Cooperative and HumanA spects of
Software Engineering (CHASE), pp. 25-32, 2013.
5.A.BegelandB.Simon,“NoviceSoftwareDevelopers,AllO verAgain,inProceedingsofthe
Fourth International Workshop on Computing Education Research (ICER), pp. 3 -14, New York,
2008, ACM.
6. F. Fagerholm, Johnson, P., Sanchez Guinea, A., Borenstein,J., Münch, J., “Onboarding in
OpenSourceSo ft ware Proje cts: A PreliminaryA na lys is,” IE EE 8thInter natio na lC onference on
Global So ftware Engineering Workshops (ICGSEW), 2013.
7. Fagerholm, F., Sanc he z G uinea A.,  Münch, J., Borenstein, J. “The Role of M entoring and
Project C harac teristics for Onbo arding in O pen Source Software Projects”. Empirica l Software
Engineering and Measurement (ESEM), 2014.
8. F. Fagerholm, O za, N., M ünc h, J., “A P lat form for Teaching Applied Distrib uted So ft ware 
Develop ment: The O ngoing Journey of the Helsinki Software Factory”, 3rd International
Workshop on Collaborative Teaching of Globally Distributed Software Development
(CTGDSD), 2013.
14
ABOUT THE AUTHORS
Fabian Fagerholm is a doctoral student at the University of Helsinki,
working for the Department of Computer Science in its Software Systems
Engineering Research group. He has driven the design, implementation, and
operatio no f t he department’sSo ftwareFac tory laboratory fore xp erimental 
software engineering research and education. His main interests are human
aspects of software engineering and software deve lopment processes.
Fagerholm obtained his Master’s degree from the University of Helsinki.
Contact him at fabian.fagerholm@helsinki.fi.
Alejandro Sanc hez Guinea is a research assistant a t the University of
Helsinki, working for the Department of Computer Science in its Software
Systems Engineering Research group. His main research interests are
software measurement, software processes improvement, and software
engineeringdesignmethodolo gies.HeobtainedhisMaster’sdegreefromthe
Institut Supérieur de l’Aéronautique et de l’Espace. Contact him a t
azsanche@cs.he lsinki.fi.
Jay Borenstein teaches computer science at Stanford University and also
runs Facebook Open Academy as part of a larger Facebook effort to
modernize education. Jay finds it very fulfilling to help motivated, bright
minds grow and succeed. Contact him at borenstein@cs.stanford.edu or
through www.facebook.com/openacademyprogram.
Jürgen Münch is a professor o f software systems engineering at the
University of Helsinki, head of its Software Systems Engineering Research
group, and principal investigator of the experimental R&D laboratory
Software Factory”. His main interests are quantitative modeling and
analysis of software systems and processes, data a nalytics, and continuous
experime ntation. He received his PhD degree (Dr. rer. nat.) in Computer
Science from the University of Kaiserslaute rn, Germany. Contact him at
juergen.mue nch@cs.helsinki.fi.
15
[sidebar]
GLOBAL OPEN SOURCE PROGRAM
Starting in spring 2013, Stanford University and Facebook, Inc. launc hed the Open Academy
program (www. facebook.com/openacademyprogram), which invo lves several open source
projects and a significant number of top universities around the world. The intention of the
program is to improve computer science university curric ula through a practical and applied
learning experience.
Table 1. P artici pating Open Source Projects.
Project Name
Web Site
Included in This Study?
Freeseer
http://freeseer.github.io/
No
Kotlin
http://kotlin.jetbrains.org/
Yes
Mongo DB
http://www.mongodb.org/
No
Mozilla OpenBadges
http://openbadges.org/
No
Revie wBoard
http://www.reviewboard.org/
No
Phabricator
http://phabricator.org/
Yes
PouchDB
http://pouchdb.com/
No
Ruby on Rails
http://rubyonrails.org/
Yes
Socket.IO
http://socket.io/
Yes
The findings we report here are based on results from the 2013 edition of the Open Academy
program, including nine OSS projects, more than a dozen universities, and more than 120
students, referred to in the study as developers. Table 1 shows a ll projects participating in the
program and indicates four projects which we examined in this study. Students at the University
of Helsinki participated in these four projects through Software Factory, an experimental
researc h and development laboratory [8], which allowed us to follow the onboarding process in
these projects very closely. The projects represent a range of different project sizes, ages, and
technology types.
The teams participating in the program followed the typical p ractices o f open source
development and can be characterized as virtual teams with members being distributed across
16
different geographical locations with their local cultures. All the participating open source
projects had a wide temporal distribution, each receiving a constant stream o f contributions
around the clock.
... Finally, in traditional projects, developers need to gain considerable prior knowledge before starting work on tasks. For example, developers need to understand architecture and design of the codebase, understanding how the defect that they are working to fix interact with these and, as a result, what functionality is likely to be relevant, what source files this functionality is implemented in, and the ways in which this is implemented (Wang and Sarma 2011;Steinmacher et al. 2015;Von Krogh et al. 2003;Jergensen et al. 2011;Fagerholm et al. 2014;Britto et al. 2020). In a microtask, developers need to know none of this context. ...
... Microtask programming adopts three core mechanisms for organizing work and motivating and supporting contributors. Microtask programming reduces the effort required to (1) onboard developers onto a project, including understanding the project structure and code and setting up a workspace (Steinmacher et al. 2015;Wang and Sarma 2011;Britto et al. 2020;Von Krogh et al. 2003;Fagerholm et al. 2013;Fagerholm et al. 2014). To reduce this traditionally lengthy process, developers work within a specialized preconfigured programming environment (Aghayi et al. 2021;Lasecki et al. 2015;LaToza et al. 2018;Goldman et al. 2011a;Nebeling et al. 2012;Schiller and Ernst 2012;LaToza et al. 2014;LaToza et al. 2013;Williams et al. 2019). ...
... When new developers join a software project, they face a number of onboarding barriers. Onboarding barriers include 1) identifying appropriate contacts and receiving timely feedback, 2) identifying proper tasks and corresponding artifacts, 3) understanding project structure and setting up a workspace, 4) outdated and unclear documentation 5) learning project practices and technical expertise (Wang and Sarma 2011;Steinmacher et al. 2015;Von Krogh et al. 2003;Jergensen et al. 2011;Fagerholm et al. 2014;Britto et al. 2020). Onboarding barriers impose a lengthy joining script that dissuades less motivated potential contributors from becoming a contributor (Steinmacher et al. 2016). ...
Article
Full-text available
In microtask programming, developers complete short self-contained microtasks through the use of a specialized programming environment. For example, given only a short description of the purpose of a function and a partially complete implementation, a developer might be asked to identify, test, and implement an additional behavior in the function. Adopting a microtask approach to programming tasks has been envisioned to offer a number of potential benefits, including reducing the onboarding time necessary for new developers to contribute to a project and achieving higher project velocity by enabling larger project teams and greater parallelism. To investigate the potential benefits and drawbacks of microtask programming we conducted a controlled experiment. We focused our investigation on the context in which microtasking is most widely used, implementing and debugging function bodies, and investigated the impact of microtasking with respect to onboarding, project velocity, code quality, and developer productivity. 28 developers worked to implement microservice endpoints, either in the form of traditional programming tasks described in an issue tracker or as programming microtasks. Our study did not examine the design effort necessary to prepare for microtask programming or consider how microtask programming might be applied to maintenance tasks. We found that, compared to traditional programming, microtask programming reduced onboarding time by a factor of 3.7, increased project velocity by a factor of 5.76 by increasing team size by a factor of 7, and decreased individual developer productivity by a factor of 1.3. The quality of code did not significantly differ. Through qualitative analysis of how developers worked, we explore potential explanations of these differences. These findings offer evidence for the potential benefits that adopting microtask programming might bring, particularly in cases where increasing project velocity is paramount.
... Mentors can also find it challenging to keep the mentee engaged, especially if the project culture is harsh or the mentees are not proactive/intensely interested in OSS [5]. The additional effort reduces the technical output of mentors in OSS [20]. Further, Labuschagne and Holmes [50] found that, although mentees valued mentorship programs, these often do not result in long-term retention of contributors. ...
... In the context of research in OSS, most research only focuses on formal mentoring, especially onboarding activities. Researchers had found that mentoring allowed for a more effective onboarding experience than when newcomers entered a project through a natural, non-deliberate process [20,21]. Google, through its formal Google Summer of Code (GSoC) mentorship program, aims to facilitate onboarding to OSS [40]. ...
... These informal mentoring included cases where the mentee or mentor reaches out to the other to ask for guidance. [5,9,20,97] Mentoring Email, Slack, Skype, etc P1, P3, P4, P5 [5,21,97] Channels Code review comments P1, P3, P4 [5,9,20] In person/Remote P4, P5 [4,21] Implicit mentoring, a form of informal mentoring where training was "implicitly" provided as a part of contributors' technical activities, such as code review: "When somebody reviews a patch, that gives a feedback to you, that's a form of mentoring" [P1]. We specifically define implicit mentoring as: "mentoring that occurs in everyday development activities such as code reviews, where a mentor provides an underlying explanation when providing suggestions, instructions, or mechanisms to address errors". ...
Conference Paper
Full-text available
Mentoring is traditionally viewed as a dyadic, top-down apprenticeship. This perspective, however, overlooks other forms of informal mentoring taking place in everyday activities in which developers invest time and effort. Here, we investigate informal mentoring taking place in Open Source Software (OSS). We define a specific type of informal mentoring—implicit mentoring—situations where contributors guide others through instructions and suggestions embedded in everyday (OSS) activities. We defined implicit mentoring by first performing a review of related work on mentoring, and then through formative interviews with OSS contributors and member-checking. Next, through an empirical investigation of Pull Requests (PRs) in 37 Apache Projects, we built a classifier to extract implicit mentoring. Our analysis of 107,895 PRs shows that implicit mentoring does occur through code reviews (27.41% of all PRs included implicit mentoring) and is beneficial for both mentors and mentees. We analyzed the impact of implicit mentoring on OSS contributors by investigating their contributions and learning trajectories in their projects. Through an online survey (N=231), we then triangulated these results and identified the potential benefits of implicit mentoring from OSS contributors’ perspectives.
... It can also be challenging for mentors to keep the mentee engaged, especially if the project culture is harsh or the mentees are not proactive/ strongly interested in OSS [7]. Given that mentors are also volunteers, this additional effort in mentoring can lead to a reduction in their technical productivity [13] and sometimes even loss in stature, where women who frequently mentor may be treated as community managers and not engineers [7]. ...
... In the context of research in OSS, several works have identified the lack of mentoring as a challenge for newcomer onboarding [13], [28], [29]. Others have identified the challenges that mentors face in OSS [7], [12], [30]. ...
... Others have identified the challenges that mentors face in OSS [7], [12], [30]. Researchers have found that mentoring allowed for a more effective onboarding experience than when newcomers entered a project through a natural, non-deliberate process [8], [13]. Google through its formal Google Summer of Code (GSoc) mentorship program aims to facilitate onboarding to OSS [31]. ...
Preprint
Mentoring is traditionally viewed as a dyadic, top-down apprenticeship. This perspective, however, overlooks other forms of informal mentoring taking place in everyday activities in which developers invest time and effort, but remain unacknowledged. Here, we investigate the different flavors of mentoring in Open Source Software (OSS) to define and identify implicit mentoring. We first define implicit mentoring--situations where contributors guide others through instructions and suggestions embedded in everyday (OSS) activities--through formative interviews with OSS contributors, a literature review, and member-checking. Next, through an empirical investigation of Pull Requests (PRs) in 37 Apache Projects, we build a classifier to extract implicit mentoring and characterize it through the dual lenses of experience and gender. Our analysis of 107,895 PRs shows that implicit mentoring occurs (27.41% of all PRs include implicit mentoring) and it does not follow the traditional dyadic, top-down apprenticeship model. When considering the gender of mentor-mentee pairs, we found pervasive homophily--a preference to mentor those who are of the same gender--in 93.81% cases. In the cross-gender mentoring instances, women were more likely to mentor men.
... One method in which companies support code comprehension during onboarding processes of software engineers is to use mentoring [5]- [7]. However, interviewed mentors reported their task to be tedious and time consuming [7]. ...
... Additionally, we aim to allow for experts 1 to influence the visual representation of projects in order to enable a transfer of knowledge to newcomers. This transfer is a significant factor for successful onboarding processes [5]- [7]. It is achieved by allowing experts define groupings of source code elements. ...
... Previous research has focused on solutions to help newcomers, for example, through mentoring [4,5,22] or an information platform that overcomes the common newcomers' barriers [25]. In this paper, we focus on the other end of the spectrum by empowering maintainers to improve their project and community health for newcomers. ...
Preprint
Tools and artifacts produced by open source software (OSS) have been woven into the foundation of the technology industry. To keep this foundation intact, the open source community needs to actively invest in sustainable approaches to bring in new contributors and nurture existing ones. We take a first step at this by collaboratively designing a maintainer dashboard that provides recommendations on how to attract and retain open source contributors. For example, by highlighting project goals (e.g., a social good cause) to attract diverse contributors and mechanisms to acknowledge (e.g., a "rising contributor" badge) existing contributors. Next, we conduct a project-specific evaluation with maintainers to better understand use cases in which this tool will be most helpful at supporting their plans for growth. From analyzing feedback, we find recommendations to be useful at signaling projects as welcoming and providing gentle nudges for maintainers to proactively recognize emerging contributors. However, there are complexities to consider when designing recommendations such as the project current development state (e.g., deadlines, milestones, refactoring) and governance model. Finally, we distill our findings to share what the future of recommendations in open source looks like and how to make these recommendations most meaningful over time.
... Onboarding is the term used to describe the process through which new employees join and integrate into an organisation. There is extensive literature on onboarding in organisations extending back to the 1970s (Bauer and Erdogan,2011;Van Maanen and Schein, 1977), and significant research into onboarding in Open Source Software Development projects (Fagerholm et al., 2014;Steinmacher and Gerosa,2014). Most of the literature on onboarding in software development organisations is agnostic about the development approaches used, namely whether agile or not (Dagenais et al., 2010;Sharma and Stol, 2020). ...
Article
Context: A stable team is deemed optimal for agile software development project success; however, all teams change membership over time. Newcomers joining an agile project team must rapidly assimilate into the organisational and project environment. They must do this while learning how to contribute effectively and without seriously interrupting project progress. Objective: This paper addresses how newcomers integrate into an established agile project team and how agile practices assist with onboarding. Method: A single, qualitative case study approach was used, investigating a co-located agile project team in a large IT department who regularly onboard inexperienced newcomers. Analysis was abductive, consisting of inductive coding and theming using categories from an existing onboarding theory. Results: We describe the team's onboarding practices and adjustments and present an agile onboarding model that encompasses onboarding activities, individual adjustments, and workplace adjustments. Conclusions: A mixture of general and specific agile onboarding practices contribute to successful onboarding in an agile team. We provide practical guidelines to improve onboarding practice in agile teams. Our major new contribution is an extended model of onboarding for agile teams.
Article
The book examines the extent to which Chinese cyber and network security laws and policies act as a constraint on the emergence of Chinese entrepreneurialism and innovation. Specifically, how the contradictions and tensions between data localisation laws (as part of Network Sovereignty policies) affect innovation in artificial intelligence (AI). The book surveys the globalised R&D networks, and how the increasing use of open-source platforms by leading Chinese AI firms during 2017–2020, exacerbated the apparent contradiction between Network Sovereignty and Chinese innovation. The drafting of the Cyber Security Law did not anticipate the changing nature of globalised AI innovation. It is argued that the deliberate deployment of what the book refers to as 'fuzzy logic' in drafting the Cyber Security Law allowed regulators to subsequently interpret key terms regarding data in that Law in a fluid and flexible fashion to benefit Chinese innovation.
Preprint
Full-text available
A common assumption suggests that individuals tend to work with others who are similar to them. However, studies on team working and ability of the group to solve complex problems highlight that diversity plays a critical role during collaboration, allowing for the diffusion of information. In this paper, we investigate the patterns behind the connections among GitHub users in Open Source communities. To this end, we use Social Network Analysis and Self-Organizing Maps as the similarity measure. Analysis of textual artifacts reveals the roles of those connections. We find that diversity of skills plays an essential role in the creation of links among users who exchange information (e.g., in issues, comments, and following networks). The connections in networks related to actual coding are established among users with similar characteristics. Users who differ from the owner of the repository report bugs, problems and ask for help more often than the similar ones.
Conference Paper
Full-text available
Context: Onboarding is a process that helps newcomers become integrated members of their organisation. Successful onboarding programs can result in increased performance in conventional organisations, but there is little guidance on how to onboard new developers in Open Source Software (OSS) projects. Goal: In this study, we examine how mentoring and project characteristics influence the effectiveness and efficiency of the onboarding process. We study a collaboration program involving a total of nine Open Source Software projects and more than 120 students from different universities around the world as part of Facebook’s Education Modernization Program. Method: We use quantitative measurements of source code repositories, issue tracking systems, and discussion fora to examine how newcomers become contributing members of their OSS projects. Results: We found that developers receiving deliberate onboarding support through mentoring were more active at an earlier stage than developers entering projects through conventional means. Also, we found that project size and lifetime influenced onboarding. Conclusion: Empirical decision support can contribute to a more effective onboarding process in OSS projects. Mentor support in critical stages can accelerate the process, but project maturity is also a significant factor that increases the effect of onboarding.
Article
Full-text available
Teaching distributed software development (DSD) in project courses where student teams are geographically distributed promises several benefits. One main benefit is that in contrast to traditional classroom courses, students can experience the effects of distribution and the mechanisms for coping with distribution by themselves, therefore understanding their relevance for software development. They can thus learn to take more care of distribution challenges and risks when starting to develop software in industry. However, providing a sustainable environment for such project courses is difficult. A development environment is needed that can connect to different distributed teams and an ongoing routine to conduct such courses needs to be established. This article sketches a picture of the Software Factory, a platform that supports teaching distributed student projects and that has now been operational for more than three years. We describe the basic steps of conducting Software Factory projects, and portray experiences from past factory projects. In addition, we provide a short overview of related approaches and future activities.
Article
Full-text available
Nowadays, many software projects are partially or completely open-source based. There is an increasing need for companies to participate in open-source software (OSS) projects, e.g., in order to benefit from open source ecosystems. OSS projects introduce particular challenges that have to be understood in order to gain the benefits. One such challenge is getting newcomers onboard into the projects effectively. Similar challenges may be present in other self-organised, virtual team environments. In this paper we present preliminary observations and results of in-progress research that studies the process of onboarding into virtual OSS teams. The study is based on a program created and conceived at Stanford University in conjunction with Facebook's Education Modernization program. It involves the collaboration of more than a dozen international universities and nine open source projects. More than 120 students participated in 2013. The students have been introduced to and supported by mentors experienced in the participating OSS projects. Our findings indicate that mentoring is an important factor for effective onboarding in OSS projects, promoting cohesion within distributed teams and maintaining an appropriate pace.
Conference Paper
Full-text available
Nowadays, many software projects are partially or completely open-source based. There is an increasing need for companies to participate in open-source software (OSS) projects, e.g., in order to benefit from open source ecosystems. OSS projects introduce particular challenges that have to be understood in order to gain the benefits. One such challenge is getting newcom-ers onboard into the projects effectively. Similar challenges may be present in other self-organised, virtual team environments. In this paper we present preliminary observations and results of in-progress research that studies the process of onboarding into virtual OSS teams. The study is based on a program created and conceived at Stanford University in conjunction with Facebook's Education Modernization program. It involves the collaboration of more than a dozen international universities and nine open source projects. More than 120 students participated in 2013. The students have been introduced to and supported by mentors experienced in the participating OSS projects. Our findings indicate that mentoring is an important factor for effective onboarding in OSS projects, promoting cohesion within distributed teams and maintaining an appropriate pace.
Article
Full-text available
Small and medium enterprises (SMEs) are the driving engine behind economic growth. While SMEs play a critical role in generating employment and supporting trade, they face numerous challenges, the prominent among them are the need to respond to fasting time-to-market, low-cost and rapid solutions to complex organizational problems. Towards that end, research and development (R & D) aspect deserves particular attention to promote and facilitate the operations of SMEs. Virtual R & D team could be a viable option. However, literature shows that virtual R & D teaming in SMEs is still at its infancy. This article provides a comprehensive literature review on different aspects of virtual R & D teams collected from the reputed publications. The purpose of the state-of-the-art literature review is to provide an overview on the structure and dynamics of R & D collaboration in SMEs. Specifying the foundation and importance of virtual teams, the relationship between virtual R & D team and SMEs has been examined. It concludes with the identification of the gaps in the existing literatures and calls for future research. It is argued that setting-up an infrastructure for virtual R & D team in SMEs still requires a large amount of engineering efforts and deserves consideration at top level management.
Conference Paper
Full-text available
Open source software projects, are based on volunteers collaboration and require a continuous influx of newcomers for their continuity. Newcomers face difficulties and obstacles when starting their contributions, resulting in a low retention rate. This paper presents an analysis of the first interactions of newcomers on a project, checking if the dropout may have been influenced by lack of answer, answers politeness and helpfulness, and the answer author. We have collected five years data from the developers' mailing list communication and issue manager (Jira) discussions of the Hadoop Common project. We observed developers' communication, identifying newcomers and classifying questions and answers content. In the analyzed period, less than 20% of newcomers became long-term contributors. There are evidences that the newcomers decision to abandon the project was influenced by the authors of the answers and by the type of answer received. However, the lack of answer was not evidenced as a factor that influences newcomers' decision to remain or abandon the project.
Article
The book, The Mythical Man-Month, Addison-Wesley, 1975 (excerpted in Datamation, December 1974), gathers some of the published data about software engineering and mixes it with the assertion of a lot of personal opinions. In this presentation, the author will list some of the assertions and invite dispute or support from the audience. This is intended as a public discussion of the published book, not a regular paper.