The Role of Architecture in

Open Source Software
Projects
Marja Aalto, Hoang Long & Jukka Pekkala

Abstract
1. Introduction
2. Background
2.1 Software architecture
2.2 Quality attributes in software architecture
2.3 Open source software projects and communities
3. Modularity in OSS
3.1 Parallel development
3.1 Division of work
4. Evolution of OSS systems
4.1 Success factors
4.1.1 Software maintenance
4.1.2 Architecture repair
4.1.3 Evolvability
4.2 Evolution patterns of open­source software systems
5. Social structure and architecture
5.1 Developer roles and specialization
5.2 Reflection of social structure in software architecture
6. Conclusions
References

1
Abstract
The  relationship between  an  open­source  community  and  the  software  architecture  affect  each
other.  We  did  a  literature review  on how  this  relationship  works  in  open­source  projects  as  the
project  evolves.  We   found  out  that  modularity  is  the  most  important  thing  about  software
architectures  in   OSSD.  The  community  organizes  itself  to  support  a  modular   software
architecture  by  creating sub­communities  around  modules  and  by  having  developers specialize
in  different  parts  of  the  architecture.  The  modularization   enables  parallel  development,
superlinear growth and lower contribution barriers for newcomers.

2
1. Introduction

Architectural  knowledge  tends  to  become  embedded   in  the  structure  and  procedures  of
established  organizations  (Henderson  &  Clark,  1990).  Because  an  open­source  community  is
one  kind   of  organization,  this  phenomenon  applies  to  them  as  well  even  though  the  structure
often  is  latent  in  OSSD  (Bird  et  al.,  2008).  This  paper  consequently  studied  the  evolving
relationship  between  an  open­source  community  and  the  architecture  of  the  software  that  they
are  developing,  i.e.  the  interplay  between  the  community  and  the  architecture as they constrain,
enable,  or  otherwise affect each other during the project’s life­time. A better understanding of this
relationship  allows  open­source  leaders  to  align  the  architecture  and  community  in  a  way  that
facilitates the successful evolution of their project.

An  OSS  project  is  usually  initiated  by  a  key  developer  who  wants  to  fork  a  project  related  to
some  issue  that  interests  him  and  he  is  usually  the  project  leader  who  is  responsible  for  the
vision  and  the  overall  direction  of  the  project.  Because  the  source  code  is  free  and  can  be
developed  and  distributed  freely,  there  are  other  developers  all  over the globe who may become
interested  and  involved  in the  project.  They  become collaborative developers who form the OSS
community   around  the  system  and  they  have  different  roles  depending  on  their  interest  and
active  participation  in  the  project.  Their  contribution   is  optional  and  therefore  they  can  choose
freely  their  level  of  participation  as  opposed  to  commercial  projects  where  someone  assigns
them  a  task.  The  structure of the community around the project then depends on the roles of the
people  in  the  project.  Changes  in  the  roles  and  the  software  result  in  natural  product  evolution,
which  is  in  contrast  to  well­planned  evolution  that  is  usually   the  case  in  commercial  projects.
(Nakakoji et al., 2002.)

We   define  our  research  question  as:  “What  is  the  relationship  between  an  Open  Source
Software  Development   (OSSD)  community  and  the  software  architecture  as  they  both
evolve?”.   The  research  question  presumes  that  there   is  an  open­source  community  that  is
responsible  for  the  architecture  and  the  evolution  of  the  system  they  develop.  Because  the
nature   of  an  OSS  project  is  collaborative  but  distributed,  there  are  a  lot  of  challenges  in
managing  the  evolution  in  two respects – both in architectural as well as in community respects.
The research method for this study is a literature review.

We   found  out  that  modularity  is  an  essential  feature   of  an  open­source  project.  The  social
structure  organizes  itself  to  support  the  modular  software   architecture  by  creating
sub­communities  around  different  modules  and having developers specialize in different parts of
the  architecture.  The  high  modularization  also  allows  developers  to  work  in  parallel  and  the
project  is  able  to  grow  at  a  rate  that  is  higher  than  linear  growth. Different  modules  also  have
different  contribution  barriers for newcomers and this can be turned to advantage to recruit more

3
developers.

The  structure  of the study is as follows. The first part is the introduction to the study. The second

part  is  about  the  background  containing  general  information  about  software  architecture,  quality
attributes  and  OSS  communities.  The  third  part  concentrates   on  the  modularity  in  OSS.  Next,
the  fourth  part  is  about  evolution  in  OSS  systems.  The  fifth  section   concentrates  on  the
relationship  between  social  structure  and  architecture.  Finally,  in  the  last  chapter,  conclusions
are presented.

2. Background
This  section  describes  general  information  about  software   architecture,  how  the  quality  of
architecture  affects  directly  the  quality  of  software,  and  what  the  quality  attributes  are.  Basic
information is also given about OSS projects and communities.

2.1 Software architecture
Software  architecture  is  a  structure  or  structures  of  the  system,  consisting  of   software
elements,  properties  of  visible  functionalities  based  on  the  elements  and  the  relationships
between  those. Architecture has  a  strong  influence  on  software  quality in software development
determining  system  attributes  like  usability,  efficiency,  maintainability  and  reliability.  Software
architecture  is seen as a bridge between business  goals and the final concrete system. (Bass et
al., 2003.)

When  a   new  project  is  forked  along  with  a  structural  system  around  it,  it  can be  referred  as a
conceptual model. Related  to  a software architecture, a conceptual architecture is then referred.
It  consists  of  a  hierarchy  with  conceptual  interactions  between  subsystems  and modules within
the  hierarchy.  Therefore, conceptual interactions are born from programmer's intuition. Concrete
architecture  in  turn shows the system’s structure which is implemented in the  source code. This
concrete  architecture  may  be  different  than  the  conceptual architecture in system’s hierarchy or
interactions  between  the  modules  or  subsystems.  This  difference  of  the  conceptual  and
concrete   architecture  may  be  the  result  of  an  architectural  drift,   which  may  evolve  during  the
time when the system is developed. (Tran et al., 2000.)

