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.

Fad1e9ed293fc5b3ec7d4abdffeb636f?s=128

Lindsay Holmwood

January 25, 2018
Tweet

Transcript

  1. Mirror, mirror, on the wall: testing Conway’s Law in open

    source communities Lindsay Holmwood @auxesis
  2. "Organizations which design systems are constrained to produce designs which

    are copies of the communication structures of these organizations." – Melvin Conway
  3. “How Do Committees Invent?” Datamation magazine, April, 1968.

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

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

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

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

    for communication”
  8. None
  9. law adage

  10. Two separate research traditions

  11. 1. Computer science Conway’s law

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

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

  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.”
  15. What is mirroring?

  16. Two networks

  17. Organisational

  18. Technical

  19. Organisational Technical Mirroring

  20. Why do we mirror?

  21. Problem solving

  22. Reduce cognitive overhead

  23. Who owns this system? ? ? ?

  24. Takes people to where the problems are

  25. Design choice to improve congruity

  26. Economy

  27. Org design & orgs as complex systems

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

  29. 3 strategies for co-ordination

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

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

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

  33. As uncertainty increases, the amount of information that must be

    processed by decision makers increases
  34. Introduces bottlenecks (Jacobides et al., 2006; Pisano and Teece, 2007;

    Baldwin, 2015).
  35. The org can respond by reducing the need to process

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

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

    information devops
  38. Creation of lateral relations: Direct contact Liaison roles Task forces

    Teams Integrating roles Managerial linking roles Matrix organisation
  39. Creation of lateral relations Matrix organisation Teams

  40. The level of uncertainty determines the adopted strategy

  41. Product design & products as complex systems

  42. On the Criteria To Be Used in Decomposing Systems into

    Modules D.L. Parnas, 1972
  43. Information hiding: interface or definition […] to reveal as little

    as possible about its inner workings
  44. Architectural Innovation: The Reconfiguration of Existing Product Technologies and the

    Failure of Established Firms Henderson & Clark, 1990
  45. 3 year study of semiconductor photolithographic alignment equipment industry

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

  47. 4 waves of innovation between 1962-1986

  48. 4 waves of innovation new leader after each: Kulicke ↩︎

    Kasper ↩︎ Perkin-Elmer ↩︎ GCA ↩︎ Nikon
  49. 4 waves of innovation each incumbent could not course correct

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

    technology
  51. 4 waves of innovation each incumbent structured organisation and communication

    based on product architecture
  52. 4 waves of innovation What about this makes sense?

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

  54. Framework validated on semiconductor photolithographic alignment equipment industry

  55. Frameworks: 1. Problem solving 2. Innovation

  56. Problem solving: channels, filters, strategies

  57. Channels: Formal: A reports to B

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

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

  60. Filters: Boost knowledge that’s important

  61. Filters: Discard knowledge that’s unimportant

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

  63. Architecture Embedded in channels, filters, strategies

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

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

  66. Don’t mirror when exploring new opportunities

  67. Do mirror when exploiting
 existing opportunities

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

    1942 Mirror Don’t
 mirror
  69. Organisations 
 that mirror 
 perform poorly
 in unstable environments

  70. What we know about mirroring

  71. Organisations 
 that mirror 
 perform well
 in stable environments

  72. Partial mirroring is a viable strategy

  73. Partial mirroring: (think guild)

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

    boundaries
  75. knowledge boundaries operational boundaries

  76. It’s possible to break the mirror

  77. Break the mirror by introducing partitions

  78. None
  79. Break the mirror by building relationships across technical boundaries

  80. What are the drawbacks?

  81. Limits opportunities

  82. Mirrored New architecture

  83. Architecture Embedded in channels, filters, strategies

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

    Baldwin, 2015).
  85. None
  86. As uncertainty increases, the amount of information that must be

    processed by decision makers increases
  87. Organisations 
 that mirror 
 perform poorly
 in unstable environments

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

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

    technology
  90. 4 waves of innovation each incumbent structured organisation and communication

    based on product architecture
  91. Open source projects that mirror do not perform as well

  92. What’s different about open source?

  93. 3 different dynamics

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

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

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

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

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

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

  100. Exploring the impact of socio-technical core-periphery structures in open source

    software development Amrit and van Hillegersberg (2010)
  101. None
  102. periphery semi- core

  103. “the ‘pattern of ties’ between actors in a network where

    the core is more densely interconnected than the periphery” Borgatti and Everett (1999)
  104. Three patterns

  105. 1. a steady shift away from the core

  106. 2. oscillatory shifts away and towards the core

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

  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)
  109. Lesson: Ensure a flow of peripheral contributors moving up the

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

  111. Hidden structure: Using network methods to map system architecture Baldwin,

    MacCormack, Rusnak (2014)
  112. 1286 releases across 17 projects written in C, C++, C#

  113. Design Structure Matrices

  114. System architecture classifications

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

  116. Open Source projects have smaller cores than proprietary ones

  117. Smaller cores mean smaller cognitive overhead when making changes

  118. High modularity (low propagation cost)

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

  120. Modularity can fluctuate

  121. Example:

  122. None
  123. None
  124. None
  125. 1. Transient groups of problem solvers, assembling for limited periods

    of time
  126. “temporary organizational ties can quickly be created at low cost

    to support highly interdependent collaboration”
  127. Temporal strong mirroring

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

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

    for communication”
  130. The Role of Participation Architecture in Growing Sponsored Open Source

    Communities West and O’Mahony (2008)
  131. examines 12 sponsored communities and contrasts them with prior research

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

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

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

  135. Three dimensions when designing open source communities

  136. 1. Intellectual property rights

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

  138. 2. Model of community governance

  139. the amount of control sponsors relinquish to the community

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

  141. Lesson: Introduce friction for private communication

  142. 3. Development approach

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

    participation architecture”
  144. More modular? Shallower learning curve.

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

  146. Lesson: Invest heavily in making code modular

  147. Lesson: Invest heavily in good documentation

  148. Lesson: Public, well documented contribution process

  149. Participation in a community is determined by…

  150. 1. The identified technical architecture

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

    decisions
  152. Two networks

  153. How do we apply this?

  154. In commercial environments

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

    1942 Mirror Don’t
 mirror
  156. When you should mirror

  157. When the environment is stable

  158. When you are exploiting
 existing opportunities

  159. When uncertainty is low

  160. When you should not mirror

  161. When the 
 environment is unstable

  162. When you are exploring new opportunities

  163. When uncertainty is high

  164. In Open Source communities

  165. Invest in “core-periphery” organizational structure

  166. Lesson: Public, well documented contribution process

  167. Lesson: Introduce friction for private communication

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

    ranks to core.
  169. Participation in a community is determined by…

  170. 1. The identified technical architecture 2. The org structure that

    results from a community’s design decisions
  171. Don’t actively seek to mirror

  172. Temporal strong mirroring: “temporary organizational ties can quickly be created

    at low cost to support highly interdependent collaboration”
  173. “flexibility of organization is important to effective design”

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

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

  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)
  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)
  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