You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: pattern-system.md
+104-8Lines changed: 104 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -75,7 +75,12 @@ postulated by Frank Buschmanns are sensible and might serve as a role model for
75
75
our InnerSource pattern system.
76
76
77
77
### A pattern language for creating pattern languages (Takashi Iba)
78
-
Takashi Iba has published an article in the ACM Digital Library from PLoP 2016: [A pattern language for creating pattern languages: 364 patterns for pattern mining, writing, and symbolizing](https://dl.acm.org/citation.cfm?id=3158175&CFID=831673585&CFTOKEN=74341142&qualifier=LU1011674) - for those without ACM DL access, there is [an earlier draft of the paper from PLoP 2016](http://www.hillside.net/plop/2016/papers/three/26.3.pdf).
78
+
79
+
Takashi Iba has published an article in the ACM Digital Library from PLoP 2016:
80
+
[A pattern language for creating pattern languages: 364 patterns for pattern
81
+
mining, writing, and symbolizing](https://dl.acm.org/citation.cfm?id=3158175&CFID=831673585&CFTOKEN=74341142&qualifier=LU1011674)
82
+
- for those without ACM DL access, there is [an earlier draft of the paper from
Another plane that would be useful is the plane of type of InnerSource. InnerSource programs can be structured to accomplish different goals: e.g.,
133
+
Another plane that would be useful is the plane of type of InnerSource.
134
+
InnerSource programs can be structured to accomplish different goals: e.g.,
106
135
107
136
* Product Development
108
137
* Tools Development
109
138
* Innovation (Proof of concepts, demos)
110
139
* Shared components development
111
140
112
-
Each of these programs have some unique characteristics. E.g., sometimes in Product Development, the open source characteristic of voluntariness has to be sacrificed to ensure that sufficient development resources are dedicated to meet customer commitments and schedules. Similarly, there might be a need to limit code visibility/transparency for certain very proprietary products while making use of InnerSource methods to facilitate joint development between different business lines.
141
+
Each of these programs have some unique characteristics. E.g., sometimes in
142
+
Product Development, the open source characteristic of voluntariness has to be
143
+
sacrificed to ensure that sufficient development resources are dedicated to
144
+
meet customer commitments and schedules. Similarly, there might be a need to
145
+
limit code visibility/transparency for certain very proprietary products while
146
+
making use of InnerSource methods to facilitate joint development between
147
+
different business lines.
148
+
149
+
#### Test run
150
+
151
+
- 30 Day Warranty
152
+
- Common Requirements
153
+
- Contracted Contributor
154
+
- Dedicated Community Leader
155
+
- Discover Your InnerSource
156
+
- Improve Findability
157
+
- Junkyard Styled InnerSource
158
+
- Modular Code
159
+
- Review Committee
160
+
161
+
- Change Middle Management Mindset
162
+
- Assisted Compliance
163
+
- Include Product Owners
164
+
- Start as Experiment
165
+
- Not Invented Here
166
+
- Change Developers Mindset
167
+
- Overcoming Project Management Time Pressures
168
+
- Open Source Trumps InnerSource
169
+
- Get Contributions Despite Silo Thinking
170
+
- Contained InnerSource
113
171
114
172
#### Pattern Classification vs. Pattern Language
115
173
116
-
One lesson from PLoP 2017 was that the GoF book presented not a pattern language but a (useful) collection of patterns. Ideally, while we may have different classification systems for our InnerSource patterns, I think we want to develop a Pattern Language--a group of patterns that work together to solve a larger problem (e.g., "How do I build a new InnerSource program appropriate for my company") vs. a collection of patterns that might not have a larger goal.
117
-
174
+
One lesson from PLoP 2017 was that the GoF book presented not a pattern
175
+
language but a (useful) collection of patterns. Ideally, while we may have
176
+
different classification systems for our InnerSource patterns, I think we want
177
+
to develop a Pattern Language--a group of patterns that work together to solve
178
+
a larger problem (e.g., "How do I build a new InnerSource program appropriate
179
+
for my company") vs. a collection of patterns that might not have a larger
180
+
goal.
118
181
119
182
### Daniel Izquierdo
120
183
121
-
Another option would be to use the principles defined by Jim Jagielski in his talk "InnerSource 101 and The Apache Way"[1] as a way to characterize patterns:
184
+
Another option would be to use the principles defined by Jim Jagielski in his
185
+
talk "InnerSource 101 and The Apache Way"[1] as a way to characterize patterns:
122
186
123
187
* Culture
124
188
* Communication
@@ -127,17 +191,49 @@ Another option would be to use the principles defined by Jim Jagielski in his ta
127
191
* Community
128
192
* Meritocracy
129
193
130
-
And in addition, this would have some ortogonal techniques to work on building a proper transparency (for instance) that could go from the infrastructure to be used to monitoring the process and produce surveys, training and other actions.
194
+
And in addition, this would have some ortogonal techniques to work on building
195
+
a proper transparency (for instance) that could go from the infrastructure to
196
+
be used to monitoring the process and produce surveys, training and other
197
+
actions.
131
198
199
+
Another potential characterization would be to use a similar structure as
200
+
existing in the organizations. This would affect all of the departments in that
201
+
organization. For instance, the 'Review Committee' pattern helps with the
202
+
process of letting developers work on their own and still give control to
203
+
middle management and business roles. Would it make sense to have another
204
+
potential characterization based on the companies structure?
132
205
133
-
Another potential characterization would be to use a similar structure as existing in the organizations. This would affect all of the departments in that organization. For instance, the 'Review Committee' pattern helps with the process of letting developers work on their own and still give control to middle management and business roles. Would it make sense to have another potential characterization based on the companies structure?
0 commit comments