The Communicational Side of Open Source Communities

Fa oltà diIngegneria

Dipartimento di Ingegneria Elettri a ed Elettroni a

The Communi ational Side of Open Sour e

Communities

Selene Uras

Supervisor PhD oordinator

Prof. Giulio Con as Prof. Alessandro Giua

PhD Thesis

Corso di Dottoratodi Ri er a in Ingegneria Elettroni a ed Informati a

S uoladiDottorato inIngegneria dell'Informazione

ING-INF/05

XX i lo

Abstra t V

1 Communi ationin Software Development Teams 1

1.1 Communi ating ina team . . . 1

1.2 Dierent kindsof softwaredevelopment teams . . . 2

1.3 Dis-lo ated versus o-lo atedteam: how ommuni ating . . . 7

2 Open Sour e Communities 9 2.1 Animportant phenomenon . . . 9

2.1.1 Thebeginning . . . 10

2.1.2 OSSbetween ethi and te hnology . . . 11

2.2 Communi ation inOpenSour e ommunities . . . 12

2.2.1 Stru tureand roles . . . 12

2.2.2 Communi ation inOS:valueand tools . . . 13

2.3 Stateof the art . . . 14

3 MAD Proje t 17 3.1 A tion resear h . . . 17

3.2 Usingextreme programming ina distributedteam . . . 18

3.3 Proje tdes ription . . . 19

3.3.1 Training . . . 20

3.3.2 People androles . . . 20

3.3.3 Co-lo ateddevelopment and XPpra ti es . . . 20

3.3.4 Distributeddevelopment andXP pra ti es . . . 23

3.5 Adopting Agile Methodologies in a distributed environment:

a ase studysimulation. . . 26

3.5.1 Method . . . 27

3.5.2 Metri s . . . 27

3.5.3 Calibration andvalidation . . . 28

3.5.4 Simulatingthe XP o-lo ated pro ess. . . 30

4 Polaris4OS proje t 33 4.1 Polaris4OS . . . 34

4.1.1 Choosing asuitable Open Sour eproje t. . . 34

4.1.2 People androles . . . 35

4.1.3 Training . . . 36 4.1.4 Designing . . . 37 4.1.5 ModuleDevelopment . . . 38 4.1.6 Companiesparti ipation . . . 39 4.2 Curri ula . . . 40 4.2.1 Dening Curri ula . . . 40

4.2.2 ResultsofBlended Learning Method . . . 41

4.3 Asu ess experien e . . . 43

5 A resear h study on Open Sour e Communities develop-ers'mailing lists 44 5.1 Someofthe mostsu essfulOpen Sour e proje ts. . . 44

5.1.1 Sour eForgewebsite . . . 45

5.1.2 Choosing most su esfulOSproje ts . . . 46

5.1.3 MailingListsDevelopers . . . 48

5.1.4 Members . . . 49

5.2 Data olle tionand analysis . . . 49

5.2.1 E-mails . . . 50

5.2.2 Threads . . . 52

5.2.3 Links . . . 54

5.3 Communi ation owin Developers'Mailing Lists . . . 56

6.1.1 A tor . . . 59 6.1.2 Link . . . 59 6.1.3 Dyad. . . 59 6.1.4 Tryad . . . 60 6.1.5 Subgroup . . . 60 6.1.6 Group . . . 60 6.1.7 So ial Network . . . 60

6.2 Centrality and prestige . . . 60

6.2.1 Centrality . . . 60

6.2.2 Prestige . . . 61

6.3 Centrality indexes . . . 61

7 Analysing the So ial Networks onstituted by Open Sour e ommunities 62 7.1 So ial Network Analysisapplied at OSS ommunities . . . 63

7.2 Analysing the So ial Networks onstituted by Open Sour e ommunities . . . 63

7.3 Dataanalysis . . . 64

7.3.1 Degree index . . . 64

7.3.2 Betweenness index . . . 66

7.3.3 Closenessindex . . . 68

7.4 OpenSour e Communities asSo ialNetworks . . . 70

Con lusion 74

1.1 Waterfall model . . . 5

1.2 Communi ation insoftwaredevelopment teams . . . 7

3.1 Storieson bla kboard . . . 22

3.2 EstimationError . . . 23

3.3 Openspa e setting . . . 24

3.4 XPSwiki . . . 25

4.1 Theweb page where to insertmessages. . . 39

4.2 Initialdevelopersskills . . . 41

4.3 Numberof visitsto Moodleplatform for ea hdeveloper . . . 42

4.4 Finaltestresults . . . 43

5.1 Mirandahomepage on Sour eForge website . . . 45

5.2 Mailssentin ea h proje t bydevelopers andusers . . . 52

7.1 Proje ts'degree distribution . . . 65

7.2 Proje ts'betweennessdistribution . . . 67

7.3 Proje ts' losenessdistribution . . . 69

3.1 Core Team . . . 21

3.2 Input parameters andoutput variables ofthemodel . . . 29

3.3 Input parameters to alibrate themodel . . . 29

3.4 Calibration ofthe modelparameters on thefth iteration . . 30

3.5 Validation of themodelparameters on thesixthiteration . . 30

3.6 Simulationresults of thewhole proje t . . . 32

4.1 Dierent Roles . . . 36

4.2 Curri ula modules andtheir orrespondent ategory . . . 42

5.1 The70 most a tive proje ts onSour eforge . . . 47

5.2 The ninestudied proje ts . . . 48

5.3 Members androles . . . 49

5.4 E-mails . . . 50

5.5 E-mails sent bydevelopers . . . 51

5.6 E-mails sent byusers . . . 51

5.7 Threads . . . 53

5.8 Threadsstartedbydevelopers . . . 53

5.9 Threadsstartedbyusers . . . 54

5.10 Links. . . 55

5.11 Linksofea h member . . . 55

7.1 Meandegree and groupdegree entralization . . . 65

7.2 Meanbetweennessand group betweenness entralization . . . 67

Whatmattermostin team

softwaredevelopmentis

ommuni ation

KentBe k

Communi ation is a fundamental value of software development teams,

espe iallyinOpen Sour e (OS) ommunities. An OS ommunity,infa t, is

a quite omplex network of individuals having dierent rolesand

responsi-bilities,who anbelookeduponasvolunteers whospendtheir time reating

and improving software. These people taking partin OSSoftware

develop-ment useto share knowledge among themselves, ex hange information and

reate a ollaborative environment.

To oordinateandimprove ommuni ationoftheseteamsdis-lo atedallover

the world and used to work at dierent times and ways, it is ne essary to

predisposeand utilizespe i tools.

Thisresear hstudy wasborn withtheproposalto individuateandevaluate

ommuni ation among members of OS ommunities analysing dierent

de-velopment teams.

Thestarting point isan a ademi softwaredevelopment proje t:

Metodolo-gieAgiliDistribuite (AgileDistributed Methodologies, MAD)proje t. This

asestudy,performedat UniversityofCagliari, wasmadeupoftwo well

de-nedsoftwaredevelopmentphases. Therstoneperformedwithinanalmost

pureXP o-lo atedenvironment,these ondoneinvolvinga20-programmers

distributedteam. Themain goalofthis experien e wasto showhow apure

doingaquantitative evaluationoftheadoption ofsomeagilepra ti es inan

open sour e proje t.

Thefo uswasthenmovedinanenterprise environment withPolaris4OS

re-sear h study. Itwasasu essfulexperien eofFLOSSadoptionamong hief

exe utive o ers(CEOs),managersand developers ofICT ompanies. The

goal ofthis proje t wasto ll thegap between well established proprietary

enterprisepro essesandtheup omingFLOSSmodel,basedon ollaboration

andknowledgesharing.

Afterthisinterestingbeginning,the resear hwasperformedinalarge s ale:

some of the most su essful Open Sour e Proje ts on Sour eForge website.

The aim of the resear h was to investigate how and why members post in

developersmailing listandtheusethatdierent membersdidofthese

mail-inglists. TheseOS ommunitieswerestudiedinorderto identifytheir main

ommuni ationalpra ti es. Therewereanalyzeddata on erning

ommuni- ation (mails ex hange), nding interesting aspe ts related to ollaborative

learningand peer supportamongdevelopersand users.

On e dis overed these relevant ommuni ational aspe ts, So ial Network

Analysis approa h was utilized to analyze these popular and mature OS

developers ommunities, in order to better understand intera tion among

