From 06ac78c8838d87d30953bb505ae32dbf12bbd04f Mon Sep 17 00:00:00 2001 From: Marion Deveaud Date: Sun, 6 Apr 2025 22:38:02 +0200 Subject: [PATCH 01/12] feat: add initial draft of a new pattern 'walk the InnerSource talk' This pattern has been collaboratively written by the team behind the social coding platform at Siemens, summarizing key lessons learned from implementing Open Source methodologies across diverse and globally distributed development teams. Co-authored-by: Florian Greinacher --- .../1-initial/walk-the-innersource-talk.md | 152 ++++++++++++++++++ 1 file changed, 152 insertions(+) create mode 100644 patterns/1-initial/walk-the-innersource-talk.md diff --git a/patterns/1-initial/walk-the-innersource-talk.md b/patterns/1-initial/walk-the-innersource-talk.md new file mode 100644 index 000000000..512b7d72b --- /dev/null +++ b/patterns/1-initial/walk-the-innersource-talk.md @@ -0,0 +1,152 @@ +## Title + +Walk the InnerSource talk + +## Patlet + +Teams across the organization are encouraged to adopt InnerSource principles such as working openly, sharing code, and +collaborating transparently. But, if the team behind the InnerSource initiative doesn’t follow these practices +themselves, it undermines credibility and adoption. Therefore, this team should lead by example: documenting their +decisions as code, working in the open, and treating their work as an InnerSource project to build trust and show others +how it’s done. + +## Problem + +The team behind the InnerSource initiative promotes transparency, collaboration, and best practices across the +organization. However, if the team itself does not adhere to these principles, others may perceive InnerSource as mere +rhetoric rather than a transformative practice. Without leading by example, adoption and trust in InnerSource +initiatives may suffer. + +## Story (optional) + +At Siemens, when the InnerSource journey began, many of the early contributors were deeply inspired by the Open Source +culture, several were also active participants in community projects. For them, setting up an InnerSource platform +wasn’t a stretch; it was a natural continuation of how they already worked: asynchronously across locations, sharing +ideas through issues, and documenting decisions transparently. + +This Open Source-inspired mindset gave the InnerSource platform a distinctly different character - transparent, +collaborative, and developer-friendly - compared to the closed, proprietary environments many developers were used to. +Unsurprisingly, it quickly attracted experts and engineers seeking more open, cross-team collaboration and meaningful +technical exchange. + +## Context + +In many large organizations, IT services rely on what we might call a “TicketOps” model: users submit requests into a +system, but the people and decisions behind the process remain invisible. This lack of transparency often breeds +frustration and mistrust, making true collaboration across departments difficult. + +In contrast, developer-centric initiatives like InnerSource thrive on openness and shared ownership. Instead of hiding +behind tickets, teams work in open repositories, discuss decisions transparently, and empower others to contribute. This +shift fosters trust, reduces the frustration of not knowing what happens behind the scenes, accelerates problem-solving, +and turns support into collaboration. + +## Forces + +### What makes the problem difficult? + +- In large, traditionally structured organizations, teams - especially platform, architecture, or governance groups - +are often used to working behind closed doors. Decision-making happens in meetings, documentation is internal or +scattered, and ownership is unclear. Shifting to transparent, open collaboration requires both cultural change and a +reevaluation of existing workflows. +- Working in the open can feel scary - when everything is public, people might hold back from contributing because they worry their work isn't perfect enough. This fear of not being "good enough" can stop many valuable ideas from being shared. +- People in central roles may fear scrutiny, overload from unsolicited input, or loss of control. Additionally, moving +towards open collaboration demands more discipline in documentation, async communication, and community management - +skills not always prioritized in internal tooling teams. + +### What are the trade-offs? + +- **Transparency vs. Control**: Sharing decisions and code openly fosters trust, invites valuable feedback, and + increases acceptance, especially when people feel included in the process. However, it also requires a mindset shift: + embracing open discussion, being comfortable with disagreement, and being willing to justify decisions in public and + potentially critical forums. + +- **Speed vs. Quality**: working transparently can slow things down in the short term compared to quick, closed + decision-making. However, this slower pace often leads to higher-quality outcomes: better-informed decisions, fewer + misunderstandings, and solutions that are easier to maintain. + +- **Effort vs. Reuse**: documenting decisions, maintaining contribution guidelines, and curating issues takes time. But +this investment leads to higher reusability, easier onboarding, and better scaling of knowledge. + +- **Risk vs. Trust**: opening up work may expose mistakes or half-finished ideas. But by showing authentic work in +progress, teams build credibility and foster trust across organizational boundaries. + +The solution - working in the open, documenting decisions transparently, and following InnerSource best practices +internally - addresses these forces by modeling the desired behavior. It increases alignment with developer +expectations, improves trust in the initiative, and helps shift the broader organizational culture over time. + +## Solutions + +✅ Verified Resolutions + +These have been successfully applied in real-world InnerSource initiatives (including at Siemens) and are known to help +solve the problem: + +1. Use version-controlled repositories for all InnerSource-related assets (policies, guidelines, tooling code, +documentation), accessible to all relevant developers. +1. Make decisions in the open by using issue trackers and discussions rather than closed-door meetings or emails. +1. Apply contribution workflows to internal platforms and tools exactly as recommended for InnerSource projects: open +pull requests, reviews, contribution guidelines, etc. +1. Document frequently asked questions (FAQs), design rationales, and change histories transparently, as part of the +repositories. +1. Encourage asynchronous collaboration, especially across locations and time zones, to foster inclusiveness and reduce +dependency on synchronous coordination. +1. Guide new contributors with patience and understanding, creating a welcoming environment where mistakes are seen as learning opportunities. Provide constructive feedback in a respectful and supportive manner, remembering that everyone was once a beginner. + +💡 Possible Resolutions + +These could be explored to address the problem further, depending on organizational context and maturity: + +1. Create InnerSource “meta-projects” that transparently host governance decisions, tooling roadmaps, and shared +architecture discussions - open to comment and contribution from the developer community. +1. Embed technical community leads or advocates into platform/tooling teams to help translate feedback and improve +transparency across organizational layers. +1. Use lightweight tooling (e.g. chat bots, dashboards) to surface changes, decisions, and contributions happening +within InnerSource-supporting teams, making their work more visible and discoverable. +1. Promote a “working out loud” culture through internal blogs, changelogs, or recorded demos where teams share updates +and learnings openly - even outside of the InnerSource platform. +1. Set up health checks or self-assessments for InnerSource-supporting teams to reflect on how well they themselves are +practicing the principles they advocate. + +## Resulting Context + +When the team behind the InnerSource initiative consistently applies the same principles they promote - working +transparently, documenting decisions, and enabling contributions - credibility increases across the organization. +Developers begin to see the InnerSource approach as authentic and achievable, not just aspirational. + +This fosters greater trust, encourages broader adoption, and creates a feedback loop where teams start to mirror these +practices in their own projects. The organization gradually shifts toward a more open, collaborative engineering +culture. + +However, this transparency can also surface new challenges, such as increased demand for contributions, the need for +community moderation, or pressure on core maintainers. These may lead to follow-up patterns like "Growing a Trusted +Committer Base" or "InnerSource Project Lifecycle Management" to ensure sustainability. + +## Known Instances + +- At Siemens, the experts behind the InnerSource initiative applied the same principles they advocated, developing key +assets such as documentation portals and contribution tooling transparently in shared repositories. Discussions about +governance, onboarding, and platform features were handled openly using issue trackers and pull requests. This visible +commitment to openness not only boosted trust among developers but also encouraged other teams to adopt similar +practices, accelerating InnerSource adoption organically across departments. + +## Status (optional until merging) + +> General pattern status is stored in GitHub's Label tagging - see any pull request. Note that this GitHub label tagging + becomes less visible once the pattern is finalized and merged, so having some information in this field is helpful. + You might store other related info here, such as review history: "Three of us reviewed this on 2/5/17 and it needs + John's expertise before it can go further." + +## Author(s) + +- Florian Greinacher (Siemens AG) +- Marion Deveaud (Siemens AG) +- Nejc Habjan (Siemens AG) +- Roger Meier (Siemens AG) + +## Acknowledgments + +- Antoine Auger (Siemens AG) +- Diego Louzan +- Ercan Uçan (Siemens AG) +- Fabio Huser (Siemens AG) +- Max Wittig (Siemens AG) From b77bbd05f50a62fb188a7a3c8d089f8e173dbf74 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Thu, 1 May 2025 00:03:02 +0200 Subject: [PATCH 02/12] Minor cleanup. Adding status value. --- patterns/1-initial/walk-the-innersource-talk.md | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/patterns/1-initial/walk-the-innersource-talk.md b/patterns/1-initial/walk-the-innersource-talk.md index 512b7d72b..ec7a5a59d 100644 --- a/patterns/1-initial/walk-the-innersource-talk.md +++ b/patterns/1-initial/walk-the-innersource-talk.md @@ -17,7 +17,7 @@ organization. However, if the team itself does not adhere to these principles, o rhetoric rather than a transformative practice. Without leading by example, adoption and trust in InnerSource initiatives may suffer. -## Story (optional) +## Story At Siemens, when the InnerSource journey began, many of the early contributors were deeply inspired by the Open Source culture, several were also active participants in community projects. For them, setting up an InnerSource platform @@ -123,18 +123,15 @@ Committer Base" or "InnerSource Project Lifecycle Management" to ensure sustaina ## Known Instances -- At Siemens, the experts behind the InnerSource initiative applied the same principles they advocated, developing key +- **Siemens** - The experts behind the InnerSource initiative applied the same principles they advocated, developing key assets such as documentation portals and contribution tooling transparently in shared repositories. Discussions about governance, onboarding, and platform features were handled openly using issue trackers and pull requests. This visible commitment to openness not only boosted trust among developers but also encouraged other teams to adopt similar practices, accelerating InnerSource adoption organically across departments. -## Status (optional until merging) +## Status -> General pattern status is stored in GitHub's Label tagging - see any pull request. Note that this GitHub label tagging - becomes less visible once the pattern is finalized and merged, so having some information in this field is helpful. - You might store other related info here, such as review history: "Three of us reviewed this on 2/5/17 and it needs - John's expertise before it can go further." +- Initial ## Author(s) From c396565ab6d92e51f8a911cb34be6176f5781bf0 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Thu, 1 May 2025 11:56:03 +0200 Subject: [PATCH 03/12] Change to list formatting --- patterns/1-initial/walk-the-innersource-talk.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/patterns/1-initial/walk-the-innersource-talk.md b/patterns/1-initial/walk-the-innersource-talk.md index ec7a5a59d..418cc6907 100644 --- a/patterns/1-initial/walk-the-innersource-talk.md +++ b/patterns/1-initial/walk-the-innersource-talk.md @@ -59,14 +59,11 @@ skills not always prioritized in internal tooling teams. increases acceptance, especially when people feel included in the process. However, it also requires a mindset shift: embracing open discussion, being comfortable with disagreement, and being willing to justify decisions in public and potentially critical forums. - - **Speed vs. Quality**: working transparently can slow things down in the short term compared to quick, closed decision-making. However, this slower pace often leads to higher-quality outcomes: better-informed decisions, fewer misunderstandings, and solutions that are easier to maintain. - - **Effort vs. Reuse**: documenting decisions, maintaining contribution guidelines, and curating issues takes time. But this investment leads to higher reusability, easier onboarding, and better scaling of knowledge. - - **Risk vs. Trust**: opening up work may expose mistakes or half-finished ideas. But by showing authentic work in progress, teams build credibility and foster trust across organizational boundaries. From 4a805ece225a4b061cbb1348129ccc0f65796c4f Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Thu, 1 May 2025 12:02:48 +0200 Subject: [PATCH 04/12] Adding ideas for Aliases --- patterns/1-initial/walk-the-innersource-talk.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/patterns/1-initial/walk-the-innersource-talk.md b/patterns/1-initial/walk-the-innersource-talk.md index 418cc6907..5bf98b50a 100644 --- a/patterns/1-initial/walk-the-innersource-talk.md +++ b/patterns/1-initial/walk-the-innersource-talk.md @@ -144,3 +144,9 @@ practices, accelerating InnerSource adoption organically across departments. - Ercan Uçan (Siemens AG) - Fabio Huser (Siemens AG) - Max Wittig (Siemens AG) + +## Alias + +- Show, don't tell +- Dogfooding the InnerSource behaviors +- Role-modeling the InnerSource behaviors From cfe8c06a63a652a2e62b5b7edb77b019ff5cf979 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Thu, 1 May 2025 12:03:12 +0200 Subject: [PATCH 05/12] Split forces into two --- patterns/1-initial/walk-the-innersource-talk.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/patterns/1-initial/walk-the-innersource-talk.md b/patterns/1-initial/walk-the-innersource-talk.md index 5bf98b50a..0310bd5cb 100644 --- a/patterns/1-initial/walk-the-innersource-talk.md +++ b/patterns/1-initial/walk-the-innersource-talk.md @@ -49,8 +49,8 @@ are often used to working behind closed doors. Decision-making happens in meetin scattered, and ownership is unclear. Shifting to transparent, open collaboration requires both cultural change and a reevaluation of existing workflows. - Working in the open can feel scary - when everything is public, people might hold back from contributing because they worry their work isn't perfect enough. This fear of not being "good enough" can stop many valuable ideas from being shared. -- People in central roles may fear scrutiny, overload from unsolicited input, or loss of control. Additionally, moving -towards open collaboration demands more discipline in documentation, async communication, and community management - +- People in central roles may fear scrutiny, overload from unsolicited input, or loss of control. +- Moving towards open collaboration demands more discipline in documentation, async communication, and community management - skills not always prioritized in internal tooling teams. ### What are the trade-offs? From 57c4dc59f94119500dc19598ba4da6f6b364e02a Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Thu, 1 May 2025 12:13:40 +0200 Subject: [PATCH 06/12] Adding a general description of the solution, before listing the verified and potential solutions --- patterns/1-initial/walk-the-innersource-talk.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/patterns/1-initial/walk-the-innersource-talk.md b/patterns/1-initial/walk-the-innersource-talk.md index 0310bd5cb..44ac532b6 100644 --- a/patterns/1-initial/walk-the-innersource-talk.md +++ b/patterns/1-initial/walk-the-innersource-talk.md @@ -73,6 +73,13 @@ expectations, improves trust in the initiative, and helps shift the broader orga ## Solutions +Rather than **telling** the teams in your organization how to practice InnerSource, find ways to **show** them how to do it. + +This role-modelling of the desired behaviors can be done by any team. However the more central that team is, i.e. the more touch points it has with other teams, +the more effective this role-modelling will be as it disseminates the InnerSouces behaviors into many different teams and parts of the organization. + +Therefore, we recommend to identify some central teams (e.g. platform teams, DevEx teams, enablement teams, or maybe even the team behind the InnerSource initiative to do this role-modelling. + ✅ Verified Resolutions These have been successfully applied in real-world InnerSource initiatives (including at Siemens) and are known to help @@ -81,7 +88,7 @@ solve the problem: 1. Use version-controlled repositories for all InnerSource-related assets (policies, guidelines, tooling code, documentation), accessible to all relevant developers. 1. Make decisions in the open by using issue trackers and discussions rather than closed-door meetings or emails. -1. Apply contribution workflows to internal platforms and tools exactly as recommended for InnerSource projects: open +2. Apply contribution workflows to internal platforms and tools exactly as recommended for InnerSource projects: open pull requests, reviews, contribution guidelines, etc. 1. Document frequently asked questions (FAQs), design rationales, and change histories transparently, as part of the repositories. From a84471e8f3d999131b1b7e388f57e7e559ddbc7a Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Thu, 1 May 2025 12:17:04 +0200 Subject: [PATCH 07/12] Adding another alias --- patterns/1-initial/walk-the-innersource-talk.md | 1 + 1 file changed, 1 insertion(+) diff --git a/patterns/1-initial/walk-the-innersource-talk.md b/patterns/1-initial/walk-the-innersource-talk.md index 44ac532b6..940b4e2e9 100644 --- a/patterns/1-initial/walk-the-innersource-talk.md +++ b/patterns/1-initial/walk-the-innersource-talk.md @@ -155,5 +155,6 @@ practices, accelerating InnerSource adoption organically across departments. ## Alias - Show, don't tell +- Lead by example - Dogfooding the InnerSource behaviors - Role-modeling the InnerSource behaviors From 4ab547a985d8d4cf1b3efd76d05c150a05aebe4b Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Thu, 1 May 2025 12:19:45 +0200 Subject: [PATCH 08/12] Adding new pattern to the overview in the README --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 1e41e6862..3663ecee9 100644 --- a/README.md +++ b/README.md @@ -94,6 +94,7 @@ Our mission * [Internal Developer Platform](/patterns/1-initial/internal-developer-platform.md) - *As InnerSource adoption increases throughout an organisation, it is not unusual that project teams start to face inefficiencies in scaling their efforts due to fragmented tooling, environments, and workflows. An Internal Developer Platform (IDP) provides a way to tackle this type of challenges through a centralized, self-service system that standardizes development environments and integrates tools to enhance consistency, collaboration, and developer productivity.* * [Document Architecture Decisions](/patterns/1-initial/document-architecture-decisions.md) - *InnerSource contributors often face challenges in grasping the system's design rationale, which can result in misalignment between maintainers, contributors, and stakeholders — potentially discouraging participation. To enhance decision-making and transparency, we recommend capturing architecture decisions and their consequences in a lightweight, accessible format to streamline onboarding, clarify decisions, and support long-term project sustainability.* * [InnerSource Incentives and Disincentives](/patterns/1-initial/incentives-and-disincentives.md) - *Lack of awareness for incentives as well well as disincentives for InnerSource contribution decrease the chances of an InnerSource project receiving contributions; this is addressed by sharing a comprehensive list of potential incentives and disincentives. +* [Walk the InnerSource talk](/patterns/1-initial/walk-the-innersource-talk.md) - *Teams across the organization are encouraged to adopt InnerSource principles such as working openly, sharing code, and collaborating transparently. But, if the team behind the InnerSource initiative doesn’t follow these practices themselves, it undermines credibility and adoption. Therefore, this team should lead by example: documenting their decisions as code, working in the open, and treating their work as an InnerSource project to build trust and show others how it’s done.*