How Social and Communication Channels Shape and Challenge ...etc.leif.me/papers/Storey2016.pdf ·...

0098-5589 (c) 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TSE.2016.2584053, IEEETransactions on Software Engineering

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 41, NO. 7, SEPTEMBER 2015 1

How Social and Communication ChannelsShape and Challenge a Participatory Culture

in Software DevelopmentMargaret-Anne Storey, Leif Singer, Fernando Figueira Filho, Alexey Zagalsky, and Daniel M. German

Abstract—Software developers use many different communication tools and channels in their work. The diversity of these tools hasdramatically increased over the past decade, giving rise to a wide range of socially enabled communication channels and social mediathat developers use to support their activities. The availability of such social tools is leading to a participatory culture of softwaredevelopment, where developers want to engage with, learn from, and co-create software with other developers. However, the interplayof these social channels, as well as the opportunities and challenges they may create when used together within this participatorydevelopment culture, are not yet well understood. In this paper, we report on a large-scale survey conducted with 1,449 GitHub users.We describe which channels these developers find essential to their work and gain an understanding of the challenges they face usingthem. Our findings lay the empirical foundation for providing recommendations to developers and tool designers on how to use andimprove tools for developers.

Index Terms—Participatory Culture, Communication, Social Media, CSCW, Software Engineering.

F

1 INTRODUCTION

Software development has transitioned from a predomi-nantly solo activity of developing standalone programs, to ahighly distributed and collaborative approach that dependson or contributes to large and complex software ecosystems.Many developers now contribute to multiple projects, andas a result, project boundaries blur, not just in terms of theirarchitecture and how they are used, but also in terms ofhow they are authored. Developers want to engage with,learn from and co-create with other developers, forming aparticipatory culture [1] within many development-relatedcommunities of practice [2]. Many developers not onlycare about the code they need to write, but also aboutthe skills they acquire [3], the contributions they make,and the connections they establish with other developers.These activities, in turn, lead to more collaborative softwaredevelopment opportunities.

To support developers’ collaboration and communica-tion needs, modern development tools are often integratedwith or supplemented by communication channels andsocial media [4] (e.g., email, chat, or microblogging ser-vices). The rich and varied ecosystems of tools that de-velopers use help them discover important technologicaltrends, co-create with other developers, and learn new skills.Furthermore, these social tools foster creativity, promoteengagement, and encourage participation in developmentprojects. We see that the collaborative and participatorynature of software development continues to evolve, shape,and be shaped by communication channels that are used

• M-A. Storey, L. Singer, A. Zagalsky, and D.M. German are with theUniversity of Victoria, Victoria, BC, Canada.E-mail: {mstorey, lsinger, alexeyza, dmg}@uvic.ca

• F. Figueira Filho is with Universidade Federal do Rio Grande do Norte,Natal, Brazil.E-mail: [email protected]

by development-related communities of practice [5]. We usethe general term communication channel to refer to traditionalcommunication channels (e.g., telephone, in-person interac-tions) as well as social features that may be standalone orintegrated with other development tools (e.g., email, chat,and forums).

Within a community of practice, software is the combina-tion of externalized knowledge (e.g., code, documentation,history of activities) as well as the tacit knowledge thatresides in community members’ heads (e.g., experience ofwhen to use an API, or design constraints that are notwritten down). Communication channels and developmenttools support developers in forming and sharing both ex-ternalized and tacit knowledge in a highly collaborativemanner. However, not much is known about the impact thisparticipatory culture may have on software developmentpractices, velocity, and software quality.

In this paper, we investigate how the choice of com-munication channels shapes developers’ activities within aparticipatory culture of development, as well as explore thechallenges they may face. We report on a large-scale sur-vey with developers that contribute to either collaborativeor community-based development projects on the popularGitHub code hosting site. We wanted to uncover the demo-graphics of the developers participating in this community,and we aimed to understand which channels and toolsthese developers use to support learning, discovery, andcollaboration with others. Our survey revealed which com-munication channels these developers find essential to theirwork, and we gained an understanding of the challengesthey face. These insights led to several recommendations onhow to use and improve communication and social tools fordevelopers.




Our work investigates the following research questions:

RQ1 Who is the social programmer that participates in thesecommunities?

RQ2 Which communication channels do these developersuse to support development activities?

RQ3 Which communication channels are the most impor-tant to developers and why?

RQ4 What challenges do developers face using an ecosys-tem of communication channels to support theiractivities?

Previously [6] we briefly described the first iteration ofour survey (conducted in 2013) with some initial high-levelresults. This paper describes our survey in detail and pro-vides in-depth analyses of the results from two deploymentsof the survey, conducted at the end of 2013 and again at theend of 2014. This work has formed an initial descriptivetheory of the role communication channels play in support-ing software development activities within a participatorydevelopment ecosystem.

2 BACKGROUND

We begin with an overview of communities of practice andcommunication channels in software development, illustrat-ing the interplay between them. The ongoing formation andevolution of these channels brings numerous challenges,both to the individual software developer and to the com-munity as a whole.

2.1 Communities of Practice in Software DevelopmentCommunities of practice are groups of people connected bythe similarity of their activities [2]. Such communities can befound in many domains, including software development.Community members do not have to be spatially or so-cially connected, but they solve similar problems and learnfrom each another through processes like apprenticeshipor mentoring. Members advance through a process calledlegitimate peripheral participation: novices watch passivelyand then take on peripheral activities that are not vital, butnevertheless provide value to the community.

For example, in open source development, a potentialcontributor might start by only reading discussions andreporting defects. Over time, these contributors learn com-munity conventions and move closer to the core group ofexperts. Developers may start fixing bugs and progress tothe point where they can add their own features. They maygain commit rights, and at some point become involved instrategic project decisions. This phenomenon has also beenobserved by Crowston et al. [7] and Pham et al. [8].

We see that developers consider themselves to be partof a broader community of like-minded individuals thatlearn from and teach one another. In open source projects,professionals and hobbyists contribute to the same projectsand interact in the same communities—some companiesthat rely on open source projects may have their own staffcontribute to them.

Since software development lends itself to distributedor remote work—collaborators need not be in the sameoffice, city, or time zone [9]—developer communities ariseon a global scale and are mostly connected through tools

that incorporate social aspects, helping developers connectwith and learn from each other. In a sense, socially enabledtools and media can be considered catalysts to the formationof global, virtual software development communities ofpractice.

2.2 The Importance of Media in Software Development

When we think of software development tools, our firstthoughts often concern development environments, debug-gers, source code forges, version control systems, and bugtrackers. But as Naur [10] emphasizes, software is muchmore than the code being developed. Software also involvesthe immediate knowledge in developers’ minds and thedocumentation accompanying the code. Thus, other toolsthat play an essential role in collaborative developmentinclude project management tools and communication chan-nels such as mailing lists [11], micro-blogging services [12]and chat [13], [14]. These tools support knowledge manage-ment activities that are central to the success and longevityof a large software project.

Naur further argues that programmer knowledge tran-scends documentation in three primary ways: it helps relatethe software back to the real world, it helps explain whyeach part of the software is what it is, and lastly, it allows formodification of the software while maintaining a mappingto real-world aspects. Furthermore, Naur notes that cer-tain software development activities (e.g., maintenance andcontinued support) are dependent on knowledge which isdistributed among the members of the development group.Thus, in this paper, we look at software development asan activity that creates two types of knowledge—tacit andexternalized—and we explore how developers use media tocommunicate and share this information.

Likewise, Scacchi’s open source studies refer to theimportance of “software informalisms”, which he says are“information resources and artifacts that participants useto describe, proscribe, or prescribe what’s happening in aOSSD project.” [15] Such informal narratives are capturedand related in a myriad of online Web-based communica-tion artifacts and documentation resources (such as emails,blogs, wikis, IRC). Together, these resources comprise adistributed knowledge base that continually evolves as par-ticipants gain knowledge about the systems they developand use.

Media—i.e., development tools and communicationchannels—play a critical role in how externalized and tacitknowledge is formed, shared, manipulated, and captured.These tools and channels become an extension of the pro-grammer [16], helping them extend and distribute theircognition to develop, refine, and share knowledge. We pre-viously [6] reported on an in-depth survey of how tools andchannels play an essential role in communicating knowl-edge that is:

• captured in developers’ heads;• externalized in tools;• stored in community knowledge resources; or• captured in developer networks.

Figure 1 provides a historical perspective of how dif-ferent tools support the communication of these types of




knowledge during software development. This simplifiedview—developed in our previous research—reveals howdevelopment tools and media have evolved from a non-digital form to a digital form, eventually becoming infusedwith social features. We see a recent trend towards the use ofsocial media channels and the embedding of social featuresin development tools. Other researchers have also noted anincrease in the number of tools (in particular, social tools)adopted by software developers [17], [18], [19].

In Fig. 1, we distinguish tools that support the com-munication and capture of knowledge in developers’ headsfrom knowledge that is externalized through developmentartifacts and tools, and from knowledge that is embeddedwithin community resources or social networks. The inclu-sion of more social aspects over time has led to an increase ofknowledge that is stored in community resources and socialnetworks. We have previously [6] provided an overview ofthe research that has been conducted on social channelsduring software development. Giuffrida and Dittrich [20]elaborate on this topic further by providing a systematicmapping study on research that has studied the use of socialsoftware in global software development.

2.3 The Rise of the Social ProgrammerDevelopers are becoming increasingly social and rely ontheir social networks to keep up to date, to find projectsto contribute to, and to find others to collaborate with. Theyrely on tools to help them participate effectively in thesesocial networks, although sometimes they also face hurdlesin participating and in staying up to date. The rise of thesocial programmer [6], [21] and the ways that communitiesof developers make use of increasingly social tools haveled to the emergence of a highly participatory culture ofsoftware development. Jenkins [1] defines a participatoryculture as one that:

• lowers barriers to participation;• provides strong support for sharing;• facilitates informal mentorship;• has its members believe their contributions matter;

and• values social connections and what others think.

While this framework helps us better understand howdevelopers work in this new context, we do not havea good understanding of how particular combinations ofchannels and tools shape and are shaped by communitiesof developers. We also do not adequately understand whichchannels support which knowledge activities, and whetherindividual developers face challenges using such a complexecosystem of tools while contributing to potentially manydifferent communities and projects. Achieving a deeper un-derstanding of how media shape this participatory culturewill guide tool designers and provide recommendations forhow individual developers, teams, and communities shoulduse the media effectively. In the next section, we describe alarge-scale survey we designed to investigate this topic.

3 METHODOLOGY: THE DEVELOPER SURVEY

Our overarching research goal is to understand how com-munication channels and social media support a broad set of

knowledge activities within a participatory culture of soft-ware development. To help realize this goal, we designedand conducted a survey to learn how developers use toolsto support their knowledge activities, which media channelsare important to them, and what challenges they may face.

We deployed the same survey during two different timeperiods: at the end of 2013 and at the end of 2014. For bothdeployments, we downloaded account data for the mostrecently active GitHub users with public email addresses.To indicate activity, we used the 25 event types defined bythe GitHub API v31. Most of these events concern develop-ment tasks such as committing code, creating repositories,and creating issues, but there are also more general eventsrelated to following users or watching repositories. To finddevelopers for our survey, we used the GitHub Archive2 toquery public events happening on GitHub. Therefore, ourfindings are limited to this population. We sorted eventsby their timestamp and excluded users who did not havepublic email addresses at the time we sent our invitationemails. For the second iteration, we also ignored userswe had emailed in the first iteration. We focused on thispopulation of developers because GitHub is currently themost widely used social coding platform by developerswho contribute to one or more collaborative developmentprojects in an open manner3.

We emailed our survey to 7,000 active GitHub usersduring November and December of 2013, and to 2,000 activeGitHub users in December of 2014. 1,492/332 developersresponded to the two instances of the survey in 2013 and2014, respectively (21% and 16% response rates). The onlystatistical difference between the two deployments was anincrease in the number of women (from 3.5% to 6.3%,ρ = 0.042). We combined the responses from both surveysand ignored incomplete ones, resulting in 1,449 surveyresponses.