2.2 Quality attributes in software architecture
Quality  attributes  are  revised  according  to  Bass  and  Kazman  (1994)  as  often  called  as
non­functional  qualities  or requirements.  They are supposed to define not, what the system shall
do  ­  like  functional  requirements  ­  but,  what  a  system  shall  be.  Depending  on  the  system
involved,  the quality attributes are many and diverse. Relating systematically the quality attributes
of   the  system  to  the  architecture  makes  a  sound  basis  for   accurate  predictions  about  the
relevant  system  quality  attributes and their relative importance for the system. It is an issue to be
evaluated  at the  early beginning phase of the design. Different quality attributes should  reflect the
4
contextual  validity,  and  be  assessed  against  the  internal  and  external  requirements.  (Bass  &
Kazman, 1994.)

Modularization  is  an  important  quality  factor  in  architectural  design.  It   is  a  good  predictor  of
quality.  Ideally,  the  structure  of  a large software should be hierarchical, i.e. the system should be
represented  by  a  tree,  whose  internal  nodes  are  subsystems   and  the  leaves  are  modules  or
source  files.  The  root  of  the  tree  is  the  system.  Related  modules   are  then  grouped  to
subsystems and further higher level subsystems. (Tran et al., 2000.)

2.3 Open source software projects and communities
Open  source  software  development  projects  are  generally  established  in Internet­based hosting
repositories   and  those  repositories  are  surrounded  with  active  communities  of  software
developers.   The  software  is  made  freely  available  to  all  to  exactly  follow  the  licensing  terms
specified  by the open source project, and  this means that the community will have different kinds
of   people  involved.  Open  source  software  projects  have  spread  rapidly  and  widely,  and  many
thousands  exist  today  having  created  evenly  many  communities.  (Von  Krogh  &  Von  Hippel,
2003.)

Sharma  et  al. (2002) suggested that the structure of Open Source Software (OSS) communities

can  be  checked  with  the  labor  division,  mechanism   of  coordination,  decision  making  authority
and  in  the  case  of  inner  source  also  the  boundary  of  the  company.  Since  this  kind  of
communities  are  different  from  traditional  communities,  they  consist   of  many  volunteer
members   who  make  contributions  as individual  or  as  a  part  of  a  team.  Due  to  the  fact  that  the
geographically  distributed  members  of  OSS  communities  rarely  meet  face  to  face, they have to
use  a   proper  coordination  to  work  with  others  (Fielding,  1999).  In  addition,  the  membership  of
OSS  communities  is  flexible,  e.g.  they  can  join  and  leave  at  any  time  and  the  relationships
among  organizations  are  formed  and  discarded   as  needed.  (Sharma,  Sugumaran,  &
Rajagopalan, 2002.)

3. Modularity in OSS
Modularity  can  be  seen  as  the  key  architectural  element  that  explains  the  development  and
success  of  many  open­source  projects. It also explains many phenomena that take place on the
community  side  as  it  divides  and  coordinates  its work. Antoniol et al. (2002) even go as far as to
claim  that  it  would  be impossible to use the open­source development model without modularity.
(Antoniol et al., 2002; Narduzzo & Rossi, 2003.)

The  open­source  development  process  benefits  from  a  modular  architecture  by  allowing  higher
autonomy  to  individual  developers  and  promoting  module  innovation. Module innovation refers to
a  situation  where  new  solutions  to  common  problems   are  explored  and  experimented.  These
two  factors  create  an  environment where developers  can comfortably experiment and contribute

5
without having to fear getting in the way of other developers. (Narduzzo & Rossi, 2003.)

3.1 Parallel development
Modular  architecture  enables  parallel  development  by  eliminating  or  reducing  the  likelihood  that
changes  in  one  module  will  clash  with  the  other  modules.  For  example,  the  architecture  of  the
Linux  kernel  was  redesigned after  the  first  successful  portings  of  the  initial i386  version  so  that
there  was  one  common  codebase  and  different  branches  for  different  machine  architectures.
This  allowed  code  that  is specific to  one  porting to  be changed without causing clashes with  the
development of the core codebase or other machine branches. (Antoniol et al., 2002.)

Brook’s  Law   claims  that  adding  developers  to  a  late   software  project  makes  it  only  later.
Raymond  (1999) uses  the  Linux  project  as  a counterexample to this statement saying that such
a  project  would  be  impossible  if  Brook’s  Law  was  the  whole  truth.  While   Raymond  stresses
cheap  Internet  as  a  necessary  condition  for  the  Linux  model  to  succeed,  Narduzzo  and  Rossi
(2003)  make  the  claim that the massive modularized structure of Linux has been the real reason
for   its   success.  The  reduced  interdependencies   between  different  parts  of  the  software  allow
new   developers  to  take  on  independent  subprojects  that  don’t  conflict  with  or  slow  down  the
existing development. (Narduzzo & Rossi, 2003.)

3.1 Division of work
Narduzzo  and  Rossi  (2003) criticize the perception that an open­source project always starts as
a  chaotic  mess  of  contributions  that  then  self­organizes  into  a  coherent  system spontaneously.
According  to  them,  an  open­source  architecture  is  not  necessarily  deregulated  and  flat  but
modularity  can  be  used  to  create  hierarchical  order.  In  the  Linux  kernel,  this  hierarchical
architecture  has  been  maintained  and  preserved  by  Linus  Torvalds  and  the  inner  team  of
developers  by  having  strict  regulation  over  the  code   integration.  Thus,  modularity  can  be
exploited  to  achieve  a  hierarchical  division  of  work   despite  the  usual  anarchical  nature  of
open­source development. (Narduzzo & Rossi, 2003.)

