Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

“the prevailing system concept may need to change”

Slide 6

Slide 6 text

“flexibility of organization is important to effective design”

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

law adage

Slide 10

Slide 10 text

Two separate research traditions

Slide 11

Slide 11 text

1. Computer science Conway’s law

Slide 12

Slide 12 text

2. Management Org design & orgs as complex systems

Slide 13

Slide 13 text

2. Management Product design & products as complex systems

Slide 14

Slide 14 text

“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.”

Slide 15

Slide 15 text

What is mirroring?

Slide 16

Slide 16 text

Two networks

Slide 17

Slide 17 text

Organisational

Slide 18

Slide 18 text

Technical

Slide 19

Slide 19 text

Organisational Technical Mirroring

Slide 20

Slide 20 text

Why do we mirror?

Slide 21

Slide 21 text

Problem solving

Slide 22

Slide 22 text

Reduce cognitive overhead

Slide 23

Slide 23 text

Who owns this system? ? ? ?

Slide 24

Slide 24 text

Takes people to where the problems are

Slide 25

Slide 25 text

Design choice to improve congruity

Slide 26

Slide 26 text

Economy

Slide 27

Slide 27 text

Org design & orgs as complex systems

Slide 28

Slide 28 text

Organization design: an information processing view Galbraith, 1974

Slide 29

Slide 29 text

3 strategies for co-ordination

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

2. Hierarchy Route problems to correct path + level

Slide 32

Slide 32 text

3. Targets and goals People choose behaviours to meet targets

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

The org can respond by reducing the need to process information

Slide 36

Slide 36 text

The org can respond by increasing the capacity to process information

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

Creation of lateral relations Matrix organisation Teams

Slide 40

Slide 40 text

The level of uncertainty determines the adopted strategy

Slide 41

Slide 41 text

Product design & products as complex systems

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

3 year study of semiconductor photolithographic alignment equipment industry

Slide 46

Slide 46 text

field based study, high rate-of-change industry

Slide 47

Slide 47 text

4 waves of innovation between 1962-1986

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

4 waves of innovation each incumbent could not course correct

Slide 50

Slide 50 text

4 waves of innovation each incumbent invested heavily in new technology

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

4 waves of innovation What about this makes sense?

Slide 53

Slide 53 text

Framework based on observations from the aviation and automotive industries

Slide 54

Slide 54 text

Framework validated on semiconductor photolithographic alignment equipment industry

Slide 55

Slide 55 text

Frameworks: 1. Problem solving 2. Innovation

Slide 56

Slide 56 text

Problem solving: channels, filters, strategies

Slide 57

Slide 57 text

Channels: Formal: A reports to B

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

Filters: Boost knowledge that’s important

Slide 61

Slide 61 text

Filters: Discard knowledge that’s unimportant

Slide 62

Slide 62 text

Strategies: How we use channels + filters to solve problems

Slide 63

Slide 63 text

Architecture Embedded in channels, filters, strategies

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

4 waves of innovation What about this makes sense?

Slide 66

Slide 66 text

Don’t mirror when exploring new opportunities

Slide 67

Slide 67 text

Do mirror when exploiting
 existing opportunities

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

Organisations 
 that mirror 
 perform poorly
 in unstable environments

Slide 70

Slide 70 text

What we know about mirroring

Slide 71

Slide 71 text

Organisations 
 that mirror 
 perform well
 in stable environments

Slide 72

Slide 72 text

Partial mirroring is a viable strategy

Slide 73

Slide 73 text

Partial mirroring: (think guild)

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

knowledge boundaries operational boundaries

Slide 76

Slide 76 text

It’s possible to break the mirror

Slide 77

Slide 77 text

Break the mirror by introducing partitions

Slide 78

Slide 78 text

No content

Slide 79

Slide 79 text

Break the mirror by building relationships across technical boundaries

Slide 80

Slide 80 text

What are the drawbacks?

Slide 81

Slide 81 text

Limits opportunities

Slide 82

Slide 82 text

Mirrored New architecture

Slide 83

Slide 83 text

Architecture Embedded in channels, filters, strategies

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

No content

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

Organisations 
 that mirror 
 perform poorly
 in unstable environments

Slide 88

Slide 88 text

4 waves of innovation each incumbent could not course correct

Slide 89

Slide 89 text

4 waves of innovation each incumbent invested heavily in new technology

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

Open source projects that mirror do not perform as well

Slide 92

Slide 92 text

What’s different about open source?

Slide 93

Slide 93 text

3 different dynamics

Slide 94

Slide 94 text

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

Slide 95

Slide 95 text

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

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

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

Slide 98

Slide 98 text

Core Contributors to larger components, and system as a whole

