From 89b33b49e05ba850a44a07864e044e35814fbd3b Mon Sep 17 00:00:00 2001 From: Georg Gruetter Date: Wed, 15 Nov 2017 19:57:44 +0100 Subject: [PATCH 1/6] added document to collect proposals for pattern systems --- pattern-system.md | 113 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 113 insertions(+) create mode 100644 pattern-system.md diff --git a/pattern-system.md b/pattern-system.md new file mode 100644 index 000000000..47c37e2f1 --- /dev/null +++ b/pattern-system.md @@ -0,0 +1,113 @@ +# InnerSource Pattern System + +## About + +This document shall serve to define a system with which we organize our +patterns using a limited set of classifications. + +## Related Work + +### Design Patterns (Erich Gamma et. al.) + +From the Authors of the classic GoF book "Design Patterns": + +> Design patterns vary in their granularity and level of abstraction. Because +> there are many design patterns, we need a way to organize them. + +They classify patterns so that they "can refer to families of related patterns." +The authors also suspect that this classification will make "learning the +catalog" faster. They Classify patterns according to two criteria: Purpose and +Scope. They introduce the following classes of purpose in their book: + +- Creational, +- Structural and +- Behavioral. + +Orthogonal to this, they distinguish two scope classes, related to object +oriented SW development: + +- Class and +- Object. + +The main ordering criterion in the books catalog is the Purpose and each +pattern is "tagged" with the scope classification. + +### Pattern-Oriented Software Architecture (Fram Buschmann et. al.) + +Frank Buschmann also organizes the patterns in his (first) book using, what he +calls "categories". Similarly to the GoF book he uses one category to organize +the content of his book, in this case the level of abstraction the pattern +applies on: + +- Architectural Patterns, +- Design Patterns and +- Idioms. + +The second criterion categorizes the problems solved by the patterns: + +- _From Mud to Structure_, +- _Distributed Systems_, +- _Interactive Systems_, +- _Adaptable Systems_, +- _Structural Decomposition_, +- ... + +you get the point. + +In addition to this, he postulates a number of properties, a pattern system +must exhibit. According to Buschmann, a pattern system + +- should be simple and easy to learn, +- should consist of only a few classification criteria, +- should use a classification criterion that the reflects _natural properties_ + of patterns (e. g. kinds of problems, not e. g. what pattern language a + patterns belongs to), +- should provide a _roadmap_ that leads users to a set of potentially + applicable patterns and +- it should be open to the integration of new patterns. + +### Conclusion + +I have used both books extensively and found their respective pattern systems +very helpful in finding patterns for specific problems and for finding related +patterns. I also think that the criterions for a useful pattern system +postulated by Frank Buschmanns are sensible and might serve as a role model for +our InnerSource pattern system. + +## Candiate Classifications + +This section shall serve to collect individual proposals for systems of ISC +patterns. Contribute away ;) + +### Georg Grütter + +I propose we use a classification of the problem, a pattern tries to solve as +the main criteria for organizing our list of patterns. The following +classifications come to mind: + +- Getting started with InnerSource +- Getting sustainable middle management buy-in and support +- Getting buy-in of developers +- Fostering contributions +- Interfacing with traditional, non-InnerSource projects + +As an additional category, we might classify the solutions provided by the +patterns into: + +- organizational and +- social. + + + + + + + + + + + + + + + From fd032b556d5307c01aaadbb407e1d6c0ade93a4c Mon Sep 17 00:00:00 2001 From: Tim Yao Date: Wed, 29 Nov 2017 16:46:47 -0600 Subject: [PATCH 2/6] Update pattern-system.md Added Iba's paper as a reference on building pattern languages; and also proposed another plane for classifying InnerSource patterns. --- pattern-system.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/pattern-system.md b/pattern-system.md index 47c37e2f1..9a7402d15 100644 --- a/pattern-system.md +++ b/pattern-system.md @@ -74,6 +74,9 @@ patterns. I also think that the criterions for a useful pattern system postulated by Frank Buschmanns are sensible and might serve as a role model for our InnerSource pattern system. +### A pattern language for creating pattern languages (Takashi Iba) +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). + ## Candiate Classifications This section shall serve to collect individual proposals for systems of ISC @@ -97,7 +100,20 @@ patterns into: - organizational and - social. +### Tim Yao + +Another plane that would be useful is the plane of type of InnerSource. InnerSource programs can be structured to accomplish different goals: e.g., + +* Product Development +* Tools Development +* Innovation (Proof of concepts, demos) +* Shared components development + +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. + +#### Pattern Classification vs. Pattern Language +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. From eb1ed253a9648f5031d1cb2293cd3c538f823040 Mon Sep 17 00:00:00 2001 From: Daniel Izquierdo Cortazar Date: Wed, 29 Nov 2017 23:57:30 +0100 Subject: [PATCH 3/6] Add two extra potential ways to characterize patterns --- pattern-system.md | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/pattern-system.md b/pattern-system.md index 9a7402d15..62ce63ec7 100644 --- a/pattern-system.md +++ b/pattern-system.md @@ -116,7 +116,29 @@ Each of these programs have some unique characteristics. E.g., sometimes in Prod 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. +### Daniel Izquierdo +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: + +* Culture +* Communication +* Transparency +* Collaboration +* Community +* Meritocracy + +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. + + +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? +* IT/DevTeams +* Marketing +* Management +* Legal +* Business +* Financial + +[1] https://es.slideshare.net/jimjag/apachecon-2017-innersource-and-the-apache-way From de31ad998f518692e56c9be48e2a0e6f42d8b60f Mon Sep 17 00:00:00 2001 From: Georg Gruetter Date: Fri, 1 Dec 2017 13:59:11 +0100 Subject: [PATCH 4/6] prepared for patterns meeting (added list of patterns for sample classification) --- pattern-system.md | 112 ++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 104 insertions(+), 8 deletions(-) diff --git a/pattern-system.md b/pattern-system.md index 62ce63ec7..aba49d40f 100644 --- a/pattern-system.md +++ b/pattern-system.md @@ -75,7 +75,12 @@ postulated by Frank Buschmanns are sensible and might serve as a role model for our InnerSource pattern system. ### A pattern language for creating pattern languages (Takashi Iba) -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). + +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). ## Candiate Classifications @@ -100,25 +105,84 @@ patterns into: - organizational and - social. +#### Test run + +- 30 Day Warranty +- Common Requirements +- Contracted Contributor +- Dedicated Community Leader +- Discover Your InnerSource +- Improve Findability +- Junkyard Styled InnerSource +- Modular Code +- Review Committee + +- Change Middle Management Mindset +- Assisted Compliance +- Include Product Owners +- Start as Experiment +- Not Invented Here +- Change Developers Mindset +- Overcoming Project Management Time Pressures +- Open Source Trumps InnerSource +- Get Contributions Despite Silo Thinking +- Contained InnerSource + ### Tim Yao -Another plane that would be useful is the plane of type of InnerSource. InnerSource programs can be structured to accomplish different goals: e.g., +Another plane that would be useful is the plane of type of InnerSource. +InnerSource programs can be structured to accomplish different goals: e.g., * Product Development * Tools Development * Innovation (Proof of concepts, demos) * Shared components development -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. +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. + +#### Test run + +- 30 Day Warranty +- Common Requirements +- Contracted Contributor +- Dedicated Community Leader +- Discover Your InnerSource +- Improve Findability +- Junkyard Styled InnerSource +- Modular Code +- Review Committee + +- Change Middle Management Mindset +- Assisted Compliance +- Include Product Owners +- Start as Experiment +- Not Invented Here +- Change Developers Mindset +- Overcoming Project Management Time Pressures +- Open Source Trumps InnerSource +- Get Contributions Despite Silo Thinking +- Contained InnerSource #### Pattern Classification vs. Pattern Language -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. - +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. ### Daniel Izquierdo -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: +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: * Culture * Communication @@ -127,10 +191,18 @@ Another option would be to use the principles defined by Jim Jagielski in his ta * Community * Meritocracy -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. +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. +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? -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? * IT/DevTeams * Marketing * Management @@ -138,6 +210,30 @@ Another potential characterization would be to use a similar structure as existi * Business * Financial +#### Test run + +- 30 Day Warranty +- Common Requirements +- Contracted Contributor +- Dedicated Community Leader +- Discover Your InnerSource +- Improve Findability +- Junkyard Styled InnerSource +- Modular Code +- Review Committee + +- Change Middle Management Mindset +- Assisted Compliance +- Include Product Owners +- Start as Experiment +- Not Invented Here +- Change Developers Mindset +- Overcoming Project Management Time Pressures +- Open Source Trumps InnerSource +- Get Contributions Despite Silo Thinking +- Contained InnerSource + + [1] https://es.slideshare.net/jimjag/apachecon-2017-innersource-and-the-apache-way From e890ec9b444fbc9ec843af6c63e35c702849fa5f Mon Sep 17 00:00:00 2001 From: rrrutledge Date: Fri, 1 Dec 2017 06:31:10 -0800 Subject: [PATCH 5/6] Update pattern-system.md --- pattern-system.md | 28 +++++++++++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/pattern-system.md b/pattern-system.md index aba49d40f..e2d68d568 100644 --- a/pattern-system.md +++ b/pattern-system.md @@ -238,10 +238,36 @@ potential characterization based on the companies structure? +### Russ Rutledge +I like a lot of the other planes suggestions. Wanted to add one more - the point in the lifecycle of the InnerSource project. Does this pattern apply to: +* Pre-launch (prepration to launch) an InnerSource project? +* Launch (initial kick-off)? +* Initial growth? +* Broad adoption? +* End-of-life? +#### Test run +- 30 Day Warranty +- Common Requirements +- Contracted Contributor +- Dedicated Community Leader +- Discover Your InnerSource +- Improve Findability +- Junkyard Styled InnerSource +- Modular Code +- Review Committee - +- Change Middle Management Mindset +- Assisted Compliance +- Include Product Owners +- Start as Experiment +- Not Invented Here +- Change Developers Mindset +- Overcoming Project Management Time Pressures +- Open Source Trumps InnerSource +- Get Contributions Despite Silo Thinking +- Contained InnerSource From d5b452d130b131427da78b5ac2c9f27c0924f8fd Mon Sep 17 00:00:00 2001 From: Georg Gruetter Date: Fri, 1 Dec 2017 22:16:46 +0100 Subject: [PATCH 6/6] - added categorization proposal. Thanks Ofer! - added categorizations for Tims and Georgs proposal based on discussion in 2017-12-01 patterns group meeting --- pattern-system.md | 70 +++++++++++++++++++++++++++++------------------ 1 file changed, 43 insertions(+), 27 deletions(-) diff --git a/pattern-system.md b/pattern-system.md index e2d68d568..1c59fefb9 100644 --- a/pattern-system.md +++ b/pattern-system.md @@ -93,11 +93,14 @@ I propose we use a classification of the problem, a pattern tries to solve as the main criteria for organizing our list of patterns. The following classifications come to mind: -- Getting started with InnerSource -- Getting sustainable middle management buy-in and support -- Getting buy-in of developers -- Fostering contributions -- Interfacing with traditional, non-InnerSource projects +- 1. Getting started with InnerSource +- 2. Getting sustainable middle management buy-in and support +- 3. Getting buy-in of developers +- 4. Fostering contributions +- 5. Interfacing with traditional, non-InnerSource projects + +Tim: Could be tags, instead of (orthogonal) planes +Ofer: Ideas for vectors: Timeline, adoption, ... As an additional category, we might classify the solutions provided by the patterns into: @@ -107,15 +110,15 @@ patterns into: #### Test run -- 30 Day Warranty -- Common Requirements -- Contracted Contributor -- Dedicated Community Leader -- Discover Your InnerSource -- Improve Findability -- Junkyard Styled InnerSource -- Modular Code -- Review Committee +- 30 Day Warranty;1/2/3/4/5 +- Common Requirements;1/4 +- Contracted Contributor;1/2/4 +- Dedicated Community Leader;1/4 +- Discover Your InnerSource;1/4/5 +- Improve Findability;? (similar to "Discover your InnerSource"?) +- Junkyard Styled InnerSource;3/4 +- Modular Code;1/2/3/4/5 +- Review Committee;1/2 - Change Middle Management Mindset - Assisted Compliance @@ -133,10 +136,11 @@ patterns into: Another plane that would be useful is the plane of type of InnerSource. InnerSource programs can be structured to accomplish different goals: e.g., -* Product Development -* Tools Development -* Innovation (Proof of concepts, demos) -* Shared components development +* P: Product Development +* T: Tools Development +* I: Innovation (Proof of concepts, demos) +* S: Shared components development +* C: Culture Each of these programs have some unique characteristics. E.g., sometimes in Product Development, the open source characteristic of voluntariness has to be @@ -148,15 +152,15 @@ different business lines. #### Test run -- 30 Day Warranty -- Common Requirements -- Contracted Contributor -- Dedicated Community Leader -- Discover Your InnerSource -- Improve Findability -- Junkyard Styled InnerSource -- Modular Code -- Review Committee +- 30 Day Warranty;P/T/S +- Common Requirements;P/I/S +- Contracted Contributor;P/T/I/S +- Dedicated Community Leader;P/T/I/C +- Discover Your InnerSource;T/S +- Improve Findability (s. above) +- Junkyard Styled InnerSource;T/S/C +- Modular Code;P/T/S +- Review Committee;I/S/C - Change Middle Management Mindset - Assisted Compliance @@ -271,3 +275,15 @@ I like a lot of the other planes suggestions. Wanted to add one more - the poin - Contained InnerSource +### Ofer Hermoni + +tools +security +Culture change (probably need to separate into multiple categories) +buy in +trust +etc. +Processes / Methodology +Coding practices + +