Modularity  can  also  be  used  to  divide  work  between  open­source and commercial  developers.
Software  is occasionally created as a result of academic research and it is increasingly released
as  open­source  software.  As  this  technology  is  transferred  to  a  larger  public,  it  will  often  be
integrated  with  commercial  code.  Modularity  allows  only  part  of  the  software  to be  open source
and  the  rest  to  be  commercially  maintained.  Such  a  division  of  architecture  between  two
organizations  is  called  a  dual  architecture.  However,  because  all  interdependencies  between
modules  cannot  be  eliminated,  such  an  architecture  would  need  to  be  accompanied  by   a
governance  structure  that  combines  authority  and  leadership with transparency of decisions. By
using  a  proper  collaborative  development  platform,  non­profit  and  for­profit  entities  can  develop
their  modules  concurrently  while  the  platform  takes  care  of  intellectual  property  right
management. (Dalle & Rousseau, 2004.)

6
4. Evolution of OSS systems
Software  architecture  has  gained  increasing  attention  as  a  quality  factor  of  OSS.  According  to
Nakagawa  (2008),  OSS  quality  can be improved by paying attention to the software architecture.
(Nakagawa et al., 2008.)

Many  OSS  projects  have  been  developed  without   significant  commercial  input.  Although  there
are  difficulties   in  addressing  usability,  by  using  an  analysis   of  the  architecture  of  usability
processes  and  their  manifestations,  such  as  practices  and  appropriation  of  available
technologies,  the  current  practice  can  be  improved.  In  addition,  there is  no  specific design from
the  infrastructure  of  usability  to  the  functionality­centric  ones  such  as  the  architecture  in  CVS,
SourceForge  and  Bugzilla.  When  such  an  infrastructure   involves,  it  is  likely  to  include  the
components  or  draw  attention  from  activities.  For  example,  a   blog  entry  design  may  contain  a
problem  description,  information  about  the  goals  and  constraints  of  the  design  or  the  design
criteria. (Nichols & Twidale, 2006.)

One  characteristic  in  OSSD  is  that  the  evolution  is  managed  loosely,  without  paying  much
attention   to  the  planning.  Developers  are  keen  to  contribute  and  develop  new  features   and  fix
bugs  whenever they  have  a  chance  to  do this. This kind of freedom and different personal views
lead to an architectural drift. (Tran et al., 2000.)

Another  problem  related to OSSD is that the development is mainly devoted to new development

and  corrective  maintenance,  and  little  effort  is  paid  to  the  preventive  maintenance  like redesign
and  restructuring.  Furthermore,  preventive  maintenance  is  considered  tedious  and  not
intellectually  challenging,  and  it  impedes  the  speed  of  the  development  process,  which  implies
active  involvement  and  maintaining  interest  via  reciprocal  communication  with  the  other  code
developers.  All these factors add to the decay of the OSS architecture during the evolution.  (Tran
et al., 2000.)

4.1 Success factors
In order to correct the evolutionary and architectural drift, some factors affecting and contributing
to the success of an OSS project are covered in this paper: modularity, software maintenance,
architecture repair and evolvability. Modularity was presented in the previous chapter.

4.1.1 Software maintenance
Maintaining  a  large  software  system  is  very  difficult,  complicated,  and  time  consuming.  The
tasks  of  adding new  features,  adding  support  for  new  hardware  devices  and  platforms,  system
tuning,  and  defect  fixing  all  become  more difficult as a system ages and grows. The single most
important  requirement of  an  open  source software system is that its source code must be freely
available  to anyone who wishes to examine  it or change it for their own purpose. There are some

7
traditional  software  development  features  that  are   often  missing  in  open  source  software
development,  such  as scheduling, code quality assurance, unstable code and planned evolution,
testing and preventive maintenance. (Godfrey & Tu, 2000.)

Code  understandability  is  considered  to  be  a  basic  factor   of  maintainability,  therefore  one
measure  for  this  is  to  measure  code  structure  like  code  size, average size  of modules, number
of   macro  and  micro  modules  as  an  indicator  of  code  understandability  (via  calculating  code
indistinctness).  McCabe’s  cyclomatic  complexity  has  been  used  most  as  a   measure  of
complexity  of  the  code.  Also  other  measures  of  complexity   has  been  used,  e.g.  calls  per
functions,  coupling,  interface  complexity  and  complexity   of  data  structures.  Modularity  can  be
determined  by  calculating  distinct  and  logically  cohesive  subunits.  Modularity  is  considered  to
reduce  complexity  in  software  systems.  Usually,  it  is  studied  in  the  class  and  file  level.
(Capiluppi, Faria, & Ramil, 2005.)

4.1.2 Architecture repair
As   a  system  evolves,  the  concrete  architecture  changes  from  the  conceptual  architecture  give
rise  to  an  architectural  drift.  This is  the  case  particularly  in  OSSD,  where software is developed
by  highly  distributed  co­developers,  who  are  developing  the  software  as  their  part­time  hobby
and  their  interests  may  be  in small pieces of the software leading to not carefully planned overall
architecture.

The  difference  between  conceptual  and  concrete   architecture  hinders  understanding  of  the
software  code  and  makes  the  maintenance extremely difficult and error prone. Tran et al. (2000)
presented  a  forward  and  reverse  architecture  repair  frameworks  to analyse and repair structural
anomalies  (i.e.  gap  between  conceptual  and  concrete  architectures)  in  Linux  and  VIM
­architectures.  They  wanted  to  show  the  effectiveness  of  the  forward  and  reverse  repair  –  also
for   developers  with  not  much  knowledge  about  the  system  under  repair  beforehand  –  and  how
practical  they  are,  especially  for  large  OSS  projects.  In  both  case  studies the authors were able
to  reconcile  the  conceptual  and  concrete  architecture  of  the  software  decreasing the number of
anomalies  (i.e.  architectural  elements  present  in  the  other architecture but not in the other). This
study  revealed  that  the  repair process  was  quick  and  it was easy to identify problem areas from
the  software.  They  excluded,  however,  the  external  validation  work  by  the  related  OSS
communities from this article to be conducted in the future projects.  (Tran et al., 2000.)

