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.

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”
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
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).
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)
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:
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