Slide 99

Slide 99 text

Periphery Contributors to smaller, localized components in the code base

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

No content

Slide 102

Slide 102 text

periphery semi- core

Slide 103

Slide 103 text

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

Slide 104

Slide 104 text

Three patterns

Slide 105

Slide 105 text

1. a steady shift away from the core

Slide 106

Slide 106 text

2. oscillatory shifts away and towards the core

Slide 107

Slide 107 text

3. no perceptible shift away or towards the core

Slide 108

Slide 108 text

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

Slide 109

Slide 109 text

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

Slide 110

Slide 110 text

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

Slide 111

Slide 111 text

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

Slide 112

Slide 112 text

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

Slide 113

Slide 113 text

Design Structure Matrices

Slide 114

Slide 114 text

System architecture classifications

Slide 115

Slide 115 text

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

Slide 116

Slide 116 text

Open Source projects have smaller cores than proprietary ones

Slide 117

Slide 117 text

Smaller cores mean smaller cognitive overhead when making changes

Slide 118

Slide 118 text

High modularity (low propagation cost)

Slide 119

Slide 119 text

Modularity can be changed consciously, and improved through effort

Slide 120

Slide 120 text

Modularity can fluctuate

Slide 121

Slide 121 text

Example:

Slide 122

Slide 122 text

No content

Slide 123

Slide 123 text

No content

Slide 124

Slide 124 text

No content

Slide 125

Slide 125 text

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

Slide 126

Slide 126 text

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

Slide 127

Slide 127 text

Temporal strong mirroring

Slide 128

Slide 128 text

“flexibility of organization is important to effective design”

Slide 129

Slide 129 text

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

Slide 130

Slide 130 text

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

Slide 131

Slide 131 text

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

Slide 132

Slide 132 text

Autonomous: founded by individuals and grown through grass roots communications

Slide 133

Slide 133 text

Sponsored: founded by corporations and grown with more strategic direction

Slide 134

Slide 134 text

A project’s participation architecture? Sum of design decisions

Slide 135

Slide 135 text

Three dimensions when designing open source communities

Slide 136

Slide 136 text

1. Intellectual property rights

Slide 137

Slide 137 text

the allocation of rights to use the community’s output

Slide 138

Slide 138 text

2. Model of community governance

Slide 139

Slide 139 text

the amount of control sponsors relinquish to the community

Slide 140

Slide 140 text

Lesson: Make all contributions from sponsor public by default

Slide 141

Slide 141 text

Lesson: Introduce friction for private communication

Slide 142

Slide 142 text

3. Development approach

Slide 143

Slide 143 text

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

Slide 144

Slide 144 text

More modular? Shallower learning curve.

Slide 145

Slide 145 text

Helps people focus on specific modules, not the whole system

Slide 146

Slide 146 text

Lesson: Invest heavily in making code modular

Slide 147

Slide 147 text

Lesson: Invest heavily in good documentation

Slide 148

Slide 148 text

Lesson: Public, well documented contribution process

Slide 149

Slide 149 text

Participation in a community is determined by…

Slide 150

Slide 150 text

1. The identified technical architecture

Slide 151

Slide 151 text

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

Slide 152

Slide 152 text

Two networks

Slide 153

Slide 153 text

How do we apply this?

Slide 154

Slide 154 text

In commercial environments

Slide 155

Slide 155 text

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

Slide 156

Slide 156 text

When you should mirror

Slide 157

Slide 157 text

When the environment is stable

Slide 158

Slide 158 text

When you are exploiting
 existing opportunities

Slide 159

Slide 159 text

When uncertainty is low

Slide 160

Slide 160 text

When you should not mirror

Slide 161

Slide 161 text

When the 
 environment is unstable

Slide 162

Slide 162 text

When you are exploring new opportunities

Slide 163

Slide 163 text

When uncertainty is high

Slide 164

Slide 164 text

In Open Source communities

Slide 165

Slide 165 text

Invest in “core-periphery” organizational structure

Slide 166

Slide 166 text

Lesson: Public, well documented contribution process

Slide 167

Slide 167 text

Lesson: Introduce friction for private communication

Slide 168

Slide 168 text

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

Slide 169

Slide 169 text

Participation in a community is determined by…

Slide 170

Slide 170 text

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

Slide 171

Slide 171 text

Don’t actively seek to mirror

Slide 172

Slide 172 text

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

Slide 173

Slide 173 text

“flexibility of organization is important to effective design”

Slide 174

Slide 174 text

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

Slide 175

Slide 175 text

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

Slide 176

Slide 176 text

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)

Slide 177

Slide 177 text

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)

Slide 178

Slide 178 text

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