Also,  Nakagawa  et  al.  (2008)  highlighted  the  importance   of  knowledge  and  experience  of
architecture  in  OSS  projects.  They  conducted  an  architectural  refactoring  using  architectural
patterns and architecture evaluation methods.

Also,  because  planning,  documentation  and  modeling  are  not  the  main  focus  in  OSS,   the
architecture  degradation that  occurs  in  OSS  more  than  in  proprietary  software,  results  in a  gap
between  the  conceptual  and  concrete  architectures.  In  OSS  projects,  new  functionalities  are
aggregated  into  stable  versions  by project leaders. They  decide the aggregation of functionalities

8
based  on  the  conceptual  architecture  of  the  system.  The  OSS  community  must  therefore
incorporate  an  architecture  refactoring  activity  so  that  the  concrete  architecture  can be  brought
back to match the conceptual architecture. (Nakagawa et al., 2008.)

4.1.3 Evolvability
Software’s  evolvability  means  system’s  ability  to accommodate  easily  to  changes. Architecture
is  considered  one  of  the most  important  constituent  for  software  evolvability.  Evolvability  is  also
regarded  as  one  of  the  success  factors  for  an  OSS  project.   According  to  the sixth  Lehman’s
law   of  software  evolution,  when  a  system  grows  in  size  and  capabilities,  it  will  also  grow  in
complexity.  According  to  Chauhan  (n.d.),  there  exist  three   main  factors  that  contribute  to  the
evolvability:   code  understandability,  complexity  and   modularity.  Therefore,  modelling  software
growth  can  be  used  to  predict  software  evolution  and  other  characteristics.  (Capiluppi  &
Beecher, 2009.)

Architecture  as  a  contributor  to the  quality  aspects  has  a  very  important  role  in OSS  evolution  .
Capiluppi   and  Beecher  studied  (2009)  effects  of  software  architecture  to  OSS  evolution  by
considering  function  analysis  by  measuring  three   key  variables:  fan­in,  fan­out  and  instability.
Also  other  methods  for  evaluating  the  architecture  exist,  e.g.  Architecture  TradeOff  Analysis
Method  (ATAM)  evaluates  the  risks  for  inhibiting  to  achieve   the  business  goals  and  how  the
quality  goals  are  met  and  how  the  quality  goals   interact  with  each  others.  Besides,  by
documenting  the  architecture  with  proper  tools  e.g.  by Architecture Description Language (ADL)
or  Unified  Modelling  Language  (UML)  will  help  analysing  the  architecture  to  meet  proper  and
desired  quality.  To  meet  these  desired  achievements,  architecture  refactoring  is  proposed  to
repair the software.  (Nakagawa et al., 2008.)

Different  metrics  for   evaluating  evolvability  can  be  used,  e.g.  number  of  connections  to  a
component.  The  open  architecture  (an  OSS  or  proprietary  software  with  open  application
interfaces  ­  APIs)  can  evolve  by  changing  connectors  between  components,  rearranging
connectors  to  a  different  configuration,  or  changing  the  interface  through  which  a  connector
accesses   a  component,  altering  the  system  characteristics.  Revising  or  refactoring  the
configuration,  in  which  a  component  is  connected  can  change  also how  its  license  affects  the
rights and obligations for the overall system. (Scacchi & Alspaugh, 2012.)

4.2 Evolution patterns of open­source software systems
Linux  operating  system  kernel  is often  pointed  as  an  example  in  many  literature  reviews related
to  OSS  mainly  perhaps  due  to  its  large  software size and successfulness. Research according
to  Godfrey  &  Tu  suggests, that the growth rate of large software systems tends to slow down as
the  systems  become  larger.  E.g.  the  growth  rate  of  Linux   is  surprisingly  strong  given  its  large
size  of  over two million lines of code including comments and  blank lines. Its development model
is  a  highly  collaborative  and  geographically  distributed   set  of  developers,  many  of  whom
contributing  their  time  and  effort for free. In addition, it  is useful to examine the growth patterns of
the  subsystems  to gain  a  better understanding  of how and why the system seems to have been
9
able to evolve so successfully. (Godfrey & Tu, 2000.)

To  illustrate  more  about  the  growth  rate  of  Linux kernel, Figure 1 shows the growth in number of

source  code   files  of  the  Linux  kernel.  During  the  time  period  of  5  years  from  1994  to  1999,  the
number  of  source  code  files in  the  development  releases  increased  from  below  1000  to  nearly
5000.

Figure 1. Growth in number of source code files in Linux kernel (Godfrey & Tu, 2001, p.104).

Prompted  by  the  superlinear growth of  Linux,  Robles  et  al.  (2005)  set  out  to  find  out  if  similar
patterns  of  superlinear  growth  exist  in  other  open­source  projects.  They  studied  18  large
open­source  applications  with  active  communities  and  concluded  that  the  studied  projects
exhibited  mainly  linear  growth.  They  discovered  that  superlinear  growth  patterns  emerge  for
three  reasons:  sudden  inclusion  of  external  code  to  parts of  the  software that  don’t  need  to  be
maintained,  specific software architecture designs with fixed specifications and wide testing, and
allocation  of  work  between  different  teams.  The  uncommon   growth  rate  of  Linux  kernel  can
therefore  be  attributed  to these factors, e.g. device drivers that constitute a large part of the code
without requiring active maintenance. (Robles et al., 2005.)