Our survey followed several iterations of design andwas based on an in-depth review of the existing literatureon software engineering as well as related literature onknowledge work. In the survey4, we first inquired aboutthe developers’ demographics. We then inquired aboutcommunication channel use for a set of 11 developmentactivities. The activities we inquired about were informedby our review of the literature that examines tool and com-munication channel use by software developers [6]. Theseactivities, which go beyond finer grained development andproject management activities, were as follows:

• STAY UP TO DATE about technologies, practices,and tools for software development

• FIND ANSWERS to technical questions• LEARN and improve skills• DISCOVER interesting developers• CONNECT with interesting developers• GET and GIVE FEEDBACK• PUBLISH development activities• WATCH other developers’ activities

1. https://developer.github.com/v3/activity/events/types/2. https://www.githubarchive.org3. https://octoverse.github.com/4. http://thechiselgroup.org/2013/11/19/

how-do-you-develop-software/

https://developer.github.com/v3/activity/events/types/

https://www.githubarchive.org

https://octoverse.github.com/

http://thechiselgroup.org/2013/11/19/how-do-you-develop-software/





Fig. 1. Development communication channels over time and how they support the transfer of different kinds of developer knowledge.

• DISPLAY my SKILLS/ACCOMPLISHMENTS• ASSESS other developers• COORDINATE with other developers when partici-

pating on projects

The survey questions relating to activities all followedthe same form: we used a matrix of options that the surveyrespondents could select from to indicate that an item wasused for the corresponding activity (see Fig. 2 for an ex-ample question about activity and channel use). The socialchannels specified in the matrix were determined from ourown knowledge as developers, as well as through feedbackfrom fellow developers. The channels were refined usingthe research literature and through piloted surveys. Weincluded an “Other” option to elicit channels we did notconsider. We asked developers to rank the most importanttools and channels they used to support developmentactivities and explain why those tools were important.

We further aimed to understand the challenges devel-opers may face using social channels, probing about pri-vacy, interruptions, and feeling overwhelmed, as these wereconcerns that came up in earlier studies conducted withadopters and non-adopters of social media (e.g. Singer etal. [12]).

The survey instrument is one of the contributions of thispaper and its source code can be found in a repository onGitHub5. This will allow others to replicate our survey and

5. https://github.com/thechiselgroup/devsurvey

build upon our work. We describe our analysis approachas we present each research question, and refer to thelimitations of the study in the discussion section of thepaper.

In the following sections, we present the results from ouranalysis of the survey responses to answer our four researchquestions.

4 SOCIAL PROGRAMMER DEMOGRAPHICS

For our first research question (RQ1), we wished to charac-terize the modern social programmer that openly participateson projects hosted on the GitHub social coding platform.

Canada and USA

Latin America

Africa

Europe

Asia

Oceania

0 100 200 300 400 500 600

Fig. 3. Demographics of the programmers that answered the survey(those recently active on GitHub with public activity).

https://github.com/thechiselgroup/devsurvey




Fig. 2. The channel matrix designed for the survey.

0

200

400

600

800

1000

1200

1400

fem

ale

mal

eot

her

Gender

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

0

100

200

300

400

500

600

700

800

<=

22

23−

32

33−

45

46−

60

>=

61

Age

0%

10%

20%

30%

40%

50%

0

50

100

150

200

250

300

350

solo

2−3

4−5

6−7

8−10

11−

50

51−

100

>10

0

Team Size

0%

10%

20%

0

100

200

300

400

500

<=

1

2−5

5−10

10−

20

>20

Prog. Exp.

0%

10%

20%

30%

0

50

100

150

200

250

300

350

400

0 1 2 3 4 5

>5

Num. Projects

0%

10%

20%

0

200

400

600

800

1000

1200

NoP

rof

Pro

f

NoO

SS

OS

S

NoP

et

Pet

Tenure

0%

10%

20%

30%

40%

50%

60%

70%

80%

Fig. 4. Demographics of the programmers that answered the survey (those recently active on GitHub with public activity).

javascriptpython

javaphp

c++

c

ruby

c#

htm

l

css

bashobjective−c

sql

perl

coffeescript

go

scalashell

node.js

hask

ell

rcloj

ure

html5

lua

matlab

jquery

sass

objective c

erlang

ruby on rails

xmlcss3

actionscript

golang

mysql

.net

assembly

groovy

fortran

less

lisp

scheme

vb.net

latex

f#

ocaml

swiftclojurescript

haml

pascal

powershell

puppet

zsh

as3

common lisp

elisp

emacs lisp

julia

pl

rust

visual basicawk

cfml

coldfusion

dart

jade

mathematica

qt

racket

styl

us

t−sql

verilog

vhdl

Fig. 5. Word cloud of the programming languages used by the program-mers that answered the survey.

We asked our survey respondents to provide demo-graphic information such as gender, age, their geographicallocation, programming experience, the programming lan-guages they use, the number of projects they participate in,whether they program professionally, and the size of projectteams they worked with. The answers to these preliminarysurvey questions are summarized in Figures 3, 4, and 5.

TABLE 1Most mentioned languages

Language Frequency PercentageJavaScript 912 61.9Python 657 44.6Java 611 41.5PHP 411 27.9C++ 383 26.0C 351 23.8Ruby 341 23.1C# 213 14.5HTML 194 13.1

Geographic location: Our survey was successful in at-tracting respondents from all over the world: 43.4% fromNorth America, 24.2% from Asia, 21.1% from Europe, 7.1%from South or Central America, and 4.1% from Africa orOceania. It is notable that there were more respondents fromAsia than Europe; 143 respondents originated in China,making it the second most frequent country of origin, afterthe United States with 547 respondents. Canada was thirdwith 90 respondents.

Gender: The overwhelming majority of our respondentsidentified as male—only 3.9% said they were female. How-ever, it is possible that other respondents were female butdid not wish to be identified as such6.

Age: 56.7% of respondents said they were between 23and 32 years of age (so-called millennials), representing thelargest age group in our survey and showing a strong biastowards relatively young developers. In fact, 77.9% said

6. http://meta.stackoverflow.com/a/281304

http://meta.stackoverflow.com/a/281304




they were 32 or younger; 3.7% were older than 45, and only0.4% were older than 60.

Team size: Team size was slightly more evenly dis-tributed. Only 1.8% of respondents said they had workedin teams of more than 50 members. We found a slight biastowards smaller teams, with 61.5% having worked on teamsof 5 members or less, and 16.2% saying they had onlyworked on projects where they were the sole member.

Programming experience: In terms of experience, re-sponses varied. Only 5.1% had 1 year of experience or less.33.5% had worked as a developer for 2 to 5 years, 29.1% for5 to 10 years, 24.4% for 10 to 20 years, and only 7.6% formore than 20 years.

Number of projects: The majority of our survey respon-dents (88.9%) had worked on 5 projects or less, and mosthad experience working on 2 (21.5%), 3 (27.7%), or 4 (15.7%)projects.

Professionalism: Most respondents were professionalsoftware developers (78%). 54% considered themselvesopen source developers, and 51% worked on pet projects.

Programming languages: Figure 5 shows a word cloudof programming languages used by the participants, whileTable 1 shows the top 10 most popular languages. Thethree most popular languages included JavaScript (61.9%),Python (44.6%), and Java (41.5%). This may indicate that atleast 60% of our respondents develop for the Web.

Table 2 shows the results of testing independence be-tween the different factors surveyed. Our respondents pro-vided three types of answers: categorical (including dichoto-mous), such as whether the respondent was a professionalprogrammer; ordinal, such as how concerned they wereabout their privacy; and numeric, such as the number ofdifferent channels used. This forced us to use differenttests of independence for each pair of factors: for pairsof categorical factors, we used chi-square; for pairs of onecategorical and one ordinal or numeric, we used Kruskall-Wallis; and for pairs of two ordinal or numeric, we usedSpearman correlations. We highlight some of the differencesbelow.

Regarding age, we found a moderate positive correlationbetween age and programming experience (ρ = 0.56, p �0.001); also, older programmers are more likely to work onprofessional projects (H=160.63, df=1, p � 0.001) and lesslikely to work on open source projects (H=34.87, df=1, p �0.001). However, there is almost no correlation between ageand team size (ρ = 0.09, p = 0.001).

Regarding gender, we found that female programmersare less likely to have professional experience (H=21.55,df=4, p � 0.001) and pet projects (H=10.6, df=2, φ = 0.08,p = 0.05), and they work on fewer projects (H=14.79, df=6,p = 0.022) than their male counterparts.

People working in larger teams are more likely to be pro-fessional programmers (H=65.05, df=1, p� 0.001). There isvery little (if any) positive correlation with both the numberof projects they are members of (ρ = 0.18, p � 0.001) andthe different channels they use (ρ = 0.18, p� 0.001).

When a person is a professional programmer, it is lesslikely they will work on open source projects (H=102.6,df=1, φ = 0.27). However, a person that has a pet projectis more likely to also be involved in open source projects(H=177.4, df=1, φ = 0.35).

Regarding the different number of channels a personuses, there is very little (if any) positive correlation withteam size (ρ = 0.18, p � 0.001) and the number of projectsthey belong to (ρ = 0.18, p� 0.001).

5 COMMUNICATION CHANNELS DEVELOPERSUSE TO SUPPORT DEVELOPMENT ACTIVITIES

To answer our second question (RQ2), we asked the re-spondents to indicate which channels they use for a varietyof software development activities. As mentioned, theseactivities were determined through a literature review andfrom our previous research.

On average, developers indicated they use 11.7 channelsacross all activities, with a median of 12 and quartiles of[9, 14] (see Fig. 6 for the distribution of channels used bysurvey respondents).

0

20

40

60

80

100

120

140

160

180

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Channels Used

0%

2%

4%

6%

8%

10%

12%

Fig. 6. Histogram of number of channels selected by each developer.

Table 4 shows an overview of the channels developerssaid they use to support different activities. In this table,we grouped the channels according to analog, digital, andsocial+digital (see our discussion for Fig. 1). This table high-lights that there appears to be more reliance on communica-tion channels that support social features. For each activity,we generated a radar graph showing the distribution ofresponses about channel use (see companion website7).

For each activity, we also asked developers to indicateother channels they might use that we did not list in thesurvey (see Table 3). There are a number of channels thatwe did not specify or did not specify clearly enough in oursurvey, including events and meetups, software documenta-tion, and personal blogs and Websites. The respondents alsomentioned research papers, headhunters, recruiting Web-sites, and conference calls as important ways of supportingtheir activities.

Although Table 4 paints a high-level picture of whichchannels tend to support a set of development activities,a limitation with this data is that we only know that de-velopers use the selected channels for supporting a givenactivity—we don’t know how important these channels are.Consequently, we asked the respondents to tell us whichthree channels are the most important across all activitiesand why. We report these results in the next section.

7. http://thechiselgroup.github.io/channel-study/

http://thechiselgroup.github.io/channel-study/




TABLE 2Test of independence between the different demographic factors in the survey, the number of channels they use, and their responses regardingprivacy, feeling overwhelmed, and being distracted. Each value is preceded by the name of the test used followed by its results: kw representsKruskall-Wallis (degrees of freedom, χ2 value), cs represents Chi-square (degrees of freedom, χ2 value and Cramer’s φ), and sp represents

Spearman correlation (r value). Values in bold represent where there the two factors appear not to be independent with p < 0.05, specifically ***corresponds to p < 0.001, ** for p < 0.01, * for p < 0.05

Age Gender TeamSize Prog. Exp. Tenure Prof Tenure Pet TenureOSS

NumberProjects

Gender kw: 2,2.58Team size sp: 0.09*** kw: 7,3.61Prog. Exp. sp: 0.56*** kw:

4,21.55***sp: 0.11***

Tenure Prof. kw:1,160.63***

cs:2,3.8,0.05

kw:1,65.05***

kw:1,128.13***

Tenure Pet kw: 1,0.49 cs:2,10.6,0.08**

kw: 1,4.24* kw:1,55.39***

cs: 1,0.4,0.02

Tenure OSS kw:1,34.87***

cs:2,4.7,0.06

kw:1,8.35**

