Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Testing Conway’s Law in open source communities

Testing Conway’s Law in open source communities

You’re probably familiar with Conway’s Law, that “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." But did you know that there’s a tradition in academia spanning as far back as the 1960’s that has studied it in action?

Our understanding began in the traditions of organisational design, product design, and organisations-as-complex-systems. Conway’s Law is a separate tradition in technology, embracing our idioms and ways of storytelling.

But all three traditions point back to the same underlying concepts.

Conway’s Law has been studied across auto, aviation, software, banking, and healthcare. Each study has revealed how humans organise to build systems, and how those systems influence how we organise ourselves.

The results are not what you’d expect.

The internet has completely changed how we communicate – the cost of communication is lower than ever. Open Source breaks new ground about how we organise ourselves when working together. How Conway’s Law applies to open source development will surprise you.

Lindsay Holmwood

January 25, 2018
Tweet

More Decks by Lindsay Holmwood

Other Decks in Research

Transcript

  1. Mirror, mirror,
    on the wall:
    testing Conway’s Law in
    open source communities
    Lindsay Holmwood
    @auxesis

    View Slide

  2. "Organizations which design
    systems are constrained to
    produce designs which are
    copies of the communication
    structures of these
    organizations."
    – Melvin Conway

    View Slide

  3. “How Do Committees
    Invent?”
    Datamation magazine, April, 1968.

    View Slide

  4. “the design which
    occurs first is almost
    never the best
    possible”

    View Slide

  5. “the prevailing
    system concept may
    need to change”

    View Slide

  6. “flexibility of
    organization is
    important to effective
    design”

    View Slide

  7. “a design effort
    should be organized
    according to the need
    for communication”

    View Slide

  8. View Slide

  9. law adage

    View Slide

  10. Two separate
    research traditions

    View Slide

  11. 1. Computer science
    Conway’s law

    View Slide

  12. 2. Management
    Org design &
    orgs as complex
    systems

    View Slide

  13. 2. Management
    Product design &
    products as complex
    systems

    View Slide

  14. “In a complex system, the technical
    architecture and the division of labor
    will “mirror” one another in the sense
    that the network structure of one will
    correspond to the structure of the other.”

    View Slide

  15. What is mirroring?

    View Slide

  16. Two networks

    View Slide

  17. Organisational

    View Slide

  18. Technical

    View Slide

  19. Organisational Technical
    Mirroring

    View Slide

  20. Why do we mirror?

    View Slide

  21. Problem solving

    View Slide

  22. Reduce
    cognitive overhead

    View Slide

  23. Who owns
    this system?
    ? ?
    ?

    View Slide

  24. Takes people to where
    the problems are

    View Slide

  25. Design choice
    to improve congruity

    View Slide

  26. Economy

    View Slide

  27. Org design &
    orgs as complex
    systems

    View Slide

  28. Organization design:
    an information
    processing view
    Galbraith, 1974

    View Slide

  29. 3 strategies
    for co-ordination

    View Slide

  30. 1. Rules and programs
    Specified behaviours
    “See x, do y”

    View Slide

  31. 2. Hierarchy
    Route problems to
    correct path + level

    View Slide

  32. 3. Targets and goals
    People choose behaviours
    to meet targets

    View Slide

  33. As uncertainty increases,
    the amount of
    information that must be
    processed by decision
    makers increases

    View Slide

  34. Introduces
    bottlenecks
    (Jacobides et al., 2006; Pisano and Teece, 2007; Baldwin, 2015).

    View Slide

  35. The org can respond by
    reducing the need to
    process information

    View Slide

  36. The org can respond by
    increasing the capacity to
    process information

    View Slide

  37. The org can respond by
    Increase the capacity to
    process information
    devops

    View Slide

  38. Creation of lateral relations:
    Direct contact
    Liaison roles
    Task forces
    Teams
    Integrating roles
    Managerial linking roles
    Matrix organisation

    View Slide

  39. Creation of lateral relations
    Matrix organisation
    Teams

    View Slide

  40. The level of uncertainty
    determines the
    adopted strategy

    View Slide

  41. Product design &
    products as complex
    systems

    View Slide

  42. On the Criteria To Be
    Used in Decomposing
    Systems into Modules
    D.L. Parnas, 1972

    View Slide

  43. Information hiding:
    interface or definition […] to
    reveal as little as possible
    about its inner workings

    View Slide

  44. Architectural Innovation: The
    Reconfiguration of Existing
    Product Technologies and the
    Failure of Established Firms
    Henderson & Clark, 1990

    View Slide

  45. 3 year study
    of semiconductor
    photolithographic
    alignment equipment
    industry

    View Slide

  46. field based study,
    high rate-of-change industry

    View Slide

  47. 4 waves of innovation
    between 1962-1986

    View Slide

  48. 4 waves of innovation
    new leader after each:
    Kulicke ↩︎
    Kasper ↩︎
    Perkin-Elmer ↩︎
    GCA ↩︎
    Nikon

    View Slide

  49. 4 waves of innovation
    each incumbent
    could not course correct

    View Slide

  50. 4 waves of innovation
    each incumbent
    invested heavily
    in new technology

    View Slide

  51. 4 waves of innovation
    each incumbent
    structured organisation
    and communication
    based on product
    architecture

    View Slide

  52. 4 waves of innovation
    What about this
    makes sense?

    View Slide

  53. Framework based on
    observations from the
    aviation and automotive
    industries

    View Slide

  54. Framework validated on
    semiconductor
    photolithographic
    alignment equipment
    industry

    View Slide

  55. Frameworks:
    1. Problem solving
    2. Innovation

    View Slide

  56. Problem solving:
    channels,
    filters,
    strategies

    View Slide

  57. Channels:
    Formal: A reports to B

    View Slide

  58. Channels:
    Informal: I talk to
    Sarah because Sarah
    knows about X

    View Slide

  59. Channels:
    A + B report to C:
    embodies architectural
    relationship

    View Slide

  60. Filters:
    Boost knowledge
    that’s important

    View Slide

  61. Filters:
    Discard knowledge
    that’s unimportant

    View Slide

  62. Strategies:
    How we use
    channels + filters
    to solve problems

    View Slide

  63. Architecture
    Embedded in
    channels,
    filters,
    strategies

    View Slide

  64. Henderson & Clark’s
    framework for defining innovation
    Based on Schumpeter, 1942

    View Slide

  65. 4 waves of innovation
    What about this
    makes sense?

    View Slide

  66. Don’t mirror when
    exploring
    new opportunities

    View Slide

  67. Do mirror when
    exploiting

    existing opportunities

    View Slide

  68. Henderson & Clark’s
    framework for defining innovation
    Based on Schumpeter, 1942
    Mirror
    Don’t

    mirror

    View Slide

  69. Organisations 

    that mirror 

    perform poorly

    in unstable environments

    View Slide

  70. What we know about
    mirroring

    View Slide

  71. Organisations 

    that mirror 

    perform well

    in stable environments

    View Slide

  72. Partial mirroring is a
    viable strategy

    View Slide

  73. Partial mirroring:
    (think guild)

    View Slide

  74. Partial mirroring:
    Knowledge boundaries are
    drawn more broadly than
    operational boundaries

    View Slide

  75. knowledge boundaries
    operational boundaries

    View Slide

  76. It’s possible to
    break the mirror

    View Slide

  77. Break the mirror by
    introducing partitions

    View Slide

  78. View Slide

  79. Break the mirror by
    building relationships
    across technical
    boundaries

    View Slide

  80. What are the
    drawbacks?

    View Slide

  81. Limits opportunities

    View Slide

  82. Mirrored
    New architecture

    View Slide

  83. Architecture
    Embedded in
    channels,
    filters,
    strategies

    View Slide

  84. Introduces
    bottlenecks
    (Jacobides et al., 2006; Pisano and Teece, 2007; Baldwin, 2015).

    View Slide

  85. View Slide

  86. As uncertainty increases,
    the amount of
    information that must be
    processed by decision
    makers increases

    View Slide

  87. Organisations 

    that mirror 

    perform poorly

    in unstable environments

    View Slide

  88. 4 waves of innovation
    each incumbent
    could not course correct

    View Slide

  89. 4 waves of innovation
    each incumbent
    invested heavily
    in new technology

    View Slide

  90. 4 waves of innovation
    each incumbent
    structured organisation
    and communication
    based on product
    architecture

    View Slide

  91. Open source projects
    that mirror
    do not perform
    as well

    View Slide

  92. What’s different
    about open source?

    View Slide

  93. 3 different dynamics

    View Slide

  94. 3. Formation of a
    “core-periphery”
    organizational
    structure

    View Slide

  95. 2. Technical systems
    are very modular,
    have low cognitive
    complexity

    View Slide

  96. 1. Transient groups of
    problem solvers,
    assembling
    for limited periods of time

    View Slide

  97. 3. Formation of a
    “core-periphery”
    organizational
    structure

    View Slide

  98. Core
    Contributors to larger
    components, and system
    as a whole

    View Slide

  99. Periphery
    Contributors to smaller,
    localized components in
    the code base

    View Slide

  100. Exploring the impact of
    socio-technical
    core-periphery structures
    in open source software
    development
    Amrit and van Hillegersberg (2010)

    View Slide

  101. View Slide

  102. periphery
    semi-
    core

    View Slide

  103. “the ‘pattern of ties’ between
    actors in a network where the core
    is more densely interconnected
    than the periphery”
    Borgatti and Everett (1999)

    View Slide

  104. Three patterns

    View Slide

  105. 1. a steady shift away
    from the core

    View Slide

  106. 2. oscillatory shifts
    away and towards the
    core

    View Slide

  107. 3. no perceptible
    shift away or towards
    the core

    View Slide

  108. “without new members aspiring to
    become core developers, the
    development of the Open Source project
    will stop the day the existing core
    members decide to leave the project”
    Nakakoji et al., (2002)

    View Slide

  109. Lesson:
    Ensure a flow of
    peripheral contributors
    moving up the ranks to
    core.

    View Slide

  110. 2. Technical systems
    are very modular,
    have low cognitive
    complexity

    View Slide

  111. Hidden structure: Using
    network methods to map
    system architecture
    Baldwin, MacCormack, Rusnak (2014)

    View Slide

  112. 1286 releases
    across
    17 projects
    written in
    C, C++, C#

    View Slide

  113. Design
    Structure
    Matrices

    View Slide

  114. System architecture
    classifications

    View Slide

  115. 67%core-periphery
    25%borderline
    0.5%multi-core
    7%hierarchical

    View Slide

  116. Open Source projects have
    smaller cores
    than proprietary ones

    View Slide

  117. Smaller cores mean smaller
    cognitive overhead when
    making changes

    View Slide

  118. High modularity
    (low propagation cost)

    View Slide

  119. Modularity can be changed consciously,
    and improved through effort

    View Slide

  120. Modularity can fluctuate

    View Slide

  121. Example:

    View Slide

  122. View Slide

  123. View Slide

  124. View Slide

  125. 1. Transient groups of
    problem solvers,
    assembling
    for limited periods of time

    View Slide

  126. “temporary organizational ties
    can quickly be created at low
    cost to support highly
    interdependent collaboration”

    View Slide

  127. Temporal
    strong mirroring

    View Slide

  128. “flexibility of
    organization is
    important to effective
    design”

    View Slide

  129. “a design effort
    should be organized
    according to the need
    for communication”

    View Slide

  130. The Role of Participation
    Architecture in Growing
    Sponsored Open Source
    Communities
    West and O’Mahony (2008)

    View Slide

  131. examines
    12 sponsored communities
    and contrasts them with
    prior research on
    autonomous communities

    View Slide

  132. Autonomous:
    founded by individuals and
    grown through grass roots
    communications

    View Slide

  133. Sponsored:
    founded by corporations and
    grown with more strategic
    direction

    View Slide

  134. A project’s participation
    architecture?
    Sum of design decisions

    View Slide

  135. Three dimensions
    when designing open source
    communities

    View Slide

  136. 1. Intellectual property
    rights

    View Slide

  137. the allocation of rights
    to use the community’s
    output

    View Slide

  138. 2. Model of community
    governance

    View Slide

  139. the amount of control
    sponsors relinquish
    to the community

    View Slide

  140. Lesson:
    Make all contributions
    from sponsor public by
    default

    View Slide

  141. Lesson:
    Introduce friction for
    private communication

    View Slide

  142. 3. Development approach

    View Slide

  143. “a project’s technical
    architecture is one subset of
    a community’s participation
    architecture”

    View Slide

  144. More modular?
    Shallower learning curve.

    View Slide

  145. Helps people focus on
    specific modules,
    not the whole system

    View Slide

  146. Lesson:
    Invest heavily in making
    code modular

    View Slide

  147. Lesson:
    Invest heavily in good
    documentation

    View Slide

  148. Lesson:
    Public, well documented
    contribution process

    View Slide

  149. Participation in a
    community is
    determined by…

    View Slide

  150. 1. The identified
    technical architecture

    View Slide

  151. 2. The org structure
    that results from a
    community’s design
    decisions

    View Slide

  152. Two networks

    View Slide

  153. How do we
    apply this?

    View Slide

  154. In commercial
    environments

    View Slide

  155. Henderson & Clark’s
    framework for defining innovation
    Based on Schumpeter, 1942
    Mirror
    Don’t

    mirror

    View Slide

  156. When you
    should mirror

    View Slide

  157. When the
    environment is stable

    View Slide

  158. When you are
    exploiting

    existing opportunities

    View Slide

  159. When uncertainty
    is low

    View Slide

  160. When you
    should not mirror

    View Slide

  161. When the 

    environment is unstable

    View Slide

  162. When you are
    exploring
    new opportunities

    View Slide

  163. When uncertainty
    is high

    View Slide

  164. In Open Source
    communities

    View Slide

  165. Invest in
    “core-periphery”
    organizational
    structure

    View Slide

  166. Lesson:
    Public, well documented
    contribution process

    View Slide

  167. Lesson:
    Introduce friction for
    private communication

    View Slide

  168. Lesson:
    Ensure a flow of
    peripheral contributors
    moving up the ranks to
    core.

    View Slide

  169. Participation in a
    community is
    determined by…

    View Slide

  170. 1. The identified
    technical
    architecture
    2. The org structure
    that results from a
    community’s
    design decisions

    View Slide

  171. Don’t actively seek
    to mirror

    View Slide

  172. Temporal
    strong mirroring:
    “temporary organizational ties
    can quickly be created at low
    cost to support highly
    interdependent collaboration”

    View Slide

  173. “flexibility of
    organization is
    important to effective
    design”

    View Slide

  174. “a design effort
    should be organized
    according to the need
    for communication”

    View Slide

  175. Thank you!
    ❤ the talk? Let @auxesis know.

    View Slide

  176. Bibliography

    “The mirroring hypothesis: theory, evidence, and exceptions” 

    Colfer, L. and Baldwin, C. (2016)

    “Hidden structure: Using network methods to map system architecture” 

    Baldwin, C., MacCormack, A., and Rusnak, J. (2014)

    “Architectural Innovation: The Reconfiguration of Existing Product
    Technologies and the Failure of Established Firms” 

    Henderson, R. and Clark, K. (1990)

    “Organization design: an information processing view” 

    Galbraith, J. (1974)

    “On the Criteria To Be Used in Decomposing Systems into Modules” 

    Parnas, D.L. (1972)

    “The architecture of complexity” 

    Herbert, S. (1962)

    View Slide

  177. Bibliography

    "The Role of Participation Architecture in Growing Sponsored Open
    Source Communities”

    West and O’Mahony (2008)

    ”Hidden structure: Using network methods to map system architecture”

    Baldwin, MacCormack, Rusnak (2014)

    "Models of Core/Periphery Structure”

    Borgatti and Everett (1999)

    ”Evolution Patterns of Open-source Software Systems and Communities”

    Nakakoji, Yamamoto, Nishinaka, Kishida, Ye (2002)

    “Exploring the impact of socio-technical core-periphery structures in
    open source software development”

    Amrit and van Hillegersberg (2010)

    View Slide

  178. Stock photos from
    Other images
    http://meekrosoft.files.wordpress.com/2013/06/conway.png
    http://i.ebayimg.com/thumbs/images/g/JdwAAOSwTf9ZUEaB/s-l225.jpg
    Fonts
    Junction from League of Movable Type
    Fanwood from League of Movable Type

    View Slide