10
Wu   (2006)  inspired  by  biological  evolution  studies  and  developed  a  concept  of  punctuated
software  evolution.  In  such  evolution,  most  of  the  time  the  changes  made  had  little  impact  on
the  system  architecture,  but  these  long  periods  are  punctuated  by  short  periods  of  avalanche
changes  that  affect  the  architecture  in  a  major  way.  The  long  periods  are  called  periods  of
equilibrium   that  rarely  violate  design  principles  but  lead  to  gradual  decay  nevertheless.  This
accumulated  decay  may  then lead  to  a  need  to  do  a  massive  restructuring  of the  architecture
called  periods  of  punctuation.  Wu  (2006)  then  examined  three  open­source  projects  and  found
evidence  for  punctuated  evolution.  The  projects  were  OpenSSH, PostgreSQL  and  Linux  kernel.
He  observed  that  the periods of punctuation in these three projects were associated with notable
system growth, especially in connection to new major or milestone releases. (Wu, 2006.)

Godfrey  and  Tu  (2001)  also  did some growth checking of several  open source systems such as

VIM  text  editor  and  the  GCC compiler  suite.  Each  system’s  growth  has  different  situations. For
instance,  the  growth  of  VIM  was  similar  to that  of  Linux.  However,  VIM’s software architecture is
decaying  due  to the  information  collected  to  two biggest source files. They also developed a tool
named  Beagle  to  explore  the  architectural  evolution  and  provide  aid  to  the  software  maintainer.
The  tool  has  some  useful  features  such  as  flexible  architecture,  supporting querying, navigation
and  visualization,  and  it  also  supports  identification  and  detection  of  the  changing  the  patterns.
(Godfrey & Tu, 2001.)

Nakakoji   et  al.  (2002)  proposed  an  sustainable  evolution  pattern   based  on  classification  of
OSS  projects  due  to  the  structure  and  the  social  mechanism  of  the  of  OSS  community.  This
classification  divides  OSS  projects  into three different types:  exploration­oriented, utility­oriented,
and  service­oriented.  By  identifying  the  type  of  the   OSS  project,  they  presented  the  evolution
pattern  of  OSS  project. Therefore, differences in collaboration models result in different evolution
patterns  in  both  the  system  and  the community. According to the evolution pattern, it will be then
easier  to control and guide the project meaningfully. The type of the project is expected to evolve,
since  the  project  changes over  time.  The  sustainable  evolution  pattern  of a specific project may
first  start  with  a  rapid  Exploration­Oriented  or  Utility­Oriented  evolution  phase  (mostly  linear),
following  with  a  slow  Service­Oriented  one  (stable  growth).  Rapid  and  slow  evolution  phases
tend  to  alternate  during  time.  The  three  types  of  collaboration  models  will  be explained  below.
(Nakakoji et al., 2002; Ruffell, Selby 2006.)

Exploration­oriented  OSS  aims to  create  new  innovations  and  it  is similar to scientific research.

Exploration­oriented  type of OSS tries to create something  new instead of improving the existing.
A  characteristic  for  this  type is the high quality requirements. Thousands of developers will study
and try to learn from the system. Nakakoji and Yamamoto (2005)  also confirm that for this type of
system,  the   community’s  contributions  only  serve  as  feedback.  For   example,  the  community
members   are  often  readers,  bug  reporters,  or  peripheral  developers  providing  feedback.
Consequently,  this  type  of  software  tends  to  have   a  project  leader  that  oversees  that  the
changes  conform  to  the high quality requirements. Success of this software system depends on
the  vision,  management  and  leadership  of  the   leader.  (Nakakoji  et  al.,  2002;  Nakakoji  &
Yamamoto, 2005.)
11
Utility­oriented  OSS   like  the  GNU/Linux  operating  system  –  excluding  the  kernel  itself which  is
categorized  as  exploration­oriented  OSS  –  seeks to fill some  void in functionality. Such software
gets  initiated  when  the  original  developer  cannot  find  an  existing  program  that  fulfills  his  needs.
Because  of  the  practical focus  of  this  type  of  OSS,  the  quality  requirements  are not as strict as
in  exploration­oriented  OSS.  There  is  no  centralized  control  and  it  is  common  for  the project  to
be  forked.   The  different  forks  then  compete  against  each  other  in  an  evolution  pattern  called
tournament  style  where  the  best  implementation  will  prevail.  Device   drivers   are  one  type  of
examples of this type. (Nakakoji et al., 2002.)

Service­oriented  OSS  is  characterized by a big population of stakeholders that is not limited only

to   the  OSS  community.  Any  changes  to  the  software  must  be   carefully  considered  so  that  it
won’t  disrupt  the  stakeholders.  This  leads  to  a  very  conservation   evolution  style.  Whereas
Raymond’s  (1999)  Cathedral­like  style  can  be  applied  to   exploration­oriented  OSS  and
Bazaar­like  to  utility­oriented  OSS, service­oriented OSS is somewhere  in the middle in terms of
control.  The  community  will  usually  adopt  a  council,  instead  of  a  single  project  leader,  which
oversees  the  changes. Thus,  this  kind  of  control  is called  Council  style. There is control, but it is
spread  over  a  larger  number  of  people  without  resulting  in  a  chaotic  bazaar.  (Nakakoji  et  al.,
2002.)

5. Social structure and architecture
Conway’s  Law   (Conway,  1968)  states  that  the  architecture   of  any  organization  producing  any
piece  of  software is usually isomorphic to the architecture of that software. In OSS development,
this  means  that  the  allocation  of  collaborative  work  correlates  with   the  characteristics  of  the
code.  What  is   more,  the  community  also  self­organizes  itself  to  match  the  code  base.  The
architecture  of  the  OSS  community  and  the  architecture  of  the  system affect each other in both
ways.  This  malleability  of  the  OSS  community  allows  the  architecture  of  the  system  to  be
changed  more  easily  than  in  organizations  that  employ   a  more  rigid  social  hierarchy.  (den
Besten et al., 2008.)

