###### Contents

  1. 1 Introduction
    1. 1.1 A note on terminology
  2. 2 Research goals
  3. 3 Background work
    1. 3.1 Collaborative software development
      1. 3.1.1 Communication
      2. 3.1.2 Coordination
      3. 3.1.3 Awareness
      4. 3.1.4 Task division and conflict resolution
    2. 3.2 Open source software development
    3. 3.3 From oss to industry: Theories and frameworks
      1. 3.3.1 Howison & Crowston’s theory of collaboration through superposition
      2. 3.3.2 Stol et al.’s factors for adopting Inner Source
      3. 3.3.3 Sharma et al.’s framework for creating hybrid-oss communities
    4. 3.4 Current trends
      1. 3.4.1 Decentralized versioning and workflow through software forges
      2. 3.4.2 External participation for collaboration
  4. 4 Research questions and conceptual framework
  5. 5 Methodology
    1. 5.1 Study of decentralized workflow
    2. 5.2 Study of external participation
  6. 6 Expected contribution
  7. 7 Timeline

##  1 Introduction

The proposed research outlined in this document intends to investigate the
effect of principles related to Open Source Software (oss) projects on the
collaboration of teams developing Closed Source Software (css). The principles
translate into practices that frame how development teams organize their work
(what we will describe as workflow) and how they communicate, coordinate, and
interact when they change their boundaries by accepting external
contributions. Collaborative software development has been an active research
area, aiming at proposing ways to support development teams in facing the
challenges of working in a distributed way and coordinating their collective
activity in an efficient and productive way. Recognizing the success of oss
teams in collaborating effectively and producing high quality software through
the combined effort of loosely coordinated individuals, research has been
proposing the adoption of development and collaboration techniques used in oss
projects by commercial organizations. We propose to study cases that
illustrate such adoption of oss-like practices in organizations developing
css, and the effects on the team level and how members collaborate. We aim to
contribute to theories of collaborative software development by building a
framework of factors-at-play when teams adopt oss-like practices. We also aim
to contribute to practice, by highlighting the benefits and challenges of
teams adopting oss practices and help guide organizations that are following
similar initiatives or plan to adopt them.

The proposal is structured as follows: After establishing the terminology that
will be used throughout the text, we present details about the research goal
of the study, and the main research questions that frame it in Section 2. The
background for the research goal is discussed in Section 3, presenting studies
that shape the research area. The background work spans three sub-areas:
literature that investigates collaborative software engineering and related
issues, studies and writings looking into Open Source Software (oss)
development and its practices, and literature that has tried to form a bridge
between the two areas, with frameworks, theories, and practices that advocate
the transfer of development and collaboration practices from oss development
to development taking place inside software organizations. We revisit the
research questions after presenting the background work, giving an overview of
the proposed research as a conceptual framework in Section 4. Sections 5 and 6
present the proposed methodology and expected contribution, and a tentative
timeline is presented in Section 7.

###  1.1 A note on terminology

The proposal follows the rules below regarding terminology:

A software team will refer to a group of developers that collaborate to
develop a collective codebase which represents a system or an application.

Software engineering and software development will be used interchangeably.
Programming is the term that will be used to refer to the activities that
relate to writing code. By extension, programmers are members of the software
team that perform activities related to writing code.

Open Source Software (oss) development will be used to refer to the
development of software systems or applications, the code to which is open and
respects the freedoms regarding redistribution, modification etc, as described
in the Open Source Definition 111http://opensource.org/osd. We acknowledge the
differences between free/libre and oss software, as well as the multitude of
corresponding licences, but the distinction is out of scope for the current
proposal and oss will be the only term used. Also, although oss development
results in producing software with open source code, this is not the
identifying characteristic that we will be focusing on regarding oss; it’s the
particular development and collaboration practices that characterize oss
projects that we will be focusing on, outlined in more detail in the
corresponding background work in Section 3.

Conversely, Closed Source Sofware (css) development will refer to development
of software that prohibits inspection and modification of the source code, and
which is regulated by licence agreements between the end-user and the software
company. Again, the focus is not on the legal nature of the end product, but
on the way that the software is developed and the collaboration of the
software team.

css will also be referred to as commercial software, representing that this is
software that is produced for commercial purposes and produced by a commercial
organization. The organizational entities producing commercial software will
be referred to as software organizations or software companies. Software teams
that develop css will be referred to as css teams or commercial software
teams.

We also acknowledge the differences between distributed and global software
development as described in Agerfalk et al [AFHLLC05], but for our scope the
two terms are considered equal and will be used interchangeably.

##  2 Research goals

Open Source Software (oss) development is fundamentally different from the
development of Closed Source Software (css). Since users can examine and
modify the source code, anyone that is interested can voluntarily contribute
to the improvement and advancement of the software. The most notable examples
of oss development are large-scale, geographically distributed projects that
produce complex, high-quality, reliable systems while attracting and
maintaining a community of developers and users around them.

The example of oss development is frequently cited as a successful example of
open and distributed collaboration with projects benefiting from the ideas,
skill and input of highly motivated and competent developers [AF08, BHC09].
Several empirical studies have analyzed a wide range of oss projects to
distill principles on which they operate, and investigate if and how these
principles can be transferred to css development projects [SSR02, MFH02,
NYNK02]. For the most part the studies identify the constructs on which oss
projects operate but not specific techniques or practices of how to transfer
them to css projects (even more so, transfer them successfully). Also, what
seems to be missing is accounts of such initiatives and how they were
implemented in practice, along with their effects on organizing work and
collaborating [Fitzgerald11, SABLF14]. At the same time the software industry
has gradually moved closer to the oss paradigm by borrowing tools that are
used frequently, moulding its processes to reflect the tools’ capabilities,
and making changes to its licensing rules to allow more community-based
development. However, it is still not known how the collaboration of teams in
software companies changes under these circumstances and research is looking
for ways to help development teams and organizations embrace openness as a
driver for innovation [BVK09].

Collaboration is a high-level concept that can remain elusive if not framed
properly in our discussion. Collaboration of software teams is made up of
members’ interdependent actions, coordinated towards a common goal
[Whitehead07]. In order to systematically study collaboration we follow Malone
& Crowston’s [MC94] view of coordination as the direct or indirect actions
needed to manage interdependencies in a team’s activities. We synthesize a
team’s collaboration process by observing practices, mediated by tools to
handle coordination through communication, awareness, task division, and
conflict resolution. We refer to these as the collaboration elements and
discuss background work regarding them in Section 3.

The descriptions of how collaboration works in oss projects [Shah03,
Ljungberg00] seem to converge to loosely coordinated participants openly
sharing contributions, part of what is becoming known as “the open source way”
222http://www.theopensourceway.org/. Decomposing this description, we see two
influences from the oss world that growingly enter the environment of
proprietary software projects, each discussed below.

The first one is the adoption of Decentralized Version Control Systems (dvcs)
and workflows to manage code contributions, lowering coordination needs. dvcs
enable parallel development through easy branching and merging, making it
operationally efficient for individual developers to create their own branch
or copy of a main repository and even work offline on their own. Merging back
to the main repository is also handled efficiently and therefore the option to
isolate concerns and development effort has lower operational cost, while
potentially increasing the speed of the team’s development. Teams use dvcs
together with a workflow, a protocol that prescribes the steps that developers
follow when branching, merging, reviewing, testing, and deploying code that
forms the collective codebase.