kw: 1,4.55* cs:1,102.6,0.27***

cs:1,177.4,0.35***

NumberProjects

sp: 0.05* kw:6,14.79*

sp: 0.18*** sp: 0.19*** kw:6,84.80***

kw:6,58.26***

kw:6,18.39**

ChannelsUsed

sp: 0.03 kw:19,27.17

sp: 0.18*** sp: 0.05 kw:19,63.91***

kw:19,32.58*

kw:19,26.27

sp:0.18***

Face

-to-

face

Book

s

Web

Sear

ch

Con

tent

Rec

omm

ende

rs

Ric

hC

onte

nt

Priv

ate

Dis

cuss

ions

Dis

cuss

ion

Gro

ups

Publ

icC

hat

Priv

ate

Cha

t

Feed

san

dBl

ogs

New

sA

ggre

gato

rs

Soci

alBo

okm

arki

ng

Q&

ASi

tes

Prof

.Net

wor

king

Site

s

Dev

elop

erPr

ofile

Site

s

Soci

alN

etw

ork

Site

s

Mic

robl

ogs

Cod

eH

osti

ngSi

tes

Proj

ectC

oord

inat

ion

Tool

s

analog digital digital and socially enabled

Stay Up to DateFind Answers

LearnDiscover Others

Connect With OthersGet and Give Feedback

Publish ActivitiesWatch Activities

Display Skills/AccomplishmentsAssess Others

Coordinate With Others

Legend: 0-10% 10-20% 20-30% 30-40% 40-50% 50-60% 60-70% 70-80% 80-90% 90-100%(percentage of survey respondents mentioning a channel being used for an activity)

TABLE 4Channels used by our respondents and the activities they support.

6 SOFTWARE DEVELOPERS’ MOST IMPORTANTCOMMUNICATION CHANNELS

Beyond mapping the channels developers use as part oftheir software development activities, it is also important tounderstand why these channels are important to them. Forthis purpose, as well as to answer RQ3, we asked developersto indicate the top three channels that are important to themand why each one is important. Figure 7 shows the numberof responses given per channel.

In the following, we provide more insights into whycertain channels were perceived as important to the de-veloper respondents. We also provide quotes from specificparticipants, indicated by P#.

Code hosting sites allow for better team collaboration,

group awareness, and project coordination. The ability toshare one’s code on the Web has lowered the barriers toentry by making source code easily accessible: “All levels ofusers and employees know how to use it: The hard-core developersuse the command-line-based tools, and the ‘end users’ just use theWeb interface, without feeling overwhelmed.” [P64]

Face-to-face interactions were also deemed very im-portant by our survey respondents. Developers can receiverapid feedback from their co-workers, which facilitates talk-ing though complex problems, discussing ideas, and makingdesign decisions: “Nothing beats being able to sit one-on-oneand talk through a topic, plan out a design or just converse whilecoding. This is also my favorite way to learn from an instructorbecause of the ability to ask as many questions as possible and




Activity Channels

Keeping up to date events and meetups (18), soft-ware documentation (3), researchpapers (3), formal education (2),MOOCs (2)

Finding answers software documentation (11), re-search papers (3)

Learning educational sites and MOOCs (20),events and meetups (19), soft-ware documentation (13), tutori-als (7), research papers (6), codereviews (4)

Discovering developers headhunters (16), recruitingsites (12)

Connecting with developers events and meetups (35), program-ming competitions (2), formal edu-cation (2)

Getting and giving feedback events and meetups (9), code re-views (4), issue trackers (4)

Publishing activities personal blogs and Websites (32),conferences (7)

Watching activities events and meetups (4), personalblogs and Websites (3)

Displaying skills personal blogs and Websites (64),resumes (6), events and meetups (5)

Assessing others personal blogs and Websites (2),source code(2)

Coordinating with others conference calls (10), cloud-basedservices (e.g., Dropbox, GoogleDrive) (8)

TABLE 3Other channels reported in the survey. The values indicate the number

of times the channel was mentioned by respondents for thecorresponding activity.

have an open conversation.” [P319] Some respondents reportedusing videoconferencing as a way to mimic co-located inter-actions with other developers.

Q&A sites offer a quick way to debug issues while pro-viding access to high-quality answers: “Almost any questionthat I have, I can get an answer through these sites.” [P635]Other respondents mentioned additional uses of Q&A sites,including learning from code examples and getting feed-back from experts.

Search is an essential tool for finding information: “Goodfor finding the initial direction; also [...] to learn something new.”[P484] It also provides quick access to software documen-tation and supports problem solving. Many respondentsreported using search engines as the entry point for findinganswers on Q&A sites.

Microblogs provide just-in-time awareness of the latestadvancements and updates in the development community:“Allows me to get up-to-date information on topics I’m interestedin—conferences, new releases, new articles/books, etc.” [P95]They were also considered important for getting feedbackfrom other developers and for nurturing relationships with

social_bookmarking

recommenders

professional_networking

dev_profile_sites

other

rich_content

sns

books

project_coord

aggregators

discussion_groups

public_chat

private_discussions

feedsblogs

private_chat

microblogs

search

qa_sites

f2f

code_hosting

0 100 200 300 400 500 600 700 800 900 1000 1100

Most important

Second Most Important

Third Most Important

Most important

Second Most Important

Third Most Important

0% 10% 20% 30% 40% 50% 60% 70%

Fig. 7. Number of responses per channel indicating the importance ofeach channel.

like-minded people.Private chats (e.g., IM, Skype chat, Google chat) are

essential tools for supporting team communication andcollaboration through a single channel: “It provides a singlechannel to digest and discuss everything that is going on withthe team.” [P415] Many survey respondents felt that privatechats are the closest replacement for face-to-face interactionswhen quick feedback is needed and team members aregeographically distributed.

Feeds and blogs provide the most up-to-date infor-mation on development practices and technologies: “Byfollowing several feeds, one can find out how veterans use atool/technology/language... And it’s easier to know the trends”.[P1016] Blogs encapsulate a more personalized view on agiven topic and are an important channel for documentingtechniques while sharing specific coding tips and tweaksthat can be used by other developers.

Private discussions (e.g., email) support communicationacross virtually every platform and among different stake-holders (e.g., customers and users). They are a convenientchannel for disseminating information to large groups (e.g.,mailing lists) while keeping conversations private and per-sistent for later retrieval: “This is how you get to communicateprivately and can have proof for a later stage.” [P1041]

Public chats (e.g., IRC) have the advantage of enablingcommunication among developers and users of a particularsoftware project. By being public, anyone with an interestcan join in and have a conversation with project maintainers:“Gives me direct access to the people who write my tools, andgives me direct access to people who are using things I’ve writ-ten” [P191]. Public chats also enable discussions and fasterfeedback among team members, even if they are distributedaround the world: “As a team spreads across the world, we useIRC to preview most of our concepts before any code is written.”[P731]

Discussion groups (e.g., mailing lists, Google groups,forums) support mass communication and coordinationamong people scattered across large and geographicallydistributed groups: “We are a physics collaboration of 3000




people, spread all over the world. Internal discussion groupsare essential for coordination on all subjects, including softwaredevelopment.” [P365] Respondents also reported the useful-ness of discussion groups for gathering customer feedback:“Because it’s where I find my customers’ opinions and ideas.”[P130]

Aggregators (e.g., Reddit) are socially curated channelsfocused on new trends. They provide access to crowd-sourced content that has been filtered and collated byothers, allowing for developers to stay up to date withthe latest technologies without active participation. As onerespondent put it, aggregators are “[...] roughly the heartbeatof the current software dev industry. If a technology is worthtalking about, it will be talked about.” [P1419] The value ofaggregators is closely associated with the value of their sup-porting communities, and survey respondents appreciatedthat aggregators allow them to interact with like-mindeddevelopers and get their feedback: “[Hacker News] is the mostwelcoming community I have ever seen. [...] You can interact withanyone (if they have public email) and the content quality is topnotch.” [P1126]

Project coordination tools increase group awareness ofcurrent tasks and issues, and provide a means for trackingprogress and discussing next steps: “Permits tracking in-progress work as well as receiving feedback. Essential for dis-tributed teams.” [P105] These tools improve the transparencyof a project’s activities, increasing progress visibility notonly among team members, but also among clients: “Helpsus coordinate large tasks bases, especially when reporting back toclients.” [P486]

Books were indicated by some of our survey respon-dents as a cohesive and progressive way for learning about atopic: “[They make] learning much easier than the hunt and peckmethod of digging through sites on the net.” [P1189] Anothersubtle but crucial advantage of books was mentioned byone respondent: “[They are] distraction free and generally betterthought through and considered.” [P1319] Developers can gainin-depth and focused understanding about specific topics,while avoiding being distracted by the noise of concurrentinformation.

Social network sites increase awareness of the com-munity and help developers disseminate information fromother channels in various ways: “Because most often they func-tion as the entry point to more relevant information published onblogs, newspapers, books, etc.” [P224] In addition, developerscan reach potential users more easily, which is essential forgathering feedback: “We have a group for Android DevelopmentTesters in Google Plus where we can post things we want testedand receive almost immediate feedback.” [P1240]

Rich content such as screencasts and podcasts providelearning materials and communicate the state of the art intechnologies, tools, and practices for software development.Developers are able to consume content while commutingor performing other tasks. One survey respondent high-lighted yet another interesting aspect of learning using richcontent: “I’m a visual and audible learner. Seeing and hearingothers makes learning better.” [P1354]

Count

Overwhelmed

Privacy

Distracted

1000 500 0 500

Strongly Agree

Strongly disagree

Fig. 8. Frequency of responses to Likert questions probing on developerchallenges with DISTRACTION, PRIVACY, FEELING OVERWHELMED.

7 THE CHALLENGES DEVELOPERS FACE USINGCOMMUNICATION CHANNELS

Our fourth research question (RQ4) inquires about thechallenges developers face using communication channels.Our previous work [3], [6], [12] revealed that developersface challenges related to distractions, privacy, and feelingoverwhelmed by communication chatter when using socialmedia channels. Consequently, our survey specifically askedwhether the respondents experienced these concerns. Weshow the results from these Likert-style questions in Fig. 8.We note that privacy is not a big concern for everyone,whereas being interrupted and feeling overwhelmed bycommunication traffic are issues for more developers.

To investigate if there were any relationships betweenthese three factors (Privacy, Distraction, Overwhelmed) andtheir demographics, we performed a more in-depth analysisof the responses. Table 5 shows the test of independencebetween whether a person feels their privacy is affected ornot and if they feel overwhelmed or distracted by theiruse of communication channels, as well as the differentdemographic factors of our respondents. We anticipated thatage might influence responses in terms of privacy concerns,but no factor shows a statistically significant relationshipwith the Privacy factor. A similar result was found regardingthe Distraction factor, where the only statistically significantresult was that there is very little correlation (if any) withprogramming experience: ρ = 0.07, p = 0.008. The Over-whelmed factor was found to have a very low correlation (ifany) to: age (ρ = 0.07, p = 0.014), programming experience(ρ = −0.07, p = 0.012), and number of projects (ρ = −0.07,p = 0.004). It was also found that people who work on opensource projects feel slightly more overwhelmed than peoplewho do not (H=19.89, df=6, p = 0.005). We believe theseresults show a lack of evidence that the developers whoworry about privacy, feel overwhelmed, or feel distractedbelong to any specific type of group (as reported in thesurvey). Nonetheless, it is notable that there is a modest pos-itive correlation between the three factors (with p� 0.001):people who worry about their privacy feel overwhelmed(ρ = 0.21) and distracted (ρ = 0.19), and those who feeldistracted also feel overwhelmed (ρ = 0.24).

We also asked the respondents to share any additionalchallenges they face through an open-ended text question.432 respondents (356 to the 2013 survey, 76 to the 2014deployment) either elaborated on the challenges mentionedabove or informed us about other challenges they experi-ence. A wide variety of challenges were reported and wecoded, sorted, grouped, and then categorized them usingan open coding and iterative clustering technique. Postman,who extensively studied the use of media in communi-ties of practice, refers to a media ecology and suggestswe undertake the study of “the entire environments, their