5.1 Developer roles and specialization
The  participants  of  an  open­source  community  can  be  divided  into  three  groups  based  on  their
level  of  contributions. A joiner  is  someone  who  has  just recently joined the community and does
not  have  access  to  the  repository  yet.  When  that  person   has  made  his  first  changes  to  the
repository,  he  becomes a  newcomer.  A developer is a fully­fledged contributor that actively adds
new code to the repository. (von Krogh et al., 2003.)

A  developer  often  starts  out  by making  bug  fixes  that  are  related  to  his  work  and  interests.  The
bug  fixes  are   not  randomly  scattered  around  the  software  but  they  tend  to  focus  on  the  same
modules.  Gradually  he  gains acceptance  and  a  higher  status  in  the  community  through  his  bug

12
fixes  and  participation  in  discussions  and  debates  about  new  features.  This  process
characterizes  how  a  developer  becomes  an  expert  on  some  part  of  the architecture and is able
to influence its development. (Ducheneaut, 2005.)

Many  software developers and users participate in OSS development and communities because
they  want  to   learn.  The  system  architecture  can  be  designed   in  a  modularized  way  to  create
independent tasks with  progressive  difficulties  so  that  newcomers  can  participate and  move  on
gradually  to  take  care  of  harder  tasks.  This  approach  can  encourage  more  users  to  become
developers.   Developers  at  the  center  of  OSS  communities  should  focus  on  developing  the
system   as  well  as  having  enough  attention  to  the  creation and maintenance  of  a  dynamic  and
self­reproducing OSS community. (Ye & Kishida, 2003.)

A  joining  script  refers  to  a  barrier  that  a  joiner  has  to  overcome  before  he can  understand  the
architecture  and  is  accepted  by  other  developers.  It is a type  of activity that he has to go through
before   he  actually  starts  contributing  code,  and  the  failure  to  comply  with  the  joining  script  can
result  in  being  denied  to  access  to  the  developer   community.  Usually  the  joiner  starts  out  by
observing  the  technical  discussion  for  several  weeks   or  months  without commenting  anything
himself.  When  the  joiner  starts  participating  in  the  discussion,  it  is  most  often about an existing,
on­going  issue. Joiners  do not  start  out  by  making  completely  new  technical  suggestions.  (von
Krogh et al., 2003.)

The  contributions  of  newcomers  are  not equally distributed across  all modules. The newcomers

tend  to  specialize  on  modules  that  have  low  contribution  barriers.  This  contribution  barrier
depends on  how  easy  the  module  is  to  modify  and  how easily  it  can be  plugged  into  the overall
architecture  of  the  system.  The  pluggability  of  the architecture reduces the learning curve that is
needed  to  make  changes.  Therefore  it  is  important  not  to  have  intertwined  modules  if
newcomers are expected to work on those modules. (Aberdour, 2007; von Krogh et al., 2003.)

Only  a  few  people fully  understand  the  architecture  of  the  OSS system  (Von  Krogh,  Spaeth,  &
Lakhani,  2003).  Often  developers  contribute  only  to  a  small  part  of  the  software  and  they
increasingly  become knowledgeable  about that part of the architecture, while their understanding
of   other  parts  of  the  architecture  remains  low.  However,  the  contributions  they  make  do  not
always exist in isolation from other artifacts and people (see Figure 2). When adding a new piece
of  software,  other people and  artifacts might have to change to accommodate that addition.  This
in  turn   can  create  opposition  in  the  interrelationships  of  people  and  artifacts  that  has  to   be
managed before the addition is fully implemented. (Ducheneaut, 2005.)

13
Figure  2.  The  hybrid  network  of  people  and  artifacts  that  create  resistance  and  need  to  be
handled when adding a new module (Ducheneaut, 2005, p.347).

5.2 Reflection of social structure in software architecture
Even  though  the  organizational  structure  of  open­source  communities  is  not  as  visible  as  in
commercial  organizations,  there  is  nevertheless  evidence  of  strong  community  structure.  An
open­source  project  reflects  division  of  work  by  having  subcommunities  based  on  the
collaboration  behavior  of  the  developers.   This  structure  follows  the  modular  architectural
structure  and  becomes  visible  especially  when  developers  discuss  source  code artifacts.  This
means  for  example  that developers from the same email subcommunity are likely to work on the
same  modules  and  the  architectural  structure  of  the  software  is  accordingly  visible  in  the  email
subcommunities. (Bird et al., 2008.)

Emails  are  one  of  the  most  important  sources  for  discovering  information  about  the  social
structure  of  developers.  Emails  are  however  written  in  natural   language  and  linking  them  to
source  code   artifacts  without  human  intervention  is  not  so  straightforward.  Systems  that  try  to
achieve  this  are  called  automated  traceability  systems.  Information  retrieval  methods,  including
vector  space  models  and  latent  semantic  indexing,  are  widely  used  in  other  areas  requiring
natural  language  processing,  areas  such   as  management  of  scientific  literature  and  web
searches.  Bacchelli,  Lanza  and  Robbes  (2010)  studied  how  to  recover  the  traceability  link
between  emails  and  source  code  artifacts  in  open­source  software  projects.  They  discovered
that  simply   ‘grepping’  the  class  name  or  using  ‘regexes’  outperformed the  information retrieval
methods.  (Bacchelli et al., 2010; Chen & Grundy, 2011.)