members, individuate ommuni ational ows and dis over whether there is

a sub-sequential ommunity oordination and ontrol. The knowledge of

these relationships is useful in orderto better understand how

ommuni a-tionowsamongteammembersandwhetherthereissomeone oordinating,

ontrolling andfa ilitating informational pro ess.

Finding these important ommuni ational aspe ts is the ore of this study,

be ausetheyareveryusefulto improve,fa ilitateandin reasethee ien y

of software development. In that manner, basing on these dierent and

arti ulated experimental resear hes, it is also possible to draw a lear and

omplete pi ture of the urrent situation of ommuni ational ows in OS

Communi ation in Software

Development Teams

One annotnot ommuni ate

PaulWatzlawi h

1.1 Communi ating in a team

Sometimes the nature of a task determines the ne essity to work in a

team. It an be anintriguing hallengetrying tokeep together thedierent

skills, apabilities and needsof all team members. Steiner[1℄, for example,

inhisstudiesexamined arelevant numberofteamsfor ed toworkingroup

toattainaspe i goal. Hefoundthat, inspiteofaninitial relu tan e,after

thee ienta hievementofthattask,teammemberspreferredto ontinueto

worktogetheronlyin aseofsimilarkindsoftasksandafterapositiveresult.

In that manner a team an also de ide to hange its internal organization,

to better ope with a parti ular task. To similar results arrived Triplett

[2℄ observing athleti performan es; he noti ed that y lists pedalled more

qui klywhen they were in group, instead of whether they were alone. But

workinginagroupisnot alwayseasy. It an bedi ult ndingan univo al

solution or, better, a right solution. Thomas and Fink [3℄, in fa t, found

teamleader. In fa t,theynoti ed that, sin e thebeginning ofa task,group

membersusedtointera tmoreoftenwithsomebetterinformedorproa tive

members on task solution. Gradually these members be ome team leader,

playingafundamentalrole,be auseoftheir entralpositioninsidetheteam.

Soitisdi ultdrawingageneraldenitionofteamworkingin ludingallthe

important aspe ts,but an ee tiveapproa h ouldbealways on entrating

theattention on the kinds of taskand thespe i team. But it ould also

be useful to rememberthat "the hampion teamdefeats hampions'team".

1.2 Dierent kinds of software development teams

Software development is an arti ulated pro ess where is important to

follow some spe i a tivities:

•

System requirements spe ify what the system has to do and its bonds

•

Development issoftwareimplementation

•

Validation is ontrolling thatthe systemis ableto dowhat the us-tomer needs

•

Evolution is modifying thesystem be ause of further needs with re-spe tto theinitial requirements

Models suited to des ribe software development pro ess are based on

several aspe ts su h as main a tivities, temporal and logi relationships,

produ ed manufa turesand roles.

Parti ularly two fundamentalmodels areveryusefulfor a omplete

des rip-tionofthe wholedevelopment pro ess: PlanDriven andAgile. Asthename

suggests, Plan Driven approa h follows a thorough planning, trying to

an-ti ipate allthepossible needsand furtherfeatures. Instead,Agileapproa h

isbasedonshortinterationsand ontinuousadaptation;infa t,theirsaying

is " do it right the rst time". It is possible to des ribe these two dierent

•

A tivity performedeither by the wholeteam or a single member and the relationships amongthem

•

Notationmodels to des ribe spe i aspe ts ofthesystem

•

Do uments, ode andall othermaterials

•

People's roles

•

Pra ti es andadopted method

It isnot possible to talkabout an univo alsoftwaredevelopment model

be ause reatingasoftwareprodu tisnotlikebuildingahouse. Inasoftware

development pro ess, therefore, it is better to take into a ount dierent

phasesinordertodevelop,ina ontrolledway,qualitysystems. Infa t,these

phasesareaben hmarkforallthe involvedpartners (developers, managers,

ustomers...); phases are not xed be ause every kind of proje t needs its

spe i ones. They are not ne essarily done in order, so it is possible to

nullifythemandre-start. So,atthestartupphaseofasoftwaredevelopment

pro ess,it ould be usefulto keep inmind these re ommended phases:

•

Feasibility study onsistsinproblemdenition, trying tond alter-nativesolutions andtheir relativeadvantages,takinginto a ount,for

ea halternative,requiredresour esand osts. Eventuallytheproposal

for the lient isprepared based on a syntheti and preliminary

evalu-ation; it is syntheti be ause there is the risk that the lient hanges

hismind andretreats

•

Requirements eli itation identies requirements ne essary for the appli ation (fun tionalities, usability,portability...). Inthis phase are

importantfun tionalrequirements (theydes ribewhatthesystemdoes,

with formal, informal and mixed notations), non fun tional

require-ments (reliability, se urity, interfa e and e ien y) and requirements

related to development pro ess and evolution ( ontrolling quality and

testing). Requirements an be expressed by the requirements

do u-ment, use ases, user stories, formal spe i ation methods and

•

System analysis, also named requirements analysis,is useful for de-velopers to have a omplete knowledge of the domain and to avoid

ambiguityinrequirements expression. Itis animportant pro ess that

hasto be done with lient involvement; it utilizes spe i te hniques

and notations, it is brought about thedetailed ontra tual denition

ofthe systemand isthebasefor thedesign, oding andtesting

•

Designdenessystemar hite turebysharingoutthesystemin mod-ulesand des ribing relationships amongthem. Designand odingare

related: they arealways performedina y li way

•

Coding produ es a system des ription available and exe utable by omputer, utilizes dierent environment and development languages

(IDE). It is important to remember that the ode produ es value for

the ustomer

•

Testing veries the orre tness of developed modules by unit tests (whi h verify the fun tioning of ea h system omponents), fun tional

tests(whi h verifythefun tioning ofthewhole systemsimulating

a - esses),a eptan etestsspe ied bythe lient

•

Evolution onsists in system maintenan e ( orre tive, adaptive and perfe tive)

Thisshortdes riptionof mainsoftwaredevelopment pro essphases itis

useful to understand that it is absolutely ne essarya well organized model

to perform all the a tivitiesand toprodu e a good-qualitysoftware.

For this studyit isinteresting to keep inmind twomain models on erning

softwarelife y le:

•

Waterfallappeareadinliteratureinthe'50sbut hadalargediusion sin e '70s. It is the traditional software development model where a

phase starts when the previous one ends. There are spe i

respon-sibilities for ea h artifa t, roles are predened and ommuni ation is

basedondo uments ex hange.

Waterfall is often riti ized be ause of its stri t division inphases; in

thatmanner itishard and expensivere eivingnew requirements, but

it an be very useful when requirements are omprehensible and well

establishedsin e thebeginning

Figure1.1: Waterfall model

•

Agile methodologies (AM) onsist in a parti ular approa h to soft-waredevelopment. Agoodwaytodesr ribeAMisby omparingthem

withtraditional software development models; infa t, AM are

adap-tive and not predi tive, oriented toward the people and not toward

the pro ess, kept simple to be able to qui kly rea t, in remental and

intera tive with very short itera tions, based on testing and not on

proje tanalysis,requirementsareverbal,developersplay

inter hange-able roles, analysis and proje t are done in an informal way and not

utilizing formal diagrams, the do umentation is maintained minimal

apartfrom the ode, teammembers share important values.

All these aspe ts suggest that the pro ess is very simple but it must

be done with strong dis ipline. There are dierent approa hes within

AM;theydepend onthe nalgoal,team resour es and needs:

 SCRUMis suited for small o-lo ated teams

laborative, andlearn y les

 Agile Proje t Management (APM) is a spe i framework

broken down into ve phases

 CrystalMethodsaresuitedfor small o-lo atedteamsworking

onnot life- riti al systems

 Lean Software Development is summarized by seven

prin i-plesto followa ordingto setting andresour es

 Feature Driven Development (FDD) onsists in a mass of

industry-re ognized and lient-valued best pra ti es entred on

fun tionality

 Dynami SystemsDevelopmentMethod(DSDM)isa

frame-work utilizing ontinuous user involvement inan iterative

devel-opment and in remental approa h

AgileManifesto[5℄ isado ument writtenbymanyauthorspersonally

involved inAgilemethodologies improvement; theynamed themselves

AgileAllian e tounderlinetheir groupthinkaspe tandtheir

indepen-dent thought.

Agile Allian e xedsome relevant values to better explain theiraim:

 Individualsand intera tions overpro esses and tools

 Workingsoftwareover omprehensive do umentation

 Customer ollaboration over ontra t negotiation

 Respondingto hange over following a plan

Thewholeteamofauthorswasmovedbysomespe i ideasandmain

themes,astherightwaytoapproa htoAgilemethodologiesingeneral,

howtoinvolveandtakealwaysintoa ount ustomer'sopinion,

adapt-ing software development to new requirements, releasing frequently

software, involvingdierentskilledpeopleinthedevelopment pro ess,

the seventeen authors involved inAgileManifesto writing be ause,as

they asserted: "A set of values based on trust and respe t for ea h

other and promoting organizational models based on people,

ollabora-tion,andbuilding thetypesof organizational ommunities inwhi hwe

would wantto work".

1.3 Dis-lo ated versus o-lo ated team: how

om-muni ating

In this short des ription about software development approa hes and

methodologies itisevident that ommuni ationplays afundamental roleat

alllevels: amongdevelopers,among thedevelopment team,among

develop-ersand users... As thepi tureabove suggests. In fa t, development phases

arevarious asfarasparti ipating rolestoo.

Figure 1.2: Communi ation insoftwaredevelopment teams

Watzlawi k [6℄ asserted that "one annot not ommuni ate" but it is

lear thatsometimes ommuni ating ouldbevery di ult; infa t,talking

about software development teams, Be k [7℄ said "What matters most in

software development is ommuni ation", underlining the di ulty to nd

anappropriatewaytoshareskillsandknowledgethatallowanee tiveand

e ient software development pro ess. At the same time there are some

displa ement. So,although everyapproa h to software development hasits

pe uliarwaysto ommuni ate(formalversusinformalorboth),

ommuni a-tiondependsalso onemployed tools and,obviously,itwill bevery dierent

ina o-lo ated development withrespe tto adis-lo atedone.

Traditionalsoftwaredevelopmentteamsaredisposedonlytoformal

ommu-ni ation: ea h ommuni ationalex hangehastobedo umented,ea hphase

has its own written and established do umentation, meetings have to be

plannedinadvan e.... Itis lear that, be ause ofthis pe uliarorganization,

thesetraditionalteams ouldnot workinadis-lo atedmanner,infa t, itis

verydi ult ndingappropriatetools tokeep a formal ommuni ation ata

distan e.

Instead,AM preferinformal ways of ommuni ating be ausethey aremore

agile andfriendly. So fa e-to-fa e ommuni ation inthese teamsisthebest

asfar asinformal meeting (like stand-up-meeting) in ase itis ne essaryto

inform and make a de ision for the whole team. In AM ambit there are

someteamsworkinginadis-lo atedmanner(forOpenSour eseeChap. 2).

Theyprefer their proper ommuni ational methods mediated bye-mail

ex- hange, instant messaging, informal meeting, hat, forum, mailing list and

wiki. Sometimesthismethodsrepla etheonesinpresen e,forexampleteam

members ommuni atinginaforumdoasiftheyaresharing thesame pla e

(thesitting togetherof eXtremeProgramming).

Thisis helpful to understand that ommuni ational strategies are very

im-portant in a software development team and sometimes, as M Luhan [8 ℄

asserted in his famous studies about human intera tion, the good or bad

Open Sour e Communities

Wedidnot alloursoftware

'freesoftware'

Ri hardStallman

2.1 An important phenomenon

Abookisdened lassi alassumingthatittalksaboutuniversalmatters

and questions with whi h the man has always, sin e the beginning of life,

had troubles. Just so, everyone thinks to have these kind of books in his

library. It isthe same when we talkabout Open Sour e(OS) ommunities;

the lassi al arti le, a milestone, in that ase is "The Cathedral and the

Bazaar" by Raymond [9 ℄. He starts omparing two dierent development

styles: athedral modelversusbazaar model,inotherwords ommer ial

ver-susOSworld.

His aimwasto understand the dieren esbetween thetwo approa hesand

whetherthehuge su essof OSproje tswasbasedonmoralmotivations or

not. Hestartsfromtheassumptionthatimportantsoftwareneedstobebuilt

inaserious andwellplanned way,ashand raftsdidfor Gothi athedrals.

The omparison between software odingand thebuilding ofa athedral is

perfe t be ause, in that manner, Raymond underlines not only all the

fa tthat, at the rst glan e,an OSteam ouldbeseen as"a great babbling

bazaar"but,bystudyingitspra ti es andpro esses,itisevidentthata

fun-damentaland entralroleisplayedbythe ommunityandthe orresponding

senseof belonging. Infa t,hefoundthattheseparti ular kindsof

ommuni-tiesarenot movedbymoralmotivations (asself-helpgrouporhumanitarian

organizations, for example) but they gain power from a plurality of people

involvedinthepro ess. Thissenseofbelongingand ooperation atalllevels

permitstotakeadvantageofvarious andenormousdierentskills,aswellas

everyone'sproposalsandsuggestions;soitisasifahuge teamisworkingat

thesameproje tandeveryone'sopinionand"waysofstressingthe program"

isrequested to develop anex ellent software.

This short introdu tion is appropriate to start to understand the vast OS

phenomenon butsome histori al spe i ationswill be better explain it.

2.1.1 The beginning

AtthebeginningofComputerAgetherewasaquitedierent s enarioin

ComputerS ien erespe tnowadays;infa t,therewerenodieren esamong

hardware and software, among users and developers, and using a omputer

wasasortofse retpra ti eexer isedinamysteriouswaybyveryfewpeople.

Therstrevolutioninthisambitwasprodu edbythefallofhardwarepri es:

immediatelyappearedthe ne essityof newrolesand skills.

Thiswasonlythestartingpointofawidediusionof omputersandthehuge

in reasing of the related industry. And, as Weber [10 ℄ asserts, "Suddenly

the ar ane subje ts of operating systems and sour e ode had moved from

the te hni al journals to the front page of The New York Times. And open

sour e be ame a kindof modermday Rors ha h testfor theInternet-enabled

so iety".

OS is a kind of software development model with a parti ular li en e; in

fa t, an interesting way to analyse software produ ts onsistsin omparing

their li en es and distribution, in other words sour e ode availability and

ost. Based onthis denitionthere arefour most diused kindsofsoftware

•

Commer ialisthe proprietary software; sour e ode isnot available

•

Shareware is often free distributed in a version with some limita-tions and thenreleased only after li ensepayment; sour e ode isnot

available

•

Freeware issimilar to shareware li en e, but without its limitations; sour e ode isnot available

•

Open Sour e Software (OSS): an be downloaded from a website and sour e ode is available, permitting modi ations and

improve-ments. There areseveralOSSli ensesdieringforsome pe uliar

har-a teristi slike,for example, ommer ial utilization.

2.1.2 OSS between ethi and te hnology

As asserted in Par. 2.1.1, the revolution of OSS onsists in the great

opportunity of modifying the ode. In fa t a person ould de ide his own

roleinsoftwaredevelopment: he an simplydownload thesoftwarefromits

websiteand utilize it, a ording to hisproper task;thendis overing that it

isla king aparti ular featureand de idingto signalitor personallywriting

the orrespondant ode, it ould also happen to dis over a malfun tioning

inthe systemandsignalit...

Linus Torvalds's [11 ℄ words ould be ertainly useful to better understand

this: "Thisisaprogramforha kersbyaha ker. Ihaveenjoyeddoingit,and

somebodymight enjoylookingatit andevenmodifyingitfortheirownneeds.

Itisstillsmallenough tounderstand, useandmodify, andIamlooking

for-ward toany ommentsyou might have. Iamalso interested in hearingfrom

anybody who has written any of the utilities library fun tions for minix. If

youreorts are freely distributable(under opyright or evenpubli domain),

I would like tohear from you,so I an add them tothe system".

On e Raymond [9 ℄ has oined the term Open Sour e dierent

abbrevia-tionsstartedtoappearfordeningthismethodology: FreeSoftware,Shared

Sour e and FLOSS, probably the most ommon. It stands for Free Libre

Teamworkisdenedbydierentfa tors: teamsize,memberskills,

mem-berroles, intera tions and ommuni ation.

Asfaras ommuni ationis on erned,someresear hstudies[12 ℄havefound

that team members involvement and performan e depend also on the

in-formation provided about what it is asked to do. In some teams, as XP

for example,theimportan e of ommuni ation isself-evidentand itis

well-known thatit an widely hange ina ordan e with team displa ement; in

fa t, ommuni ation is maximized in o-lo ated teams but, sometimes, a

teamhasto workina dislo atedmanner,asinOSteams [13℄[14 ℄.

Communi ationinOS ommunitiesgrowsuparound odesharing: members

parti ipateinthesamesoftwaredevelopmentproje ttoimprovethereleased

produ t. Toa hievethismanypra ti esareadopted,asinformationsharing,

a tiveparti ipation in ommunitylife,bugreporting, informingother

mem-bers about whi h new releases are essential for the su ess of the proje t.

Asthe ode isopen, ommuni ationneeds tobefa ilitated. Teammembers

may oftenbe dispersed worldwide, thus it is essential being able to readily

ommuni ate withone another.

InOS ommunitiesea hinvolvedpersonplaysanimportantrole,also

onsid-eringthat ommunitymembersarebasi allyvolunteers,ea ha omplishing

adierent task.

2.2.1 Stru ture and roles

Ea h OS proje t is dierent and hasits own pe uliarities; in fa t, open

approa h to development allows everyone to organize his own work as he

prefers.

Ontheotherhand, ertaingroupsofpeoplearealwayspartofa ommunity,

onstitutingthebase aroundwhi h theproje t growsup:

•

Usersuse the softwarebut do not a tually parti ipate inits develop-ment. Someof themtakepartinthe ommunitybyposting questions

to theproje tforum orto themailing list

a -opers usingthe proper ommuni ational tools

•

BugFixersaremainlyuserswhodete t andreportanykindoferrors or bugsinthe software

•

Developerswrite the odeand arethemain sour e ofknowledgefor other people in the ommunity. In most ommunities, developers do

nothavethesameresponsibilitiesandauthority,be ausesomeofthem

have beenworkingontheproje tsin etheoutset;theyare alled ore

developers, and have a ess to the sour e ode repository (they an

ommitthe ode)

•

Managersareoftenproje tfounders,asearlydevelopersbe ome man-agersastheproje tgrowsinsizeandimportan e;theyareresponsible

for organizational aspe ts, like release management and developers'

work oordination.

2.2.2 Communi ation in OS: value and tools

In an online ommunity, intera tion among members enables them to

learn throughknowledgesharing, asAgile Manifesto[5℄ de lares

"Individu-als and intera tions over pro esses and tools" and "Customer ollaboration

over ontra t negotiation".

OS ommunitiesareaparti ularkindofonline ommunity,wheredevelopers

dis usstheproblems theyen ounterinimplementingaparti ular featureor

xing anastybug,and theusers ask advi eonhow tosolveanydi ulties

they omea rosswhenusingthesoftware,oralerttheothermembersabout

errors and bugs. In thelatter ase, there are dierent tools for fa ilitating

on line ommuni ation su h as hats, instant messenger, forum, wiki and

mailing lists.

A further toolis alsooften used: thedevelopers mailing list. It is usedlike

a(virtual)spa einwhi hdevelopers anex hange ideasandshare

informa-tionabout proje tdevelopment. Infa t, knowledgesharing and freea ess

part in a development ommunity. In this sense, an OS ommunity may

appear quite similar to a development team working in a ommer ial

soft-ware house, but the main dieren e lies inthe fa t thatusers also a tively

parti ipatein the ommunity: OSphilosophy is basedon ode sharing and

improvement,soea hpra ti ewhi h anhelptoa hievethisgoaliswel ome.

Every OS ommunity is organizedaround its parti ular virtual spa e often

onsistingof a dis ussion forum, a wiki and several other tools to fa ilitate

ommuni ationamongteammembers;thesetoolsareimportantinstruments

to keep togetherthe ommunityand helptheproje tto rea h su ess.

2.3 State of the art

Apart from an enormous number of resear hes about te hnologi al

as-pe ts in OS ommunities, there is also a proli strand on erning their

ommuni ation. In fa t, understanding ommuni ational pro ess is a good

method to try to improve e ien y, produ tivity, ohesion and mind-group

ofthis parti ular kind ofteams.

A short synthesis of some of these works is helpful in drawing the a tual

s enarioof OS ommunities.

It is known that the ommunity is the fundamental unit around whi h the

teamgrows up;motivation isone of these growing fa torsasYe and all

un-derlined[15℄ studying theimportan e of motivation for parti ipating inOS

ommunities and for be omingpart of a su essfulOSS proje ts Basingon

peripheral parti ipation theory of Lave and Wenger [16 ℄ they found that in

these ommunitieslearningpro essexer isesaprominentrole,thankstothe

o-evolution between software development and peripheral parti ipation to

ommuni ation. Infa t,for ommunitymembersitisne essary

ommuni at-ingea hday,improvingtheirlevelofknowledgeonthedevelopmentpro ess

and the relationships among themselves; in that manner "users turned

de-velopers, forminga ommunityofpra ti e",androletransformationhasjust

started. Peripheralmembersspendtheirso ialandpsy hologi alsupportto

role be oming "sour es of the evolution of the system",thanks to

appropri-ate ontributions, and entral members "have a larger radius of inuen e".

This anbeeasyexplainedwithtwophilosophi al on epts: ontogenesis and

phylogeny. Infa t, naivemembers startedtoparti ipateat OSS ommunity

to solve their problemsrelated to software utilization and,on eunderstood

how the system works, "knowing in a tion" [18 ℄ they rea h a more entral

position. Thereisa o-evolutionpro ess: the naive membersbe ameskilled

and entral members ofa ommunity,whi h iswell organized thanksto the

ontribution of its members (that at the starting point were naive

mem-bers...).

Ragab et al. o upied also of members parti ipation in a study on

mem-bers proa tivity among the ommunity [19℄. They analyzed ommunities

as networks, nding that ea h a tor is part of a de ision pro ess to

"join-leave the ommunity network by reating-destroying its logi al links with its

neighbor's members based on its user's preferen es". Ea h member's

ontri-bution plays a bilateral role, improving both the development pro ess and

ommuni ationale a y,andsub-sequentiallyimproving satisfa tionofthe

whole team. In fa t, the network performed by members allows to qui kly

pass information only on e among the ommunity, avoiding redundan ies,

de reasing the tra among nodes and improving members' satisfa tion.

Other studies [20 ℄ analyze ommuni ation ow in spe i OSS

ommuni-ties: every message posted in a dis ussion pla e (spe i web page, forum,

wiki..) is onsidered an artifa t; in fa t, these messages (or e-mails) are

helpful to oordinate proje t-spe i development a tivities, negotiate and

revise relations, emerging as "boundary obje ts" [21℄ that allow to express

softwarerequirementsanddesign. S a hi[22 ℄denesthispro ess"software

informalism"be ausethesespe i virtualtoolsletrolesandtheirdynami s

(authority, expertise, ollaboration, leadership, ontrol, oni t)to emerge,

andfa ilitate ommuni ationamongalltheteam,inspiteof itsdis-lo ation

allovertheworld.

ThesamestudiesfoundalsothatOSS anbeinterpretedalsoasa ommunity

ingbugs,requestingsoftwarefeatures,writing ode,parti ipatingtomailing

list,forums andnewsletter,anti ipatingandsolving questionsandtroubles.

Alltheseissuesexplainthe goodorganization ofthese ommunitiesthatare

tidily oordinated by the leadership (in these ommunities theleader is

al-ways a developer, a modulemaintainer or arelease manager): theonlyrole

formalized here.

Ingeneral,leadershipemergesintwoways: intheeld,givingte hni al and

so ialsupporttoothers,implementingnewideas,managingproje tissues,or

a eptingthenominationdonebyothers: "tobe ertain,though,roles donot

imply authority, but instead responsibility. Authority in the Netbeans

om-munity is based more so on reputation and respe t. This authority ontrols

manpower (what tasks get done), ommunity infrastru ture (how members

intera t), information availability and transparen y, and representation in

(and transparen y of)de ision-making".

Communi ational and oordination aspe ts,asleadership [23℄ and ohesion

[24℄, are widely studied in OSS ommunities be ause they are extremely

important to build a good and ollaborative team with a strong sense of

belonging. In general sharing the ode allows to share also resour es, to

learnnewte hniques,developnewskillsandsolveproblemsimprovingteam

ohesionand itslater e ien y, thanksto "a sense of ommon knowledge".

This ohesionand widespread ommuni ation allow to ope with problems

ina spe i (virtual) pla e where all themembers an and are en ouraged

to parti ipate, in reasing "individual responsibility and self-worth regarding

MAD Proje t

Sin e now thedis ussion was in- entered on theimportan e of

ommu-ni ation in software development teams. In fa t, as previously asserted,

knowing ommuni ational aspe ts ishelpful to getbetter software

develop-ment pro ess.

Thewordmodel omesfromtheLatinmodulus,whi hindi atesthemodelof

abuildingmadebyar hite tstodemonstrate to the ommitmentthefuture

work: something smallstanding for something bigger.

Amodel an also be builtina metaphori almanner,asthis thesis

on ern-ingOSS ommunities wouldlike to be. Infa t, beforepassing to aresear h

studyonlarges ale(seeChap.5andChap.7)itwas onsideredbetterto

a - uratelyfollowtwo softwaredevelopment proje ts: thersta ademi (using

eXtremeProgramming)andthese ondindustrial(adoptingOSSapproa h).

Thesepro esseswerefollowedsin ethebeginningtohavea ompleteparamount

ofallkindsof ommuni ationhappeningamongmembersandtoinvestigate

whatlevel ofagility an be brought inadistributed ontext.

Inthis hapterisdis ussedthea ademi asenamedMAD(AgileDistributed

Methodologies) andinthefollowing (see Chap. 4) theindustrial one.

3.1 A tion resear h

Itwaspreviouslyassertedthatthisworkisin- enteredon ommuni ation

Inthis resear h alsothepsy hologist playsa fundamental role infa t,sin e

thestartingphaseoftheproje t,shesharedthespa ewithotherparti ipants

performing ana tion resear h.

This interesting te hnique was formalized by Kurt Lewin [25℄ in 40's, after

theSe ondWorld War. Infa t, USA government asked to him to persuade

Ameri an families to onsume also less pre ious pie es of meat, asoal, to

tryto solvenan ial re ession.

Lewin performed a spe i experiment with the aim to understand whi h

ould be the best strategy to hange food-behaviour. Then he dis overed

that target dire t observation and its involvement, inthis ase housewives,

giveimmediatelyandlastingresults(aftertheexperiment32%ofhousewives

startedto ookoal).

Lewindenedhisapproa has"a omparative resear honthe onditionsand

ee tsofvariousformsofso iala tionandresear hleadingtoso iala tion"

and "a spiral of steps, ea h of whi h is omposed of a ir le of planning,

a tion,and fa t-ndingabout the result of the a tion".

On e formalized, this approa h was adopted in every situation in whi h it

wasimportanttheunderstandingofhumanbehaviourtotrytosolvespe i

problems, adopt new solutions and improve e ien y, as the psy hologist

involvedinthese resear hes (seeChap. 3 andChap. 4) did.

3.2 Using extreme programming in a distributed

team

AgileMethodologies(AM)havebeen proposedasasolutionto problems

resulting from theturbulent businessand te hnology environment fa edby

organizations engaged in software development and have been largely and

su essfulappliedinordertoimprovequalityandtorespondtofast

require-ment hanges. AMembra e ommuni ationasamainvalue,asstatedbythe

AgileManifesto[5 ℄"IndividualsandIntera tionsover Pro esses andTools".

ExtremeProgramming(XP),forexample,supports ommuni ation

fa e-to-pair programmingand informative workspa e. This leads to assert that an

agileapproa hisin ompatiblewithdistributedenvironmentswhere

fa e-to-fa e ommuni ation isinevitably ompromised.

On the other hand, nowadays distributed development models give rise to

great interest. For example, in order to redu e osts and improve time to

market, many ompanieshave turnedto o-shoring andoutsour ing, whi h

imply a strong distributed organization. Another su essful and always

more largely applied distributed model is OS. The great su ess of many

OSproje tsdevelopedbyfree ommunityofdevelopers(seeLinux, Apa he,

KDE, Gnome, et .) has attra ted the attention of many industrial rms,

whi hhave adoptedtheOSpro essasabusinessmodel(seeIBMforLinux,

theE lipseConsortium, et .).

Despite the in ompatibility, some ompanies have started trying to merge

AM and distributed development, in order to preserve as more as possible

theadvantages deriving fromthe two approa hes [26 ℄[27℄ [28℄ [29 ℄.

3.3 Proje t des ription

ThemaingoalofthisstudyistoinvestigatehowtheAgileMethodologies

(AM), witha spe ial fo uson XP, an be applied ina distributed

environ-ment andunderstand whatlevelofXP pra ti esadoption an beapplied in

su ha ontext. Inordertorea hthisgoalitwasestablishedana ademi ase

study. Morepre isely,inthis work it isdes ribed an experien e,performed

at the University of Cagliari, in using XP within a distributed ontext. It

will seekto demonstrate trough empiri al eviden e that XP values an be

supported by multi-site team and it will present how to redesign some XP

pra ti es inorderto t theneedsof asoftwaredistributedteam.

The proje t onsists of two well dened phases, the rst one onsisting of

the development of a kernel set of fun tionalities and the se ond one of a

setof add-on fun tionalities to be plugged on the kernel. The development

of the appli ation kernel has been performed by the ore team, within an

tothe se ondphase. Itwill seektoinvestigate howthevalues andpra ti es

of XP must be modied, removed or tool-supported as therst o-lo ated

teambe omesdis-lo ated.

3.3.1 Training

The rst phase was important to homogenize knowledge and skills, so

team members whom need (almost students) spent three months learning

the fundamental information about ode writing, programming language,

XPapproa hinorder to be ableto parti ipate atdevelopment pro ess.

3.3.2 People and roles

The ase study onsists of the development of an information, ontent

and servi e management portal appli ation for the University of Cagliari.

Theproje tinvolves34dierentlyskilledpeoplefromdierent ba kgrounds.

More pre isely, the team is made up of 14 ore members working as a

o-lo ated group, and 20 undergraduate dislo ated students working

indepen-dently from the ore team. Among the ore members there are two PhDs,

oneofthem playingtheroleof proxy ustomerfor thetea herand

adminis-trative sides,sixPhD studentsandsixundergraduatestudents,oneof them

playing the roleofproxy ustomerfor thestudent side. Also,the oreteam

issupportedbytheworkofapsy hologistparti ipatingobservant,whoplays

a role not ontemplated by the XP methodology. She was alled by others

"The Spy". The Spyhelps team to understand the dynami s of human

in-tera tion, in order to improve the quality of ommuni ation and the sense

of team partnership. Ea h ore team member plays a spe i XP role (See

Table3.1).

3.3.3 Co-lo ated development and XP pra ti es

Thisrstphasewentontwomonths,itismadeupofseveniterationsand

itis going to explain inmore details how themost important XP pra ti es

Ph.D. ProxyCustomer(Tea herandAdministrative Sides),Coa h

Ph.D.Student Tra ker,Tester,Developers(4)

UndergraduateStudent ProxyCustomer(StudentSides), Developers(5)

Psy hologist TheSpy

Table 3.1: Core Team

to be applied in order to make those values expli it [7 ℄, [30℄. This se tion

des ribesthe kernel development, explainingwhi h XP pra ti es have been

adoptedbythe oreteam inorderto reate a ommunitythatembra esXP

values.

•

Communi ationamongteam membersmustbe maximized. Among oremembersthereisastrongemphasisondire t ommuni ation

re-atingasenseofteamandee tive ooperation. The oremembers

ap-ply some XP pra ti es, su h as SitTogether, Informative Workspa e,

Pair Programming, Stories, Weekly Cy le, in order to improve

om-muni ation

•

Simpli ity onsiststodothesimplestthingthat ouldpossiblywork. In the kernel development many XP pra ti es su h as Weekly Cy le,

Stories, Testing and Emerging Design from Coding and Refa toring

areappliedinordertohelpdevelopmentteamtodothesimplestthing

•

Feedba k at dierent time-s ale. Weekly Cy le, Pair Programming, Stand Up Meeting, Real Customer Involvement, Testing allow

pro-grammers to obtain ontinuous feedba kon their work

•

Courage onsistsinnottohavefear. Allmethodologiesandpro esses are tools to handle and redu e the teams' fears. In order to rea h

this goal the ore team is supported by the following pra ti es: Pair

Programming, Testing, SimpleDesignand Refa toring

•

Respe t onsists in not to have King and Queen. The ore team applies SitTogether and Shared Code that help team-members to be

•

Stories: all system fun tionalities were written by two proxy us-tomersandthenestimatedbydevelopersto quantify thedevelopment

eort. Until third Iteration ea h story was onsidered done when its

taskswere ompleted,sin efourthIterationitwasdoneonlyifitstasks

weredone anditsa eptan etestswerepassed. Thisisanexample of

the methodology evolution

•

Informative Workspa e: inorder to tra kthe proje tevolution, it wasde idedto useboth anautomatedtool[31℄and abla kboard (see

Fig. 3.1). The developers usually hang thestories on thebla kboard.

Itismadeupofthreedierentparts: "todo","inprogress"and"done"

whereare olle tedtheuserstoriesdependingonthestatus. Thistool

allowed the developers to know at any time the proje t evolution in

detail.

Figure3.1: Storieson bla kboard

•

Pair Programming : during the rst phase of the proje t, the soft-warewasdevelopedinpairprogramming. TheExtreme Programming

[30 ℄suggeststhatpairsshouldrotatefrequently. Itwasnotedthatthe

pairsdidnot rotate duringwhole development task. At thebeginning

thisbehaviorwas(partially)tolerated,but sin ethese ondhalfofthe

proje t, the team leader imposed the pair members ex hange every

development session. Afteradi ult,initialadjustment period,ithas

afterthefourthiteration the estimation error de reased

Figure3.2: EstimationError

•

Weekly Cy le: the teamworkwasplannedinaweekly y le. Atthe beginning of every week the ore team had a meeting. During these

meetings,the teamleader withproxy ustomerspi ked up thestories

toimplementfortheweek. Thendevelopersbrokethestoriesintotask

and ea h one was able to hoose a story to develop. As said above,

the systemkernel wasdeveloped inpair. So,a developer whohadnot

assignedneithera storyor apair wasable to hooseapair

•

Sit Together: thekernel wasdeveloped inan open spa ebigenough forthewhole oreteam. Thelayout oftheroom(seeFig. 3.3)allowed

the ommuni ation amongdierent pairs

•

In remental Design: this pra ti e is quite di ult to apply and requires developers to have a great amount of experien e. Also it is

simple to misunderstand the meaning of this pra ti e falling into a

no-designbehavior. In thisproje t, itishardlytrying to makedesign

naturallyrisingfrom oding,alwaysdoingthesimplestthingthat ould

possiblywork.

3.3.4 Distributed development and XP pra ti es

Dashboard

Blackboard

TODO

DONE

IN PROGRESS

Figure3.3: Open spa esetting

pra ti es and introdu ing supporting tools. The following se tion explains

howtheadoptedXPpra ti esareae tedbythetransitionfroma o-lo ated

to adistributedenvironment.

•

PairProgramming : whilethispra ti erepresentsapowerfultoolfor supporting ommuni ation and knowledgesharing among team

mem-bers, it strongly needs the o-lo ation of the team. Sin e, as there

are few examples of te hniques to support distributed pair

program-ming [32 ℄, [33℄, it was initially de ided to renoun e in applying this

pra ti e. Then it was tried to use some tools su h as Sobalipse [34 ℄

andSkype [35℄, thatguaranteed a good ommuni ation levelbetween

the two developers of a distributed pair. Sobalipse allows developers

sitting at dierent ma hines to edit and review the same le, and to

ommuni ateusinga hatorbetterusingtheVOIPte hnology. Oneof

the mostimportant featuresof these toolsisthat theyare ompletely

integratedinthedevelopment environment [36 ℄

•

Real Customer Involvement: it is possible to apply this pra ti e alsointhese ondphaseoftheproje tbe ausetherearetwodevelopers

playing the roleof proxy ustomer

•

Sit Together: ina sit together team all developers work in an open spa einorderto maximize ommuni ationamongteam-mates. It

ab-an instant messenger and a mailing list in order to favor a "sense of

team"among distributeddevelopers

•

Informative Workspa e: this pra ti e allows the team to improve the ommuni ation. Inthese ondphaseoftheproje tthis pra ti eis

represented only by XPSwiki. The Fig. 3.4 shows the XPSwiki user

interfa e.

Figure3.4: XPSwiki

•

SharedCode: ea hteammemberisenabledtoa essto aSVN ode repository in order to improve and hange any part of the system at

anytime

•

Continuous Integration: in the se ond phase the ontinuous inte-gration is automated and performed after no more than a ouple of

hours

•

User Stories: the fun tionalities of the system are des ribed using storiesthat arepublishedinthe XPSwiki

•

Weekly Cy le: by using the XPSwiki tool, ea h developer an un-derstandwhi huserstoriesaredone,inprogressortodointheweekly

In some ases, as the resear h just exposed, the task requires a

dier-ent dis-lo ation of the same team and, to understand team dynami s and

emerging roles, it is important to evaluate how hanging ommuni ational

strategiesinthese two dierent modalities.

Inthis studyit wasfoundthat, sin e thestartingphase, more skilled

mem-bers (PhD e PhD students) had a prominent role among the ommunity.

Espe iallyoneofthemusingtoorganizestand-upmeeting,towritetaskand

to do lists on the bla kboard, and keeping an "organizational" behaviour,

wasre ognized byothers as"key member". In fa t othermembers usedto

ask him information and suggestion; hisrole wasalso fundamental when it

wasde ided to for eturning ofpair programming.

Daybyday,thanksalsotothe ommongoal,theteamwasmoreharmonious

and ommuni ation wasmaximed.

When the team moved ina dis-lo ated ontext it was uriousto note that

relationships and roles were not hanged and that team members tryed to

adaptthe provided ommuni ational tools to maintain thesame

ommuni- ation level inthegroup.

3.5 Adopting Agile Methodologies in a distributed

environment: a ase study simulation

On e obtained theseresults it wasde ided to understand how XP

pra -ti eswouldhavetobemodiedinordertoadapttheminadistributed

envi-ronment, trying to demonstrate trough empiri al eviden e howintrodu ing

some supporting tools allowed XP pra ti es to be adopted in a distributed

environment.

In fa t, Agile Methodologies and distributed development are two popular

trendsofsoftwareengineering. Theformerallowstorespondtorequirement

hanges while improving the overall quality of appli ation released. The

benets of the latter are both the redu tion of osts and of development

fe tiveness of agile methodologies in a distributed environment. So it was

performed a quantitative evaluation of theadoption of some agile pra ti es

inan open sour e proje t, arrying out an a ademi ase study witha

dis-tributedteam adopting some XPpra ti es. To evaluate thedieren esand

the analogies among the two methodologies it was adopted a simulation

approa h to understand how the agile development pro ess is ae ted by

the distribution of the team members and how development a tivities are

enhan ed, inuen ed or sometimes misdire ted when developers usethe

In-ternet asmain oordination and ooperation tool.

Thesimulatedproje thasbeen realizedusingasimulator ofanXPpro ess.

Thissimulatorhasbeen alibratedandvalidatedusingdatagatheredduring

therstphase ofthe real proje t.

3.5.1 Method

Thisresear h follows ve mainsteps:

1. Colle tionof metri s during the o-lo ated phase

2. Calibrationandvalidation oftheXPsimulator usingdatagatheredin

stepone

3. Simulation ofthe proje tasifithad beenperformedfollowing theXP

o-lo ated methodology

4. Colle tionof metri s during the dis-lo ated phase

5. Evaluation of the dieren es between the real and simulated proje t

in terms of ode produ tivity, rate of released fun tionalities (User

Stories) and other metri s that will be explained in more details in

se tion3.5.2.

3.5.2 Metri s

In order to ompare the real and the simulated proje t there were

proa h. Inparti ular, ontextmetri sareusedto hara terizethedistributed

and o-lo ated teams and ee tiveness metri s to quantify dieren es and

analogiesbetweenthetwomethodologies. Among ontextmetri sthe

atten-tionwasfo usedonTeamSize (NumberofTeamMembers),TeamEdu ation

Level (Number of PhDs, Undergraduates) and Team Skill (Domain

Exper-tizeandLanguageExpertize). Theee tivenessmetri sin ludebothpro ess

andprodu tmetri s. Pro ess Metri shave been extra ted fromXPSwiki, a

webbasedXPproje tmanagementtoolusedformanagingrequirements,for

planningandtra kinga tivities. Thetool analsobeusedtoextra tmetri s

su h as numberof stories, numberof tasks perstory,estimated and a tual

eortforea hstoryandtask,teamvelo ity,releaseanditeration lengthand

soon.

Theprodu tmetri sgatheredin lude proje t, lassandmethodmetri s.

Theproje t metri s are: NumberofClasses, Numberof Methods andTotal

LinesofCode. The lassmetri sin lude: Numberofmethods,Linesof ode.

Finallymethodmetri saretheLinesofCodeofea hmethod. Thesemetri s

have been extra ted from Subversion [37 ℄, the version ontrol system that

hasbeenadoptedinthis asestudy. Subversioneasilyallowstoexaminethe

evolutionofthe sour e ode, apturing snapshotsoftheproje tsour e ode

atanytimeinstant. Inparti ularitwasanalyzedthesour e odesnapshots

at the end of ea hiteration, using a systemthatis ableto parse thesour e

odeand extra tthe desiredmetri s.

3.5.3 Calibration and validation

AgilegroupofUniversityofCagliarihasdevelopedanXPsimulatorthat

allows to fore ast theevolution ofan XP proje t implementing someof the

mostsigni antXP pra ti es(PairProgramming, TDD,Planning Game...),

anditisabletovarytheadoption levelofsomeofthem. Thissimulatorhas

been used to study how the MAD proje t would be evolved if it had been

performedfollowingthe XPtraditionalmethodology. Theinputparameters

and the output variables that an be obtained from the simulation model

NumberofinitialUSs NumberofnalUSs

Numberofdevelopers Defe t density

MeanandstandarddeviationofinitialUSsestimation NumberofClasses,methods,DSIs

InitialTeamvelo ity(pts/iteration)

NumberofIterationsperRelease

Typi aliterationduration Ea hmodelledentity

Table3.2: Input parameters and outputvariablesof themodel

Data used to alibrate and validate thesimulator oming from the rst

release ofthe proje t. During this releasethe systemkernel wasdeveloped.

The alibrationofthemodelparametershasbeenperformedusingdatafrom

thefthiteration,su hasthenumberofdevelopers,thenumberofuserstory

andsoon (see table3.3).

Input parameters Values

NumberofinitialUSs 30

Numberofdevelopers 14

MeanandstandarddeviationofinitialUSsestimation(pts) 265(220)

InitialTeamvelo ity(pts/iteration) 810

Typi aliterationduration(days) 5

Table 3.3: Input parameters to alibrate themodel

With these input parameters a number of simulation runs have been

performed. Inparti ular,itwasiteratively alibrated themodelparameters

inordertobetterttherealdataoftheproje t. Intable3.4 1

thesimulation

outputare ompared withthe ones taken fromthis ase study.

Then, a model validation has been done using data gathered from the

sixthiteration of the real proje t. In detail, it was hanged only theinitial

number of stories developed (35), while it was maintained un hanged the

modeland proje t parameters obtained during the alibrationof themodel

1

Comparisonbetweensimulationresultsaveragedon100runsand asestudy.Standard

TotaldaysofDevelopment 36.9(8.1) 36

NumberofUserStories 38.2(4.3) 39

EstimatedEort[Storypoints℄ 13697.6(5191.1) 13252

A tualEort[Storypoints℄ 17902.4(4206.3) 18443

DevelopedClasses 77.2(19.2) 80

DevelopedMethods 407.4(100.7) 400

LOCs 3259.7(805.2) 3260

Table3.4: Calibration ofthemodel parameters onthe fthiteration

(see table 3.5 2

). It was de ided to hoose data from these two iterations

be ause it was noted empiri ally that they were more signi ant than the

previousones be ause the methodology wasnot ompletely tuned.

Outputvariable Simulation Real Proje t

TotaldaysofDevelopment 42.5(9.5) 41

NumberofUserStories 45.3(5.2) 44

EstimatedEort[Storypoints℄ 15680.7(5182.5) 15442

A tualEort[Storypoints℄ 21369.8(5337.2) 21570

DevelopedClasses 92.1(25.4) 91

DevelopedMethods 488.0(134.3) 451

LOCs 3904.0(1075.2) 3951

Table3.5: Validationof themodelparameters on thesixthiteration

It isinteresting to notethatthe number ofuserstories developedat the

endofthe fth/sixthiteration(seetable3.4/3.5)isgreater thanthenumber

of initial user stories set as input parameter. In fa t, the initial user story

ouldbesplitor new userstory ouldbe added during thedevelopment.

3.5.4 Simulatingthe XP o-lo ated pro ess

After alibrationandvalidationofthesimulationmodelitwassimulated

the o-lo atedproje t. Therewereperformed100runsusingtheuserstories

2

of the whole proje t. In table 3.6 mean and standard deviation of the

simulator outputvariables arereported.

3

TotaldaysofDevelopment 163.9(20.9)

NumberofUserStories 196.0(11.1)

EstimatedEort[Storypoints℄ 69291.5(19009.5)

A tualEort[Storypoints℄ 93109.1(11198.2)

DevelopedClasses 471.7(76.5)

DevelopedMethods 2492.9(405.1)

LOCs 19940.8(3239.3)

Table 3.6: Simulation results ofthewholeproje t

Itwasfoundthatthereisabigdieren eamongtheresultsobtained

dur-ingthe real development and thesimulated approa h,so thesame

method-ology was applied to Apa he HTTP Server to evaluate the ee ts of TDD

(Test Driven Development) [38℄ but this is another resear h study with a

Polaris4OS proje t

MAD proje t (see Chap. 3) was performed with parti ular attention to

ommuni ationalpra ti es,inordertounderstandhowthey an hangeand

evolve a ordingto web te hnologies.

Apartfrom universitysta (PhDstudents andPhD), people involved were

almost students at their rst software development experien e. So it was

de ided to perform another proje t ofthis kind involving adierent target:

professional developers. This proje t involves University of Cagliari and

Polaris (a te hnologi al and s ienti park) with the aim to promote OSS

adoption intheirarea.

In fa t, FLOSS adoption in Small Medium Enterprises SMEs introdu es

some non-trivial drawba ks. For business men and hief te hnology o er

(CTO),FLOSS is riti alsin e thereare not asestudiesand deep analysis

about it, making themlost inahuge olle tionof untrustedreports.

Ontheother side,itisper eived byproje tmanagersasa riti alresour e,

for whi h they have nobody toblame for malfun tioning or troubles.

Finally, developers onsider FLOSS as a synonymous of "Save as..."

om-mandin their browser: FLOSS is the heapest way to a ess example ode

andgetready-to-runlibrariesandappli ations. Bothbusinessandte hni al

people miss most potential opportunities oered by FLOSS,like knowledge

sharing, ollaborative software improvement, large feedba k basis,

ommu-nitysupport.

onsid-learning path represented by universities, s hools and erti ation enters.

A new approa h at learning program is needed to take advantages of the

FLOSS e osystem,as onsumerand produ era tor.

This work mainly fo uses on an "open sour e urri ulum" dened and

ap-plied inthePolaris4OS proje t. Itenables developers to ee tively work in

theFLOSSworldanden ourages hiefexe utiveo ers(CEOs)to take

ad-vantage of these opportunities: itimplies new learning methodologies, new

skills to supersede losed and proprietary approa hes, newbusiness models

to optimize ompanyresour es.

Thepsy hologist parti ipates also inthis resear h not only playing therole

ofa tion resear her, but also doingtutor pro ess mediator, monitoring

on-tinuouslyparti ipants' a tivitiesand their ommuni ational ex hanges.

4.1 Polaris4OS

The main goal of the Polaris4OS proje t is to ll the gap between well

establishedproprietaryenterprisepro essesandtheup omingFLOSSmodel,

basedon ollaboration andknowledgesharing.

Elevenlo ally-based smalland mediumITfo usedenterprises(SMEs) were

involved in design and development of extension modules for existing open

sour eframeworks. Theyhadbeen sele teda ordingto themissionofea h

ompanyandtheirmarket. Polaris4OS onsistsofapreliminaryset-upphase

andthreeexe utivephases: thetrainingbasedonablendedlearningmodel,

the ollaborative design andthe open sour e distributeddevelopment.

4.1.1 Choosing a suitable Open Sour e proje t

During the preliminaryphase, ompanies wereinvited to evaluate

exist-ing state-of-the-art open sour e proje ts, and were asked to sele t proje ts

to ontribute to.

TheyidentiedanEnterpriseResour ePlanning(ERP)andaContent

Man-agementSystem(CMS),whi hwere onsideredasstrategi solutionsfortheir

both ustom solutions and o-the-shelf appli ations. Moreover, they were

ompetitors in the same geographi area and they never ooperated. They

had dierent experien es with amixed ba kground of Java and .NET

envi-ronments, and ea h had its own software engineering methodology, usually

basedon pra ti eand not ona formalapproa h.

Preliminarymeetingslettoset-upatrustedenvironmentinwhi h ompanies

agreed to share their experien e, knowledge, resour e, ode anddevelopers.

The mentors identied the skillsand themain ompeten e areas neededto

parti ipate to sele ted proje ts. The key te hnologies were deemed to be

obje torientedprogramming, integrateddevelopment environments,

ollab-orativeutilities,versioning systems;themostimportantmethodologieswere

onsidered to be design patterns, test driven development, ontinuous

inte-gration;thekeypro essesweredeemedtobe ollaborativeworkandfrequent

iterations.

Theproje teortwasestablishedintwoman-daysaweekper ompany,for

atimespan ofnine months.

4.1.2 People and roles

There aredierent roles involved inthis proje t, as it is possible to see

Mentor Theyidentifytheskillsandthemain ompeten eareasneeded

to parti ipate to sele ted proje ts and organizemeetings with

the ompaniestodesignandplanallthephases

5

CEO Theyare ompetitorsinthesamegeographi areaandtheyhave

never ooperatedbefore

11

Developer Theyareemployeesoftheinvolved ompanies 18

Customer They play the roleof real ustomerinorder toa hievebetter

resultstonaluser

2

Tea her They learn fundamental on epts related to software

develop-ment

12

Coa hes Theyare skilledpeopletryingtohelp developersandfa ilitate

developmentphase

2

Tutor She fa ilitates ommuni ational pro ess among parti ipants

bothinpresen eandinblendedmodality

1

Table 4.1: Dierent Roles

Allthesedierentskilledandmotivatedpeople omposethedevelopment

teamand worked together.

4.1.3 Training

Sin e the initial developers skills were very dierent, it was de ided to

adoptaexiblelearningmethodtosupportatrainingpro ess,mixing

lass-roomlessonand laboratorya tivities,on-linetrainingand support,

ollabo-rative learningamong learners, oa hingand tutoring[39 ℄.

Learning model answering to these ne essities is the blended learning one

(BLM) [40℄ [41℄. It was supported by Moodle [42 ℄ learning management

system (LMS) and by the ollaborative knowledge base, realized with the

learningobje ts publishedbytea hers.

Thisresear h model onsistsof threemain learningmoments:

•

Collaborative learning is based on spe i and pra ti al a tivities duringfrontal lesson

•

Consolidation: developers ame ba k in lassroom to demonstrate the a hievement ofthe administered on epts

The BLMwasrealized in:

•

4hours of lassroomfrontal lessons

•

8 hours for individual study, ollaboration, exer ises based on the learning obje tprepared by tea hers and having thesupport of

tu-torsand oa hes

•

4hours for lassroomknowledge and apabilities assessment

The LBSmonitored developers a tivities, asthetime spent byea hone

onitandthe resultofon-linetests,for example. Fromtheir analysis,itwas

denedatrainingpro esstailoredonindividualne essities, reatingasortof

learning ustomization;itwasalsonoti edthatthedevelopersspontaneously

reatea ommunitywherepeoplehelpedea hotherandsharedmaterialsand

information [43℄.

The ommunity reated intherstphaserepresents animportantresultfor

theproje tbe auseitshowedthattheinitialformersdiden ewasover ame

sin e the startingphase.

4.1.4 Designing

Insu h phase,there wereanalyzedthe sele tedFLOSS proje ts andthe

denitionoftwospe i appli ations enarios. Tohavetheexe utionphases

likearealproje t,itwasde idedtohavereal ustomersthereforetherewere

sele tedthelo aladministrationofPula,inSardinia, andaprivatebreeding

ompany.

Meetingsweretakentoknow ustomerneedsandthesoftwareandhardware

solutionthey used.

It emerged the interest of the rst ustomer for a tourist event alert

sys-tem,while these ond onewouldlike anautomati tra ingsystemofanimal

growthfor a pigsfarm.

[45℄theERPto extendandmodifyinwaytoimplement thetra ingsystem.

On esele tedthesoftware,developerteamworkedto denethetasksand a

preliminaryTO-DOlist.

Ea h item list was assigned to a developer. Design a tivities were mainly

ondu ted remotely by means of hats, web forum and mails, with weekly

intera tions for requirement denition, tasksidenti ation andassignment.

4.1.5 Module Development

Developers implemented the extension modules driving their a tivities

with on epts learned in the rst phases and using the results of the

de-sign pro ess. The development model was based on ontinuous integration

and frequent releases in order to verify the orre tness of the implemented

software and the referential integrity of therequired hanges respe t to the

originaldatabases stru ture.

During weekly meetings, the en ountered problems had been analyzedand

the possible solutions dis ussed by all developers for the adoption of the

best hoi e. In su h meetings, oa hes and tutors applied a

learning-by-doingmodel[46℄ inway to addressthe developers la ksraised inthe ourse

ofthis phase.

Asetofproblemswasrelatedtotheinexperien eofthedevelopmentFLOSS

model,likethe remoteanddistributed ollaborationmodelandthe

possibil-ityof reusingthe sour e odeand thedatabasesof thesele tedsoftware.

For both of modules, the rst development task was the installation of

theoriginal softwareand set-up of theintegrated development environment

(IDE).Therewerenotavailableautomati allypro eduresfortheinstallation

thenthe developerexe uted inseparately steps theDBMSinstallation, the

database reation, theCompiereor Infoglueinstallation and the onne tion

between databaseand these software.

RegardingtotheIDE,the sele tedonewasE lipse[47℄. Thefollowing tasks

were tailored on the module. The alert system for Infoglue required the

mapping of thenew tableson the databasesstru ture using Hibernate,the

Figure4.1: Theweb page where to insertmessages

4.1.6 Companies parti ipation

Companies involved in Polaris4OS ome from dierent IT market areas

andtheyhave dierentsize. Mostofthemarefo usedonservi esforPubli

Administration, whileothersworkintheInternet ontext,withwebservi es

andappli ation,mobilesolutions,digitaltelevisionandprofessionaltraining.

Average teamsize is 3-4developers for ea h ompany.

Before starting the proje t, ea h ompany presented itself to other

parti -ipants, in order to better identify resour es provided to the proje t and

expe ted results. Te hni al team had experien e in database engines,

ob-je t oriented programming language and some web framework experien e.

Therefore,therewasnotanhomogeneous expertisenorsimilar obje tivefor

those ompanies. Most important, there were no previous experien e with

OSproje ts.

CTOshavebeenintrodu edto FLOSSe osystems,inordertoprovide them

withall elements to de ide what te hnology to adopt and what kind of OS

proje t to work for. They have been preliminarily introdu ed to FLOSS

li- enses,theirs ope,theirlimitsandtheiradoptiona rossleadingOSproje ts.

Companies have been en ouraged to parti ipate Polaris4OS be ause they

wouldper eive thetraining phaseasavaluable benet for theirteam: they

and they onsidered it too short to a hieve a relevant produ t but, on the

otherside,they wereunable to assignmore resour esto theproje t.

4.2 Curri ula

An important and none evident aspe t of the Polaris4OS proje t was

the denition of developers urri ula. Tea hers, tutors and oa hes guided

their a tionsin thedesigning and development phases inway to t it. The

urri ula denition started with the training phase and it was adapted to

a hieve four main goals:

•

Alldevelopershad to work ontheproje t

•

Alldevelopershad to usethe sele ted te hnologies

•

Collaborative approa hto all proje t a tivities

•

Build a developers shared knowledge, pra ti es and learning ommu-nityfor all thefollowing proje tphases

It wasalsodened alistoffundamental ompeten esforthe urri ulum

andgrouped them infour ategories:

•

Informationseminar

•

Softwareengineering methodologies

•

Useoftools and IDE(Java,E lipse, Sour eForge...)

•

Featuresand onstraintsofthetwosele tedopensour eproje ts(lo al administrationversus tra kingsystem)

Dening urri ula wasbasedonwhat an be usedto design oursesand

urri ula on erningAgiledevelopment [13℄.

4.2.1 Dening Curri ula