The workflow is a team rule more than anything else. The team decides which
workflow suits them and can even reach their optimal workflow after trial and
error. Git, the most adopted dvcs at the moment, has the potential of working
well and supporting a variety of different workflows and therefore gives teams
flexibility. For the demands for distribution of the oss world for which it
was created, Git is considered to have addressed some of the shortcomings of
centralized version control systems and is now a favoured choice of both
starting and established projects [AS09], making it an appealing choice for
distributed development teams in software organizations too.

Parallel to the adoption and growth of dvcs we see the creation and growth of
web-based platforms for code hosting, version control and repository
management. The most notable and advanced example currently is GitHub. GitHub
is a software forge, meaning a platform that supports collaborative
development by providing tools for version control, issue trucking, testing
etc, integrated under the same interface. GitHub also provides integration
with a growing list of specialized tools for bug tracking, testing, continuous
integration and communication, and has opened its source code that handles
integrations to allow the community and teams to build service hooks for its
preferred tools. The advantages that GitHub offers are a user-friendly
interface to Git, a transparent development environment [DSTH13] that allows
awareness of activity, as well as implementations of pull-based development
[GPD14] and decentralized workflows.

The adoption of dvcs in general, and Git and GitHub in particular, has been
the focus of attention of both researchers and practitioners lately. Most of
the information comes from public repositories and therefore represents oss
development and the way a decentralized workflow in practice supports the
collaboration and interactions for a software team are not fully known. Our
research goal is to study how a decentralized workflow, as implemented through
GitHub, is used in practice by commercial software teams and how the five
collaboration elements are supported by the principles of the decentralized
workflow and GitHub’s features.

The second influence from the oss environment on proprietary software
projects, is accepting external contributions to the produced software. We
will consider external to be the contributions that come from outside the
organizationally recognized development team. For example, a company that
maintains a number of public repositories, in addition to its private ones,
where interested volunteers can contribute, is considered to be accepting
external contributions. Another example would be an organization that still
keeps the software development private but opens its repositories to other
departments in the organization.