The  social  network  fragmentation  is  mostly  visible  in  discussions   that   relate  to  actual
development  activity,  such as  function  interfaces,  bug  fixes  and  feature  implementations.  While
high­level  architectural  changes  are  important,  communication  patterns  when  the  community
14
discusses  architectural  changes  do  not  reflect  the   social  structure  of  the community  because
everyone  is   affected  by  such  changes.  The  high­level  software  architecture  is  thus  more
identifiable  in  communication  patterns  in  local  module  discussions  and  less  so  in  discussions
that specifically focus on the high­level architecture. (Bird et al., 2008.)

OSS  design  and  development processes are made possible and enacted by shared, structured,

and  (more or  less) complex knowledge management environments that capture traces of design
and  analysis  processes.  These  systems,  which  range  from  simple  newsgroups  to  complex
repositories   and  compiled  documents,  allow  the  community  to  accumulate,  organize,  make
sense of, and use the wide variety of knowledge contributed by many people involved. (Gasser et
al., 2003.)

6. Conclusions
The  aim  of  the study was to do a literature review in order find out about the relationship between
the  OSSD  communities  and  the  software  architecture  as  they  both  evolve.  The  context of  the
research  problem  assumed,  that  there  is  a  community  in  OSSD  which  is  responsible  for
software  evolution  in  architecture;  and  because  the  nature  of an  OSSD  project  is  collaborative
and  distributed,  there are  also  challenges  in  managing  the  evolution  in both the architecture and
in the community.

Narduzzo  and  Rossi  (2003)  claimed  that  modularity  is  the  key  element  in  the  development  and
success  of  many  open  source  projects.  While  Linux  achieved  super  fast growth rate  in  OSSD
evolution,  they  also  criticized  that  Linux  started  as  a  chaotic  mess  of  contributions,  which  then
self­organized  into  a  coherent  development  spontaneously.  In  community  aspect,  according  to
von  Krogh  et  al.  (2003),  the  participants  of  open­source   community  can  be  divided  into  three
groups  based  on  the  contributions:  joiner,  newcomers  and  developer.  Sharma et al. (2002) also
insisted  on   the  importance  of  decision­making  in  the  OSS  community  and  suggested  that  the
structure  can   be  examined  with  the  division  of  labour,  coordination  mechanism,  distribution  of
decision­making authority and ­ in the case of inner source ­ also the boundary of the company.

Tran  et  al.  (2000)  also  mentioned  that  the  architecture  drift,   a  change  from  conceptual
architecture  to  concrete  architecture,  is  very  important  situation   in  the  evolution.  They  also
presented  a  forward  and  reverse  architecture  repair frameworks to analyze and repair structural
anomalies.   In  addition,  according  to  Godfrey  and  Tu  (2000),  the maintenance  of  large  software
system   is  very  difficult,   complicated  and  time  consuming  since  there  are  many  things  causing
troubles  such  as  defects,  hardware  and  platforms.  Nakagawa  et  al.  (2008)  mentioned  that  in
OSS  projects,  all  contributions  of  new  functionalities  need  to  be  verified  by  project  leaders  or
high­privileged persons in the community to make sure all the changes are stable.

From  the  review  of  earlier  research,  the  OSSD  software  architecture  and  the  community  has a
close  relationship  since  most  of  the latest  changes  came  and  developed  from the communities

15
and  they  were  also  verified  by the  communities.  The  study  also  found out, that modularity  is  an
essential  feature  of  an  open­source  project.  The  social  structure  organizes  itself  to support  the
modular  software  architecture  by  creating  sub­communities  around   different  modules  and
having  developers  specialize  in  different  parts  of  the  architecture. The  high  modularization  also
allows  developers  to work  in  parallel  and  the  project  is  able  to  grow  at  a  rate  that  is  higher than
linear growth.

The  research  was  limited  because  it  to  a  large  extent   assumed  that  a  modular  software
architecture  is  used  in  the  open­source  project.  It  might  be   possible  that  non­modular
architectures  also  exist  in  successful  open­source  projects  but  we  did  not  find  evidence of this.
Such  a   non­modular  project  might  exhibit  widely  different  organizational  characteristics  and
evolution patterns.

For   future  research  we  recommend  studying  the  role  of  non­modular  architectures  in  OSSD.
Such  research  can be approached from many perspectives. What kind of extra community traits
are  needed  in  order  to  support  a  non­modular   architecture?  Does  a  non­modular  architecture
inevitably   evolve  to  a  modular  architecture  in  open­source  software?  Do  newcomers  have  a
higher contribution barrier in non­modular projects?

16
References
Aberdour, M. (2007). Achieving quality in open­source software. Software, IEEE, 24(1), 58­64.

Antoniol, G., Villano, U., Merlo, E., & Di Penta, M. (2002). Analyzing cloning evolution in the linux
kernel. Information and Software Technology, 44(13), 755­765.

Bacchelli, A., Lanza, M., & Robbes, R. (2010, May). Linking e­mails and source code artifacts. In
Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering­Volume
1 (pp. 375­384). ACM.

Bass, L., Clements, P., Kazman, R.(2003). Software Architecture in Practice. Addison­Wesley,
2003.

Bird, C., Pattison, D., D'Souza, R., Filkov, V., & Devanbu, P. (2008, November). Latent social
structure in open source projects. In Proceedings of the 16th ACM SIGSOFT International
Symposium on Foundations of software engineering (pp. 24­35). ACM.

Broek, P. & Ciraci, S. (2006). Evolvability as a quality attribute of software architectures.

Capiluppi, A., & Beecher, K. (2009, March). Structural complexity and decay in FLOSS systems:
An inter­repository study. In Software Maintenance and Reengineering, 2009. CSMR'09. 13th
European Conference on (pp. 169­178). IEEE.

Capiluppi, A., Faria, A. E., & Ramil, J. F. (2005, March). Exploring the relationship between
cumulative change and complexity in an open source system. In Software Maintenance and
Reengineering, 2005. CSMR 2005. Ninth European Conference on (pp. 21­29). IEEE.