TABLE 5Test of independence between the different demographic factors and whether respondents feel worried about privacy, feel overwhelmed, or aredistracted by their use of communication channels. Each value is preceded by the name of the test used followed by its results: kw representsKruskall-Wallis (degrees of freedom, χ2 value), cs represents Chi-square (degrees of freedom, χ2 value and Cramer’s φ), and sp represents

Spearman correlation (r value). Values in bold represent when the two factors appear not to be independent with p < 0.05, specifically ***corresponds to p < 0.001, ** for p < 0.01, * for p < 0.05

Age Gender TeamSize

Prog.Exp.

Tenure Prof Tenure Pet TenureOSS

NumberProjects

ChannelsUsed

Privacy Over-whelmed

Privacy sp: -0.04 kw:6,8.26

sp: 0.01 sp: -0.04 kw: 6,10.69 kw: 6,11.39 kw:6,8.97

sp: -0.04 sp: 0.03

Over-whelmed

sp:0.07**

kw:6,9.36

sp: -0.01 sp: -0.07* kw: 6,11.71 kw: 6,12.57 kw:6,19.89**

sp:-0.07**

sp:0.08**

sp:0.21***

Distracted sp: 0.04 kw:6,4.94

sp: 0.01 sp: 0.07** kw: 6,5.49 kw: 6,8.35 kw:6,7.54

sp: 0.01 sp: 0.05 sp:0.19***

sp:0.24***

structure, content and impact on people.” [22] We note thatthe categories we found mirror the main areas of studysuggested by Postman. The main categories of challengesthat emerged from our analysis are as follows:

• Developer issues• Collaboration and coordination hurdles• Barriers to community building and participation• Social and human communication challenges• Communication channel affordances, literacy, and

friction• Content and knowledge management concerns