The latter practice is gaining ground, especially with large software
companies or large organizations that handle (at least some of) their software
development in-house, an initiative known as Inner Source [O'Reilly99]. Inner
Source is considered to be a development philosophy rather than a clear set of
practices, operating on oss principles. The software projects that run under
Inner Source are usually started as the initiative of a single developer or a
small team, are hosted in an accessible location like a software forge and
members of other teams, departments, organizations, or individual volunteers
can contribute in any form they prefer.

Inner Source initiatives have been reported through case studies focusing on
how the organization can adopt and promote them. However, it is natural to
expect that accepting external contributions will change conditions under
which the team operates. Examples are added transparency and awareness,
increased size of the team, need for reviewing and handling contributions in
an operationally efficient way. There are also managerial issues that need to
be addressed in this case, such as balancing assigned versus voluntary labour,
and these can also have an effect on how the team functions. Inner Source
resembles initiatives to create oss-like communities around projects inside
organizations or between the organization and the outside environment, but the
effect on the collaboration and function of the development team is largely
unexplored. Our research goal is to study in-depth the structure, process, and
culture of the development team under an Inner Source initiative and how the
five collaboration elements are supported by the followed practices.

For the proposed thesis, we are interested in how commercial teams collaborate
in the face of two influences from oss development:

  * •

the use of tools and workflows that support decentralized development

  * •

receiving external contributions to the development of a software product.

Both influences change conditions under which teams function. We therefore
assume that a software company that adopts either or both the above influences
experiences changes in the collaboration and interactions of the development
team. By investigating the principles that teams operate under and how they
translate them into practices, we can create a framework for css development
teams in software organizations that want to follow “the open source way”. The
resulting framework can inform theories of collaborative software development,
as well as inform the practices of css development teams in software
companies.

The two research goals outlined above correspond to the following two research
questions:

RQ1: How does a decentralized workflow fulfill the collaboration and
interaction needs of commercial software teams?

RQ2: How does accepting external contributions impact the collaboration and
interactions of commercial software teams?

The following section summarizes and discusses literature from three areas
related to the proposed research: collaborative software development, oss
development, and studies that have attempted to bridge the two areas by
sharing findings and conclusions between the two. Additionally, we present
work and information relating to the two current trends we propose to
investigate: decentralized work through software forges, and external
participation for collaboration.

We revisit the research questions in Section 4 and break them into sub-
questions, following the discussion of background work in Section 3.

##  3 Background work

###  3.1 Collaborative software development

Software engineering is generally considered a collaborative activity where
teams of developers need to work together effectively to deliver a project in
a timely manner to an appropriate level of quality [DSQTR07]. They follow a
development process that on the low level tackles the programming activities,
while on the high level addresses project management and organizational
activities. The selection of processes depends on the characteristics of the
team as well as current trends and best practices. Examples of such trends are
quality assurance through peer review, and bottom-up human-oriented
development processes, such as agile methods [HC01, CH01].

Collaboration is by no means a straightforward task; it is a complex state
involving the “right” mix of communication and information sharing to drive
coordination of teams members’ activities. Teams with a shared culture, goals
and mental models have a performance advantage [EK02], even more needed if
teams operate over distance, which can cause failures [WSDN09] and delays
[HMFG00]. Although the critical role of collaboration is recognized and there
are many tools and approaches to support it, it is still an open subject to
understand from both theoretical and practical standpoints.

Software teams today are, in more cases than not, distributed. Distributed
teams face the regular collocated challenges of coordination, communication
and collaboration [HG99IEEE], plus the complexities introduced by global
distance [CA01, DZ03, HM03]. Research on global software development focuses
on characterizing the distributed teams’ behaviour or developing tools and
techniques to mitigate problems [LEPV10, NWD08, Herbsleb07].

Tool support for collaborative development offers variety of choice to
software teams. Collaborative Development Environments (CDEs) have evolved
from Integrated Development Environments (IDEs) by becoming web-based and
supporting the development team’s collaboration on top of the individual
programmers’ activities. CDEs are also called software forges, and researchers
see them as having originated in the oss community [REMMNNO09]. Software
forges typically include tools for source code management and version control,
bug tracking, and also support communication and co-ordination between team
members through chat clients, wikis, mailing lists and forums [LEPV10]. As the
tools provide the technological conditions that enable efficient collaboration
and mitigate geographical distribution, however, they create additional social
and organizational considerations.

Apart from selecting tool platforms and development processes to support
collaboration at the appropriate scale, software teams and companies face the
challenge of operationally adjusting to them. The creation of lean
organizational structures with self-organizing teams, for example, is a
challenging approach for organizations moving away from hierarchical
structures, borrowing some insight from oss projects and other instances of
open collaboration [BVK09]. In their overview of the collaborative software
engineering research field, Whitehead et al. [WMGH10] named three trends
expected to improve collaboration: software development environments being
web-based, the potential for social network integration, and the participation
by end-users (and other interested individuals) in development. Today we see
these trends unfold with the growing use of software forges like GitHub
333https://github.com/blog/1724-10-million-repositories, the adoption of
social media by software developers [BBS13], and the changing development
participation models followed by big software organizations [DGMN02, SABLF14].
Although these are seen as potential improvements they present their own
challenges for teams and organizations that want to adopt them and their
effects on collaboration are not thoroughly studied.

Collaboration of software teams is made up of members’ interdependent actions,
coordinated towards a common goal [Whitehead07]. We follow Malone & Crowston’s
[MC94] view of coordination as the direct or indirect actions needed to manage
those interdependencies. We synthesize a team’s collaboration process by
observing practices, mediated by tools to handle coordination through
communication, awareness, task division, and conflict resolution. We refer to
these as the collaboration elements and discuss background work regarding them
below.

####  3.1.1 Communication

Low-cost, globally reaching communication enabled global distribution of css
projects and created the technological conditions that supported the emergence
of oss. Communication is a big overhead in large organizations [Brooks95,
KS95], with developers spending half to three quarters of their time on
communication [Scacchi84]. Factors like the number of people communicating,
different backgrounds, the effectiveness of tools, and the socio-cultural
distribution of the team affect the frequency and efficiency of their
communication [HCAF06] and the bigger the communication overhead, the less
effective is an organization.

Collaboration can happen with or without explicit communication. Collaboration
can be mediated through artifacts and traces of development work found in code
repositories, comments and archives, a trend that has been documented in oss
projects [BHC09, HC14]. However, communication is still necessary if
information is not obtainable [TVL06]. Both collocated and distributed teams
rely on communication [HM03, KLV07, TVL06], either to coordinate activities or
to acquire knowledge. Researchers have, therefore, distinguished two types of
communication: Coordination communication, to discuss, negotiate or avoid
possible conflicts among software components, and expertise communication, to
ask for information that is essential for the developers’ task at hand.

Communication costs are high. While supporting communication is important,
encouraging more communication in general is not the goal since there are
documented negative effects from too much communication [DISK07].
Partitioning/decomposition of the system under development, and documentation
are usually used to isolate developers and reduce the need for direct
communication, however they are far from perfect [CKI88] (for example,
developers often skip writing documentation). Modularization is not always the
answer either [Grinter95], since even in a modular project there can be a lot
of concurrent work causing defects, even with state-of-the-practice version
control tools in place.

Programmers generally prefer solitary work with long periods of concentration
[ML99], a fact consistent with case studies showing that knowledge workers
need to experience a state of flow [Csikszentmihalyi91]. Software forges are
currently building on the capabilities of Decentralized Version Control
Systems (dvcs) to ensure that a developer can focus on their task, and then
facilitate easy communication with peer programmers when it becomes necessary.
They form transparent environments [DSTH13] where information is visible and
available, consistent with research studies that have shown that configuration
management information and data from issue tracking can be used to guide
communication [SRCMP04, MH02]. In addition, wikis are now used to leverage
communication and continuous integration tools provide awareness regarding the
effects of changes on the product.

Concluding point. Communication and collaboration among team members are key
success factors for large, complex software projects. In addition to industry,
examples of such projects can be found in the oss community (e.g Mozilla,
Apache, Eclipse). oss projects are of particular interest for communication
and collaboration research because their members rarely (if ever) meet face-
to-face, and yet the projects function efficiently though their own
collaboration practices. More details are discussed in 3.2.

####  3.1.2 Coordination

Coordination is recognized as the main challenge of distributed development
[Herbsleb07], since communication is not as effective over distance and teams
face misunderstandings and difficulties in sharing information [HMG06, GHP99].
A team’s productivity is affected by distance: the productivity of distributed
teams is lower than the productivity of collocated teams [HMFG00], which is
lower than the productivity of radically collocated teams [TCKO00]. Herbsleb
et al.’s study comparing collocation and distribution [HMFG00] found that in
distributed team development it is harder to locate people, get work-related
information through casual conversation, get access to information shared with
collocated colleagues or receive help, and that negatively affected the team’s
productivity. A similar study some years later [NWD08] didn’t find evidence
that distributed communication introduced significant delays more than same-
site communication. This interesting contradiction points towards the fact
that teams are gradually dealing with the reality of distribution more
effectively and that there may be other mediating factors of the effects of
distribution, possibly of an organizational or social nature.

Coordination has been studied in various domains and contexts as any kind of
group entails coordination [Amrit05, MC94]. The need for coordination between
developers arises from underlying technical dependencies among work artifacts
as well as the structure of the development process [CWHC06, Crowston97,
SFD05]. Optimizing towards one aspect of collaboration support often involves
tradeoffs with respect to other aspects [SHH08]. Congruence has been proposed
as a theoretically optimal level of support [CWHC06]. One tension point
recognized is relative to the fact that developers use tools but also
establish informal practices [RDHAAHQSSDST07]. Coordination needs adjustments
and individuals have to have the ability to respond to ongoing changes and the
effects of those changes to their work.

A host of tools have been created to improve team coordination, mainly by
increasing awareness of coordination needs through highlighting relevant
dependencies to a developer, recommending work items that need attention, and
providing notifications of changes made by other developers [SRH10]. However,
information overload is a frequent side-effect of trying to keep developers
aware [Sullivan04]. Basic version control tools like cvs and svn indirectly
address coordination through forcing work serialization or allowing parallel
work (but demanding merging effort) [MWE10]. dvcs is built on the premise of
de-coupling work by not locking files as programmers are working on them and
reducing merging effort.

oss projects, by default distributed, look for coordination practices that
demand the least interaction. For example, coordination in oss projects
doesn’t follow the connotation of a hierarchical structure where work goals
are defined and tasks are assigned to individuals. Instead participants
identify tasks that they would like to work on, or create tasks they think
need to be done and work on providing a solution. The result is “loose”
coordination based on visible information and receiving feedback from peers
[Shah03] when necessary. The principles of meritocracy and competence are
central in oss projects [LW03] meaning that individual developers and the
community can determine on their own how work should be carried out.

Concluding point. Coordination, a central activity for any collaborative
project, is usually handled through communication. Geographical distribution
hinders coordination communication and tools have been developed to keep
developers aware of dependencies through notifications. oss projects have a
looser approach to coordination, mediated by the competence and self-
organization of participating developers.

####  3.1.3 Awareness

When engaging in a collaborative development project, members need to maintain
awareness about what is happening in the project and what other members are
working on. In distributed development maintaining awareness becomes even more
difficult as communication is not as efficient and team members cannot use
visual cues as in collocated communication [SCG05]. Limited awareness of
members’ activities and the changes they make to artifacts provides a poor
basis for coordination in a team.

Awareness is strongly related to communication and coordination since the goal
is essentially to detect and communicate relevant information to developers.
Tools and approaches that support awareness to facilitate coordination are
targeted towards detecting possible conflicts [SRH12] or anticipating
communication requirements between team members [CWHC06]. Conflict detection
uses an artifact-based approach, assuming potential code conflicts based on
the files developers work on. Communication requirements can be identified
when there are known technical dependencies between components that developers
are working on. In either case, tools aim to provide developers with the
required information to keep them aware of changes that might affect them,
usually at the cost of information overload. Other tools are created with the
rationale of enabling developers to see information about developers’
activities rather the artifacts they touch [GSPP04]. A framework for
evaluating visualization tools that support awareness and a survey of tools is
provided in [SCG05].

Gutwin et al. [GPS04] looked at how oss developers maintain group awareness
and found that this is mostly achieved through text-based communication in
mailing lists and chat systems. Their findings show that even in the absence
of sophisticated tools oss developers maintain both general group awareness
and more detailed knowledge of people that they plan to work with. Software
forges generally built on this idea of lightweight communication and
visibility as a driver of awareness and a mediator for distributed
collaboration.

Concluding point. Awareness is maintained through receiving information about
activities in the project and changes in the artifacts. Configuration
management tools can be possible information sources of technical dependencies
to recommend activity that developers need to keep track of, but involve the
risk of overwhelming them with information that they do not deem important. In
oss projects developers maintain awareness through lightweight communication
and information in the source code repositories.

####  3.1.4 Task division and conflict resolution

Task division includes the definition of tasks and their allocation between
team members. Task division shapes a social network of developers that handle
a task and, therefore, creates communication and coordination requirements
between them [CWHC06]. The degree to which the coordination requirements are
met, translated into a metric called Socio-Technical Congruence stc has been
shown to correlate with a team’s productivity [CHC08]. The product’s
architecture impacts task division via its modularization [Parnas72], and also
follows the established communication structure of the organization
[Conway68].

Lamersdorf et al. [LMR09] reviewed the state of the practice regarding task
allocation in distributed software projects through an interview study with
managers from software organizations. Functional expertise was the major
criterion for task allocation, along with availability and process ownership.
However, the authors also focus on task allocation between different
development sites, a decision more affected by market analysis. Apart from
architectural views and interrelationships, task allocation depends on
temporal, knowledge and cultural dependencies between distributed individuals
or teams [Imtiaz12].

In hierarchical organizational structures, typically associated with large
software organizations, task division and allocation is handled at a
managerial level and tasks are handed down to individual team members or sub-
teams. In oss projects task division and allocation is part of the self-
organizing nature of teams and developers choose the tasks they work on,
sometimes also creating those tasks to begin with. Issue trackers are mostly
used as a task management tool in oss.

In either case, even if special care has been taken to modularize the tasks
and align them with the developers’ expertise, conflicts still occur. Research
and practice have tried to detect possible conflicts early as a prevention
measure [SRH12], and parallelize development in order to avoid them
[Parnas72], but it is an accepted fact that technical dependencies cannot be
removed entirely. Therefore, some mechanism needs to be in place so that
conflicts can be resolved efficiently. Version control systems handle merging,
and some web-based versioning tools (GitHub for example) have the
functionality of informing whoever handles the merge if the committed files
are going to cause conflicts or not when merged. Conflict resolution is part
of the development process that a programming team follows, usually handled by
an integrator or a maintainer in oss projects.

Concluding point. Task division and conflict resolution are tightly related to
coordination is a software project: task division points towards coordination
needs to avoid problems, and conflict resolution points towards coordination
needs to solve problems. oss projects use self-organization and meritocracy as
the basis for both functions.

###  3.2 Open source software development

oss projects have become a major player in research and commercial software
development [Scacchi07]. However, oss operate under circumstances that are
different from css projects. Most analysis of socio-technical relationships in
oss teams aims to understand why and how they work and can support
collaboration in this domain [BL01, SG06], recognizing that the social,
psychological, and even philosophical elements play a critical role [HK03].
Motivation for participation in oss projects is based primarily on the desire
to learn and develop new skills [Herte03, HO01, LW03]. oss projects need to
coordinate across a diverse community of volunteers, and use processes and
collaboration tools to support the distributed team, from version control and
repositories to bug tracking and release management [Scacchi07].

oss development is a way of building, deploying and sustaining large software
systems on a global basis and differs in many ways from principles and
practices advocated in traditional software development. A significant feature
is the formation and enactment of collaborative software development practices
and processes performed by loosely coordinated developers and contributors.
Developers volunteer their time and skill and may only work at their personal
discretion rather than as assigned and scheduled. oss projects are usually
global without a corporate owner or management staff to organize, direct,
monitor and improve the process in place.

oss developers are typically users of the software they develop [HK03, NYNK02]
and end-users often participate and contribute to oss development as non-
developers, in an onion-like model of contribution based on the ratio of the
parts of the produced software that are contributed over used [CWHW08, CH05].
The onion model describes that typically oss projects have their initiator and
small team of core developers in the middle, with write-access to the
project’s repository. Around them there are co-developers that submit code but
cannot commit it to the repository. Further out there are active users who
occasionally submit bug reports. The outer circle consists of the passive
users, those who just use the software without contributing. Substantial
effort is directed at enabling and facilitating collaboration among developers
but generally there is no traditional software project regime, budget or
schedule (although there are exceptions, e.g Ubuntu is released every 6 months
and its development is led by a proprietary organization).

oss development has been an intriguing research domain for well over a decade
now. Studies of developer motivation and project organization were the first
attempts of the research community to understand and explain the presence and
evolution of oss development, and try to predict its future as a software
development trend analyzing its viability as an economic and business model
(for exampe [LT02]). Interest in the collaboration model that supports oss
development has also been considerable, given that oss developers are highly
distributed and mostly don’t engage in face-to-face communication. Due to the
pragmatic constraints they face, it has been considered surprising that oss
projects achieve smooth coordination and consistency in design and innovation.

Yamauchi et al. [YYSI00] found that oss programmers are biased towards action
rather than coordination and follow a rational decision-making process where
the technologically-superior options are always chosen. In terms of tools, the
oss projects they observed relied on version control, to-do lists and mailing
lists. They used their findings to challenge traditional approaches in cscw
literature advocating for rich interactions through multimedia conference
systems. Shared ideology has been found as a driver for supporting the loose
coordination of oss projects and acting as a linchpin of oss development
efforts [Ljungberg00]. Stewart & Gosain [SG06] grouped values related to oss
development in three categories: collaborative, individual, and oss process
beliefs. These values were found to have significant positive effects on team
effectiveness because they had positive impact on trust and communication
quality. Beliefs regarding freedom were found to have negative effects because
they tended to polarize developers.

Given the special characteristics of oss development and the interest in how
oss developers coordinate their work, research has shown interest in the tools
and practices that facilitate oss development. Version control tools work as a
centralized mechanism for coordinating and synchronizing development [BOS99],
and also mediate control of what will be checked in the collective codebase.
Ducheneaut [DUCHENEAUT05] found that that oss developers coordinate their work
almost exclusively by three information spaces: implementation, documentation
and discussion. The versioning system provides the backend of the
implementation space, keeping track of changes made to the project related
files and corresponding versions. The internet is used as the documentation
space with wikis, mailing list archives, most recently also peer-developed
resources like Stack Overflow. Because of the distributed and informal nature
of oss projects, discussions between project members, associates and users are
done and tracked in mailing lists and online forums, more recently shown to
also take place in the issue repository [GBLPD13]. The technical
infrastructure of an oss project usually consists of the versioning system,
bug tracking system, and mailing lists [Fogel09].

The public availability of oss project data has helped research in this
domain. Crowston et al. [CWLEH05] used data from developer mailing lists and
online forums of 3 active projects to analyze coordination mechanisms. They
found similarities between oss groups and reported practices of proprietary
projects in the coordination mechanisms used to manage task-task dependencies.
Differences were found in the coordination of task-actor dependencies. “Self-
assignment” was the most common mechanism used in oss projects. Governance
through meritocracy [Fielding99] centralizes and concentrates certain kinds of
authority, trust, and respect for experience, making governance more tractable
where decision-making is shared among core developers. Leaders in oss projects
are typically those who have recognizably done the most work.

Walt Scacchi [Scacchi10] thoroughly discussed collaboration affordances that
facilitate work in oss projects based on insights from several empirical
studies on the work practices followed by oss teams. He defined affordances as
“situated, interactional properties between objects and users, that facilitate
social interactions in a complex environment” (giving Code of Conduct as an
example). Scacchi recognizes several collaborative affordances of oss
projects. Firstly, they nurture the motivations of developers, and give them
the responsibility to organize and manage themselves to fulfill their
motivations. oss projects provide an environment of shared beliefs in freedom
regarding software, speech and choice [ES04], trust and social accountability.
Beliefs, values and norms form part of the developer’s mental model [EK02] and
serve as affordances that enable collaboration and teamwork, while the failure
to enact these beliefs can drive developers apart [ES08]. Finally, artifacts
that developers can use to prescribe or question what is happening in an oss
project (called software informalisms) are also considered collaboration
affordances, creating a healthy environment for discourse in the project.
Scacchi concludes his review by recommending systematically comparing
collaboration affordances in oss and css projects to see what’s similar,
what’s different and why.

Although some oss projects maintain their own online presence as a gateway for
potential contributors to find them and access them, a large number of oss
projects used code hosting websites that combined free repository hosting with
a series of tools that facilitate collaboration. SourceForge
444http://sourceforge.net/ has been the most notable example, attracting a
large number of oss projects, a fact that also made it an appealing dataset.
Ghosh [Ghosh03] showed that many oss projects on SourceForge are self-
organizing social networks. Xu et al. [XGCM05] classified developer roles in
oss projects on SourceForge, similar to those in the onion model. Lopez et al.
[LRG04] found that oss projects have small world and scale free properties and
that weakly associated co-developers and active users may be important factors
in oss development. Code hosting websites are an important medium for oss
projects because they facilitate the availability and visibility of project-
related information that is central to oss development.

Recently many oss projects have migrated to Git 555http://git-scm.com/ as
their version control system and GitHub 666https://github.com/ as a
collaborative development platform. We will discuss this trend in more detail
in 3.4

oss projects are recognized for producing high quality and sustainable
software systems with thousands to millions of users [MFH02]. Aberdour
[Aberdour07] addressed the question of how to achieve oss quality, by
comparing the practices of oss with css development. He reported that high-
quality oss relies on having a large and sustainable community that has to be
fully understood by the community members. Final guidelines to quality oss
imply high code modularity, rapid release cycles, and many bug finders. These
findings on quality justify the aim to better understand software project
dynamics in oss and css projects.

###  3.3 From oss to industry: Theories and frameworks

Research and practitioner interest in oss development has been inspired by how
oss development seems to overcome difficulties encountered in commercial
software development, in either its collocated or distributed form.
Researchers have therefore tried to distill useful lessons for conventional
development from the oss model of organizing [KH06, AF08]. Below we discuss
influential frameworks and theories that will guide the proposed research.

####  3.3.1 Howison & Crowston’s theory of collaboration through superposition

Howison & Crowston [HC14] developed a theory of collaboration that represents
a way of working that builds on individual work being highly independent. They
analyzed oss projects to arrive at a theory of collaboration in that setting.
Their study intended to investigate what they called “the open source way” as
a model for collaboration and organizing. To this end, they selected
community-based oss projects without a formal institutional representation,
and with no corporate involvement. Their study is based on extensive
ethnographic study, a replication field study, and theorization, with a
primary focus on collaboration that leads to insights on work-breakdowns.

The authors’ primary findings have been that developers didn’t plan their work
relying on others’ availability and planning was kept to a minimum, based on
what was already in the codebase. Developers proceeded with their work in
small, independent steps that had almost immediate return and the results of
which were stackable, what the authors’ named “collaboration through
superposition”. Their replication study provided evidence of working in short
increments that were more or less self-contained. The authors also observed
productive deferral, postponing work on a task that is difficult to complete.

In their theory of collaboration through superposition, Howison & Crowston
propose “building on what’s there” and “productive deferral” as the way
successful oss projects evolve their work, suggesting that planning ahead is
not the usual option. For collaboration through superposition to succeed in
any domain they recognize certain conditions: Firstly, the object of work
needs to be layerable, have low instantiation cost, and low distribution cost.
Low distribution cost is something that is easily afforded through using
online code hosting sites like SourceForge and GitHub, which make project
artifacts accessible to everyone and lower the barriers to contribution.
Irrevocable openness is another condition that will allow individual
developers’ work to be superposed by allowing the freedom of modification and
redistribution. Finally, time is the third condition; projects take some time
to be discovered and generate interest for contributions.

Critique:

Howison & Crowston’s theory represents a current development in oss-related
research. The authors uncover the workings of oss projects but the fact that
they focused on “pure” oss projects (with no ties to commercial organizations)
acts as a double-edged sword: on the one hand the authors can have confidence
in claiming that what they record is “the open source way”, but on the other
hand they leave open questions regarding the transferability of their
conclusions regarding work organization to software companies. The time cost
is probably the characteristic that can be the most problematic for commercial
organizations. The notion of productive referral has merit but it is
questionable whether a company can postpone implementing features until it
becomes easier or wait to engage enough external contribution to assist with
implementation. This could work for tools and features that are not time-
critical and/or for software that the company uses in-house, as is the case of
Inner Source initiatives, discussed below.

####  3.3.2 Stol et al.’s factors for adopting Inner Source

Stol et al.’s study on Inner Source [SABLF14] builds on and adds to literature
that has aimed to understand the success of oss projects in producing great
software with their own process, and draw lessons and practices and transfer
them to commercial software development [Fitzgerald11]. Organizations have
shown interest in leveraging oss development practices, a practice that was
earlier called Inner Source [O'Reilly99]. Inner Source does not have a
specific definition, only a loose description as “[organizations] using open
source development techniques within the corporation, or with a cluster of key
customers–even if they aren’t ready to take the step all the way to releasing
their software as a public open source project” [O'Reilly99]. This loose
definition means that there might be different types of Inner Source
initiatives.

The authors investigated the important factors for the adoption of Inner
Source by organizations. They frame Inner Source as a philosophy of
development rather than a development methodology, based on the principles of
egalitarianism, meritocracy, and self-organization, and staying away from
predefined approaches, tasks, artifacts and roles. They conducted a review of
literature discussing the transfer of oss development principles in commercial
software projects, and extracted a framework (shown in Figure 3.3.2) of
factors that support the adoption of Inner Source in organizations.
Additionally, they conducted a multiple case study to illustrate and
demonstrate the factors in action.

The identified factors focus on building and sustaining a bazaar inside an
organization [Raymond99], publicly and openly sharing projects and
contributions with the rest of the organization, or the world. The authors
recognize 3 areas that need attention; the software product needs to be
interesting, serve multiple stakeholders and be modular. The practices need to
support bazaar-style development and quality assurance, and use standardized
tools. Finally, the community around the project needs to be backed by the
organization’s management, be transparent, and follow self-organization and
meritocracy. The authors show that these factors have been in effect on three
occasions of Inner Source initiatives in large organizations.

Critique:

There are three gaps in the Stol et al. [SABLF14] study that our proposed
research aims to fill:

Firstly, although the study provides an excellent high-level view of factors
that organizations can take into account when considering adopting an Inner
Source initiative and highlights the areas that need attention, it doesn’t
provide specific practices that organizations can use and what benefits or
tensions they should expect, a limitation recognized by the authors
themselves. Secondly, the study doesn’t cover Inner Source initiatives that
have moved beyond the adoption stage, to investigate whether there were
additional or different areas where changes were recorded. This leaves room
for the investigation of the impact of adopting Inner Source initiatives in
organizations, especially on the team level, which is one of the aims of the
proposed research of this thesis. Thirdly, the factors identified in the
literature regarding organizations may not cover the reality of how teams
collaborate when following oss-like practices. For example, in our own initial
investigation (more details in Section 5) we found that a particular workflow
co-exists with practices like code reviews before merging and self-assignment
of tasks, both known practices in oss projects. Our work can extend the
existing framework by adding factors of organizing work in a bazaar style to
aid collaboration on the team level, an area not investigated by Stol et al.
[SABLF14].

Figure 1: Overview of framework for adopting Inner Source in organizations,
from Stol et al. [SABLF14].

####  3.3.3 Sharma et al.’s framework for creating hybrid-oss communities

Sharma et al. [SSR02] produced a framework in 2002 for creating hybrid-oss
communities inside organizations, a similar concept to the bazaar advocated by
Stol et al. [SABLF14]. The authors’ goal was to help organizations foster an
environment similar to oss projects to transfer some of the benefits. Their
framework builds on a framework from organizational theory, analyzing
organizations based on the dimensions of structure, process, and culture
[MS78].

By reviewing extensive literature the authors extracted oss practices
regarding division of labour, coordination, governance, development process,
and values, among others. They compared those to known practices of commercial
organizations and distill transition steps to building oss-like communities
inside companies to highlight the differences in the structure of
organizations, projects and teams, differences in the processes followed
regarding development, communication, and coordination, and differences in the
underlying culture. The identified differences were used by the authors to
propose areas to address for filling the gap and potentially help in creating
hybrid-oss communities inside the organization.

The framework is shown in Figure 3.3.3. All the identified factors relate to
how to build, govern and support communities through infrastructure. The
authors propose that building communities of practice is key, where
information flows between informal networks that rely on electronic
communication. They advocate shared decision making and flexible membership
status, where members can join and leave teams freely. Finally, they propose
and infrastructure that helps coordinate team members’ activities around
repositories and versioning, as well as common development and testing tools.

Critique:

The visible shortcoming of the framework is that it is rooted in literature
and not empirically validated. The overlap between the factors for building
hybrid-oss communities in the Sharma et al. framework and the factors for
adopting Inner Source in the Stol et al. framework is substantial, which gives
more confidence in the findings. In the proposed thesis we plan to use the
Sharma et al. framework to target areas for investigation of the effects of
adopting oss-like practices in commercial projects, and in the process
validate factors present in the framework.

Figure 2: Overview of framework for creating hybrid-oss communities in
organizations, from Sharma et al. [SSR02]. The framework focuses on how
communities should be built, governed and supported by infrastructure.

###  3.4 Current trends

####  3.4.1 Decentralized versioning and workflow through software forges

Development teams follow a process, usually one they have decided or was
provided to them. A process is a predefined structure for the sequence of
steps to be performed, the roles to be fulfilled and the artifacts created,
expressed as a software process model [WMGH10]. Having a typical sequence of
steps means reducing coordination work required by regularizing points of
collaboration. The process guides the collaborative activity of developers
working on artifacts.

Programming teams usually refer to their process as a workflow. The term
“workflow” has been used in business analysis to describe business process
models. The Business Analysis Body Of Knowledge (babok) defines workflow as “a
visual representation of the flow of work in a business area. Workflow models
are used to document how work processes are carried out, and to find
opportunities for process improvement” (cited in [WMGH10]). A programming
workflow represents the steps that programmers perform when sharing, managing,
reviewing, and integrating changes to project artifacts. For reference, GitHub
provides the overview of a recommended branch-based workflow
777https://guides.github.com/introduction/flow/index.html.

Version control is an essential part of any collaborative project’s tool kit,
allowing the sharing and management of different versions of the software that
form as a result of the multiple contributions from different members. It is
not in the scope of this proposal to exhaustively explain the different types
of version control systems 888A good online reference is Eric Sink’s “A
History of Version Control”, but for our purposes we follow the distinction
between centralized version control systems (cvcs) and their decentralized
counterpart (dvcs).

Decentralized version control systems have gradually been adopted by more and
more projects, both oss and css [AS09]. The major difference is that in dvcs
programmers can have a clone of the original repository and commit there,
making them independent of the work of others. Git, the most notable example
of dvcs and the most widely used, provides lightweight branching and merging
as a way to separate the work and the concerns of programmers, supporting
distributed collaborative work. Under dvcs, programmers commit to their branch
or repository clone and send a pull request to notify the project of their
changes which can subsequently be reviewed and merged. This is in contrast to
the cvcs model where programmers commit to the same central repository. Also,
time-efficient branching and merging allows small, frequent commits and lower
chances that the programmers’ workspaces have diverged a lot, risking
conflicts.

State-of-the-practice collaborative development platforms have shaped around
dvcs in the form of software forges. They provide code hosting, a user
interface for repository management to share code among the team, and
additional tools for issue tracking, project management, and communication.
GitHub is the most used such environment and is adopted by both oss and css
projects, either in its web-based form or as a system a company can install
and run on its servers. Another notable example is Atlassian’s BitBucket
999https://bitbucket.org/. However, Atlassian’s
101010https://www.atlassian.com/ offering to organizations leans more towards
tool suites that combine separate tools (rather than features) per
functionality, providing more comprehensive and sophisticated solutions to
cover the entire software development lifecycle, not just the programming
activities.

The dvcs-based software forges build on the concept of pull requests. A pull-
based development model has, therefore, emerged [GPD14]. In terms of oss
projects the pull-based model replaces the earlier practice of submitting
patches through e-mail. For css projects, however, the adoption of the pull
based model creates a potentially different workflow. In place of all team
members using their write-access to the code repositories, the css programming
team can opt for individual copies of the repository, creating individual
branches, committing in them, and submitting a pull request to notify the rest
of the team. Subsequently the team can perform code review and, upon
agreement, merge the branch. In case of conflicts teams need to have a
mechanism to resolve them. We call this sequence of steps a decentralized
workflow, and software forges offer different implementations of those, giving
the programming team flexibility to build their own.

As mentioned before, a workflow regulates collaboration and potentially
reduces the need for coordination. dvcs, the decentralized workflow, and
software forges, are tools and practices that were developed with oss projects
in mind to support them in working more effectively with their special
characteristics of distribution, asynchronicity, and relaxed coordination
requirements [Ebert09]. However, they are now entering css development and
organizations, although we don’t yet know how they fit with the development
practices already in place and how they affect collaboration. Part of the
research in the proposed thesis will aim to address this gap.

####  3.4.2 External participation for collaboration

Open collaboration has been a growing trend in the past few years, fuelled by
successful implementations of it principles, such as Wikipedia and oss
development. Levine & Prietula [LP13] define open collaboration as “any system
of innovation or production that relies on goal-oriented yet loosely
coordinated participants, who interact to create a product (or service) of
economic value, which they make available to contributors and non-contributors
alike”. Although in first read the definition seems to exclude commercial
organizations due to limited access to their products, the model of open
collaboration can work in companies that release parts of their software
products as oss. Inner Source can be considered an adaptation of open
collaboration that stays inside the organizational boundaries of a company.

In an open collaboration model the obvious benefit is building upon others’
work in a direct way, that gives companies the advantage of having multiple
sources of innovation. However, an open collaboration and innovation approach
is not without its challenges. West & Gallagher [WG06] highlighted possible
managerial challenges in integrating internal and external innovations and
added coordination costs, as well as complications revolving around accepting
external contributions.

The major feature of an open collaboration model of design or production is
external participation. The externality of participation is, of course, a
question of boundaries. For a commercial organization that follows a structure
where different departments or teams handle parts of development without
working together, an Inner Source initiative can be seen as promoting external
participation. For other organizational structures external participation can
translate into a different model. In any case it is natural to assume that
such a transition brings managerial and operational changes to a team’s
collaboration. It is necessary to record and study how receiving external
contributions works in action and how it affects the collaboration and
interaction of development teams. Part of the research in the proposed thesis
will aim to address this gap.

The recognized end goal is to build a theoretical understanding of
collaborative software development: what factors influence collaborative work
and how these factors together determine the overall effectiveness of a given
collaborative effort. This includes identifying each factor and how they
influence each other. Lessons and practices from oss projects can shed light
to the collaboration puzzle, by posing the open question of how can css
development benefit from oss practices.

##  4 Research questions and conceptual framework

Given the review of the background work and the current trends discussed in
the previous section we refine our research questions by breaking them down to
sub-questions. We then summarize the direction of the proposed research in a
conceptual framework, before going into methodological details in Section
[sec:method].

The proposed research will be guided by the following research questions:

RQ1: How does a decentralized workflow fulfill the collaboration and
interaction needs of commercial software teams?

This question will be investigated through studying the use of a software
forge (GitHub) for collaborative software development.

RQ1.1: What GitHub features support decentralized work?

RQ1.2: Can software forges play an effective role in supporting coordination,
communication, awareness, task division, and conflict resolution in commercial
software teams?

RQ1.3: What are the drawbacks from using software forges for the collaboration
of commercial software teams?

RQ1.4: What are the perceived affordances for developers working in commercial
teams using software forges?

RQ2: How does accepting external contributions impact the collaboration and
interactions of commercial software teams?

This question will be investigated through studying the adoption of Inner
Source initiatives.

RQ2.1: What different approaches exist to receive external contributions
inside/outside a software company?

RQ2.2: What managerial and cultural challenges do software teams encounter in
their activities relating to receiving external contributions?

RQ2.3: What changes do commercial software teams experience on their
interaction and collaboration when receiving external contributions?

The conceptual framework that will guide the proposed thesis is graphically
represented in Figure 4 and briefly described below. More details on how each
part of the conceptual framework will be studied are given in Section 5. The
proposed thesis will focus on two influences from oss development: (A) Using a
decentralized workflow enabling de-coupled work and (B) Accepting external
contributions. The use of a decentralized workflow in practice will be studied
through GitHub and commercial teams that are using it. The focus is on the
practices and features that support the five collaboration elements. Once we
have collected and analyzed the input regarding the five collaboration
elements, we will review them in light of the Sharma et. al framework [SSR02],
discussed earlier.

Accepting external contributions will be investigated through Inner Source
initiatives in commercial software organizations. The focus will be on tools,
process and practices that support and shape the structure, process and
culture of the team to study how they comply with oss-like communities. We
will also focus on recording the specific practices that support the five
collaboration elements.

We will use the factors and practices identified through the studies to build
a framework of team collaboration and interaction when following “the open
source way”.

Figure 3: Conceptual framework showing study items.

##  5 Methodology

###  5.1 Study of decentralized workflow

{This part of the work has been partly completed}

The study focused on how GitHub, as a proxy for a decentralized workflow,
supports collaboration. We studied a number of different projects on GitHub.
Collaboration was broken down to five collaboration elements: communication,
coordination, awareness, task division, and conflict resolution, following
Malone’s framework. We conducted a survey to see how GitHub users address
these needs through GitHub, and also recruit participants for interviews to
focus on specific projects. The reason for using self-reports was to get more
in-depth information and the perceived collaboration needs. Teams select their
techniques and practices based on their specific needs and perceptions and
qualitative methods are better suited to capture that.

The characteristics of our interviewees are shown in Table 1, showing that the
majority of interviews came from commercial projects, both distributed and
collocated.

|  Interviewees |  35
---|---|---
|  Primarily for job-related projects |  24 (68%)
GitHub |  Primarily for oss contribution |  6 (17%)
use |  Primarily for solo projects |  5 (15%)
|  Professional developers |  25 (71%)
Job |  Managers (also developers) |  4 (11%)
situation |  Students |  3 (9%)
|  Developers in internship |  3 (9%)
|  Job-related projects |  24
Distri- |  Distributed |  16 (67%)
bution |  Collocated |  8 (33%)
|  Median team size |  7
Table 1: Interviewees’ and projects’ descriptive characteristics.

  1. 1.

Findings:

     * •

We have conducted a mixed-methods study of GitHub repositories and users. A
survey has indicated different types of uses for the repositories, some
expected and some unexpected. These have been validated by quantitative
analysis of a representative sample of GitHub repositories. This answers
RQ1.1.

     * •

GitHub effectively covers all collaboration elements through its features and
the decentralized workflow (Table 2). In most cases GitHub was not used as the
single development tool but in concert with tools that integrate with it. This
answers RQ1.2.

     * •

The only reported drawback from using GitHub is the exclusion of non-technical
stakeholders because they find the tool too complicated to use. Developers
bridge the gap by using tools that non-technical stakeholders are familiar
with. When possible they select tools that already integrate with GitHub. This
answers RQ1.3.

     * •

We found evidence of a code-centric perspective: The programmers’ perception
of collaboration is one of decoupled rather than joint work. The code-centric
perspective runs on three principles: Focus, Independence, and Exposure.
GitHub and its decentralized workflow is in line with the code-centric
collaboration perspective, supporting parallel segmentation. This answers
RQ1.4.

     * •

The decentralized workflow is in fact used in a centralized way. There is
always a main repository that acts like the common point of reference for
everyone. The focus is on operational efficiency through maximizing parallel
work and minimizing the need for interaction. This is an additional finding.

     * •

Some practices that are followed resemble oss practices. We analyze them
through the Sharma et al. framework [SSR02] and find that they cover elements
on all 3 dimensions: Structure, Process, and Culture. The practices that we
have recorded support the operation of hybrid-oss communities or teams inside
software companies. This is an additional finding.

Decentralized workflow practice |  GitHub enabler |  Collaboration element effect
---|---|---
Independent development |  Forking repositories and branching |  Minimized coordination needs
Concise process of committing changes |  git flow (also mentioned as GitHub workflow) |  Minimized coordination needs
Visible progress and status |  Timeline, notifications, integration with chat client |  Awareness
Code reviews |  Pull requests |  Highlighted coordination needs
Code-centric communication |  Comments on commits, issues, and pull requests |  Targeted communication
Self-organization |  Public issue tracking |  Task Division
Automatic testing and deployment |  Service hooks in corresponding tools |  Conflict Resolution
Table 2: Decentralized workflow practices, enabled through GitHub, supporting
the collaboration elements

  2. 2.

Validation: We will validate our findings through a survey targeted towards
commercial software teams that use GitHub and its decentralized workflow. The
survey will contain statements of practices and processes that we recorded
through our study and respondents will be asked to indicate their level of
agreement based on their team’s experience.

  3. 3.

Threats to validity:

In terms of internal validity, the participants to our survey and interviews
were active but self-selected, and we can only rely on what they report given
their time and motivation to participate in our study.

In terms of construct validity, we made the use of GitHub the proxy for the
use of a decentralized workflow. We believe there is a valid and
representative connection between the two. GitHub builds on the functionality
of Git which provides decentralized workflows. Also, the pull-based model (an
implementation of a decentralized workflow) is widely used within the GitHub
environment [GPD14]. Another threat to construct validity is the interviewees’
understanding of the concepts of collaboration and coordination, especially
given their code-centric perspective. We mitigated this risk by having
interviewees provide examples and by providing them with explanations when
needed, to ensure that we have achieved a mutual understanding of the
constructs.

Finally, in terms of external validity, we achieved saturation in the results
of the group of participants we studied but the themes, principles, and
practices we found may not generalize to everyone. The majority of the
participants we interviewed are professional, experienced developers which
gives us a degree of confidence that the insights we uncovered are valuable
and relevant.

###  5.2 Study of external participation

In this study we will investigate cases of Inner Source initiatives and their
effect on the development team’s structure, process and culture. During our
investigation we will also take special notice of how the five collaboration
elements are fulfilled through the team’s or organization’s approach to Inner
Source.

Inner Source initiatives are not standardized and organizations don’t always
enact them in the same way. Adoption of Inner Source takes into account the
nature of the software product, the tools in use, and the organization
[SABLF14], and therefore organizations tweak it differently to make it work
with their specific characteristics. As a result the value is more in
investigating cases of Inner Source adoption in-depth to hopefully uncover
factors that play a role in its adoption and how teams collaborate under such
initiatives, rather than reach generalized conclusions.

For the Inner Source studies it is important to understand processes on the
organization level before we can investigate the collaboration on the team
level. The first point to be investigated is the goals of the organization in
following Inner Source, and the managerial and policy implementations in place
to do so. Governance, as one example, is a factor that is particularly
interesting if oss principles and self-organization are going to be used in
practice in an organizational context where the chain of responsibility and
decision power is more rigid. The aim is to combine sources of input in the
form of interviews with key members of management, and reviewing documents or
other artifacts that contain related information. The combination of
interviews and empirical data will potentially create a comprehensive trail of
decision making regarding the Inner Source initiative. The result will be the
organization’s expected benefits and perceived challenges regarding Inner
Source.

On the team level, input will come in the form of interviews. If the Inner
Source project was initially a project that was handled by a specific team and
there was a subsequent decision that the project would accept external
contributions then the target for interviews is the original team. If the
Inner Source project was initiated as such then the target for interviews
would be the team that has gathered around the project and we would
investigate how their collaboration functions (through the five collaboration
elements), and also collect data about the process, structure and culture of
the teams. Interviewees would also be asked to make comparisons between their
experience in the Inner Source team versus the non-Inner Source one along the
already mentioned factors.

  1. 1.

Expected Findings: Since the frameworks regarding Inner Source are still in
progress, and the case studies are still few, we are aiming towards
identifying additional factors that play a role in adopting and implementing
Inner Source. Additionally, we will be focusing on the collaboration of the
development team and the processes and interactions that are shaped by the
Inner Source initiative. Additionally, we will record real-world practices
that can be used as reference and guidance to teams and organizations that are
looking into implementing Inner Source. Depending on the organizations’
characteristics, additional insight may be gained from combining the
conclusions drawn from each.

  2. 2.

Validation: The validation of such qualitative studies has been noted before
[SABLF14]. We will not be looking to generalize but provide insightful
conclusions from in-depth investigation, and aim towards trustworthiness of
the study and the extended frameworks that come out of it by building
credibility, transferability, dependability, and confirmability [LG85] into
our design and evaluating its results. To gain more insight and confidence in
the findings, a second Inner Source study will be conducted.

  3. 3.

Threats to validity: We cannot claim generalizability of the study or its
findings. However, it is generally understood that the value in such case
studies is in depth rather than width.

##  6 Expected contribution

By investigating the practices and processes of real-world teams, the goal is
to identify factors that need to be considered when teams use a decentralized
workflow (usually through adopting a software forge), and when they accept
external contributions. We are interested in the factors that have to do with
the team and its interactions, but those are seldom contained inside the team
and are the product of an interplay between processes and tools on the team
and the organization level. Therefore, we take a more holistic view before
focusing on the specific factors that affect collaboration.

The process through which these initiatives or new practices are implemented
cannot be standardized since organizations all have different characteristics.
However, attempting to build frameworks can hopefully gradually give
researchers a more clear view on some principles that are more universal than
others and those that are more local. In that sense we will contribute towards
building and extending frameworks or even theories of collaboration and work
organization, under conditions that are inspired by oss development and open
collaboration forms. The expected contribution will take two forms:

  * •

Factors that are at play when teams use a decentralized workflow and when they
accept external contributions (we will refer to the combination of those two
conditions, “the open source way”). This will lead to the creation of a new
framework of team collaboration under the open source way, or the extension of
existing frameworks. Theorization based on our findings about use of
technologies and tools and appropriating their use in practice under specific
conditions can result in informing existing theories of collaboration in
software engineering. Organizational theories of structuration and
technologies-in-practice will help in this direction.

  * •

Recorded practices that real-world teams follow under the open source way,
challenges and benefits. This can form part of a growing list of lessons and
conclusions that can inform practice and help guide organizations that are
following similar initiatives or plan to adopt them.

##  7 Timeline

Below is a tentative timeline for the completion of the activities leading to
the final dissertation. The top half of the timeline represents completed
activities while the bottom half shows planned activities and time estimations
for their completion.

Figure 4: Timeline of completed (top) and planned (bottom) activities towards
the dissertation.