Chauhan, M. A. (n.d.). A Survey of Open Source Software Evolution Studies.

Chen, X., & Grundy, J. (2011, November). Improving automated documentation to code
traceability by combining retrieval techniques. In Proceedings of the 2011 26th IEEE/ACM
International Conference on Automated Software Engineering (pp. 223­232). IEEE Computer
Society.

Conway, M. E. (1968). How do committees invent. Datamation, 14(4), 28­31.

Dalle, J. M., & Rousseau, G. (2004). Toward collaborative open­source technology transfer.

den Besten, M., Dalle, J. M., & Galia, F. (2008). The allocation of collaborative efforts in

17
open­source software. Information Economics and Policy, 20(4), 316­322.

Ducheneaut, N. (2005). Socialization in an open source software community: A socio­technical
analysis. Computer Supported Cooperative Work, 323­368.

Fielding, R. T. (1999). Shared leadership in the Apache project. Communications of the ACM,
42(4), 42­43

Gasser, L., Ripoche, G., Scacchi, W., & Penne, B. (2003). Understanding continuous design in
F/OSS projects. In In 16th. Intern. Conf. Software & Systems Engineering and their Applications.

Godfrey, M., & Tu, Q. (2001, September). Growth, evolution, and structural change in open
source software. In Proceedings of the 4th international workshop on principles of software
evolution (pp. 103­106). ACM.

Henderson, R. M., & Clark, K. B. (1990). Architectural innovation: the reconfiguration of existing
product technologies and the failure of established firms. Administrative science quarterly, 9­30.

Kruchten, P., Obbink, H., & Stafford, J. (2006). The past, present, and future for software
architecture. Software, IEEE, 23(2), 22­30.

Lehman, M. M., Ramil, J. F., Wernick, P. D., Perry, D. E., & Turski, W. M. (1997, November).
Metrics and laws of software evolution­the nineties view. In Software Metrics Symposium, 1997.
Proceedings., Fourth International (pp. 20­32). IEEE.

Mockus, A., Fielding, R. T., & Herbsleb, J. (2000). A case study of open source software
development: the Apache server. In Software Engineering, 2000. Proceedings of the 2000
International Conference on (pp. 263­272). IEEE.　

Nakagawa, E. Y., de Sousa, E. P., de Brito Murata, K., de Faria Andery, G., Morelli, L. B., &
Maldonado, J. C. (2008, July). Software architecture relevance in open source software
evolution: a case study. In Computer Software and Applications, 2008. COMPSAC'08. 32nd
Annual IEEE International (pp. 1234­1239). IEEE.

Nakakoji, K., & Yamamoto, Y. (2005). The co­evolution of systems and communities in free and
open source software development. Free/open source software development, 59.

Nakakoji, K., Yamamoto, Y., Nishinaka, Y., Kishida, K., & Ye, Y. (2002, May). Evolution patterns
of open­source software systems and communities. In Proceedings of the international
workshop on Principles of software evolution (pp. 76­85). ACM.

Narduzzo, A., & Rossi, A. (2008). Modularity in action: GNU/Linux and free/open source
software development model unleashed (No. 020). Department of Computer and Management
18
Sciences, University of Trento, Italy.

Nichols, D. M., & Twidale, M. B. (2006). Usability processes in open source projects. Software
Process: Improvement and Practice, 11(2), 149­162.

Raasch, C., Herstatt, C., & Abdelkafi, N. (2008). Open source innovation: Characteristics and
applicability outside the software industry (No. 53). Working Papers/Technologie­und
Innovationsmanagement, Technische Universität Hamburg­Harburg.

Raymond, E. (1999). The cathedral and the bazaar. Knowledge, Technology & Policy, 12(3),
23­49.

Robles, G., Amor, J. J., Gonzalez­Barahona, J. M., & Herraiz, I. (2005, September). Evolution
and growth in large libre software projects. In Principles of Software Evolution, Eighth
International Workshop on (pp. 165­174). IEEE.

Ruffell, F. P., & Selby, J. W. (2006). The pervasiveness of global data in evolving software
systems. In Fundamental Approaches to Software Engineering (pp. 396­410). Springer Berlin
Heidelberg.

Scacchi, W. (2006). Understanding open source software evolution. Software Evolution and
Feedback: Theory and Practice, 9, 181­205.

Scacchi, W., & Alspaugh, T. A. (2012). Understanding the role of licenses and evolution in open
architecture software ecosystems. Journal of Systems and Software, 85(7), 1479­1494.

Sharma, S., Sugumaran, V., & Rajagopalan, B. (2002). A framework for creating hybrid‐open
source software communities. Information Systems Journal, 12(1), 7­25.

Sullivan, K. J., Griswold, W. G., Cai, Y., & Hallen, B. (2001, September). The structure and value
of modularity in software design. In ACM SIGSOFT Software Engineering Notes (Vol. 26, No. 5,
pp. 99­108). ACM.

Tran, J. B., Godfrey, M. W., Lee, E. H., & Holt, R. C. (2000). Architectural repair of open source
software. In Program Comprehension, 2000. Proceedings. IWPC 2000. 8th International
Workshop on (pp. 48­59). IEEE.

von Krogh, G., Spaeth, S., & Lakhani, K. R. (2003). Community, joining, and specialization in
open source software innovation: a case study. Research Policy, 32(7), 1217­1241.

von Krogh, G., & von Hippel, E. (2003). Special issue on open source software development.
Research Policy, 32(7), 1149­1157.

19
Wu, J. (2006). Open source software evolution and its dynamics (Doctoral dissertation,
University of Waterloo).

Ye, Y., & Kishida, K. (2003, May). Toward an understanding of the motivation of open source
software developers. In Software Engineering, 2003. Proceedings. 25th International Conference
on (pp. 419­429). IEEE.

20