We report these challenges below. A few participantsalso noted strategies they use to address the challengesthey face, which we describe in the Discussion sectionof the paper. In the following, we provide representativeparticipant quotes (shown in italics and linked to eachparticipant using P#), and we use bolded text to indicatecodes we assigned to quotes. Note that some responsesfrom the survey were coded with multiple codes. The mainchallenges that emerged from our analysis are shown inboxes. When appropriate, we discuss and link the reportedfindings to relevant literature. We summarize the categoriesof challenges found, the main findings that emerged, andthe codes with their respective counts in Fig. 9. Furtherdetails (linking categories to findings to codes, and countsof codes and additional quotes) can be found on the com-panion website8.

However, we stress that counting the coded challengescould be misleading—only some participants took the timeto share this information with us after an already longsurvey, and thus, they may have selected which challengesto share with us in an ad-hoc manner. Nevertheless, for con-cerns that were mentioned numerous times, the counts mayhelp us identify challenges that may be more prevalent andwarrant further investigation, and so we share these countsto perhaps provoke future research. Two researchers inde-pendently coded these challenges, iterating several times toreach agreement on the codes derived and how they wereapplied. When agreement was not reached, the researchersfollowed a conservative approach and omitted applyingthose codes to the survey responses.

7.1 Developer IssuesSome of the challenges reported concerned the developersthemselves or specific development activities.

8. http://thechiselgroup.github.io/channel-study/

Distractions and interruptions from communication chan-nels negatively impact developer productivity:

Survey respondents spoke of how the social and com-munication media at their finger tips can be a distractionor can negatively impact their productivity through inter-ruptions [23] (see also Fig. 8). As P165 mentioned, “SocialNetworking Websites like Facebook are the worst ingredients forgood concentration in general.” P541 described how easy it isto be drawn into unnecessary work: “If I spend a lot of timetalking with other developers about the best way to do things orreading articles on social sites, I end up constantly refactoring oroptimizing code instead of making progress toward the functionalrequirements of the project.”

P320 discussed how notifications and emails can be botha cause for distraction and a waste of time: “Notifications:when used in a moderate way, it is fine, but when overused, it isa distraction for developers. Emails: too many emails from ProjectCoordination Tools can easily waste 15-30 minutes only to gothrough them all in the morning, specially when I’m involved inmore than a few projects simultaneously.”

Keeping up with new technologies and project activitiescan be challenging, but social tools help:

Keeping up with new technologies was a concern forour respondents: “Staying cutting edge is a never-ending task.”[P625] Several respondents discussed not knowing whichchannels to watch: “Knowing where the activity is. Some days,Hacker News might be the best place to follow. Another day,Twitter might be. Another day, GitHub might be where I shouldlook. Another day, it might be a site or network I’m not evenaware of.” [P1564] The challenge of keeping up also emergedin our previous work that investigated how developers useTwitter [12]. P706 discussed how they found it easier to keepup with technology in open source because of their use ofsocial tools: “Staying up to date with new company internaltechnology because it is not on Twitter [or] Hacker News. I guessthere is a theme here: if it’s open source, help is plenty and readilyavailable, not so much for internal tools.”

Tools for keeping up with activities on projects wereseen as inadequate and in need of improvement: “In abig project (WebKit, Mozilla, etc.) it can be hard to filter foronly ongoing work that is relevant. Most legacy UIs are terrible(Bugzilla) and new ones (GitHub) lack features for large-scaledevelopment.” [P109] While Baysal et al. [24] also noted thischallenge, other respondents described how some moderntools address it: “We use HipChat (kind of a private IRC)with HUBOT that watches our GitHub activity. It’s wonderful





Developer Issues: Distractions and interruptions from communication channels negatively impact developer productivity

Distractions 38* Interruptions 11*

Keeping up with new technologies and project activities can be challenging, but social tools help

Keeping up with new technologies 9 Keeping up with activities on projects 8 Collaboration and coordination hurdles:

Sharing and explaining code lack adequate tool support Sharing code 4 Explaining code 7

Getting feedback on development activities is challenging Getting feedback 8 Proprietary projects 3

Collaborative coding activities need improved tool support Collaborative coding 3 Barriers to community building and participation:

Geographic, cultural and economic factors pose participation barriers Time zones 14 Access to the Internet 3 Language barriers 20

Despite social channels, finding developers to participate is difficult Finding right people 9

Convincing others (to participate) 3 Social and human communication challenges:

Miscommunications on text-based channels are common Miscommunications 24

For many developers, face-to-face communication is best (Not) Face-to-face 24

People are challenging, no matter which channels are used Poor attitude 13 Intimidated 12 Communication channel affordances, literacy and friction:

Developers need to consider channel affordances Private vs. public 10* Synchronous vs. asynchronous 10

Ephemeral vs. archival 3 Anonymous vs. identified 1 Text-based vs. verbal 7 Face to face (vs. not) see above No one tool fits all 14 Communication with users 11

Developers need to be literate with communication channels Literacy 22 Lack of documentation 9 Learning tools 10

Communication channel friction can obstruct participation Tool friction 23 Search is inadequate 16 Poor mobile support 5 Vendor lock-in concern 6 Notification issues 5 Poor channel integration 8 Channel overload 36 Poor adoption by others 21 Content and knowledge management:

Use of many channels leads to information fragmentation Information fragmentation 15

The quantity of communicated information is overwhelming Quantity 11* (Finding the signal in the) noise 19*

The quality of communicated information is hard to evaluate Quality 29 Obsolete information 8 Spam 4 Niche technologies 4 History of information missing 4 Strategies:

Developers used a variety of strategies to address their challenges Deciding when to use particular channels 3 Deciding which channels to use and how 6 Encouraging others to use tools 1 Unplugging 3

Fig. 9. This shows the categories, codes, and counts of each code occurrence in the additional challenges shared by participants. Note that someparticipants shared multiple challenges in the Other field. The categories of challenges we derived are shown in bold text; the findings thatemerged from the analysis are shown in italics, followed by the codes and counts in normal font. Codes marked with an * indicate challenges theparticipants already indicated in the closed question (see Fig. 8). Strategies shared are described in the Discussion section of the paper.

because our entire team can be instantly notified about who’sdoing what on which repository, and we’re all in communicationvia mobile and desktop with the same feed.” [P892] Keeping upwith projects also relates to how developers collaborate onprojects, which is discussed next.

7.2 Collaboration and Coordination Hurdles

Respondents spoke of the challenges they face managingand coordinating their projects. As noted earlier, the vastmajority of respondents said they had contributed to two ormore projects, including professional projects (see Fig. 4).

Many of the challenges shared with us did not relate tothe use of communication channels but rather poor projectdocumentation, a lack of requirements management, poorstandards adherence, and managing software licenses.Respondents also mentioned challenges specific to projectcoordination, such as work distribution, workflow friction,scheduling hurdles, and the lack of a roadmap: “A lot ofdevelopers I know spend more time planning and debugging theworkflow, rather than developing.” [P49] Organizational con-straints were also discussed, such as how outside communi-cation was discouraged in one organization, and how therewas a reliance on proprietary services in certain projects.However, some respondents did talk about the lack of tool

support for collaborative coding and coordination activities,which is discussed next.

There is a lack of adequate tool support for sharing andexplaining code:

Developers had difficulties sharing code and explainingcode using their existing tools. P1416 discussed this issueand how he dealt with it: “Many communication tools (email,IM, etc.) are not especially good for talking about code. Generallyin any given conversation I’ll end up using several tools, e.g.,IRC + a paste-bin (GitHub Gists), to effectively communicateideas.” P445 was enthusiastic about collaboration tool sup-port except when needing to explain code: “The biggestchallenge in soft-dev for me is four-fold: communicating the idea(Hangout), managing the idea (Trello), logging the implementedidea (GitHub), and explaining the implemented idea with the team(Nitrous.io). The first three solutions are pretty solid. It’s the factyou can’t always sit right next to someone and show them the codeand explain how everything works that is the most challengingpart. Cloud9, Koding, Nitrous, etc. are all trying to solve the lastproblem.”

Getting feedback on development activities is challenging:

Developers also faced challenges in getting feed-




back about their own activities, especially for proprietaryprojects that can’t use social tools: “Getting quick feedback forinternal technology because you cannot ask on Stack Overflow.”[P706] Sometimes the challenge of getting feedback can bedue to the size of the project (community) rather than thechannel: “It’s difficult to share small new projects that aren’tvery far along and get feedback.” [P751]

Collaborative coding activities need improved tool sup-port:

Our survey concerned communication tools, but P1154spoke of how coding tools do not adequately support col-laborative coding activities: “Live collaborative coding tools.For example, we can currently edit a document collaboratively inGoogle Docs. If we can have an IDE/tool like that for coding too,that would be useful.” Some Browser-based IDEs now providethis support and are starting to see increased adoption [25],such as Nitrous.io and Cloud9. Such tools may also addressthe challenges of explaining code and getting real-timefeedback (as mentioned above).

7.3 Barriers to Community Building and Participation

Over half of the survey respondents said they contributedto open source projects, many of which were “pet” projects(see Fig. 4)—we can anticipate that most developers rely onone or more open source projects or community-authoredresources such as Stack Overflow. Thus, it is not surprisingthat many respondents found it challenging to participatein or find others to join community-based projects.

Geographic, cultural, and economic factors can pose bar-riers to participation through social channels:

The survey exposed challenges relating to geographic,economic, and demographic factors. Respondents men-tioned that different time zones interfered with their work,as well as other issues such as poor access to the Internetdue to economic or political reasons. Language barrierswere also a common concern as many of the respondentswere from non-English speaking countries (see Fig. 3): “Themajority of development-related communication I do is primar-ily written—IRC, chat, email, forums, microblogging, blogging,etc. Considering that the developers I work with come from avariety of nationalities and cultural backgrounds, the intent ofcommunication is often hard to impart or judge, which can lead tomisunderstanding.” [P31] These challenges may be reducedin the future as modern tools such as Slack incorporate thenotion of time zones, while Skype now offers multilingualsupport.

Despite using social channels, finding developers to par-ticipate can be difficult:

A few developers also discussed challenges in findingdevelopers to collaborate with or convincing others toparticipate. As P1285 mentioned, “I used to think that pub-lishing application code with an open source license would attractcollaborators with an interest in using/improving that application,but now I feel like most users of code hosting sites are moreinterested in collaborating on tools they can incorporate intotheir own projects, and almost no one is interested in working

on application code. I guess the challenge here is convincingdevelopers that your application is interesting even if your codeis not.” But P556 discussed how social tools make it easierto reach people that could participate: “When I was firstcontributing to an open source video game project on GoogleCode, it was hard to get in touch with one or more of the coredevelopers of that project because there was no right place/tool todo that. The same project moved to GitHub recently, and now Ifeel more comfortable because I can simply make a pull request tothe project.”

7.4 Social and Human Communication Challenges

Many respondents specifically mentioned struggling withcommunication or people issues. We discuss a selection ofthe most prominent themes below.

Miscommunication on text-based channels is common:

Respondents frequently mentioned experiencing issuesdue to miscommunications on text-based channels, whichP385 discussed: “With the increasing amount of communicationbeing done with social tools and IMs, chat, the amount of misun-derstanding and bad, incomplete briefs grows [at] the same rate.”P126 described how much more effort text-based communi-cation requires: “When you write, context and expression is lost.There have been so many times when something I wrote did notcome across to the other person as intended. This causes problemsall the time. You must be careful and spend time on the words andphrases you use when communicating in text. If you can’t pickup the phone, then use IM, and as a last resort, email.” P1331agreed with this and mentioned how slang can introduceeven more ambiguity.

Text-based miscommunication also relates to the lan-guage barriers mentioned above. As P31 lamented, “Thelone shooter that misunderstands you and begins shooting at you.[I] have been called an arrogant dickhead once and have also beeninformed that I was dictating somebody something when I actuallytried to SUGGEST something. So, language is also a challengebecause I am a Dane.”

For many developers, face-to-face communication is best:

Many respondents shared the opinion that “nothing re-places face-to-face communication” when trying to avoid mis-communications. As P136 explained, “Without face-to-facecommunication, misunderstandings happen more often.” Otherdevelopers discussed how face-to-face communication isneeded for activities such as code review and for explainingthe big picture underlying a design, as P319 mentioned,“When working apart people aren’t always at their computer orresponding to messages, and in the case of code review they haveto summarize their thoughts into a few paragraphs. In person it’smuch easier to convey a thought, have a discussion and come toa resolution.” P1241 added, “Clarity of intent (it can be hard toget a point across through text-based media)—it can be difficultto see the big picture, or even the pieces, without talking face toface.”

P176 mentioned that to address such issues, some com-panies move their staff on-site: “Often collaboration tools arestill not as good as face-to-face communication. Many softwarecompanies have moved to having all of their staff on-site full-time,because the communication is just better. Especially when two or




more developers are collaborating on the same code in real time(pair programming) or ‘whiteboarding’ on a design... being therein person is just different.”

Others shared with us that there are tools that can sup-port face-to-face-like interactions: “Often times it is difficultto get ideas across in written communication. This is where toolssuch as Google Hangout and Skype can be beneficial, but they arenot always an option.” [P206] On the other hand, not everyonewants face-to-face interactions. P737 mentioned their mainchallenge was “other developers that insist on using face-to-facecommunication exclusively.”

People are challenging, no matter what channels are used:

Poor attitude and a lack of willingness to collaborate areissues no matter what tools are used: “[Tools] still don’t solvethe difficult people problems.” [P264] As P532 explained, “Toolsfacilitate good processes and interactions between individuals whoare willing to collaborate and cooperate. They don’t make peoplewilling to cooperate in the first place; in these situations theyactually get in the way of identifying the root problems anddealing with them. People can hide behind GitHub better thanthey can in person.”

P421 mentioned that the benefits of using these toolscan be achieved by ignoring some of these people issues:“Personal restraint [with] people who are mean (or, dicks). Oth-erwise, amazing area for learning and sharing.” P468 explainedthat although tools bring opportunities for transparency andcollaboration, getting others to buy in can be tricky: “Thebiggest challenge is getting other devs to be open both with theirwork and to new ideas.”

The social transparency [26], [27] of the channels intro-duced other issues [28]. Developers told us how they felt in-timidated, either because they were worried that their owncontributions or skills were not good enough, or that othersmay not react well to their contributions. As P302 told us,“The biggest thing I fear in my work is that I’ll say something thatis not 100% technically accurate or could be misinterpreted. Otherdevelopers are utterly merciless, and I have thin skin. Whenever Ipost something on HN or Stack Overflow, I find that I feel anxiousthat someone will tear me a new one over some oversight inmy analysis.” P643 discussed how feeling intimidated couldlead to repressed interactions within the community: “Lotsof people communicate less than they otherwise would for fear oflooking stupid to peers who are assessing them in a colossal globalmeritocracy. Very unhealthy. I suspect it contributes to the highprevalence of anxiety and depression in IT (in combination withoften sedentary lifestyles).”

7.5 Communication Channel Affordances, Literacy,and FrictionHere we consider challenges that relate closely to the prop-erties of the communication channels used, such as theaffordances of the channels, literacy needs, the impact ofthe ways developers use (or misuse) the channels, and thefriction the channels may pose to development activities.

Developers need to consider channel affordances:

Different channels provide different kinds of affor-dances, as Daft and Lengel’s Media Richness Theory de-scribes [29]. But developers don’t always consciously think

about these affordances when choosing which channels touse.

For example, communicating using face-to-face and ver-bal channels is normally ephemeral as opposed to archivaland may be more suited to a smaller group size, but on theother hand, “voice communication is much quicker, but it is noteasily transcribed and it is difficult to use with more than 3 (if not2) people.” [P1224]

Developers also frequently referred to a tension be-tween synchronous versus asynchronous communicationchannels. P927 elaborated why asynchronous is sometimespreferred: “I try to use asynchronous communication so [I] candecide the time when to communicate and [I won’t] be disturbedwhen [I’m] programming or learning! On the other side I havethe [ability] to talk face to face to the other developers in theteam, which is the most effective way to learn, coordinate etc.But it is not asynchronous.” However, as mentioned, theuse of synchronous channels can lead to interruptions andmisunderstandings.

Developers experienced tension when having to choosebetween private versus public communication channels:“Many developers host their code projects on blogs, etc. Sometimesthe only way to communicate with the author is to post acomment, since they do not disclose their email address. Also,on forums, of say, a particular library—e.g., openCV forums. Theforum posters seem so professional and experienced, I tend to avoidposting on the forum to avoid embarrassment (lol).” [P1036]Some respondents reacted negatively to the transparentnature of social networking tools over traditional commu-nication media such as email: “Very few new developers arelearning how to use old tools such as email and are tending towardusing social networks and other tools. It can be frustrating whenyou want to collaborate and they insist on proprietary softwareor technology, or insist on using privacy-invasive tools such asSkype or Facebook.” [P897] Some also experienced confusionusing channels where communication can be private orpublic: “I am sometimes frustrated that there are too manyplaces to do the same thing, especially when I answer a questionprivately and want to instead make that answer public.” [P137] Incontrast, P1399 shunned the use of private channels: “Peoplecomplaining about their privacy tend to slow down development.”

Another affordance touched on by P40 relates to the fan-fare of the communication channels used: “Sending urgent ormajor information is hard, too: how to highlight information sentto others when they are free to ignore it?”

Developers shared with us that no single tool fitsall developers’ needs nor suits all stakeholders. Differentstakeholders have very different needs, therefore differentchannel affordances will not suit everyone. “Different groupsin the entire team often prefer to use different tools. For example,the coders will use GitHub, but a project manager and thetesting team will use Basecamp. This makes overall coordinationextremely difficult.” [P160]

Finding the right channel to support communicationwith users is also a challenge. P1528 described how difficultit can be to keep track of communication from users (andother developers): “Users/developers tend to report bugs or askfor new features with email and forum posts which can be trickyto keep track of.” To address this, some projects promoteuser reporting of issues on GitHub, but P394 explained thepotential disadvantage with this approach: “ ...it’s also a lot of




work to separate real, confirmed issues that we create from the tonsof not-always-useful stuff that our users create. I think the nail inthe coffin was when a user closed one of our bugs.” Moreover,P700 did not appreciate any communication with users anddisliked the way social channels create opportunities forusers to contact them: “Users of my open source software oftenfeel entitled to free technical support. Because it’s so easy to reachme, they can be a nuisance sometimes.”

Developers need to be literate with communication chan-nels:

Inadequate communication channel literacy and a poorunderstanding of channel affordances can lead to challengesfor developers wishing to collaborate, exchange informa-tion, or network with others across their communities, asP1005 said, “The main challenge for me is the interaction withpeople who are not literate enough to use the tools I considerstandard.” P1600 discussed how Git (the underlying versioncontrol system for GitHub) can be challenging to use: “Also,Git is a critical collaboration tool, but it is not well understoodby many of the programmers I interact with.” Developersrecognize that learning these tools is a challenge. P1385mentioned how using GitHub itself, or even IRC, can seemdifficult: “I still don’t understand how to do simple things in IRCand often don’t bother because of the perceived effort involved—much easier to post on Stack Overflow. With tools like GitHub,there are similar issues (like how to submit patches) althoughdocumentation is improving.”

Respondents discussed the challenges around having tolearn new tools. P404 felt that “the biggest challenge [about us-ing] social tools during development is when a new one is adoptedinto the mix; the learning curve associated with a new tool eatstime unless the program is intuitive and pointed.” P1315 empha-sized how these channels require different communicationskills than when communicating face to face: “Basically avery different way to communicate compared to face-to-face comm.It simply has to be learned.” Furthermore, each new channelmay necessitate the acquisition of a different vocabulary.P526 felt that “if you don’t know the right [vocabulary] ortechnology you want to use, the [dialog] usually ends quickly.”P981 mentioned that some of these tools are difficult to learnbecause of a lack of documentation.

Literacy, however, is not just about knowing how to usea particular channel, but when to use it and when not to useit (depending on the need, e.g., to avoid interruptions).

Communication channel friction can obstruct participatorydevelopment activities:

Technical issues introduced friction for developers, suchas the lack of mobile support, tools crashing, poor supportfor search, annoying notifications, and hardware limita-tions. P919 claimed that they “never have enough screens.”This concern about monitors is not surprising given thenumber of channels and tools developers use. Other tools,despite being highly popular among developers, suffer us-ability issues: “Hacker News dominates and is terrible.” [P1279]

Vendor lock-in was also an issue that was mentioned bydevelopers, and not surprisingly since many of the socialtools developers use are proprietary. P334 discussed thisissue at length: “Much of the value that we [are] responsible

for is now kept safe and maintained by a third party. It’s risky...If eclipse.org, stackoverflow.com or github goes away, our team(s)would suffer severe damages. I would love to be able to have myown weekly backup of the social interactions that take place in aformat that is machine processable such that in the event of totalfailure I could migrate our history of communication to anotherhost or another technology.” Projects also face issues when aproprietary tool’s privacy policies change: “Having to shiftplatforms when a company’s policies change (e.g. Facebook’s alter-ing of privacy settings, SourceForge’s adware, Google’s pushingPlus).” [P681]

Developers also mentioned usability issues getting intheir way—that collaboration tools and social tools canintroduce friction even though they bring benefits: “Codereview and collaboration tools (Asana, Trello) I mostly find to benecessary to some extent but generally very annoying. Seems likeone more thing. Maybe they’re necessary evils, but they seem toget in the way a lot.” [P1255]

Many challenges arise due to poor channel integration,such as having to deal with identity management. P1430explained the many issues that a lack of integration brings:“Poor integration between them and an overabundance of options.There are a lot of tools out there, but it’s hard to put themtogether into a cohesive workflow. Especially when participatingin a lot of open source projects, every one has a different setof overlapping but different tools. Another problem is identitymanagement. With personal projects and work projects, I’d like tobe able to manage them separately but without the inconvenienceof maintaining separate accounts.” Poor integration makes itdifficult to monitor multiple channels, but developers alsocomplained about channel overload—there are simply toomany channels to choose from and follow.

Poor or scattered tool adoption can also introduce fric-tion, especially when there are many tools available: “Thereare too many variants of things like project management tools,time-trackers, issue-trackers ... it’s hard to get a team to agreeon tools, and none of these stand out as an obvious leader.”[P694] And getting agreement on communication tools isalso difficult. P422 experienced difficulties “convincing otherdevelopers on a project to all use the same communication toolfor [the] project.” The problems are exacerbated by globallydistributed teams: “I live internationally and work on globallydisparate project teams, so G11N [globalization] is a big deal.Finding a consistently-used platform for such a large and variedgroup of developers is also a challenge, as some only do IRC, othersonly Google Groups, others only email.” [P380]

7.6 Content and Knowledge Management

Developers face challenges with information fragmenta-tion and with the “quality/quantity of information available.”[P1242]

Use of many channels leads to information fragmentation:

Information fragmentation results from the use of toomany channels: “One of the things that bugs me most is multiplemediums. At any given moment I can get a chat, an email,a text, or whatever—wish it was more streamlined.” [P1401]Fragmentation also occurs because of the inconsistent orpoor adoption of particular channels (as discussed above).P1250 suggested that one could address this by encouraging




others to use the same tools or by using tools that integratecommunicated information from multiple channels: “Mak-ing sure everyone else you’re working with also uses the tools. Oneof the biggest issues with fragmentation of the communication op-tions is that there are so many different ways to communicate thatit’s harder to find it all in one place. Important communicationsget lost; Key people don’t see them; They can’t be retrieved bya single search tool. Companies such as Slack are attempting tosolve this problem, but it has a long way to go.”

The quantity of communicated information is overwhelm-ing:

Developers found it challenging to find the “signal inthe noise”—the “explosion” of available channels has ledto an increase in volume and duplicate information postedin multiple locations. This is particularly difficult for devel-opers working on multiple projects where different tools areused: “The variety of tools, and the need to switch context and toolset between various sub-projects, adds a lot of cognitive overhead.”[P815] There is also a fear of missing important information:“Too many channels means that needed or interesting informationdisappears, and going through all of the channels you mentionedis impossible in limited time.” [P917] Although poor channelintegration that leads to information fragmentation is oneissue, the channels themselves further promote an increasein the quantity of communication posts to attend to: “I feelthat social tools largely present information in fragments, withmany different approaches and styles and agendas, which makesit time consuming to stitch together a working knowledge oftechnologies I’m learning.” [P1189]

The diversity and velocity of information makes it hardfor developers to keep up with new technologies. AsP1409 put it, “There definitely is information overload. Peoplethink I’m joking when I mention the ‘javascript framework ofthe day’.” Developers try to stay up to date on these newtechnologies [12], but the availability of so many differ-ent news sites and aggregators means they are inundatedwith content. P1144 told us how they affect productivity:“The News overload via Aggregators (Hackernews, Reddit, Digg,Slashdot, ...) affects productivity. I don’t use too much socialnetworking (Facebook or Twitter) as they are a huge time-sink andsheer noise as far as technical development work is concerned.”

The quality of communicated information is hard to eval-uate:

In addition to receiving too much information, manydevelopers described their concerns with the quality of theinformation: “Judging the reliability and credibility of sourcescan be a challenge as information changes quickly and isn’t alwayscorrect.” [P846] There was a particular concern with socialsites, as P95 described, “I sometimes feel the lack of qualitycontent on social networks, q&a sites—especially when it comesto incompetent answers to questions I ask. So the challenge is tofilter the information you get from all of the sources.” Develop-ers were also concerned by discoveries of contradicting orinconsistent information.

There were also complaints that some information maybe obsolete: “Technologies are moving so fast, and most of thecontent on the Internet could be outdated quickly. It’s sometimeshard to filter that outdated information.” [P492] Sometimes

the channels developers use are subject to spam. As P750told us, “Recruiters keep spamming me through GitHub orStack Exchange looking for Web developers.” Developers alsodescribed how it can be difficult to find content on nichetechnologies and that it was hard to acquire and understandthe history of the information created.

8 DISCUSSION

Through our survey, we investigated how a complex ecosys-tem of communication channels shapes and challenges aparticipatory development culture.

We first discovered characteristics of the programmersthat participate in and contribute openly to projects hostedon the GitHub social coding site. We now examine how thereported respondent characteristics may indicate a lack ofparticipant diversity, as well as the implications that arisefrom this.

Our survey asked respondents about their participatorydevelopment activities. Previous research has focused ondevelopment activities, but we discuss why it is importantto also consider non-development activities (such as net-working and learning) in terms of understanding future toolneeds.

Next, we look at the complex ecology of communicationtools that our survey revealed. We compare our findingsabout the benefits and challenges of using these tools toexisting research about communication tool use in globalsoftware and open source development contexts. We alsoshare some recommendations that emerged directly fromthe survey responses to address challenges developers ex-perience using a complex communication and social toolecology.

Finally, we discuss some of the limitations of our studyand propose future research directions.

8.1 Characteristics of the Programmers Surveyed

Our survey was answered by developers that contributeto publicly hosted software projects on GitHub. When wedesigned our survey, we expected that this populationmay be skewed towards younger, male, North Americandevelopers, and that we might see differences across thedemographics in the number and types of tools used, andtheir perceived benefits and challenges. Our expectationswere somewhat met—the respondents were skewed in themanner we expected—but our analysis did not reveal dif-ferences in the tools used or how they were used across thevaried developer demographics.

We were surprised that only 3.9% of our respondentssaid they were female. We expected this number to be higheras a recent survey of more than 2,000 FLOSS contributorsindicated that 10% were female [30]. Our statistic is, how-ever, more in line with earlier surveys that indicated femalesaccounted for 1–5% of open source participants [31]. Com-bined, these results may indicate an ongoing or increasinglack of gender diversity in the FLOSS community. This lackof gender diversity may go beyond FLOSS as many of oursurvey participants were professional developers. A lack ofdiversity has recently been shown to negatively impact pro-ductivity in FLOSS projects [32], but we are also concerned




that skill development and networking benefits gained fromparticipating in FLOSS or publicly hosted projects may beharder to achieve for certain groups of developers. Furtherresearch is sorely needed to investigate if and how commu-nication and social channels can be improved to reduce thediversity gap in software development.

Another interesting but somewhat expected characteris-tic about our respondents relates to their age: 77.9% saidthey were 32 or younger, so-called millennials. Other sur-veys with FLOSS developers also show similar distribu-tions, e.g., [32], [30]. We expected that older developers maynot use the same set of tools or as many tools as youngerdevelopers, but we did not see much of a difference, likelybecause our survey was biased towards developers thatembrace social tools. We hope to repeat the survey with adifferent population of developers. Our survey also showedthat older programmers are more likely to work on pro-fessional projects and less likely to work on open sourceprojects. Meanwhile, we found that when a person is aprofessional programmer, it is less likely they will contributeto open source. One hypothesis is that some software orga-nizations may discourage open source participation amongtheir employees, either directly or indirectly. Future work isneeded to investigate this.

8.2 Beyond Coding: Understanding Tool Needs for Par-ticipatory Development

Previous research into tool needs has tended to focus ondevelopment activities rather than the broader set of activ-ities that are the hallmark of a participatory developmentculture [6]. In our survey, we considered how commu-nication and social tools are used to support a numberof different activities that developers care about, such aslearning and sharing with others, networking, and keepingup to date with new technologies and project activities. Theparticipatory activities we inquired about were inspired byJenkins’ definition of a participatory culture [1], but ourprevious literature review [6] revealed that this list of activ-ities is also important to developers. However, it is possiblethat this set of activities is not complete and that furtherresearch is needed to understand the full set of participatorydevelopment activities that need to be supported throughcommunication and social tools.

We feel it is important to understand the broader ac-tivities that developers care about so that our future toolsand guidance on work practices can support these needs.Although developers care about code quality and velocity,they also recognize that they need to continuously learnand network to create opportunities. Ultimately, this shouldhelp improve the work they do on current as well as futureprojects.

8.3 Towards Understanding the Ecology of Communi-cation Channels Developers Use in a Participatory Cul-ture

Through our survey, we were able to paint a picture of thecomplex and broad ecology of tools that developers use. Wewere also able to determine which tools were deemed to bethe most important for participatory development activities:

code hosting sites, face-to-face interactions, Q&A sites, andsearch engines (Fig. 7).

It is not surprising that the majority of respondents saidcode hosting sites were the most important (73% chose it),as we contacted respondents via GitHub. Code hosting sitesserve an important role in providing version control, issuetracking, and several means of communication betweendevelopers.

Face-to-face and Question & Answer (Q&A) sites werepractically tied in second place. The importance of Face-to-face implies that, even in a rich environment of electroniccommunication channels, developers still have a strongpreference towards communicating in person. This findingresonates with previous works on the impact of distancein collaborative settings (e.g., [33], [34]). Although Face-to-face is recognized as the “richest” channel for communica-tion [35], we were still surprised that so many developerssaid it was important. A high percentage of respondentssaid they worked on distributed open source projects whereco-location is likely impossible—we suspect that many de-velopers thought of Skype or Google Hangouts as a Face-to-face channel.

We know from other research [36] that Q&A sites play aprominent role in developers’ activities, but we do not knowif developers use it as a communication channel with otherdevelopers (bidirectional communication) or mostly as aresource where they can get quick answers to questions thatthey have (unidirectional communication). We also suspectthat the goal of Search (the fourth most important channel)may be related to the goal of Q&A sites, as answeringtechnical questions is one of the most important developerinformation needs [37], [38] and resources such as StackOverflow are designed to be reached through Search tools.

Giuffrida and Dittrich [20] reported on the usage ofsocial software in software engineering projects and indistributed teams through a systematic mapping study.They discussed the use of instant messaging for reducingcommunication barriers between remote collaborators. In arelated work, Dittrich and Giuffrida [14] explored the role ofinstant messaging in a global software development projectand found that IM not only supports communication amongdistributed team members, but also provides a means tobuild trust and social relationships among co-workers. Inour survey, Private (e.g., Skype chat) and Public (e.g.,IRC) chats were deemed as the most important channelsby nearly 15% of our survey respondents (6th and 9thpositions, respectively; see Fig. 7), which indicates the im-portance of chat tools for supporting development activities,especially regarding informal communication.

Giuffrida and Dittrich [20] also mapped studies on theuse of blogs and microblogs. In our survey, Microblogswere deemed as the most important channel by over 200respondents (nearly 20% chose it), thus earning the 5thposition, while Blogs ranked 7th. Our qualitative analysisshowed that both of them help increase awareness of themost up-to-date developments in developer communities. Itis important to note that the vast majority of papers foundin Giuffrida and Dittrich’s systematic mapping refer to theuse of communication channels in enterprise settings. As thedemographics of our survey indicate, our survey populationis more mixed, including professional, open source, and




hobbyist developers. Further research is needed to explorethe interplay between private and public software develop-ment when it comes to communication channel usage.

It is also important to note that most studies that haveexplored how social tools are used in software developmentstudied just one or two communication or social tools [6],[20]. One exception is a short survey conducted by Black etal. in 2010 where they found that several social media toolswere used to support development work [18]. Another keyexception is the work by Turner et al. [17] where theystudied the “workplace communication ecology” in a smallcompany of about 50 participants using surveys in 2008 and2009, followed by interviews with 23 participants. They re-ported on clusters of tools used, as well as the strengths andweaknesses from the various channels. Since the employeeswere co-located, not surprisingly, Face-to-face was the mostpreferred communication channel.

The ecology of tools that developers use is interesting tostudy because we see developers using multiple tools forthe same activity, as well as using more tools over time.Turner et al. [17] also found an increase in the number oftools used as far back as 2009. We stress that this increasingreliance on a complex constellation of tools brings severalchallenges, as discussed in the findings above and as Giuf-frida et al. presented in their mapping study [20].

Next, we discuss preliminary recommendations for prac-titioners wanting to address some of these challenges, butwe also call on the research community to study these issuesfurther and to suggest new processes or tools to address theincreasing participatory needs of software developers.

8.4 Recommendations for Practitioners ChoosingToolsIn our survey, we probed through an open-ended questionabout the challenges developers face using an ecosystemof communication channels. These challenges point to anumber of recommendations that may be helpful to otherdevelopers. In the following, we formulate some recommen-dations for developers that rely on a number of communi-cation channels while engaging with a participatory cultureof software development. Our recommendations are partlybased on our literature review as well as on strategies thesurvey respondents reported using to address the variouschallenges they experienced. We coded and categorizedthese shared strategies, as shown in Fig. 9.

We stress, however, that future research is needed tovalidate these recommendations and that this set of recom-mendations is likely not complete; discovering them wasnot one of our research goals, and thus our survey did notexplicitly attempt to elicit such recommendations.

Recommendation 1: Be aware of channel affordances andchoose tools accordingly.

There is a vast array of communication channels thattoday’s developers (and other knowledge workers) can use(see Fig. 1). Particular channels offer different affordances,as described by the “Media Richness” theory [33] and aselaborated in Section 7.5 of this paper. For example, somechannels offer more immediacy for communication (e.g.,face-to-face) while asynchronous channels such as email

offer a chance for deeper reflection before having to respond.Other channels, although immediate, may introduce distrac-tions.

In previous work, Treude et al. [39] investigated theproperties of different documentation channels in softwareprojects and found that different channels had differentbenefits and drawbacks. For example, they found that blogswere seen to generate more fanfare than wikis and weremore suitable for posting important announcements thatshould not be missed, whereas wikis were easier to change.Similarly, Calefato et al. [40] discuss the appropriatenessof different communication media to support distributedrequirements engineering.

Developers may not always be consciously aware ofchannel affordances and the trade-offs between them. How-ever, they need to learn to recognize the strengths andweaknesses of different channels and to recognize tensionsbetween private vs. public channels, synchronous vs. asyn-chronous communication, ephemeral vs. archival channelproperties, anonymous vs. identified participation, andsupport for different communication types, such as textualvs. verbal vs. face-to-face conversations.

Recommendation 2: Define a communication covenant withproject members.

To enhance distributed work, Olson and Olson [33]suggest that teams create a “communication covenant” to pre-scribe which channels should be used for different kinds ofcommunication within a team. Similarly, Giuffrida and Dit-trich [19] conceptualize the role of communication channelsin helping to establish persistent coordination mechanismsamong team members. Indeed, many successful open sourceprojects recommend which channels to use, such as how theAngular project specifies which channels should be used fordifferent activities9. P253 felt that collaborators should notjust agree on tools, but also agree on how they must be used:“The tool matters less than how people use it. Biggest problem ispeople not using tools the way it was agreed upon.” Althoughsome project teams do figure this out without a formalcovenant: “Small autonomous projects/teams who have a fairlymutual understanding of what communication/collaboration toolsthey want to use to achieve their needs/goals tend to experiencelittle communication friction, I find.” [P783]

Giuffrida et al. [20] also suggest that groups need topay attention to how tools are socially negotiated. Socialprotocols and tools not only need to be initially decidedupon, but also adopted and adapted by people over time,thus being socially shared, modified, and appropriated [19].Furthermore, other researchers have noted that there is aneed to establish practices on how to use social software indevelopment contexts [20].

Recommendation 3: Think lean when adopting new tools.

A common challenge reported by our respondents waschannel overload, as discussed above. Although there aremany possible channels that developers can use, using

9. https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md

https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md

https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md




too many will lead to feeling overwhelmed from manag-ing different tools and will also increase the chance thatinformation is fragmented across different channels. P232suggested a way to address this: “The use of numerous toolsmay be overwhelming. It is usually assumed that it is better touse fewer tools, and increase the direct communication frequencybetween developers using face-to-face or chat.”

Recommendation 4: Stay abreast of the latest tools that mayimprove development productivity and team work.

This recommendation may seem to contradict the lastrecommendation to use fewer tools, but many of the morerecent tools (such as Slack) aggregate communication fromdifferent tools through one channel. We learned from our re-spondents that no one tool fits all needs, as P980 mentioned,“There are too many sources of communication to monitor, Ihave been trying to use tools like HipChat and Flowdock to geta more unified communication channel.” Likewise, new toolsmay emerge that address other challenges and they shouldbe considered for adoption.

Recommendation 5: Take the time to learn how to use thechannels most effectively.

As discussed above, tool literacy is considered to bevery important. P488 described how poor literacy with teammembers can lead to frustrations: “Lesser-skilled developers(typically designer-developers) sometimes struggle to use the com-mon tools like Git/GitHub, screen sharing, text-based communi-cation and to configure their own development environment. This[means those] collaborating remotely get bogged down in stupidtroubleshooting sessions.” P729 described how important it isto develop skills that make the most of particular channelsand avoid challenges such as noise: “Developing filter skillsto pick out the important things from the noise.”

Recommendation 6: Know when to unplug.

Some respondents described how they unplug from theInternet or from specific communication channels to allowthem to focus and to avoid interruptions and distractions.P1336 shared how they consciously decide when to usecertain communication channels: “I turn off most commu-nication tools at the right times (i.e., when I’m not in need offeedback or help). I’ll still use GitHub for finding resources and aprivate messaging tool, HipChat or email for quick questions.”Similarly, P534 described using a command line tool toavoid distractions in the Browser: “If you have to go to a Webbrowser there is a 10% chance you’ll be distracted. I use the project‘howdoi’ to get answers from Stack Overflow on the command lineso I can stay out of the browser and keep focus.”

P825 discussed how it is important to be mindful abouthow one feels: “Biggest challenge is meta–e.g. *noticing* whenI’m feeling overwhelmed or distracted and adjusting to adapt (e.g.closing IRC, taking a twitter hiatus, etc)”. P646 recommendedthat “one needs to exercise self control when using these tools,otherwise it’s easy to end up spending more time on them thanneeded.” P692 went one step further, suggesting that “some-times it helps to have a day of development where you unplug[the] Internet.”

8.5 LimitationsStudying the participatory culture of software developmentis challenging because it involves understanding the toolsand communication channels developers use, the content gen-erated through these channels, the developers themselves andtheir perspectives, the development activities and actionssupported by the tools, and the interplay between all ofthese aspects. Through our survey, we aimed to focus ourinvestigation on the communication channels developersuse to support their participatory development activities, aswell as developers’ perspectives concerning the use of thesecommunication tools.

We opted to use a survey instrument to reach a broadpopulation of developers. The survey design followed sev-eral phases of design and pilot studies as we needed tocompromise between developer time and the amount ofinformation we gathered. The survey inclusion criteria sug-gest participant bias towards social code hosting systems,however, this population was the focus of our study. There-fore, we do not claim generalizability of our results to alldevelopers. Our survey and the underlying source code areavailable online.

At least 60% of our respondents work in Web develop-ment. Our results resonate with an increase in the popularityof Web technologies and programming languages such asJavaScript and CSS 10. However, our findings may alsobe biased towards development practices that are mostcommonly found in Web development projects.

Despite their length, the 2013/2014 surveys had21%/16% response rates, respectively. Many developers toldus they were happy to contribute to this research as theywere also curious about the channels other developers useand the challenges others experience. Since the survey waslong, the respondents may have suffered from fatigue andmay have selected fewer channels for activities further intothe survey, and the earlier responses to questions may haveinfluenced later responses. We considered randomizing theorder of the questions, but we opted for a more logicalorder as we felt developers would find it easier to answerquestions in this manner.

Another limitation (that we recognized as we conductedour study) is that the tools developers use are changingfaster than we can study! For example, Slack was not widelyadopted at the start of our survey, but is now used by a greatmany developers.

Although our findings from the demographics and chan-nel usage questions are insightful, the data we receivedabout the challenges developers face was the most inter-esting as we learned how tools may benefit but also nega-tively impact developer work practices. To offset bias duringcoding, we recruited an independent coder to analyze ourdata. When the coders did not agree, we did not applythe code. We stress that the counts we report may not bean accurate indicator of the importance of the additionalchallenges as this was an optional open-ended questionposed at the end of a long survey. In the presentation of thechallenges, we rely heavily on the developers’ own wordsto bring credibility to our findings. In Fig. 9, we providecounts for each code and further expand this table in the

10. https://github.com/blog/2047-language-trends-on-github




companion website11 with additional quotes. Future workis needed, however, to determine the importance of thesechallenges, as well as reveal additional strategies to addressthese challenges and to validate the recommendations weprovided above.

Finally, we emphasize that our study is just one step in alarger effort towards forming a theory of knowledge work ina participatory culture of development, as we discuss next.

8.6 Future WorkOur study paves the way for the development of theoriesconcerning how developers use tools and suggests waysthat tools may be improved. The software engineering com-munity has witnessed a major paradigm shift in recent yearsin how developers communicate and participate in eachother’s projects and in each other’s learning. There is a greatneed to study emergent software practices as well as the toolconstellations that modern developers use.

To date, we have collected data from two large-scalesurveys (in 2013 and 2014), but we intend to deploy thesame in future years (with some changes to account fornewer communication channels) as we wish to understandhow the use of communication channels by developers mayevolve over time. But surveys are limited in the kinds ofdata and insights they can provide.

As a continuation of this study, we anticipate that futureinterviews with developers would shed more light on thestrategies they use to mitigate the challenges we revealed inour survey. Observations may also uncover other challengesas well as how developers are using new tools (such asScreen Hero12, which supports collaborative screen sharing)and how they use homegrown tools.

Additionally, these studies should be extended to com-mercial projects—i.e., non-open source projects—with dif-ferent constraints and restrictions (e.g., being forced to usespecific tools). The themes that emerged in this study willhelp form a new version of the survey13.

Our future work will allow us to further develop adescriptive theory on how different channel affordancesmay shape participatory development activities. Our hopeis that this theory can be used to help developers andtool designers anticipate the benefits and challenges certaincombinations of tools may bring, as well as reveal newopportunities for tool improvements and work practices.

Currently, the vast majority of the tools developers adoptand rely on are developed by industry. We suggest thatresearchers may be able to play a bigger role in tool designby understanding the implications of the tools that are usedand then revealing ways they may be improved. For exam-ple, tools that offer aggregation mechanisms may addressthe information fragmentation issues, or there may be waysthat tools can be improved to address cultural barriers.

9 CONCLUSIONS

While this study is part of ongoing research, it presentsseveral key contributions: the survey instrument; demo-

11. http://thechiselgroup.github.io/channel-study/12. https://screenhero.com/13. http://thechiselgroup.org/2013/11/19/

how-do-you-develop-software/

graphics of the social programmer; which channels de-velopers use to support their participatory developmentactivities, and which ones are most important to them; andthe challenges developers face using a broad spectrum oftools while engaging in participatory development workpractices. We also provide a number of preliminary rec-ommendations that developers may follow to address thechallenges we presented.

Finally, communication channels shape and challengethe participatory culture in software development. How-ever, the reverse is also true: not much is understood aboutthe impact of the participatory culture on software develop-ment practices and the communication channels developersuse. We believe this research also has implications on otherknowledge workers; software developers are referred to asthe knowledge worker prototype as they are not only the firstto use and shape the tools and channels, but also have farlower barriers to build and tweak these tools [41]. It won’t besurprising if the challenges and opportunities that emergedfrom our study will propagate to other domains as well.

ACKNOWLEDGMENTS

The authors would like to thank the respondents for takingso much time to answer the survey, as well as CassandraPetrachenko for assistance with coding and editing of thepaper.

REFERENCES

[1] H. Jenkins, Confronting the challenges of participatory culture: Mediaeducation for the 21st century. Mit Press, 2009.

[2] E. C. Wenger and W. M. Snyder, “Communities of practice: Theorganizational frontier,” Harvard business review, vol. 78, no. 1, pp.139–146, 2000.

[3] L. Singer, F. Figueira Filho, B. Cleary, C. Treude, M.-A. Storey,and K. Schneider, “Mutual assessment in the social programmerecosystem: An empirical investigation of developer profile aggre-gators,” in Proceedings of the 2013 conference on Computer supportedcooperative work. ACM, 2013, pp. 103–116.

[4] M. Chui, J. Manyika, J. Bughin, R. Dobbs, C. Roxburgh,H. Sarrazin, G. Sands, and M. Westergren. (2012) The so-cial economy: Unlocking value and productivity throughsocial technologies. http://www.mckinsey.com/insights/hightech telecoms internet/the social economy.

[5] F. Lanubile. (2013) Social software as key enabler of collab-orative development environments. http://www.slideshare.net/lanubile/lanubilesse2013-25350287.

[6] M.-A. Storey, L. Singer, B. Cleary, F. Figueira Filho, andA. Zagalsky, “The (r)evolution of social media in softwareengineering,” in Proc. of the 36th Intl. Conf. on SoftwareEngineering, Future of Software Engineering, ser. FOSE ’14. NewYork, NY, USA: ACM, 2014, pp. 100–116. [Online]. Available:http://doi.acm.org/10.1145/2593882.2593887

[7] K. Crowston, K. Wei, Q. Li, and J. Howison, “Core and peripheryin free/libre and open source software team communications,”in System Sciences, 2006. HICSS ’06. Proceedings of the 39th AnnualHawaii International Conference on, vol. 6, Jan 2006, pp. 118a–118a.

[8] R. Pham, L. Singer, O. Liskin, F. Figueira Filho, and K. Schneider,“Creating a shared understanding of testing culture on a socialcoding site,” in Proceedings of the 35th International Conference onSoftware Engineering, ser. ICSE ’13, 2013, pp. 112–121.

[9] J. Fried and D. H. Hansson, Remote: Office Not Required. EburyDigital, 2013.

[10] P. Naur, “Programming as theory building,” Microprocessing andmicroprogramming, vol. 15, no. 5, pp. 253–261, 1985.


https://screenhero.com/



http://www.mckinsey.com/insights/high_tech_telecoms_internet/the_social_economy

http://www.mckinsey.com/insights/high_tech_telecoms_internet/the_social_economy

http://www.slideshare.net/lanubile/lanubilesse2013-25350287

http://www.slideshare.net/lanubile/lanubilesse2013-25350287

http://doi.acm.org/10.1145/2593882.2593887




[11] A. Guzzi, A. Bacchelli, M. Lanza, M. Pinzger, and A. v.Deursen, “Communication in open source software developmentmailing lists,” in Proceedings of the 10th Working Conferenceon Mining Software Repositories, ser. MSR ’13. Piscataway,NJ, USA: IEEE Press, 2013, pp. 277–286. [Online]. Available:http://dl.acm.org/citation.cfm?id=2487085.2487139

[12] L. Singer, F. Figueira Filho, and M.-A. Storey, “Softwareengineering at the speed of light: How developers staycurrent using twitter,” in Proceedings of the 36th InternationalConference on Software Engineering, ser. ICSE ’14. New York,NY, USA: ACM, 2014, pp. 211–221. [Online]. Available:http://doi.acm.org/10.1145/2568225.2568305

[13] E. Shihab, Z. M. Jiang, and A. Hassan, “On the use of internet relaychat (irc) meetings by developers of the gnome gtk+ project,” inMining Software Repositories, 2009. MSR ’09. 6th IEEE InternationalWorking Conference on, May 2009, pp. 107–110.

[14] Y. Dittrich and R. Giuffrida, “Exploring the role of instant messag-ing in a global software development project,” in Global SoftwareEngineering (ICGSE), 2011 6th IEEE International Conference on, Aug2011, pp. 103–112.

[15] W. Scacchi, “Understanding the requirements for developing opensource software systems,” Software, IEE Proceedings -, vol. 149,no. 1, pp. 24–39, Feb 2002.

[16] M. McLuhan and Q. Fiore, The medium is the message, New York,1967.

[17] T. Turner, P. Qvarfordt, J. T. Biehl, G. Golovchinsky, and M. Back,“Exploring the workplace communication ecology,” in Proceedingsof the SIGCHI Conference on Human Factors in Computing Systems.ACM, 2010, pp. 841–850.

[18] S. Black, R. Harrison, and M. Baldwin, “A survey of social mediause in software systems development,” in Proceedings of the 1stWorkshop on Web 2.0 for Software Engineering. ACM, 2010, pp. 1–5.

[19] R. Giuffrida and Y. Dittrich, “A conceptual framework to study therole of communication through social software for coordinationin globally-distributed software teams,” Information and SoftwareTechnology, vol. 63, pp. 11 – 30, 2015. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S095058491500049X

[20] ——, “Empirical studies on the use of social software inglobal software development a systematic mapping study,”Information and Software Technology, vol. 55, no. 7, pp. 1143 –1164, 2013. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S0950584913000153

[21] C. Treude, F. Figueira Filho, B. Cleary, and M.-A. Storey, “Pro-gramming in a socially networked world: the evolution of thesocial programmer,” in Proceedings of the Workshop on The Futureof Collaborative Software Development, ser. CSCW ’12. New York,NY, USA: ACM, 2012, pp. 1–3.

[22] N. Postman, “The humanism of media ecology,” in Proceedings ofthe Media Ecology Association, vol. 1, 2000, pp. 10–16.

[23] C. Parnin and S. Rugaber, “Resumption strategies for interruptedprogramming tasks,” Software Quality Journal, vol. 19, no. 1,pp. 5–34, 2011. [Online]. Available: http://dx.doi.org/10.1007/s11219-010-9104-9

[24] O. Baysal, R. Holmes, and M. W. Godfrey, “No issue leftbehind: Reducing information overload in issue tracking,” inProceedings of the 22Nd ACM SIGSOFT International Symposiumon Foundations of Software Engineering, ser. FSE ’14. NewYork, NY, USA: ACM, 2014, pp. 666–677. [Online]. Available:http://doi.acm.org/10.1145/2635868.2635887

[25] M. Goldman, G. Little, and R. C. Miller, “Real-time collaborativecoding in a web ide,” in Proc. 24th annual ACM symposium Userinterface software and technology. ACM, 2011, pp. 155–164.

[26] H. C. Stuart, L. Dabbish, S. Kiesler, P. Kinnaird, and R. Kang,“Social transparency in networked information exchange: Atheoretical framework,” in Proceedings of the ACM 2012 Conferenceon Computer Supported Cooperative Work, ser. CSCW ’12. NewYork, NY, USA: ACM, 2012, pp. 451–460. [Online]. Available:http://doi.acm.org/10.1145/2145204.2145275

[27] L. Dabbish, C. Stuart, J. Tsay, and J. Herbsleb, “Social codingin github: Transparency and collaboration in an open softwarerepository,” in Proceedings of the ACM 2012 Conference onComputer Supported Cooperative Work, ser. CSCW ’12. NewYork, NY, USA: ACM, 2012, pp. 1277–1286. [Online]. Available:http://doi.acm.org/10.1145/2145204.2145396

[28] I. Steinmacher, T. U. Conte, M. Gerosa, and D. Redmiles, “Socialbarriers faced by newcomers placing their first contribution inopen source software projects,” in Proceedings of the 18th ACMconference on Computer supported cooperative work & social computing,2015, pp. 1–13.

[29] R. L. Daft and R. H. Lengel, “Organizational information require-ments, media richness and structural design,” Management science,vol. 32, no. 5, pp. 554–571, 1986.

[30] G. Robles, L. Arjona Reina, A. Serebrenik, B. Vasilescu,and J. M. Gonzalez-Barahona, “Floss 2013: A survey datasetabout free software contributors: Challenges for curating,sharing, and combining,” in Proceedings of the 11th WorkingConference on Mining Software Repositories, ser. MSR ’14. NewYork, NY, USA: ACM, 2014, pp. 396–399. [Online]. Available:http://doi.acm.org/10.1145/2597073.2597129

[31] P. A. David and J. S. Shapiro, “Community-based production ofopen-source software: What do we know about the developerswho participate?” Information Economics and Policy, vol. 20,no. 4, pp. 364 – 398, 2008, empirical Issues in Open SourceSoftware. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S0167624508000553

[32] B. Vasilescu, D. Posnett, B. Ray, M. G. van den Brand,A. Serebrenik, P. Devanbu, and V. Filkov, “Gender and tenurediversity in github teams,” in Proceedings of the 33rd AnnualACM Conference on Human Factors in Computing Systems, ser. CHI’15. New York, NY, USA: ACM, 2015, pp. 3789–3798. [Online].Available: http://doi.acm.org/10.1145/2702123.2702549

[33] G. M. Olson and J. S. Olson, “Distance matters,” Hum.-Comput.Interact., vol. 15, no. 2, pp. 139–178, Sep. 2000. [Online]. Available:http://dx.doi.org/10.1207/S15327051HCI1523 4

[34] P. Bjørn, M. Esbensen, R. E. Jensen, and S. Matthiesen, “Doesdistance still matter? revisiting the cscw fundamentals ondistributed collaboration,” ACM Trans. Comput.-Hum. Interact.,vol. 21, no. 5, pp. 27:1–27:26, Nov. 2014. [Online]. Available:http://doi.acm.org/10.1145/2670534

[35] A. R. Dennis and S. T. Kinney, “Testing media richness theory inthe new media: The effects of cues, feedback, and task equivocal-ity,” Information systems research, vol. 9, no. 3, pp. 256–274, 1998.

[36] L. Mamykina, B. Manoim, M. Mittal, G. Hripcsak, andB. Hartmann, “Design lessons from the fastest q&a sitein the west,” in Proceedings of the SIGCHI Conference onHuman Factors in Computing Systems, ser. CHI ’11. NewYork, NY, USA: ACM, 2011, pp. 2857–2866. [Online]. Available:http://doi.acm.org/10.1145/1978942.1979366

[37] A. J. Ko, R. DeLine, and G. Venolia, “Information needs incollocated software development teams,” in Proceedings of the29th International Conference on Software Engineering, ser. ICSE ’07.Washington, DC, USA: IEEE Computer Society, 2007, pp. 344–353.[Online]. Available: http://dx.doi.org/10.1109/ICSE.2007.45

[38] A. Begel and T. Zimmermann, “Analyze this! 145 questions fordata scientists in software engineering,” in Proceedings of the36th International Conference on Software Engineering, ser. ICSE ’14.New York, NY, USA: ACM, 2014, pp. 12–23. [Online]. Available:http://doi.acm.org/10.1145/2568225.2568233

[39] C. Treude and M.-A. Storey, “Effective communication ofsoftware development knowledge through community portals,”in Proceedings of the 19th ACM SIGSOFT Symposium and the 13thEuropean Conference on Foundations of Software Engineering, ser.ESEC/FSE ’11. New York, NY, USA: ACM, 2011, pp. 91–101.[Online]. Available: http://doi.acm.org/10.1145/2025113.2025129

[40] F. Calefato, D. Damian, and F. Lanubile, “Computer-mediatedcommunication to support distributed requirements elicitationsand negotiations tasks,” Empirical Software Engineering, vol. 17,no. 6, pp. 640–674, 2012.

[41] A. Kelly, Changing Software Development: Learning to Become Agile.John Wiley & Sons, 2008.

http://dl.acm.org/citation.cfm?id=2487085.2487139

http://doi.acm.org/10.1145/2568225.2568305

http://www.sciencedirect.com/science/article/pii/S095058491500049X

http://www.sciencedirect.com/science/article/pii/S095058491500049X

http://www.sciencedirect.com/science/article/pii/S0950584913000153


http://dx.doi.org/10.1007/s11219-010-9104-9

http://dx.doi.org/10.1007/s11219-010-9104-9

http://doi.acm.org/10.1145/2635868.2635887

http://doi.acm.org/10.1145/2145204.2145275

http://doi.acm.org/10.1145/2145204.2145396

http://doi.acm.org/10.1145/2597073.2597129



http://doi.acm.org/10.1145/2702123.2702549

http://dx.doi.org/10.1207/S15327051HCI1523_4

http://doi.acm.org/10.1145/2670534

http://doi.acm.org/10.1145/1978942.1979366

http://dx.doi.org/10.1109/ICSE.2007.45

http://doi.acm.org/10.1145/2568225.2568233

http://doi.acm.org/10.1145/2025113.2025129

How Social and Communication Channels Shape and Challenge ...etc.leif.me/papers/Storey2016.pdf ·...

Documents

Transcript of How Social and Communication Channels Shape and Challenge ...etc.leif.me/papers/Storey2016.pdf ·...