diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS index f59f70dd7..25faf15ea 100644 --- a/.github/CODEOWNERS +++ b/.github/CODEOWNERS @@ -14,8 +14,8 @@ /book/ja/ @yuhattor /translation/zh/ @WillemJiang /book/zh/ @WillemJiang -/translation/pt/ @jrcosta @zilio -/book/pt/ @jrcosta @zilio +/translation/pt-br/ @jrcosta @zilio +/book/pt-br/ @jrcosta @zilio /pattern-categorization/pt-br/ @jrcosta @zilio /translation/gl/ @psanxiao /book/gl/ @psanxiao diff --git a/.github/vale/config/vocabularies/Base/accept.txt b/.github/vale/config/vocabularies/Base/accept.txt index cb05b5973..0602eab5c 100644 --- a/.github/vale/config/vocabularies/Base/accept.txt +++ b/.github/vale/config/vocabularies/Base/accept.txt @@ -1 +1,12 @@ -Adyen \ No newline at end of file +## For pattern: Maturity Model +Adyen + +## For pattern: InnerSource Hackathon +Ingka +Manoharan +Shanmugapriya +Kickstarting +Contribfest +Baumgarten +Trin +El diff --git a/.github/workflows/all-patterns-listed.yml b/.github/workflows/all-patterns-listed.yml index c7748dccd..311aa6ea8 100644 --- a/.github/workflows/all-patterns-listed.yml +++ b/.github/workflows/all-patterns-listed.yml @@ -13,7 +13,7 @@ jobs: all-patterns-listed: runs-on: ubuntu-latest steps: - - uses: actions/checkout@v6 + - uses: actions/checkout@v7 - name: Check if all patterns are listed in README.md run: | diff --git a/.github/workflows/book.yml b/.github/workflows/book.yml index 94638b3d9..116cd4b03 100644 --- a/.github/workflows/book.yml +++ b/.github/workflows/book.yml @@ -18,7 +18,7 @@ jobs: language: [en, ja, zh, pt-br, gl, es] steps: - - uses: actions/checkout@v6 + - uses: actions/checkout@v7 - uses: ruby/setup-ruby@v1 with: diff --git a/.github/workflows/contributor-report.yaml b/.github/workflows/contributor-report.yaml index 81039ed71..7df96e25b 100644 --- a/.github/workflows/contributor-report.yaml +++ b/.github/workflows/contributor-report.yaml @@ -28,7 +28,7 @@ jobs: echo "END_DATE=$end_date" >> "$GITHUB_ENV" - name: Run contributor action - uses: github-community-projects/contributors@v1 + uses: github-community-projects/contributors@v2 env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} START_DATE: ${{ env.START_DATE }} diff --git a/.github/workflows/generate-mindmap.yml b/.github/workflows/generate-mindmap.yml index bce021de0..653654279 100644 --- a/.github/workflows/generate-mindmap.yml +++ b/.github/workflows/generate-mindmap.yml @@ -27,9 +27,9 @@ jobs: contents: write steps: - - uses: actions/checkout@v6 + - uses: actions/checkout@v7 - name: Use Node.js - uses: actions/setup-node@v6 + uses: actions/setup-node@v7 with: node-version: 20 cache: 'npm' diff --git a/.github/workflows/i18n-consistency-checker.yaml b/.github/workflows/i18n-consistency-checker.yaml index f1e877210..79f894d5e 100644 --- a/.github/workflows/i18n-consistency-checker.yaml +++ b/.github/workflows/i18n-consistency-checker.yaml @@ -17,7 +17,7 @@ jobs: matrix: language: [ja, zh, pt-br, gl, es] steps: - - uses: actions/checkout@v6 + - uses: actions/checkout@v7 with: fetch-depth: '0' - name: Check consistency and create issue diff --git a/.github/workflows/link-checker-prs.yml b/.github/workflows/link-checker-prs.yml index f7175e260..291819d12 100644 --- a/.github/workflows/link-checker-prs.yml +++ b/.github/workflows/link-checker-prs.yml @@ -15,7 +15,7 @@ jobs: linkChecker: runs-on: ubuntu-latest steps: - - uses: actions/checkout@v6 + - uses: actions/checkout@v7 with: fetch-depth: 0 @@ -29,7 +29,7 @@ jobs: echo "MARKDOWN_FILES=$md_files" >> $GITHUB_ENV - name: Restore lychee cache - uses: actions/cache@v5 + uses: actions/cache@v6 with: path: .lycheecache key: cache-lychee-${{ github.sha }} @@ -39,7 +39,7 @@ jobs: name: Link Checker uses: lycheeverse/lychee-action@v2 with: - args: --verbose --no-progress --cache --max-cache-age 1d $MARKDOWN_FILES + args: --verbose --no-progress --cache --max-cache-age 1d --root-dir . $MARKDOWN_FILES fail: true failIfEmpty: false jobSummary: true diff --git a/.github/workflows/link-checker.yml b/.github/workflows/link-checker.yml index 73f9a4705..07f9cf419 100644 --- a/.github/workflows/link-checker.yml +++ b/.github/workflows/link-checker.yml @@ -15,10 +15,10 @@ jobs: linkChecker: runs-on: ubuntu-latest steps: - - uses: actions/checkout@v6 + - uses: actions/checkout@v7 - name: Restore lychee cache - uses: actions/cache@v5 + uses: actions/cache@v6 with: path: .lycheecache key: cache-lychee-${{ github.sha }} @@ -27,7 +27,7 @@ jobs: - name: Link Checker uses: lycheeverse/lychee-action@v2 with: - args: --verbose --no-progress --cache --max-cache-age 1d README.md patterns/ book/ translation/ + args: --verbose --no-progress --cache --max-cache-age 1d --root-dir . README.md patterns/ book/ translation/ fail: true jobSummary: true env: diff --git a/.github/workflows/lint-patterns.yml b/.github/workflows/lint-patterns.yml index b8a96f1e0..6800b5719 100644 --- a/.github/workflows/lint-patterns.yml +++ b/.github/workflows/lint-patterns.yml @@ -18,7 +18,7 @@ jobs: validate: runs-on: ubuntu-latest steps: - - uses: actions/checkout@v6 + - uses: actions/checkout@v7 - name: Problem Matcher for markdownlint-cli uses: xt0rted/markdownlint-problem-matcher@v3 - name: Lint pattern files (markdown) diff --git a/.github/workflows/markdownlint.yml b/.github/workflows/markdownlint.yml index 15287c4d7..bd2a8391b 100644 --- a/.github/workflows/markdownlint.yml +++ b/.github/workflows/markdownlint.yml @@ -20,9 +20,9 @@ jobs: runs-on: ubuntu-latest steps: - - uses: actions/checkout@v6 + - uses: actions/checkout@v7 - name: Use Node.js - uses: actions/setup-node@v6 + uses: actions/setup-node@v7 with: node-version: 20 - name: Run Markdownlint diff --git a/.github/workflows/pattern-metrics.yaml b/.github/workflows/pattern-metrics.yaml index d340b3482..cc545db15 100644 --- a/.github/workflows/pattern-metrics.yaml +++ b/.github/workflows/pattern-metrics.yaml @@ -29,7 +29,7 @@ jobs: echo "last_month=$first_day..$last_day" >> "$GITHUB_ENV" - name: Check out the code so we can get the CODEOWNERS names - uses: actions/checkout@v6 + uses: actions/checkout@v7 with: sparse-checkout: | .github/CODEOWNERS @@ -53,7 +53,7 @@ jobs: echo "CODEOWNERS_FILTER=$CODEOWNERS_FILTER" >> "$GITHUB_ENV" - name: Run issue-metrics tool for issues - uses: github-community-projects/issue-metrics@v3 + uses: github-community-projects/issue-metrics@v5 env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} SEARCH_QUERY: 'repo:InnerSourceCommons/InnerSourcePatterns is:issue created:${{ env.last_month }} -reason:"not planned" ${{ env.CODEOWNERS_FILTER }}' @@ -66,7 +66,7 @@ jobs: mv ./issue_metrics.md ready_to_merge_issues_report.md - name: Run issue-metrics tool for PRs - uses: github-community-projects/issue-metrics@v3 + uses: github-community-projects/issue-metrics@v5 env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} SEARCH_QUERY: 'repo:InnerSourceCommons/InnerSourcePatterns is:pr created:${{ env.last_month }} -reason:"not planned" ${{ env.CODEOWNERS_FILTER }}' diff --git a/.github/workflows/vale.yml b/.github/workflows/vale.yml index 0792228cf..c450d2cd2 100644 --- a/.github/workflows/vale.yml +++ b/.github/workflows/vale.yml @@ -18,10 +18,10 @@ jobs: runs-on: ubuntu-latest steps: - - uses: actions/checkout@v6 + - uses: actions/checkout@v7 - name: Vale Linting - uses: errata-ai/vale-action@v2 + uses: vale-cli/vale-action@v2 with: files: '["patterns/2-structured/", "patterns/3-validated/"]' vale_flags: "--glob=*.md" diff --git a/.markdownlint.json b/.markdownlint.json index 662a01cc2..282ad77b8 100644 --- a/.markdownlint.json +++ b/.markdownlint.json @@ -13,5 +13,6 @@ "MD034": false, "MD036": false, "MD040": false, - "MD041": false + "MD041": false, + "MD060": false } \ No newline at end of file diff --git a/README.md b/README.md index 199e35b91..5067007c6 100644 --- a/README.md +++ b/README.md @@ -69,9 +69,9 @@ Our mission * [Introducing Metrics in InnerSource](patterns/1-initial/introducing-metrics-in-innersource.md) - *Involve all stakeholders in designing and interpreting metrics to measure the current status in terms of health and performance of the InnerSource initiative.* * [Shared Code Repo Different from Build Repo](patterns/1-initial/shared-code-repo-different-from-build-repo.md) - *Deal with the overhead of having shared code in a separate repository that isn't the same as the project-specific one that is tied to production builds.* * [InnerSource Portal - Hygiene](patterns/1-initial/innersource-portal-hygiene.md) - *Allow generation of an official badge for projects intending to be recognized as InnerSource project within your company.* -* [Reluctance to Receive Contributions](patterns/1-initial/reluctance-to-accept-contributions.md) - *Core owner of shared asset is reluctant to take contributions due to the required maintenance that comes with them. Summary pattern that lays out four children patterns with three to be defined.* +* [Reluctance to Receive Contributions](patterns/1-initial/reluctance-to-accept-contributions.md) - *The team owning a shared InnerSource component is reluctant to accept contributions because doing so means taking on maintenance responsibility for unfamiliar code of uncertain quality. Establishing clear contribution guidelines, a time-limited post-merge support warranty from contributors, and a documented review workflow gives the host team confidence to accept contributions while setting clear expectations for contributors.* * [Include Product Owners](patterns/1-initial/include-product-owners.md) - *Engaging and educating Product Owners about InnerSource can help them modify their actions (e.g., in the space of KPIs) to help InnerSource collaboration work better.* -* [Assisted Compliance](patterns/1-initial/assisted_compliance.md) - *Helping repo owners be compliant by writing their CONTRIBUTING.md for them as a pull request.* +* [Assisted Compliance](patterns/1-initial/assisted_compliance.md) - *Repo owners resist adding compliance documentation like CONTRIBUTING.md, blocking contributions and slowing InnerSource adoption. A compliance task force breaks the stalemate by writing the missing documentation as a pull request on behalf of the resistant team, framing it as helpful contribution rather than enforcement.* * [Open Source Trumps InnerSource](patterns/1-initial/open-source-trumps-innersource.md) - *Developers disregard InnerSource projects because they consider open source projects to be superior. Introducing a required evaluation of InnerSource projects before choosing an open source project increases the likelihood of the InnerSource projects to be adopted.* * [Governance Level Guided Project Setup](/patterns/1-initial/governance-based-project-setup.md) - *Before publishing their first InnerSource project, a team wants to choose an appropriate Governance Level but is unsure about the impact of the different levels on their daily doing. A dedicated list of resources (best practices, recommended patterns, target maturity levels) provides specific guidance to the team and helps them to make an educated decision.* * [Contained InnerSource](patterns/1-initial/contained-innersource.md) - *Apply InnerSource methods to facilitate collaboration in a cross-divisional project but don't invest in soliciting contributions from outside of that project.* @@ -97,6 +97,7 @@ Our mission * [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.* * [Require InnerSource before Open Source](/patterns/1-initial/innersource-before-open-source.md) - *Maintaining and managing open source projects can be challenging for organizations, due to a lack of internal infrastructure and people with the knowledge of the required collaboration practices. By requiring projects to be InnerSource before becoming open source, teams have time to establish the necessary internal support, governance, and collaboration skills needed for successful community engagement.* * [AI Code Generation Context](patterns/1-initial/ai-code-generation-context.md) - *AI tools generate code that diverges from project standards and architectural patterns. Provide an AI Code Generation Context within the repositories to guide AI tools in producing contributions that align with existing project conventions, reducing review friction and maintaining code consistency.* +* [Centralized InnerSource Repository Governance](patterns/1-initial/centralized-repository-governance.md) - *InnerSource repositories lose contributor readiness when project hygiene drifts across teams. A central governance repository defines readiness checks as policy-as-code and runs automated audits that help Trusted Committers and repository maintainers keep projects discoverable, understandable, and contribution-ready without removing local ownership.* * [InnerSource as a Career Booster](patterns/1-initial/innersource-as-career-booster.md) - *Many employees wonder how contributing to InnerSource projects benefits their careers beyond their immediate team objectives. By engaging in InnerSource, individuals expand their skills, grow their network, increase visibility across the organization, and unlock new career opportunities.* * [Migrating from InnerSource to Open Source](patterns/1-initial/migrating-from-innersource-to-open-source.md) - *When an InnerSource project succeeds internally and meets criteria for external release, organizations often lack a structured approach for the transition. Establish a process that addresses legal, security, governance, and community readiness to transition the project to open source while maintaining its internal value.* @@ -105,25 +106,25 @@ NOTE: The 'Initial' Patterns below don't have a Patlet yet, which is essential f This is why we keep these patterns at the bottom of the list. --> -* [Overcome Acquisition Based Silos - Developers](patterns/1-initial/overcome-acquisition-based-silos-developer.md) -* [Overcome Acquisition Based Silos - Managers](patterns/1-initial/overcome-acquisition-based-silos-manager.md) -* [Discover Your InnerSource](patterns/1-initial/discover-your-innersource.md) -* [Junkyard Styled Inner Sourcing](patterns/1-initial/junkyard-styled-innersourcing.md) -* [Incentive Alignment](patterns/1-initial/developer-incentive-alignment-for-innersource-contribution.md) -* [Change the Developers Mindset](patterns/1-initial/change-the-developers-mindset.md) -* [Change the Middle-Management Mindset](patterns/1-initial/change-the-middle-management-mindset.md) -* [Share Your Code to Get More Done - Likely Contributors Variant](patterns/1-initial/share-your-code-to-get-more-done.md) -* [Code Consumers](patterns/1-initial/code-consumers.md) -* [Explaining InnerSource to Management by anchoring it to Agile / DevOps / Lean](patterns/1-initial/concept-anchor.md) -* [Culture Change through Hiring](patterns/1-initial/cultural-change-through-hiring.md) +* [Overcome Acquisition Based Silos - Developers](patterns/1-initial/overcome-acquisition-based-silos-developer.md) - *After a company acquisition, development teams remain siloed due to distrust, unfamiliar tools and processes, and fear of losing identity or job security, preventing the efficient cross-team collaboration InnerSource requires. A neutral governance committee, clear rules for handling code redundancy, generous onboarding, and face-to-face engagement help acquired developers overcome these barriers and begin contributing through InnerSource.* +* [Overcome Acquisition Based Silos - Managers](patterns/1-initial/overcome-acquisition-based-silos-manager.md) - *After a company acquisition, middle managers from the acquired company resist InnerSource collaboration out of fear of losing control over their team, their code domain, and their developer resources. A neutral governance committee, career advancement opportunities tied to InnerSource participation, and a realistic integration timeline with measurable milestones help managers feel secure enough to support cross-company collaboration.* +* [Discover Your InnerSource](patterns/1-initial/discover-your-innersource.md) - *When developers don't look for or can't find internally developed solutions, they may waste time and resources creating redundant software. To solve this, implement a robust internal search engine and processes that encourage the discovery and reuse of internal code.* +* [Junkyard Styled Inner Sourcing](patterns/1-initial/junkyard-styled-innersourcing.md) - *Developers share code internally for the sake of sharing without regard for reusability or production readiness, resulting in a repository of low-quality components that others find but cannot safely use. Supporting all contributions while transparently communicating component maturity — and engaging contributors in quality improvements — keeps the shared repository growing without discouraging participation.* +* [Incentive Alignment](patterns/1-initial/developer-incentive-alignment-for-innersource-contribution.md) - *Developers are not motivated to contribute to InnerSource because organizational incentives reward individual code output over cross-team mentorship and collaboration, leading to siloed work. By embedding InnerSource contribution and mentorship expectations into job descriptions and promotion criteria at each career level, organizations align personal career advancement with InnerSource participation.* +* [Change the Developers Mindset](patterns/1-initial/change-the-developers-mindset.md) - *Developers resist adopting InnerSource collaboration practices because they are comfortable with existing hierarchical workflows and middle management does not actively support the change. Combining visible recognition of InnerSource contributions, formalized training, clearer processes, and explicit management objectives creates the conditions needed to shift developer behavior.* +* [Change the Middle-Management Mindset](patterns/1-initial/change-the-middle-management-mindset.md) - *Middle managers often resist InnerSource due to misunderstanding and misaligned incentives. To overcome this resistance, educate them on the benefits, include InnerSource participation in their performance metrics, and demonstrate how it enhances their reputation, reduces team friction, and boosts overall productivity.* +* [Share Your Code to Get More Done - Likely Contributors Variant](patterns/1-initial/share-your-code-to-get-more-done.md) - *Development teams working in silos cannot deliver software fast enough but have no obvious path to increase throughput, unaware that opening their codebase to InnerSource contributions could unlock capacity from developers across the organization. By building an evidence-based project plan showing the value of contributions and actively recruiting potential contributors, teams expand their effective development capacity without adding permanent headcount.* +* [Code Consumers](patterns/1-initial/code-consumers.md) - *When a team opens their code for InnerSource reuse, they lose visibility into who is consuming it, making it hard to communicate vulnerabilities, gauge adoption, or retire deprecated components. Lightweight mechanisms such as dependency scanning, voluntary registration, or opt-in mailing lists restore that visibility without adding friction for consumers.* +* [Explaining InnerSource to Management by anchoring it to Agile / DevOps / Lean](patterns/1-initial/concept-anchor.md) - *Those wanting to bring InnerSource to organizations have difficulty starting a discussion with management. This can sometimes be made easier by anchoring InnerSource to more well known concepts such as Agile / DevOps / Lean.* +* [Culture Change through Hiring](patterns/1-initial/cultural-change-through-hiring.md) - *An InnerSource program struggles to reach critical mass because most existing employees lack open source or InnerSource experience, and HR does not factor in collaborative development skills when recruiting or reviewing performance. By aligning Engineering and HR to actively seek and develop these skills, organizations accelerate cultural change and build a self-sustaining InnerSource community.* #### Donuts (needing a solution) -* [How to Defeat the Hierarchical Constraints](patterns/1-initial/defeat-hierarchical-constraints.md) -* [Organizational Mindset Change](patterns/1-initial/organizational-mindset-change.md) -* [Bad Weather For Liftoff](patterns/1-initial/bad-weather-for-liftoff.md) +* [Defeat Hierarchical Constraints](patterns/1-initial/defeat-hierarchical-constraints.md) - *In strongly hierarchical organizations, developers want to contribute to InnerSource projects but are blocked by direct managers who prioritize their own team's goals and fear losing their team's time to cross-team work. Making InnerSource contributions a recognized part of individual performance goals and helping managers see concrete benefits for their own teams can empower developers to participate despite these constraints.* +* [Organizational Mindset Change](patterns/1-initial/organizational-mindset-change.md) - *Upper management, middle management, and developers all need to shift their mindset to support InnerSource, but organizational change is slow and costly, and pressures from deadlines and competition make experimentation feel too risky. A phased approach that starts with a small visible experiment, demonstrates concrete value early, and uses that momentum to broaden adoption is the most effective path to lasting culture change.* +* [Bad Weather For Liftoff](patterns/1-initial/bad-weather-for-liftoff.md) - *An InnerSource initiative fails to demonstrate improvement in quality or speed because the team lacks open source development experience and deadline pressure prevents adopting new ways of working. Starting InnerSource pilots with experienced practitioners and protecting time for new practices are prerequisites for success.* * [Incentive mechanisms to foster voluntary contribution](patterns/1-initial/incentive-mechanisms-for-voluntary-contribution.md) -* [Duplicated Projects](patterns/1-initial/duplicated-projects.md) +* [Duplicated Projects](patterns/1-initial/duplicated-projects.md) - *After opening codebases through InnerSource, teams discover they have independently built overlapping or identical products, but territorial management and differing technical approaches make consolidation difficult. Establishing a neutral governance process that gives all managers meaningful influence over the merged project makes it possible to consolidate duplicated efforts without losing key stakeholders.* * [Sustainable InnerSource Program](patterns/1-initial/sustainable-innersource-program.md) ## What are InnerSource Patterns? diff --git a/book/en/toc.md b/book/en/toc.md index 064e0d0b0..afcce137f 100644 --- a/book/en/toc.md +++ b/book/en/toc.md @@ -31,6 +31,7 @@ Instead edit toc_template.md * [Extensions for Sustainable Growth](../../patterns/2-structured/extensions-for-sustainable-growth.md) - An InnerSource project is receiving too many contributions, making maintenance difficult. By offering an extension mechanism outside of the core project, the maintainers enable scaling of project capabilities with minimal cost and maintenance overhead. * [Gig Marketplace](../../patterns/2-structured/gig-marketplace.md) - Establish a marketplace by creating an intranet website that lists specific InnerSource project needs as "Gigs" with explicit time and skill requirements. This will enable managers to better understand their employee’s time commitment and professional benefits thereby increasing the likelihood of garnering approval to make InnerSource contributions. * [Group Support](../../patterns/2-structured/group-support.md) - What happens if a team or individual no longer supports an InnerSource project? Keep the project alive by forming a group of interested individuals. +* [InnerSource Hackathon](../../patterns/2-structured/innersource-hackathon.md) - Only InnerSource enthusiasts practice InnerSource during the early stages of adoption, while most engineering teams lack the time or motivation to try it. Hosting a company-wide hackathon focused on InnerSource contributions provides a safe space for engineers to experiment with InnerSource practices and produces tangible contributions to InnerSource projects. * [InnerSource License](../../patterns/2-structured/innersource-license.md) - Two legal entities that belong to the same organization want to share software source code with each other but they are concerned about the implications in terms of legal liabilities or cross-company accounting. An InnerSource License provides a reusable legal framework for the sharing of source code within the organization. This opens up new collaboration options, and makes the rights and obligations of the involved legal entities explicit. * [InnerSource Portal](../../patterns/2-structured/innersource-portal.md) - Potential contributors cannot easily discover InnerSource projects that they are interested in. By creating an intranet website that indexes all available InnerSource project information you enable contributors to learn about projects that might interest them and InnerSource project owners to attract an outside audience. * [Issue Tracker Use Cases](../../patterns/2-structured/issue-tracker.md) - The InnerSource host team fails to make not only plans and progress but also context for changes transparent. This is solved by increasing the use cases for the project issue tracker to also serve brainstorming, implementation discussion, and feature design. diff --git a/pattern-categorization/innersource-program-mind-map.html b/pattern-categorization/innersource-program-mind-map.html index fc64591e0..d5f0bb7a0 100644 --- a/pattern-categorization/innersource-program-mind-map.html +++ b/pattern-categorization/innersource-program-mind-map.html @@ -38,6 +38,6 @@ if (window.matchMedia("(prefers-color-scheme: dark)").matches) { document.documentElement.classList.add("markmap-dark"); } - })(() => window.markmap,null,{"content":"InnerSource Program","children":[{"content":"Begin","children":[{"content":"Program Setup","children":[{"content":"Management hesitates to invest in InnerSource","children":[{"content":"Start as an Experiment","children":[],"payload":{"tag":"h5","lines":"8,9"}}],"payload":{"tag":"h4","lines":"6,7"}},{"content":"Slow community growth hinders InnerSource","children":[{"content":"Dedicated Community Leader","children":[],"payload":{"tag":"h5","lines":"12,13"}}],"payload":{"tag":"h4","lines":"10,11"}},{"content":"InnerSource principles are not intuitive for everybody","children":[{"content":"Document your Guiding Principles","children":[],"payload":{"tag":"h5","lines":"16,17"}}],"payload":{"tag":"h4","lines":"14,15"}}],"payload":{"tag":"h3","lines":"4,5"}},{"content":"Project Setup","children":[{"content":"Hard to assess a project quickly","children":[{"content":"Standard Base Documentation","children":[],"payload":{"tag":"h5","lines":"22,23"}}],"payload":{"tag":"h4","lines":"20,21"}},{"content":"Ad-hoc communication hinders project growth","children":[{"content":"Communication Tooling","children":[],"payload":{"tag":"h5","lines":"26,27"}}],"payload":{"tag":"h4","lines":"24,25"}},{"content":"Intransparent roadmap and direction of the project","children":[{"content":"Issue Tracker Use Cases","children":[],"payload":{"tag":"h5","lines":"30,31"}}],"payload":{"tag":"h4","lines":"28,29"}},{"content":"Language around project governance is ambiguous","children":[{"content":"Explicit Governance Levels","children":[],"payload":{"tag":"h5","lines":"34,35"}}],"payload":{"tag":"h4","lines":"32,33"}}],"payload":{"tag":"h3","lines":"18,19"}}],"payload":{"tag":"h2","lines":"2,3"}},{"content":"Adopt","children":[{"content":"Valuation Challenges","children":[{"content":"How to measure a project's business value","children":[{"content":"Cross-Team Project Valuation","children":[],"payload":{"tag":"h5","lines":"42,43"}}],"payload":{"tag":"h4","lines":"40,41"}},{"content":"Can we rely on the project for an extended period?","children":[{"content":"Standard Release Process","children":[],"payload":{"tag":"h5","lines":"46,47"}},{"content":"Standard Base Documentation","children":[],"payload":{"tag":"h5","lines":"48,49"}}],"payload":{"tag":"h4","lines":"44,45"}}],"payload":{"tag":"h3","lines":"38,39"}},{"content":"Cultural Challenges","children":[{"content":"Unrecognized effort","children":[{"content":"Praise Participants","children":[],"payload":{"tag":"h5","lines":"54,55"}},{"content":"Trusted Committer","children":[],"payload":{"tag":"h5","lines":"56,57"}}],"payload":{"tag":"h4","lines":"52,53"}}],"payload":{"tag":"h3","lines":"50,51"}},{"content":"Technical Challenges","children":[{"content":"Not meeting everyone's needs","children":[{"content":"Common Requirements","children":[],"payload":{"tag":"h5","lines":"62,63"}}],"payload":{"tag":"h4","lines":"60,61"}},{"content":"Fear of shared support responsibility","children":[{"content":"Service vs. Library","children":[],"payload":{"tag":"h5","lines":"66,67"}}],"payload":{"tag":"h4","lines":"64,65"}},{"content":"Project is difficult to contribute to and use","children":[{"content":"Core Team","children":[],"payload":{"tag":"h5","lines":"70,71"}}],"payload":{"tag":"h4","lines":"68,69"}}],"payload":{"tag":"h3","lines":"58,59"}},{"content":"Organizational Challenges","children":[{"content":"Discouragement of contributing resource","children":[{"content":"Contracted Contributor","children":[],"payload":{"tag":"h5","lines":"76,77"}}],"payload":{"tag":"h4","lines":"74,75"}},{"content":"Rejection of accepting contribution","children":[{"content":"30 Day Warranty","children":[],"payload":{"tag":"h5","lines":"80,81"}}],"payload":{"tag":"h4","lines":"78,79"}},{"content":"Radical change of management","children":[{"content":"Review Committee","children":[],"payload":{"tag":"h5","lines":"84,85"}}],"payload":{"tag":"h4","lines":"82,83"}},{"content":"Fear of shared support responsibility","children":[{"content":"Service vs. Library","children":[],"payload":{"tag":"h5","lines":"88,89"}}],"payload":{"tag":"h4","lines":"86,87"}},{"content":"Not enough maintainers to scale","children":[{"content":"Trusted Committer","children":[],"payload":{"tag":"h5","lines":"92,93"}}],"payload":{"tag":"h4","lines":"90,91"}},{"content":"Difficult cross-team coordination","children":[{"content":"Transparent Cross-Team Decision Making using RFCs","children":[],"payload":{"tag":"h5","lines":"96,97"}}],"payload":{"tag":"h4","lines":"94,95"}},{"content":"Level of influence for contributing teams is unclear","children":[{"content":"Explicit Governance Levels","children":[],"payload":{"tag":"h5","lines":"100,101"}}],"payload":{"tag":"h4","lines":"98,99"}},{"content":"Project without an owner/maintainer","children":[{"content":"Core Team","children":[],"payload":{"tag":"h5","lines":"104,105"}},{"content":"Group Support","children":[],"payload":{"tag":"h5","lines":"106,107"}}],"payload":{"tag":"h4","lines":"102,103"}}],"payload":{"tag":"h3","lines":"72,73"}},{"content":"Cross Legal Entities Challenges","children":[{"content":"Concern on legal liabilities or cross-company accounting","children":[{"content":"InnerSource License","children":[],"payload":{"tag":"h5","lines":"112,113"}}],"payload":{"tag":"h4","lines":"110,111"}}],"payload":{"tag":"h3","lines":"108,109"}}],"payload":{"tag":"h2","lines":"36,37"}},{"content":"Grow","children":[{"content":"Discovery Challenges","children":[{"content":"Can't find matching projects","children":[{"content":"Gig Marketplace","children":[],"payload":{"tag":"h5","lines":"120,121"}},{"content":"InnerSource Portal","children":[],"payload":{"tag":"h5","lines":"122,123"}}],"payload":{"tag":"h4","lines":"118,119"}},{"content":"Difficult to find active projects","children":[{"content":"Repository Activity Score","children":[],"payload":{"tag":"h5","lines":"126,127"}}],"payload":{"tag":"h4","lines":"124,125"}}],"payload":{"tag":"h3","lines":"116,117"}}],"payload":{"tag":"h2","lines":"114,115"}},{"content":"Scale","children":[{"content":"Self Education/Improvement Challenges","children":[{"content":"Not aware of InnerSource best practices","children":[{"content":"Maturity Model","children":[],"payload":{"tag":"h5","lines":"134,135"}}],"payload":{"tag":"h4","lines":"132,133"}},{"content":"Lack of open source knowledge","children":[{"content":"Document your Guiding Principles","children":[],"payload":{"tag":"h5","lines":"138,139"}}],"payload":{"tag":"h4","lines":"136,137"}}],"payload":{"tag":"h3","lines":"130,131"}},{"content":"Technical Challenges","children":[{"content":"Increasing maintenance overhead","children":[{"content":"Extensions for Sustainable Growth","children":[],"payload":{"tag":"h5","lines":"144,145"}}],"payload":{"tag":"h4","lines":"142,143"}}],"payload":{"tag":"h3","lines":"140,141"}}],"payload":{"tag":"h2","lines":"128,129"}}],"payload":{"tag":"h1","lines":"0,1"}},null) + })(() => window.markmap,null,{"content":"InnerSource Program","children":[{"content":"Begin","children":[{"content":"Program Setup","children":[{"content":"Management hesitates to invest in InnerSource","children":[{"content":"Start as an Experiment","children":[],"payload":{"tag":"h5","lines":"8,9"}}],"payload":{"tag":"h4","lines":"6,7"}},{"content":"Slow community growth hinders InnerSource","children":[{"content":"Dedicated Community Leader","children":[],"payload":{"tag":"h5","lines":"12,13"}}],"payload":{"tag":"h4","lines":"10,11"}},{"content":"Engineers lack time and a safe space to try InnerSource","children":[{"content":"InnerSource Hackathon","children":[],"payload":{"tag":"h5","lines":"16,17"}}],"payload":{"tag":"h4","lines":"14,15"}},{"content":"InnerSource principles are not intuitive for everybody","children":[{"content":"Document your Guiding Principles","children":[],"payload":{"tag":"h5","lines":"20,21"}}],"payload":{"tag":"h4","lines":"18,19"}}],"payload":{"tag":"h3","lines":"4,5"}},{"content":"Project Setup","children":[{"content":"Hard to assess a project quickly","children":[{"content":"Standard Base Documentation","children":[],"payload":{"tag":"h5","lines":"26,27"}}],"payload":{"tag":"h4","lines":"24,25"}},{"content":"Ad-hoc communication hinders project growth","children":[{"content":"Communication Tooling","children":[],"payload":{"tag":"h5","lines":"30,31"}}],"payload":{"tag":"h4","lines":"28,29"}},{"content":"Intransparent roadmap and direction of the project","children":[{"content":"Issue Tracker Use Cases","children":[],"payload":{"tag":"h5","lines":"34,35"}}],"payload":{"tag":"h4","lines":"32,33"}},{"content":"Language around project governance is ambiguous","children":[{"content":"Explicit Governance Levels","children":[],"payload":{"tag":"h5","lines":"38,39"}}],"payload":{"tag":"h4","lines":"36,37"}}],"payload":{"tag":"h3","lines":"22,23"}}],"payload":{"tag":"h2","lines":"2,3"}},{"content":"Adopt","children":[{"content":"Valuation Challenges","children":[{"content":"How to measure a project's business value","children":[{"content":"Cross-Team Project Valuation","children":[],"payload":{"tag":"h5","lines":"46,47"}}],"payload":{"tag":"h4","lines":"44,45"}},{"content":"Can we rely on the project for an extended period?","children":[{"content":"Standard Release Process","children":[],"payload":{"tag":"h5","lines":"50,51"}},{"content":"Standard Base Documentation","children":[],"payload":{"tag":"h5","lines":"52,53"}}],"payload":{"tag":"h4","lines":"48,49"}}],"payload":{"tag":"h3","lines":"42,43"}},{"content":"Cultural Challenges","children":[{"content":"Unrecognized effort","children":[{"content":"Praise Participants","children":[],"payload":{"tag":"h5","lines":"58,59"}},{"content":"Trusted Committer","children":[],"payload":{"tag":"h5","lines":"60,61"}}],"payload":{"tag":"h4","lines":"56,57"}}],"payload":{"tag":"h3","lines":"54,55"}},{"content":"Technical Challenges","children":[{"content":"Not meeting everyone's needs","children":[{"content":"Common Requirements","children":[],"payload":{"tag":"h5","lines":"66,67"}}],"payload":{"tag":"h4","lines":"64,65"}},{"content":"Fear of shared support responsibility","children":[{"content":"Service vs. Library","children":[],"payload":{"tag":"h5","lines":"70,71"}}],"payload":{"tag":"h4","lines":"68,69"}},{"content":"Project is difficult to contribute to and use","children":[{"content":"Core Team","children":[],"payload":{"tag":"h5","lines":"74,75"}}],"payload":{"tag":"h4","lines":"72,73"}}],"payload":{"tag":"h3","lines":"62,63"}},{"content":"Organizational Challenges","children":[{"content":"Discouragement of contributing resource","children":[{"content":"Contracted Contributor","children":[],"payload":{"tag":"h5","lines":"80,81"}}],"payload":{"tag":"h4","lines":"78,79"}},{"content":"Rejection of accepting contribution","children":[{"content":"30 Day Warranty","children":[],"payload":{"tag":"h5","lines":"84,85"}}],"payload":{"tag":"h4","lines":"82,83"}},{"content":"Radical change of management","children":[{"content":"Review Committee","children":[],"payload":{"tag":"h5","lines":"88,89"}}],"payload":{"tag":"h4","lines":"86,87"}},{"content":"Fear of shared support responsibility","children":[{"content":"Service vs. Library","children":[],"payload":{"tag":"h5","lines":"92,93"}}],"payload":{"tag":"h4","lines":"90,91"}},{"content":"Not enough maintainers to scale","children":[{"content":"Trusted Committer","children":[],"payload":{"tag":"h5","lines":"96,97"}}],"payload":{"tag":"h4","lines":"94,95"}},{"content":"Difficult cross-team coordination","children":[{"content":"Transparent Cross-Team Decision Making using RFCs","children":[],"payload":{"tag":"h5","lines":"100,101"}}],"payload":{"tag":"h4","lines":"98,99"}},{"content":"Level of influence for contributing teams is unclear","children":[{"content":"Explicit Governance Levels","children":[],"payload":{"tag":"h5","lines":"104,105"}}],"payload":{"tag":"h4","lines":"102,103"}},{"content":"Project without an owner/maintainer","children":[{"content":"Core Team","children":[],"payload":{"tag":"h5","lines":"108,109"}},{"content":"Group Support","children":[],"payload":{"tag":"h5","lines":"110,111"}}],"payload":{"tag":"h4","lines":"106,107"}}],"payload":{"tag":"h3","lines":"76,77"}},{"content":"Cross Legal Entities Challenges","children":[{"content":"Concern on legal liabilities or cross-company accounting","children":[{"content":"InnerSource License","children":[],"payload":{"tag":"h5","lines":"116,117"}}],"payload":{"tag":"h4","lines":"114,115"}}],"payload":{"tag":"h3","lines":"112,113"}}],"payload":{"tag":"h2","lines":"40,41"}},{"content":"Grow","children":[{"content":"Discovery Challenges","children":[{"content":"Can't find matching projects","children":[{"content":"Gig Marketplace","children":[],"payload":{"tag":"h5","lines":"124,125"}},{"content":"InnerSource Portal","children":[],"payload":{"tag":"h5","lines":"126,127"}}],"payload":{"tag":"h4","lines":"122,123"}},{"content":"Difficult to find active projects","children":[{"content":"Repository Activity Score","children":[],"payload":{"tag":"h5","lines":"130,131"}}],"payload":{"tag":"h4","lines":"128,129"}}],"payload":{"tag":"h3","lines":"120,121"}}],"payload":{"tag":"h2","lines":"118,119"}},{"content":"Scale","children":[{"content":"Self Education/Improvement Challenges","children":[{"content":"Not aware of InnerSource best practices","children":[{"content":"Maturity Model","children":[],"payload":{"tag":"h5","lines":"138,139"}}],"payload":{"tag":"h4","lines":"136,137"}},{"content":"Lack of open source knowledge","children":[{"content":"Document your Guiding Principles","children":[],"payload":{"tag":"h5","lines":"142,143"}}],"payload":{"tag":"h4","lines":"140,141"}}],"payload":{"tag":"h3","lines":"134,135"}},{"content":"Technical Challenges","children":[{"content":"Increasing maintenance overhead","children":[{"content":"Extensions for Sustainable Growth","children":[],"payload":{"tag":"h5","lines":"148,149"}}],"payload":{"tag":"h4","lines":"146,147"}}],"payload":{"tag":"h3","lines":"144,145"}}],"payload":{"tag":"h2","lines":"132,133"}}],"payload":{"tag":"h1","lines":"0,1"}},null) diff --git a/pattern-categorization/innersource-program-mind-map.md b/pattern-categorization/innersource-program-mind-map.md index 686c428d9..e0145dec0 100644 --- a/pattern-categorization/innersource-program-mind-map.md +++ b/pattern-categorization/innersource-program-mind-map.md @@ -12,7 +12,7 @@ ##### [Dedicated Community Leader](https://patterns.innersourcecommons.org/p/dedicated-community-leader) -#### Engineers lack time and safe space to try InnerSource +#### Engineers lack time and a safe space to try InnerSource ##### [InnerSource Hackathon](https://patterns.innersourcecommons.org/p/innersource-hackathon) diff --git a/pattern-categorization/innersource-program-mind-map.png b/pattern-categorization/innersource-program-mind-map.png index feb77cf3a..f1d74b227 100644 Binary files a/pattern-categorization/innersource-program-mind-map.png and b/pattern-categorization/innersource-program-mind-map.png differ diff --git a/pattern-categorization/package-lock.json b/pattern-categorization/package-lock.json index 33ddc50fe..e6be5cdda 100644 --- a/pattern-categorization/package-lock.json +++ b/pattern-categorization/package-lock.json @@ -109,9 +109,9 @@ } }, "node_modules/@hono/node-server": { - "version": "1.19.6", - "resolved": "https://registry.npmjs.org/@hono/node-server/-/node-server-1.19.6.tgz", - "integrity": "sha512-Shz/KjlIeAhfiuE93NDKVdZ7HdBVLQAfdbaXEaoAVO3ic9ibRSLGIQGkcBbFyuLr+7/1D5ZCINM8B+6IvXeMtw==", + "version": "1.19.14", + "resolved": "https://registry.npmjs.org/@hono/node-server/-/node-server-1.19.14.tgz", + "integrity": "sha512-GwtvgtXxnWsucXvbQXkRgqksiH2Qed37H9xHZocE5sA3N8O8O8/8FA3uclQXxXVzc9XBZuEOMK7+r02FmSpHtw==", "license": "MIT", "engines": { "node": ">=18.14.1" @@ -622,9 +622,9 @@ "license": "MIT" }, "node_modules/basic-ftp": { - "version": "5.0.5", - "resolved": "https://registry.npmjs.org/basic-ftp/-/basic-ftp-5.0.5.tgz", - "integrity": "sha512-4Bcg1P8xhUuqcii/S0Z9wiHIrQVPMermM1any+MX5GeGD7faD3/msQUDGLol9wOcz4/jbg/WJnGqoJF6LiBdtg==", + "version": "5.3.1", + "resolved": "https://registry.npmjs.org/basic-ftp/-/basic-ftp-5.3.1.tgz", + "integrity": "sha512-bopVNp6ugyA150DDuZfPFdt1KZ5a94ZDiwX4hMgZDzF+GttD80lEy8kj98kbyhLXnPvhtIo93mdnLIjpCAeeOw==", "license": "MIT", "engines": { "node": ">=10.0.0" @@ -3047,9 +3047,9 @@ } }, "node_modules/hono": { - "version": "4.10.6", - "resolved": "https://registry.npmjs.org/hono/-/hono-4.10.6.tgz", - "integrity": "sha512-BIdolzGpDO9MQ4nu3AUuDwHZZ+KViNm+EZ75Ae55eMXMqLVhDFqEMXxtUe9Qh8hjL+pIna/frs2j6Y2yD5Ua/g==", + "version": "4.12.29", + "resolved": "https://registry.npmjs.org/hono/-/hono-4.12.29.tgz", + "integrity": "sha512-1hNiRjawYrLq/4m3DQQjPGFg0VZkk4RjQJDff/excI6Dm9BiL75qxGrd7/c6YOxPdq6AscP3LiXhQ6fKFC1Waw==", "license": "MIT", "engines": { "node": ">=16.9.0" @@ -3243,9 +3243,9 @@ } }, "node_modules/ip-address": { - "version": "10.1.0", - "resolved": "https://registry.npmjs.org/ip-address/-/ip-address-10.1.0.tgz", - "integrity": "sha512-XXADHxXmvT9+CRxhXg56LJovE+bmWnEWB78LB83VZTprKTmaC5QfruXocxzTZ2Kl0DNwKuBdlIhjL8LeY8Sf8Q==", + "version": "10.2.0", + "resolved": "https://registry.npmjs.org/ip-address/-/ip-address-10.2.0.tgz", + "integrity": "sha512-/+S6j4E9AHvW9SWMSEY9Xfy66O5PWvVEJ08O0y5JGyEKQpojb0K0GKpz/v5HJ/G0vi3D2sjGK78119oXZeE0qA==", "license": "MIT", "engines": { "node": ">= 12" @@ -3503,9 +3503,19 @@ "license": "MIT" }, "node_modules/js-yaml": { - "version": "4.1.1", - "resolved": "https://registry.npmjs.org/js-yaml/-/js-yaml-4.1.1.tgz", - "integrity": "sha512-qQKT4zQxXl8lLwBtHMWwaTcGfFOZviOJet3Oy/xmGk2gZH677CJM9EvtfdSkgWcATZhj/55JZ0rmy3myCT5lsA==", + "version": "4.3.0", + "resolved": "https://registry.npmjs.org/js-yaml/-/js-yaml-4.3.0.tgz", + "integrity": "sha512-1td788aAnnZ5qs7V2QIRl1owjtYpbKt749Y3xauqQgwIIGF/xXWz1wMTEBx5O3LK3lXLVuqXPdPxj2BoFHaW9Q==", + "funding": [ + { + "type": "github", + "url": "https://github.com/sponsors/puzrin" + }, + { + "type": "github", + "url": "https://github.com/sponsors/nodeca" + } + ], "license": "MIT", "dependencies": { "argparse": "^2.0.1" @@ -3594,18 +3604,28 @@ "license": "MIT" }, "node_modules/linkify-it": { - "version": "5.0.0", - "resolved": "https://registry.npmjs.org/linkify-it/-/linkify-it-5.0.0.tgz", - "integrity": "sha512-5aHCbzQRADcdP+ATqnDuhhJ/MRIqDkZX5pyjFHRRysS8vZ5AbqGEoFIb6pYHPZ+L/OC2Lc+xT8uHVVR5CAK/wQ==", + "version": "5.0.2", + "resolved": "https://registry.npmjs.org/linkify-it/-/linkify-it-5.0.2.tgz", + "integrity": "sha512-ONTm2jCMAVZjgQa/Fy1kScXsuOoF5NPTsoFBdE1KVIZ2vAh/r9+Bqo+0jINCBYnavTPQZz38QzFTme79ENoN3Q==", + "funding": [ + { + "type": "github", + "url": "https://github.com/sponsors/puzrin" + }, + { + "type": "github", + "url": "https://github.com/sponsors/markdown-it" + } + ], "license": "MIT", "dependencies": { "uc.micro": "^2.0.0" } }, "node_modules/lodash": { - "version": "4.17.21", - "resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz", - "integrity": "sha512-v2kDEe57lecTulaDIuNTPy3Ry4gLGJ6Z1O3vE1krgXZNrsQ+LFTGHVxVjcXPs17LhbZVGedAJv8XZ1tvj5FvSg==", + "version": "4.18.1", + "resolved": "https://registry.npmjs.org/lodash/-/lodash-4.18.1.tgz", + "integrity": "sha512-dMInicTPVE8d1e5otfwmmjlxkZoUpiVLwyeTdUsi/Caj/gfzzblBcCE5sRHV/AsjuCmxWrte2TNGSYuCeCq+0Q==", "license": "MIT" }, "node_modules/log-symbols": { @@ -3665,14 +3685,24 @@ } }, "node_modules/markdown-it": { - "version": "14.1.0", - "resolved": "https://registry.npmjs.org/markdown-it/-/markdown-it-14.1.0.tgz", - "integrity": "sha512-a54IwgWPaeBCAAsv13YgmALOF1elABB08FxO9i+r4VFk5Vl4pKokRPeX8u5TCgSsPi6ec1otfLjdOpVcgbpshg==", + "version": "14.3.0", + "resolved": "https://registry.npmjs.org/markdown-it/-/markdown-it-14.3.0.tgz", + "integrity": "sha512-RCEsPjR+sr0x+AuYp601tKTkgFG4YEPLCzHST3cQ/fhlJkqAkz1L2/Qbp1j9qw5SBwQHFBoW8+hoN5xssOF0Tw==", + "funding": [ + { + "type": "github", + "url": "https://github.com/sponsors/puzrin" + }, + { + "type": "github", + "url": "https://github.com/sponsors/markdown-it" + } + ], "license": "MIT", "dependencies": { "argparse": "^2.0.1", - "entities": "^4.4.0", - "linkify-it": "^5.0.0", + "entities": "^4.5.0", + "linkify-it": "^5.0.2", "mdurl": "^2.0.0", "punycode.js": "^2.3.1", "uc.micro": "^2.1.0" @@ -5418,9 +5448,9 @@ } }, "node_modules/undici": { - "version": "6.22.0", - "resolved": "https://registry.npmjs.org/undici/-/undici-6.22.0.tgz", - "integrity": "sha512-hU/10obOIu62MGYjdskASR3CUAiYaFTtC9Pa6vHyf//mAipSvSQg6od2CnJswq7fvzNS3zJhxoRkgNVaHurWKw==", + "version": "6.27.0", + "resolved": "https://registry.npmjs.org/undici/-/undici-6.27.0.tgz", + "integrity": "sha512-YmfV3YnEDzXRC5lZ2jWtWWHKGUm1zIt8AhesR1tens+HTNv+YZlN/dp6G727LOvMJ8xjP9Be7Y2Sdr96LDm+pg==", "license": "MIT", "engines": { "node": ">=18.17" @@ -5661,9 +5691,9 @@ "license": "ISC" }, "node_modules/ws": { - "version": "8.18.3", - "resolved": "https://registry.npmjs.org/ws/-/ws-8.18.3.tgz", - "integrity": "sha512-PEIGCY5tSlUt50cqyMXfCzX+oOPqN0vuGqWzbcJ2xvnkzkq46oOpz7dQaTDBdfICb4N14+GARUDw2XV2N4tvzg==", + "version": "8.21.0", + "resolved": "https://registry.npmjs.org/ws/-/ws-8.21.0.tgz", + "integrity": "sha512-Vsp28b7DRcimFQvrqu2Wek3z1iYxDCWqHYB8Qsnk/S4RfaCQzPGPyBNuVjJV3cd6UiKtUtp6sNM77gWvzcCH+g==", "license": "MIT", "engines": { "node": ">=10.0.0" @@ -5733,15 +5763,18 @@ "license": "ISC" }, "node_modules/yaml": { - "version": "2.8.1", - "resolved": "https://registry.npmjs.org/yaml/-/yaml-2.8.1.tgz", - "integrity": "sha512-lcYcMxX2PO9XMGvAJkJ3OsNMw+/7FKes7/hgerGUYWIoWu5j/+YQqcZr5JnPZWzOsEBgMbSbiSTn/dv/69Mkpw==", + "version": "2.9.0", + "resolved": "https://registry.npmjs.org/yaml/-/yaml-2.9.0.tgz", + "integrity": "sha512-2AvhNX3mb8zd6Zy7INTtSpl1F15HW6Wnqj0srWlkKLcpYl/gMIMJiyuGq2KeI2YFxUPjdlB+3Lc10seMLtL4cA==", "license": "ISC", "bin": { "yaml": "bin.mjs" }, "engines": { "node": ">= 14.6" + }, + "funding": { + "url": "https://github.com/sponsors/eemeli" } }, "node_modules/yargs": { diff --git a/patterns/1-initial/ai-code-generation-context.md b/patterns/1-initial/ai-code-generation-context.md index 7bc88a5f6..b1f03a9ea 100644 --- a/patterns/1-initial/ai-code-generation-context.md +++ b/patterns/1-initial/ai-code-generation-context.md @@ -10,6 +10,18 @@ AI tools generate code that diverges from project standards and architectural pa With the growing use of AI tools (like GitHub Copilot, ChatGPT, or custom LLMs), InnerSource contributors are increasingly using generative AI to write code. However, without project-specific context, these tools often produce code that diverges from the project's architectural patterns, naming conventions, or quality standards. This leads to friction during reviews, inconsistent codebases, and technical debts or additional burden on maintainers. +## Story + +A few months ago, a team was working on a project with three engineers. They had put together a Technical Requirements Document—a shared agreement on what they were doing, how they'd do it, and why it mattered. Everything looked clear on paper. + +But once they started writing actual code using AI-assisted tools, something interesting happened. Even though all three were using AI and following the same requirements, the code they produced looked completely different. One engineer added the new logic inside an existing method. Another split it into private methods within the same file. The third created a brand-new helper class. + +Different structures. Same outcome. All technically correct. + +During code review, they sat down together, talked through their approaches, and aligned on how they wanted things done. After that meeting, the code started to look more consistent—not identical, but aligned. What happened in that meeting room? They set the context. + +Now imagine this in InnerSource. Contributors and code owners might never be in the same room—they could be in different time zones, different teams, different locations. How can a code owner share the right context with contributors across teams and repositories? That's the challenge this pattern addresses. + ## Context * InnerSource adoption is in place across the organization. @@ -37,18 +49,52 @@ Provide an **AI Code Generation Context** folder within the repository to guide ### Implementation Structure -Create an `innersource-ai/` folder in the repository root containing: - -#### Core Documentation Files (Required) - -`PROMPT.md`: Project-specific instructions for AI tools - -* Naming conventions (variables, functions, classes, files) -* Logging patterns and error handling approaches -* Testing strategy and preferred testing frameworks -* Code formatting and style preferences -* Common anti-patterns to avoid -* Preferred libraries and frameworks for specific tasks +Create a `context-store/` folder in the repository root containing: + +```code +context-store/ +├── README.md # How contributors should use this context store +├── PROMPT.md # Reusable AI prompt templates +├── ARCHITECTURE.md # Lightweight system overview +│ +├── contexts/ # Detailed project conventions +│ ├── coding-style.md # Naming, formatting, and code organization +│ ├── testing.md # Testing strategy, tools, and expectations +│ ├── security.md # Security guidelines and common risks +│ └── domain-guidelines.md # Project-specific business or domain rules +│ +├── CONFIG/ # Optional shared tooling configuration +│ ├── .editorconfig +│ └── formatter-config +│ +├── INTEGRATION/ # Optional AI tool setup guidance +│ ├── copilot.md +│ └── ide-setup.md +│ +└── EMBEDDINGS/ # Optional advanced retrieval assets + └── README.md +``` + +The exact filenames can vary by project, but the structure should make it clear where contributors can find general usage guidance, reusable prompts, architecture context, and detailed project conventions. + +#### Core Files (Required) + +Start with these three essential files: + +`README.md`: How to use the context store + +* Overview of the AI context store and its purpose +* Instructions for contributors on how to best leverage the context +* Guidelines for when and how to reference context files in AI prompts +* Examples of effective context usage +* Contribution guidelines for improving the context store + +`PROMPT.md`: Sample prompt templates + +* Ready-to-use prompt templates for common tasks +* Examples showing how to incorporate project context into AI prompts +* Templates for different scenarios (new features, bug fixes, refactoring, testing) +* Best practices for prompting AI tools with project-specific context `ARCHITECTURE.md`: Lightweight system overview @@ -58,25 +104,25 @@ Create an `innersource-ai/` folder in the repository root containing: * Module organization and layering principles * Integration patterns with external systems -`STYLE_GUIDE.md`: Comprehensive coding guidelines +#### Contexts (Required) +The `contexts/` folder contains detailed project-specific guidelines and conventions: + +* Naming conventions (variables, functions, classes, files) +* Logging patterns and error handling approaches +* Testing strategy and preferred testing frameworks +* Code formatting and style preferences +* Common anti-patterns to avoid +* Preferred libraries and frameworks for specific tasks * Language-specific style rules * Code organization patterns * Documentation standards * Performance considerations * Security guidelines and common vulnerabilities to avoid +* Project-specific and domain-specific instructions #### Enhancements (Optional) -##### Practical Examples - -`EXAMPLES/`: Sample code files demonstrating best practices - -* `good-examples/`: Well-written code snippets with explanations -* `bad-examples/`: Common mistakes with explanations of why they're problematic -* `refactoring-examples/`: Before/after code showing proper improvements -* Template files for common patterns (controllers, services, utilities) - ##### Configuration and Tooling `CONFIG/`: Shared formatter and analysis configurations @@ -101,11 +147,11 @@ Create an `innersource-ai/` folder in the repository root containing: * Vector embeddings of code examples * Semantic search capabilities for finding relevant patterns -**Context Efficiency**: Start with core documentation files (~1000 words of context) to balance context value with AI tool costs. Expand strategically based on measured impact on review cycles and code quality. +**Context Efficiency**: Start with core documentation files (<700-1000 token per context file) to balance context value with AI tool costs. Expand strategically based on measured impact on review cycles and code quality. **Naming Convention**: The suggested file and folder names follow industry common practices. However, codebase owners may choose alternative names that are more discoverable and relatable to their specific project or codebase. Any chosen naming convention should be clearly documented and communicated to contributors through proper documentation. Should files like [AGENTS.md](https://agents.md) and `.aiignore` become standard in the future, the naming conventions in this pattern might be adapted accordingly. -**Handling Existing Documentation**: If files like `ARCHITECTURE.md` already exist, the pragmatic approach is to keep them in their current location and add lightweight reference files in `innersource-ai` that point to them. When the architecture docs, style guides, or other materials are in Confluence or similar external systems, the `innersource-ai` folder becomes a crucial bridge between the codebase and external knowledge. This avoids duplication and keeps the folder consistent. For projects that want tighter integration, code owners could choose to reorganize and consolidate content under `innersource-ai`, but that requires more effort. The approach is flexible enough to support either approach—or even a hybrid—depending on what works best for the repository. +**Handling Existing Documentation**: If files like `ARCHITECTURE.md` already exist, the pragmatic approach is to keep them in their current location and add lightweight reference files in `context-store` that point to them. When the architecture docs, style guides, or other materials are in Confluence or similar external systems, the `context-store` folder becomes a crucial bridge between the codebase and external knowledge. This avoids duplication and keeps the folder consistent. For projects that want tighter integration, code owners could choose to reorganize and consolidate content under `context-store`, but that requires more effort. The approach is flexible enough to support either approach—or even a hybrid—depending on what works best for the repository. ### Usage Patterns @@ -123,7 +169,9 @@ Create an `innersource-ai/` folder in the repository root containing: * **IDE Integration**: Configure AI plugins to automatically include context * **Custom Workflows**: Integrate context into CI/CD pipelines for automated validation -### Maintenance Strategy +#### For Project Owners + +**Maintenance Strategy**: * **Version Control**: Track changes to AI context alongside code changes * **Regular Updates**: Review and update context as project standards evolve @@ -144,7 +192,7 @@ Create an `innersource-ai/` folder in the repository root containing: This pattern addresses the fundamental mismatch between AI tools' general training and project-specific requirements. By providing structured, easily consumable context, we enable AI tools to generate code that feels like it was written by an experienced project contributor rather than an outsider. -The `innersource-ai/` folder approach is intentionally explicit and discoverable, making it clear to both humans and AI tools where to find project-specific guidance. The modular structure allows teams to implement incrementally, starting with basic style guides and expanding to more sophisticated examples and configurations as needed. +The `context-store/` folder approach is intentionally explicit and discoverable, making it clear to both humans and AI tools where to find project-specific guidance. The modular structure allows teams to implement incrementally, starting with basic style guides and expanding to more sophisticated examples and configurations as needed. This solution balances the productivity benefits of AI tools with the quality requirements of professional software development, creating a sustainable approach to AI-assisted InnerSource collaboration. @@ -152,6 +200,7 @@ This solution balances the productivity benefits of AI tools with the quality re * Initial * Drafted in August 2025 +* Updated in July 2026 ## Authors diff --git a/patterns/1-initial/assisted_compliance.md b/patterns/1-initial/assisted_compliance.md index 9bfd0b58a..ca0c089ea 100644 --- a/patterns/1-initial/assisted_compliance.md +++ b/patterns/1-initial/assisted_compliance.md @@ -4,7 +4,7 @@ Assisted Compliance ## Patlet -TBD +Repo owners resist adding compliance documentation like CONTRIBUTING.md, blocking contributions and slowing InnerSource adoption. A compliance task force breaks the stalemate by writing the missing documentation as a pull request on behalf of the resistant team, framing it as helpful contribution rather than enforcement. ## Problem diff --git a/patterns/1-initial/bad-weather-for-liftoff.md b/patterns/1-initial/bad-weather-for-liftoff.md index 3397188a2..92a061708 100644 --- a/patterns/1-initial/bad-weather-for-liftoff.md +++ b/patterns/1-initial/bad-weather-for-liftoff.md @@ -4,7 +4,7 @@ Bad weather for liftoff ## Patlet -TBD +An InnerSource initiative fails to demonstrate improvement in quality or speed because the team lacks open source development experience and deadline pressure prevents adopting new ways of working. Starting InnerSource pilots with experienced practitioners and protecting time for new practices are prerequisites for success. ## Problem diff --git a/patterns/1-initial/balancing-openness-and-security.md b/patterns/1-initial/balancing-openness-and-security.md index ee11406dd..9afa74e76 100644 --- a/patterns/1-initial/balancing-openness-and-security.md +++ b/patterns/1-initial/balancing-openness-and-security.md @@ -1,17 +1,17 @@ -# Title +## Title Balancing Openness and Security -# Patlet +## Patlet While InnerSource flourishes in environments with a high degree of shared code, Security/Legal prefers the limitation of source code access to only those that need it. By making Security/Legal part of the team, introducing explicit sharing levels and security policies for shared repositories, as well as defining what qualifies as sensitive information, code sharing can be facilitated while minimizing the associated risks. -# Problem +## Problem A successful InnerSource program needs openness and transparency (e.g. access to code, issues, documentation, and roadmap), while good security practice is to minimize access, following the [principle of least privilege][principle-of-least-privilege]. How to balance and address these seemingly contradicting requirements? -# Story +## Story Most organizations developing proprietary software will have source code that they do not want to leave the organization, as this may harm their business. Think what would happen when the major competitors would have access to their latest features and would know what they are working on next. @@ -19,7 +19,7 @@ Even when the source code management system is not compromised from the outside, Restricting access typically reduces the risk of these things from happening, but at the same time hampers collaboration and re-use. -# Context +## Context - The organization has an InnerSource Program Office (ISPO), or a similar group, steering the success of the InnerSource initiative in the organization. One of their goals is to stimulate maximum openness and transparency in the organization. - The organization has a Security Team constraining unnecessary data access to prevent the organization from data-leakage and malicious code injection. @@ -27,7 +27,7 @@ Restricting access typically reduces the risk of these things from happening, bu - "Closed Source" is the default in the organization when creating new repositories, i.e. only the team owning/maintaining the code has access to the given repo. - "Shared Source" within the organization isn’t common practice. Organizational teams aren’t familiar with what code or information should or shouldn’t be placed in shared repositories. -# Forces +## Forces - A successful InnerSource program needs openness and transparency (e.g. access to code, issues, documentation, and roadmap) - Good security practice is to minimize access, following the [principle of least privilege][principle-of-least-privilege]. @@ -35,13 +35,13 @@ Restricting access typically reduces the risk of these things from happening, bu - Engineering Teams focus more on service/product development or knowledge sharing than on measures for data protection. While it is easy for Engineering Teams to decide to close or open the repository, they are usually not willing to spend time on judging how to reach a balance between both. Or to refactor their code in order to be able to share more. - No one-fit-all guideline or rules to judge what data or process is to be secured or not. That much depends on data sensitivity and overall security policy/infrastructure. -# Solutions +## Solutions To reduce the misalignment and possible misunderstanding between the teams involved, it is key to bring everybody together so that they can express their goals and concerns, and develop shared language together. After that they can decide as a group how to drive the execution of the specific goals, and what to do to reduce the risks that were identified. -## Setup +### Setup Start by bringing (representatives from) Engineering, Security, Legal, and the ISPO together, to discuss the goals of the InnerSource initiative, as well as any security concerns. @@ -55,13 +55,13 @@ Some helpful practices are: - **SHARED** - inner source: accessible for all software developers in the organization - **CLOSED** - closed source: only accessible to named individuals in the organization -## Execution +### Execution How to allow for a greater amount of SHARED code in the organizations depends a lot on the specific business domain, related regulations, and concerns identified in the initial meetings of the InnerSource task force as mentioned above. Following are some practices that have proven to be helpful in reducing security concerns and allowing for a greater amount of SHARED code. -### Security Training and SCM Setup +#### Security Training and SCM Setup - Employee training about security awareness and individual responsibility - Enhanced security measures or policies on source code management (SCM) system to prevent malicious access to shared repositories and reduce the impact of the same: @@ -76,12 +76,12 @@ Following are some practices that have proven to be helpful in reducing security - downloading source code from new devices - downloading a great amount of source code in the monitoring period. -### Split out the 'secret sauce' into separate repos +#### Split out the 'secret sauce' into separate repos Separate highly specific, differentiating code (the 'secret sauce') from code that is considered commodity in the organization (e.g. infrastructure, platform, and UI components). By placing them in separate repositories, you increase your chances of offering the commodity code as SHARED repos, while the 'secret sauce' may stay CLOSED. -### Prevent sensitive information in shared repositories +#### Prevent sensitive information in shared repositories Build up agreed security requirement of InnerSource, such as: @@ -92,7 +92,7 @@ Build up agreed security requirement of InnerSource, such as: - Leverage secrets scanning tools to scan the target repositories (including code, test cases, and helper scripts) for confidential data such as accounts, passwords, access tokens, keys, and other sensitive data. - Keep repositories CLOSED, but expose metadata about the projects (i.e. through an [InnerSource Portal][innersource-portal]), and create some kind of access request workflow. This way you could still give people access to the code, but not open it to everyone by default. *(Note: The full model is described under **Extension: An Additional Sharing Level**)* -### Extension: An Additional Sharing Level +#### Extension: An Additional Sharing Level In some cases, introducing additional sharing levels might be appropriate. Use cases include: @@ -118,7 +118,7 @@ Repositories with RESTRICTED sharing level are included in the [central catalog] - RESTRICTED repos will likely get fewer contributions due to the additional step to access the code. Where possible, INTERNAL repos should be preferred. - It is possible to use a tool that automatically adds the `README.md` and some other metadata to an internal repository in GitHub, allowing the GitHub search feature to include this data in the search results. -# Sketch +## Sketch ``` Example Repository Sharing Levels @@ -137,7 +137,7 @@ Example Repository Sharing Levels └──────┘ ``` -# Resulting Context +## Resulting Context InnerSource adoption in an organization will often [start as an experiment][start-as-an-experiment], with a small number of SHARED repositories. @@ -149,32 +149,32 @@ With the increased confidence and lessons learned from this experiment, the task Most importantly, the changes implemented through this pattern lead to more code being shared between teams, and closed source will no longer be the obvious default. -# Known Instances +## Known Instances * Philips * Verizon -# Status +## Status - Initial -# Authors +## Authors - Bart Golsteijn - Jack Yang - Sebastian Spier -# Acknowledgements +## Acknowledgements - Conley Rogers -# Alias +## Alias - Secure Discoverability - Secure Code Sharing - Secure InnerSource -# Notes (internal) +## Notes (internal) *These notes are meant for internal use within the InnerSource Commons Patterns Working Group only.* diff --git a/patterns/1-initial/centralized-repository-governance.md b/patterns/1-initial/centralized-repository-governance.md new file mode 100644 index 000000000..f1b13f75a --- /dev/null +++ b/patterns/1-initial/centralized-repository-governance.md @@ -0,0 +1,231 @@ +## Title + +Centralized InnerSource Repository Governance + +## Patlet + +InnerSource repositories lose contributor readiness when project hygiene drifts across teams. A central governance repository defines readiness checks as policy-as-code and runs automated audits that help Trusted Committers and repository maintainers keep projects discoverable, understandable, and contribution-ready without removing local ownership. + +## Problem + +As InnerSource adoption grows, teams publish repositories with uneven documentation, ownership clarity, contribution guidance, communication channels, and discoverability metadata. Some projects have strong [Standard Base Documentation](../2-structured/base-documentation.md) (like `README.md` and `CONTRIBUTING.md`); others have no maintainer contact, no issue templates, unclear CODEOWNERS, stale labels, or no clear signal that outside contributions are welcome. + +Contributors then hesitate. They cannot tell whether a repository is active, who owns it, how to ask questions, what contributions are welcome, or whether the project follows the organization's InnerSource standards. Manual reviews by an InnerSource Program Office, platform team, or community group do not scale. + +## Story + +An InnerSource Program Office observed that contributors often stopped before opening a pull request. The source code was visible, but the contribution path was not. Some repositories lacked `CONTRIBUTING.md`; others had outdated contacts or no newcomer-friendly issue labels. + +The program office created a governance repository with versioned InnerSource readiness policies. A scheduled audit compared participating repositories with those policies and sent [Trusted Committers](../2-structured/trusted-committer.md) and repository maintainers a concise report: Which checks passed, which needed attention, who owned the repository, and how to remediate gaps. + +The audit did not block teams. It made readiness visible and helped maintainers improve discoverability, documentation, ownership, and contribution paths. + +## Context + +* InnerSource is practiced across many teams, business units, or repositories. +* Teams retain ownership of their repositories and contribution process. +* Contributors need clear signals for how to use, discuss, and contribute to projects. +* Trusted Committers and repository maintainers keep project documentation and contribution paths usable. +* An InnerSource Program Office, platform team, or community group stewards shared readiness expectations. +* An InnerSource Portal, source code inventory, or repository catalogue may already exist. +* GitHub Actions, GitHub APIs, or similar automation tooling is available. + +### Use This Pattern When + +* You have many InnerSource repositories owned by different teams. +* Contributors struggle to identify how to use or contribute to projects. +* InnerSource Portal quality depends on repository metadata and project hygiene. +* Manual readiness checks are too slow or incomplete. +* You want transparent policy-as-code instead of undocumented central checks. +* Poor contributor experience costs more than maintaining the governance process. + +### Don’t Use This Pattern When + +* Only a few InnerSource repositories exist and manual support is enough. +* You need hard enforcement at merge time rather than periodic guidance. +* You cannot maintain repository ownership or lifecycle metadata. +* You cannot protect the governance repository and its credentials. +* Most projects require unique contribution models that do not fit a small set of profiles. + +## Forces + +* **Autonomy vs consistency:** Teams need local ownership; contributors need predictable project signals. +* **Contributor confidence:** Missing documentation, stale ownership, or unclear communication channels discourage contributions. +* **Scale:** Manual InnerSource readiness reviews fail as repository count grows. +* **Signal quality:** Noisy or generic findings are ignored. +* **Quality over presence:** A repository can contain the expected files and still be hard to contribute to if they are incomplete, outdated, or ignored. +* **Valid variation:** Governance levels and maturity stages may need different readiness expectations. +* **Infrastructure strain:** Large audits can consume API rate limits, runner capacity, logs, and team attention. +* **Control-plane security:** Tampering with governance policies, exceptions, inventory, or workflows can hide readiness gaps across many repositories. + +## Solution + +Create a **central InnerSource governance repository** that defines contributor-readiness expectations as policy-as-code. Run audits of these policies across all repositories in scope. + +Treat it as an internal product with clear roles, review rules, actionable reports, and an exception process. + +Example structure: + +```text +innersource-governance/ + policies/ + default/ + base-documentation.yml + contribution-process.yml + communication.yml + discoverability.yml + shared-ownership/ + codeowners.yml + maintainer-model.yml + repository-inventory.yml + exceptions.yml + audit/ + audit.py + .github/ + workflows/ + readiness-audit.yml +``` + +### InnerSource Policies + +Store readiness expectations in `policies/`. Use a small set of profiles aligned with your InnerSource operating models, such as `default`, `contributions-welcome`, or `shared-ownership`. + +Typical checks include: + +* `README.md` with purpose, usage, and getting-started guidance, +* `CONTRIBUTING.md` with contribution and review expectations, +* CODEOWNERS or documented maintainer ownership, +* issue and pull request templates, +* documented communication channels, +* support or maintainer contact information, +* license or internal sharing guidance, +* repository description, topics, and discoverability metadata, +* labels such as `good first issue` or `help wanted`, +* InnerSource Portal badge or registration metadata, and +* repository settings that support trusted collaboration, such as branch protection or workflow permissions. + +Avoid checkbox compliance. Where possible, evaluate freshness, required sections, useful links, and whether contribution-related information is maintained. + +### Repository Inventory + +Maintain the audit scope in `repository-inventory.yml`, or import it from an [InnerSource Portal](../2-structured/innersource-portal.md) or [Unified Source Code Inventory](../1-initial/source-code-inventory.md). + +```yaml +repositories: + - name: payments-api + owner: payments-platform-team + profile: contributions-welcome + lifecycle: active + portal_slug: payments-api +``` + +Each repository should have an owner, lifecycle state, and assigned InnerSource profile. If a portal or inventory is already authoritative for ownership, lifecycle, or discoverability metadata, consume that data instead of duplicating it. Store only governance-specific configuration in the governance repository. + +### Exception Registry + +Record approved deviations from the readiness baseline in `exceptions.yml`. Each exception needs an owner, reason, and expiry or review date. + +```yaml +exceptions: + - repository: payments-api + policy: issue_templates_required + reason: Team is migrating from an external tracker this quarter. + owner: payments-platform-team + expires: 2026-12-31 +``` + +Exceptions keep governance practical, but they must remain visible in reports. Avoid broad or non-expiring exceptions because they hide contributor-experience problems. + +### Readiness Audit + +Audit each repository against its assigned InnerSource policy profile. Findings should include repository, owner, policy, severity, expected state, actual state, exception status, and suggested remediation. + +Prioritize checks that affect contributor success: + +* missing or incomplete base documentation, +* missing contribution process, +* unclear ownership or maintainer contact, +* undocumented communication channel, +* missing issue or pull request templates, +* stale portal metadata or missing discoverability tags, +* missing newcomer-friendly labels, and +* repository settings that make contribution review unsafe or unclear. + +Design the audit to be incremental and rate-aware. Store the last known state and re-check changed repositories where possible. Use `ETag` / `If-None-Match`, cache expensive checks such as repository metadata, branch names, workflow files, and CODEOWNERS, and use GraphQL batching carefully for bulk metadata. Stagger scans by importance: active InnerSource projects nightly, candidate projects every few days, and archived or sandbox repositories weekly or monthly. + +### Reporting and Remediation + +Run the audit on a schedule and publish a digest report. + +```yaml +on: + schedule: + - cron: "0 2 * * *" +``` + +Start with visibility-only reporting. Reports should help Trusted Committers, repository maintainers, and contributors improve contributor experience; they should not rank or shame teams. Leadership views should aggregate trends without ranking individual teams. + +For each finding, include remediation guidance or links to templates. If remediation is automated later, use reviewable pull requests for straightforward fixes, such as adding a missing template file. + +Track: + +* percentage of repositories covered, +* percentage passing readiness checks, +* open findings by severity, +* mean time to remediate contributor-blocking gaps, +* active and expired exceptions, +* false positives and repeated findings, +* audit runtime, API usage, and runner minutes. + +### Govern the Governance Repository + +The governance repository should itself follow strong InnerSource practices. Policy changes happen through pull requests with visible discussion and review by the InnerSource Program Office, platform team, security partners, and affected Trusted Committers or repository maintainers. + +Roles: + +* **Contributors** use readiness signals to decide whether and how to contribute. +* **Trusted Committers and repository maintainers** keep project guidance current and act on findings. +* **InnerSource Program Office or community stewards** maintain readiness policies, templates, and reporting practices. +* **Platform and security partners** support automation, credentials, repository settings, and control-plane protection. +* **Product Owners or business sponsors** help prioritize remediation when contributor-readiness work competes with feature delivery. + +Trusted Committers and repository maintainers should be able to propose policy changes, improve templates, and challenge low-value checks. + +Protect the governance repository more strictly than ordinary project repositories. Require branch protection, mandatory reviews, CODEOWNERS approval for `policies/`, `exceptions.yml`, inventory, audit code, and workflows, and signed or verified changes for sensitive files. + +Use least-privilege credentials. Separate read-only audit credentials from remediation credentials. Log and alert on changes to policies, exceptions, inventory, workflows, and credentials. Periodically audit the governance repository through an independent check. + +## Resulting Context + +* Contributors can quickly assess whether a repository is ready for InnerSource participation. +* Trusted Committers and repository maintainers receive actionable guidance for documentation, ownership, communication, and discoverability. +* InnerSource expectations are transparent, version-controlled, and open to contribution. +* Exceptions are explicit, time-bound, and visible. +* InnerSource Portal and inventory data become more reliable. +* Incremental, staggered scans control audit cost and infrastructure load. +* Leadership sees InnerSource health trends without micromanaging Trusted Committers or repository maintainers. + +## Known Instances + +TBD + +## Status + +* Initial + +## Authors + +* [Amburi Roy](https://www.linkedin.com/in/amburi/) + +## Related Patterns + +* [Standard Base Documentation](../2-structured/base-documentation.md) — defines contributor-facing files that readiness checks can evaluate. +* [Assisted Compliance](assisted_compliance.md) — helps Trusted Committers and repository maintainers add missing contribution guidance. +* [Communication Tooling](../2-structured/communication-tooling.md) — describes communication channels that readiness checks can require. +* [Issue Tracker Use Cases](../2-structured/issue-tracker.md) — supports checks for issue templates and transparent planning. +* [Unified Source Code Inventory](../1-initial/source-code-inventory.md) — can provide audit scope and repository metadata. +* [Explicit Governance Levels](../2-structured/governance-levels.md) — can provide profiles for InnerSource operating models. +* [InnerSource Portal - Hygiene](innersource-portal-hygiene.md) — overlaps with checks for portal badges, metadata, and active projects. +* [Include Product Owners](include-product-owners.md) — helps with stewardship of the governance repository. +* [Trusted Committer](../2-structured/trusted-committer.md) — supports safe and consistent policy changes. +* [InnerSource Portal](../2-structured/innersource-portal.md) — complements central access to shared organizational knowledge. diff --git a/patterns/1-initial/change-the-developers-mindset.md b/patterns/1-initial/change-the-developers-mindset.md index 654325cb5..c4fc9073f 100644 --- a/patterns/1-initial/change-the-developers-mindset.md +++ b/patterns/1-initial/change-the-developers-mindset.md @@ -4,7 +4,7 @@ Change the developers mindset ## Patlet -TBD +Developers resist adopting InnerSource collaboration practices because they are comfortable with existing hierarchical workflows and middle management does not actively support the change. Combining visible recognition of InnerSource contributions, formalized training, clearer processes, and explicit management objectives creates the conditions needed to shift developer behavior. ## Problem diff --git a/patterns/1-initial/code-consumers.md b/patterns/1-initial/code-consumers.md index eaee8ef11..06432fbb0 100644 --- a/patterns/1-initial/code-consumers.md +++ b/patterns/1-initial/code-consumers.md @@ -1,12 +1,12 @@ -# Title +## Title Code Consumers -# Patlet +## Patlet -TBD +When a team opens their code for InnerSource reuse, they lose visibility into who is consuming it, making it hard to communicate vulnerabilities, gauge adoption, or retire deprecated components. Lightweight mechanisms such as dependency scanning, voluntary registration, or opt-in mailing lists restore that visibility without adding friction for consumers. -# Problem +## Problem There's several reasons why we might want to know who's using (consuming) our code. We can't do the following: @@ -16,18 +16,18 @@ There's several reasons why we might want to know who's using (consuming) our co * encourage others to use a project - by showing how many users there already are * survey users for feedback -# Context +## Context This is a general issue that affects potentially all InnerSource (and open source!) projects. The act of opening code allows people to use it without letting you know. -# Forces +## Forces * The harder it is to download/integrate the project, the less it will be adopted (forcing people to give information when they use it adds barriers) * Not all projects may want you to know what they're using (tightly closed source/top secret downstream project) * Putting in callback/call home routines into projects may introduce distrust in downstream projects and users -# Solutions +## Solutions The following are potential solutions that have been proposed to this problem: @@ -37,21 +37,21 @@ The following are potential solutions that have been proposed to this problem: * Audit code clones/artifact downloads * Incentivise/Offer users a mailing list/update stream to which they can subscribe -# Resulting Context +## Resulting Context TBD -# Known Instances +## Known Instances TBD -# Authors +## Authors * Georg Grütter (Robert Bosch GmbH) * Raimund Hook (EXFO Inc) * Katrina Novakovic (RedHat) -# Status +## Status * Initial * Drafted at the 2019 Spring InnerSource Commons Summit in Galway - 10 April 2019 diff --git a/patterns/1-initial/cultural-change-through-hiring.md b/patterns/1-initial/cultural-change-through-hiring.md index 9f96444f2..5472d426d 100644 --- a/patterns/1-initial/cultural-change-through-hiring.md +++ b/patterns/1-initial/cultural-change-through-hiring.md @@ -4,7 +4,7 @@ Culture Change through Hiring ## Patlet -TBD +An InnerSource program struggles to reach critical mass because most existing employees lack open source or InnerSource experience, and HR does not factor in collaborative development skills when recruiting or reviewing performance. By aligning Engineering and HR to actively seek and develop these skills, organizations accelerate cultural change and build a self-sustaining InnerSource community. ## Problem diff --git a/patterns/1-initial/defeat-hierarchical-constraints.md b/patterns/1-initial/defeat-hierarchical-constraints.md index b26ac86da..ffd54ec7d 100644 --- a/patterns/1-initial/defeat-hierarchical-constraints.md +++ b/patterns/1-initial/defeat-hierarchical-constraints.md @@ -4,7 +4,7 @@ Defeat Hierarchical Constraints ## Patlet -TBD +In strongly hierarchical organizations, developers want to contribute to InnerSource projects but are blocked by direct managers who prioritize their own team's goals and fear losing their team's time to cross-team work. Making InnerSource contributions a recognized part of individual performance goals and helping managers see concrete benefits for their own teams can empower developers to participate despite these constraints. ## Problem diff --git a/patterns/1-initial/developer-incentive-alignment-for-innersource-contribution.md b/patterns/1-initial/developer-incentive-alignment-for-innersource-contribution.md index 55a04ab7a..b48b3d73d 100644 --- a/patterns/1-initial/developer-incentive-alignment-for-innersource-contribution.md +++ b/patterns/1-initial/developer-incentive-alignment-for-innersource-contribution.md @@ -4,7 +4,7 @@ Developer Incentive Alignment for InnerSource Contribution ## Patlet -TBD +Developers are not motivated to contribute to InnerSource because organizational incentives reward individual code output over cross-team mentorship and collaboration, leading to siloed work. By embedding InnerSource contribution and mentorship expectations into job descriptions and promotion criteria at each career level, organizations align personal career advancement with InnerSource participation. ## Problem @@ -16,7 +16,7 @@ TBD ## Context -* There is a need to foster team-centric behaviour and limit instances of [ego-driven development](http://deliberate-software.com/ego-driven-development/) or idolizing a 'star developer.' +* There is a need to foster team-centric behavior and limit instances of [ego-driven development](https://deliberate-software.com/ego-driven-development/) or idolizing a 'star developer.' * There are multiple developers within the organization or business unit with the same or related areas of expertise, such as front-end development, devops, testing, etc. * Mid-to-top level management either do not have a technical background or their technical backgrounds and experiences are many years out of date; organizational emphasis is therefore on quantitative output of development team. * The organization wants to create more alignment between work efforts and external motivation without relying directly on financial rewards or quotas. @@ -26,7 +26,7 @@ TBD 1. Existing attitudes and developer culture - * Team-centric behaviour is not evident. Developers of all levels tend to focus mostly on their own contributions. When stories are assigned, work is often done ‘locally’ and not pushed up or checked in until the end of the sprint. + * Team-centric behavior is not evident. Developers of all levels tend to focus mostly on their own contributions. When stories are assigned, work is often done ‘locally’ and not pushed up or checked in until the end of the sprint. * Asking developers to push code early and often is met with extreme resistance, accusations of micro-management, or claims that such a practice would slow velocity. * Existing practice commonly leads to duplicated work, missed requirements, or frequent gaps in the software or process. @@ -64,11 +64,11 @@ TBD * job descriptions include mentorship & contribution language to set expectations up front & make it easier to assess if candidates have requisite skills/experience required * org is retaining and better utilizing existing talent * devs take on professional mentorship responsibilities for their peers rather than leaving it to non-technical management -* career progression clearly identified & understood by engs and management +* career progression clearly identified & understood by engineers and management ## Known Instances -TBD +* **Thales Group** - InnerSource contributions are part of the expert career path at Thales. The Thales ISPO positioned InnerSource participation as demonstrable proof of leadership and expertise, which engineers can reference when seeking the expert career path. The rationale: building communities around specific topics on top of their operational commitments demonstrates leadership and recognised expertise on those topics. See: [Why People Matter Most: Building a Sustainable InnerSource Strategy](https://www.youtube.com/watch?v=r0dx84lUDYY) (InnerSource Commons, 2026, by Marius Moulis). ## Status diff --git a/patterns/1-initial/duplicated-projects.md b/patterns/1-initial/duplicated-projects.md index d929d379a..d64c59f8b 100644 --- a/patterns/1-initial/duplicated-projects.md +++ b/patterns/1-initial/duplicated-projects.md @@ -4,7 +4,7 @@ Duplicated Projects ## Patlet -TBD +After opening codebases through InnerSource, teams discover they have independently built overlapping or identical products, but territorial management and differing technical approaches make consolidation difficult. Establishing a neutral governance process that gives all managers meaningful influence over the merged project makes it possible to consolidate duplicated efforts without losing key stakeholders. ## Problem diff --git a/patterns/1-initial/explicit-shared-ownership.md b/patterns/1-initial/explicit-shared-ownership.md index 87104cb76..43be8a8b7 100644 --- a/patterns/1-initial/explicit-shared-ownership.md +++ b/patterns/1-initial/explicit-shared-ownership.md @@ -1,12 +1,12 @@ -# Title +## Title Explicit Shared Ownership -# Patlet +## Patlet A software component that several teams depend on has grown to the point where owners are no longer capable of taking full ownership. There is confusion who to involve for changes. Sharing ownership explicitly and making expected behavior visible removes ambiguity. Writing a contributions document creates a natural way to evolve ownership. -# Problem +## Problem An organization is already using InnerSource best practices in several teams. The architecture of the software offered has grown organically. @@ -14,7 +14,7 @@ While talking about code ownership and accountability, teams notice that there i Simply forking the component would lead to a lot of duplication and wasted effort. Therefore the involved teams are looking for a less intrusive solution to the issue. -# Context +## Context - Teams are working independently but are providing one common platform as a service. @@ -22,7 +22,7 @@ Simply forking the component would lead to a lot of duplication and wasted effor - One component is in widespread use but ownership is unclear. -# Forces +## Forces - Ownership of one component is unclear. @@ -31,13 +31,13 @@ Simply forking the component would lead to a lot of duplication and wasted effor - There may be people dependent on the module that are not yet known. There often is fear around maintenance efforts arising from unwanted attribution to the project. -# Solution +## Solution Use the issue/ pull-request mechanics that work so well for code modifications to modify the way the component is developed: A volunteer creates an issue in the component's repository highlighting the apparent unclarity or even lack of ownership. Subsequently a volunteer (can be the same person) creates a suggestion for how the project should be developed going forward including a proposed list of initial [Trusted Committers](../2-structured/trusted-committer.md). This suggestion is posted to the project's documentation (e.g. it's `README.md` file) as a pull request. This pull request is left open and shared with all people affected by the change. Feedback can be given and integrated asynchronously. Development of the final state is transparent for everyone. -# Resulting Context +## Resulting Context There is an initial team of [Trusted Committers](../2-structured/trusted-committer.md) committed to the component. @@ -47,7 +47,7 @@ The entire decision process backing the result is transparent and can be influen There is a proven way to adjust the setup in the future. -# Status +## Status Initial (early draft) diff --git a/patterns/1-initial/innersource-ambassador.md b/patterns/1-initial/innersource-ambassador.md index cbb9e9931..b5a683b84 100644 --- a/patterns/1-initial/innersource-ambassador.md +++ b/patterns/1-initial/innersource-ambassador.md @@ -76,6 +76,7 @@ Here some examples from the commercial domain, academia and open source: - **[WellSky](https://wellsky.com/)** has the analogous concept of InnerSource Champions representing each business area of the company. - **Siemens** has 70 Social Coding Ambassadors from across subsidiaries and countries that promote the Open and InnerSource mindset across the company. - **Robert Bosch GmbH** has the analogous concept of *Social Coding Advocates*. +- **Thales Group** calls these representatives "Steering Board members." Each Community Leader represents an InnerSource community within their organizational unit and meets quarterly with the Thales ISPO in a "Steering Board" session to surface blockers and emerging needs from the field. The ISPO carries these inputs to the executive sponsorship board, creating a structured bottom-up/top-down governance loop. See: [Why People Matter Most: Building a Sustainable InnerSource Strategy](https://www.youtube.com/watch?v=r0dx84lUDYY) (InnerSource Commons, 2026, by Marius Moulis). ## Status diff --git a/patterns/1-initial/innersource-as-career-booster.md b/patterns/1-initial/innersource-as-career-booster.md index f2fe58e2b..245d9f09a 100644 --- a/patterns/1-initial/innersource-as-career-booster.md +++ b/patterns/1-initial/innersource-as-career-booster.md @@ -55,6 +55,24 @@ The organization sees better collaboration and higher retention among high-perfo This creates a reinforcing loop where career incentives and organizational goals align more closely. +### Consequences + +#### Positive: + +* Broader network across the organization → more opportunities and visibility. +* Enhanced reputational capital: people know your name, your contributions, and how you collaborate. +* Accelerated skill development via cross-team exposure and knowledge sharing. +* Increased job satisfaction and engagement, which supports career momentum and retention. +* Potential for roles beyond your original team (architecture, community lead, cross‐team specialist). + +#### Cautions: + +* Without genuine value and visibility, contributions may go unnoticed; simply “ticking a box” isn’t enough. +* Overcommitment: spreading too thin across many InnerSource projects may reduce focus and lead to burnout rather than a career boost. +* Without building social capital intentionally (not just coding), the career benefit may be limited—according to the study the effect is mediated by social capital rather than direct. +University of Galway Research +* The organization must provide the infrastructure and culture for InnerSource (e.g., open repositories, cross-team access, recognition mechanisms); otherwise contributions may not yield the expected social capital. + ## Rationale From a **career development** perspective, diverse project experience, network breadth, and initiative-taking are strong signals of promotability. @@ -63,6 +81,15 @@ From a **career development** perspective, diverse project experience, network b From a **game theory** lens, InnerSource transforms isolated career efforts into a reputational economy, where value created for others is returned through visibility, referrals, and opportunities. +Research findings (Stol et al., 2024) further confirm: + +* Developers engaging in InnerSource report increased job satisfaction. +* This effect is not direct—it is mediated by gains in three dimensions of social capital: + 1. **Structural** — broader networks across teams + 2. **Cognitive** — shared understanding of technical and collaborative norms + 3. **Relational** — trust, reliability, and reputation +* These outcomes align closely with the career successes observed in active InnerSource contributors. + ## Known Instances TBD @@ -78,11 +105,13 @@ TBD ## References +- Klaas-Jan Stol, Mario Schaarschmidt, Lorraine Morgan: Does adopting inner source increase job satisfaction? A social capital perspective using a mixed-methods approach. [Research paper](https://www.sciencedirect.com/science/article/pii/S0963868724000015). - Dirk Riehle - [How Open Source Is Changing the Software Developer’s Career](https://dirkriehle.com/wp-content/uploads/2015/04/r5rie-v3.pdf) - Bertrand Delacretaz - [How to convince your left brain (or manager) to follow the Open Source path your right brain desires](https://www.youtube.com/watch?v=F0SmiQ3SF6Q) ## Alias +- Creating Social Capital through InnerSource - Career Growth through InnerSource - InnerSource for Personal Branding - Cross-Team Contributions as Promotion Strategy diff --git a/patterns/1-initial/junkyard-styled-innersourcing.md b/patterns/1-initial/junkyard-styled-innersourcing.md index 6042dd90a..b9eed9a58 100644 --- a/patterns/1-initial/junkyard-styled-innersourcing.md +++ b/patterns/1-initial/junkyard-styled-innersourcing.md @@ -5,7 +5,7 @@ ## Patlet -TBD +Developers share code internally for the sake of sharing without regard for reusability or production readiness, resulting in a repository of low-quality components that others find but cannot safely use. Supporting all contributions while transparently communicating component maturity — and engaging contributors in quality improvements — keeps the shared repository growing without discouraging participation. ## Context diff --git a/patterns/1-initial/organizational-mindset-change.md b/patterns/1-initial/organizational-mindset-change.md index 85d7b88ff..499451439 100644 --- a/patterns/1-initial/organizational-mindset-change.md +++ b/patterns/1-initial/organizational-mindset-change.md @@ -4,7 +4,7 @@ Organizational Mindset Change ## Patlet -TBD +Upper management, middle management, and developers all need to shift their mindset to support InnerSource, but organizational change is slow and costly, and pressures from deadlines and competition make experimentation feel too risky. A phased approach that starts with a small visible experiment, demonstrates concrete value early, and uses that momentum to broaden adoption is the most effective path to lasting culture change. ## Problem diff --git a/patterns/1-initial/overcome-acquisition-based-silos-developer.md b/patterns/1-initial/overcome-acquisition-based-silos-developer.md index 84ec681c1..0e5414feb 100644 --- a/patterns/1-initial/overcome-acquisition-based-silos-developer.md +++ b/patterns/1-initial/overcome-acquisition-based-silos-developer.md @@ -4,7 +4,7 @@ Overcome Acquisition-based Silos (Developer Level) ## Patlet -TBD +After a company acquisition, development teams remain siloed due to distrust, unfamiliar tools and processes, and fear of losing identity or job security, preventing the efficient cross-team collaboration InnerSource requires. A neutral governance committee, clear rules for handling code redundancy, generous onboarding, and face-to-face engagement help acquired developers overcome these barriers and begin contributing through InnerSource. ## Problem diff --git a/patterns/1-initial/overcome-acquisition-based-silos-manager.md b/patterns/1-initial/overcome-acquisition-based-silos-manager.md index c947a83f3..fa7928ebf 100644 --- a/patterns/1-initial/overcome-acquisition-based-silos-manager.md +++ b/patterns/1-initial/overcome-acquisition-based-silos-manager.md @@ -4,7 +4,7 @@ Overcome Acquisition-based Silos (Management Level) ## Patlet -TBD +After a company acquisition, middle managers from the acquired company resist InnerSource collaboration out of fear of losing control over their team, their code domain, and their developer resources. A neutral governance committee, career advancement opportunities tied to InnerSource participation, and a realistic integration timeline with measurable milestones help managers feel secure enough to support cross-company collaboration. ## Problem diff --git a/patterns/1-initial/reluctance-to-accept-contributions.md b/patterns/1-initial/reluctance-to-accept-contributions.md index 2868bce14..c35dff0f3 100644 --- a/patterns/1-initial/reluctance-to-accept-contributions.md +++ b/patterns/1-initial/reluctance-to-accept-contributions.md @@ -4,7 +4,7 @@ Reluctance to accept contributions ## Patlet -TBD +The team owning a shared InnerSource component is reluctant to accept contributions because doing so means taking on maintenance responsibility for unfamiliar code of uncertain quality. Establishing clear contribution guidelines, a time-limited post-merge support warranty from contributors, and a documented review workflow gives the host team confidence to accept contributions while setting clear expectations for contributors. ## Problem @@ -70,6 +70,8 @@ Klaas-Jan Stol ## References +Old Patlet: Core owner of shared asset is reluctant to take contributions due to the required maintenance that comes with them. Summary pattern that lays out four children patterns with three to be defined. + Pattern was first created in the gDoc: [Reluctance to Receive Contributions](https://docs.google.com/document/d/13QDN-BpE_BixRFVGjao32n4Ctim0ROXAHbBWMBOijb4/edit) (this section can be deleted once the conversion from gDoc to markdown is complete) diff --git a/patterns/1-initial/share-your-code-to-get-more-done.md b/patterns/1-initial/share-your-code-to-get-more-done.md index d8cf0ad64..2fb9f99b7 100644 --- a/patterns/1-initial/share-your-code-to-get-more-done.md +++ b/patterns/1-initial/share-your-code-to-get-more-done.md @@ -4,7 +4,7 @@ Share Your Code to Get More Done ## Patlet -TBD +Development teams working in silos cannot deliver software fast enough but have no obvious path to increase throughput, unaware that opening their codebase to InnerSource contributions could unlock capacity from developers across the organization. By building an evidence-based project plan showing the value of contributions and actively recruiting potential contributors, teams expand their effective development capacity without adding permanent headcount. ## Problem diff --git a/patterns/2-structured/innersource-hackathon.md b/patterns/2-structured/innersource-hackathon.md index 2f11878be..607edf1a4 100644 --- a/patterns/2-structured/innersource-hackathon.md +++ b/patterns/2-structured/innersource-hackathon.md @@ -104,7 +104,30 @@ All these help scale InnerSource in the organization. ## Known Instances * **IKEA** (Ingka Group) -* **The Aerospace Corporation** organized an internal InnerSource contribution festival inspired by open source contribution festivals at conferences like KubeCon/CloudNativeCon. Aerospace is a Federally Funded Research and Development Center (FFRDC) where developers charge time to government contracts, making InnerSource adoption especially challenging because work not embedded in funded tasking does not happen. The event was organized by a software best practices team and held as a hybrid event (virtual and in-person in El Segundo, California). They secured dedicated funding so that all 31 participants across 21 departments could charge their time to the event. Tasks were prepared with project maintainers, documented with clear definitions of done and impact statements, and organized on task boards. At least one maintainer from every participating project was available for Q&A throughout the day. During and shortly after the event, 15 tickets were closed. Notably, one developer used the event to contribute a feature he needed back to an internal library rather than forking it — a direct demonstration of InnerSource solving the "fork storm" problem the company had been experiencing. Two-thirds of participants had never heard of InnerSource before the event, yet 100% of survey respondents agreed that InnerSource would have a positive impact on development and wanted to participate in a future event. Traffic to the company's internal documentation site nearly doubled in the month following the event. See: [Kickstarting InnerSource with a Contribfest](https://www.youtube.com/watch?v=J5KeCHFbnWA) (InnerSource Commons Summit 2025 talk by Trin Baumgarten and Caroline T Jones). +* **Thales Group** +* **The Aerospace Corporation** + +### IKEA (Ingka Group) + +**IKEA** (Ingka Group) organized a company-wide InnerSource hackathon to scale InnerSource adoption beyond the early adopters already familiar with open source practices. Despite leadership support, IKEA struggled to spread InnerSource awareness to engineers new to collaborative ways of working and to attract contributions to existing InnerSource projects. The event was organized and run by Ingka Group's Open Source Program Office (OSPO), which also supports InnerSource adoption across the engineering organization. + +The hackathon was held as a virtual, one-day event open to all developers in the company, with a few extra days allowed for participants to finish and submit their work. Participants could join individually or in teams and chose from two categories: (1) **start a new InnerSource project** — either from scratch with documentation in place from the beginning, or by converting an existing project to follow InnerSource guidelines and publishing it in the company's InnerSource marketplace; or (2) **contribute to an existing InnerSource project** — before the event, project maintainers pre-listed features and issues tagged as "hackathon" or "good first issue" so participants could pick them up on the day. The judging panel comprised representatives from different business areas across the company, all strong advocates of InnerSource. + +The event drew participation from engineers across **six countries** and resulted in contributions to around **six InnerSource projects**. The InnerSource project landscape grew by approximately **50%** as a result of the event. One newly created project was identified as a strong candidate for open sourcing. Notably, the hackathon reached many developers who would not have engaged with InnerSource through conventional awareness campaigns — making it especially effective for the late majority who had previously ignored the topic. + +Shanmugapriya Manoharan (Engineering Advisor, OSPO, IKEA IT AB) shared this experience at an InnerSource Commons community call in December 2024. See: [Hackathon: A Fun and safe approach to get started with InnerSource](https://youtu.be/7RWJUKanbqQ) (InnerSource Commons Community Call, December 2024). + +### Thales Group + +**Thales Group** runs Thales I/O Days, combining a full remote 2-day Hackathon and annual in-person conference with a reward ceremony for key contributors — open to all job families, not only engineering. See: [Why People Matter Most: Building a Sustainable InnerSource Strategy](https://www.youtube.com/watch?v=r0dx84lUDYY) (InnerSource Commons, 2026, by Marius Moulis). + +### The Aerospace Corporation + +**The Aerospace Corporation** organized an internal InnerSource contribution festival inspired by open source contribution festivals at conferences like KubeCon/CloudNativeCon. Aerospace is a Federally Funded Research and Development Center (FFRDC) where developers charge time to government contracts, making InnerSource adoption especially challenging because work not embedded in funded tasking does not happen. The event was organized by a software best practices team and held as a hybrid event (virtual and in-person in El Segundo, California). They secured dedicated funding so that all 31 participants across 21 departments could charge their time to the event. Tasks were prepared with project maintainers, documented with clear definitions of done and impact statements, and organized on task boards. At least one maintainer from every participating project was available for Q&A throughout the day. + +During and shortly after the event, 15 tickets were closed. Notably, one developer used the event to contribute a feature he needed back to an internal library rather than forking it — a direct demonstration of InnerSource solving the "fork storm" problem the company had been experiencing. Two-thirds of participants had never heard of InnerSource before the event, yet 100% of survey respondents agreed that InnerSource would have a positive impact on development and wanted to participate in a future event. Traffic to the company's internal documentation site nearly doubled in the month following the event. + +See: [Kickstarting InnerSource with a Contribfest](https://www.youtube.com/watch?v=J5KeCHFbnWA) (InnerSource Commons Summit 2025 talk by Trin Baumgarten and Caroline T. Jones). ## Status @@ -116,4 +139,4 @@ All these help scale InnerSource in the organization. ## Acknowledgments -* Trin Baumgarten and Caroline T Jones (The Aerospace Corporation) for [sharing their experience](https://www.youtube.com/watch?v=J5KeCHFbnWA) at the InnerSource Commons Summit. +* Trin Baumgarten and Caroline T. Jones (The Aerospace Corporation) for [sharing their experience](https://www.youtube.com/watch?v=J5KeCHFbnWA) at the InnerSource Commons Summit. diff --git a/patterns/2-structured/innersource-license.md b/patterns/2-structured/innersource-license.md index 981c4f9cb..1d31ac84c 100644 --- a/patterns/2-structured/innersource-license.md +++ b/patterns/2-structured/innersource-license.md @@ -57,6 +57,7 @@ The license simplifies the conversations within our organization about sharing s - **GovTech (Singapore Government)** - **Siemens** has developed their own InnerSource license alongside other necessary legal agreements between subsidiaries. - **Mercedes-Benz** +- **Thales Group** ### DB Systel @@ -88,6 +89,10 @@ Following open source practices, the GPSL `LICENSE` file is included in each rep For more details see the InnerSource Commons Community call from 09/2023 [Improving Engineering Collaboration across the Singapore Government through InnerSource](https://www.youtube.com/watch?v=-zu2X2iERv8&t=1257s&ab_channel=InnerSourceCommons) (around 20:50) by Hunter Nield. +### Thales Group + +Thales Group created a framework of four ready-to-use InnerSource licenses, developed in close collaboration with legal partners. See: [Why People Matter Most: Building a Sustainable InnerSource Strategy](https://www.youtube.com/watch?v=r0dx84lUDYY) (InnerSource Commons, 2026, by Marius Moulis). + ## Status * Structured @@ -110,4 +115,4 @@ For more details see the InnerSource Commons Community call from 09/2023 [Improv - **legal entity** - An entity that has its own legal rights and obligations (synonyms: company, subsidiary) (e.g. Lufthansa Systems GmbH, Lufthansa Industry Solutions TS GmbH, ...) [db-inner-source-license]: https://github.com/dbsystel/open-source-policies/tree/master/inner-source-license -[eupl]: https://joinup.ec.europa.eu/collection/eupl/eupl-text-eupl-12 +[eupl]: https://interoperable-europe.ec.europa.eu/collection/eupl/eupl-text-eupl-12 diff --git a/patterns/2-structured/praise-participants.md b/patterns/2-structured/praise-participants.md index 7836f815b..95b078188 100644 --- a/patterns/2-structured/praise-participants.md +++ b/patterns/2-structured/praise-participants.md @@ -74,6 +74,7 @@ Overdoing it may feel insincere and mechanical and defeat your purpose in reachi * **Nike** (multiple projects) * **SAP** - InnerSource initiatives like the Dojo and Everest projects are elevated by the 'Praise Participants' pattern, where the SAP Appreciate program plays a key role in fostering a culture of gratitude and recognition, driving innovation and collaboration to new heights. See: [InnerSource: First Contribution Explored](https://community.sap.com/t5/open-source-blogs/innersource-first-contribution-explored/ba-p/13644916) * **Siemens** awards successful InnerSource projects and contributors at their yearly internal InnerSource Summit. +* **Thales Group** - The Thales ISPO explicitly applies this pattern organization-wide, during "Thales I/O Days" event, where top contributors and community advocates across InnerSource and open source receive awards. See: [Why People Matter Most: Building a Sustainable InnerSource Strategy](https://www.youtube.com/watch?v=r0dx84lUDYY) (InnerSource Commons, 2026, by Marius Moulis). ## Status diff --git a/patterns/2-structured/repository-activity-score.md b/patterns/2-structured/repository-activity-score.md index 73c26a57f..66a0d029d 100644 --- a/patterns/2-structured/repository-activity-score.md +++ b/patterns/2-structured/repository-activity-score.md @@ -65,14 +65,14 @@ function calculateScore(repo) { // updated in last 3 months: adds a bonus multiplier between 0..1 to overall score (1 = updated today, 0 = updated more than 100 days ago) let iDaysSinceLastUpdate = (new Date().getTime() - new Date(repo.updated_at).getTime()) / 1000 / 86400; - iScore = iScore * ((1 + (100 - Math.min(iDaysSinceLastUpdate, 100))) / 100); + iScore = iScore * (1 + (100 - Math.min(iDaysSinceLastUpdate, 100)) / 100); // evaluate participation stats for the previous 3 months repo._InnerSourceMetadata = repo._InnerSourceMetadata || {}; if (repo._InnerSourceMetadata.participation) { // average commits: adds a bonus multiplier between 0..1 to overall score (1 = >10 commits per week, 0 = less than 3 commits per week) let iAverageCommitsPerWeek = repo._InnerSourceMetadata.participation.slice(-13).reduce((a, b) => a + b) / 13; - iScore = iScore * ((1 + (Math.min(Math.max(iAverageCommitsPerWeek - 3, 0), 7))) / 7); + iScore = iScore * (1 + (Math.min(Math.max(iAverageCommitsPerWeek - 3, 0), 7)) / 7); } // boost calculation: diff --git a/translation/es/patterns/innersource-license.md b/translation/es/patterns/innersource-license.md index e59d13bbc..ed1ba9aa5 100644 --- a/translation/es/patterns/innersource-license.md +++ b/translation/es/patterns/innersource-license.md @@ -108,7 +108,7 @@ Para más detalles, vea la llamada de la Comunidad InnerSource Commons de 09/202 - **entidad legal** - Una entidad que tiene sus propios derechos y obligaciones legales (sinónimos: empresa, subsidiaria) (por ejemplo, Lufthansa Systems GmbH, Lufthansa Industry Solutions TS GmbH, ...) [db-inner-source-license]: https://github.com/dbsystel/open-source-policies/tree/master/inner-source-license -[eupl]: https://joinup.ec.europa.eu/collection/eupl/eupl-text-eupl-12 +[eupl]: https://interoperable-europe.ec.europa.eu/collection/eupl/eupl-text-eupl-12 ## Histórico de Traducciones diff --git a/translation/gl/patterns/innersource-license.md b/translation/gl/patterns/innersource-license.md index 024a19efe..30674ec11 100644 --- a/translation/gl/patterns/innersource-license.md +++ b/translation/gl/patterns/innersource-license.md @@ -88,7 +88,7 @@ Paga a pena mencionar que, ata agora, o software compartido baixo esta licenza I - **Entidade xurídica**: unha entidade que ten os seus propios dereitos e obrigas legais. (Sinónimos: empresa, filial. Por exemplo, Lufthansa Systems GmbH, Lufthansa Industry Solutions TS GmbH etc). [db-inner-source-license]: https://github.com/dbsystel/open-source-policies/tree/master/inner-source-license -[eupl]: https://joinup.ec.europa.eu/collection/eupl/eupl-text-eupl-12 +[eupl]: https://interoperable-europe.ec.europa.eu/collection/eupl/eupl-text-eupl-12 ## Tradución diff --git a/translation/ja/patterns/innersource-license.md b/translation/ja/patterns/innersource-license.md index 44376f734..75a041c0f 100644 --- a/translation/ja/patterns/innersource-license.md +++ b/translation/ja/patterns/innersource-license.md @@ -90,7 +90,7 @@ DB 社の中で最初の法人(企業) は、このインナーソース ライ - **法的エンティティ** - 独自の法的権利と義務を有するエンティティ (同義語: グループ子会社、子会社、関連会社) (例: Microsoft Japan, GitHub, LinkedIn) [db-inner-source-license]: https://github.com/dbsystel/open-source-policies/tree/master/inner-source-license -[eupl]: https://joinup.ec.europa.eu/collection/eupl/eupl-text-eupl-12 +[eupl]: https://interoperable-europe.ec.europa.eu/collection/eupl/eupl-text-eupl-12 ## 翻訳の履歴 diff --git a/translation/pt-br/patterns/innersource-license.md b/translation/pt-br/patterns/innersource-license.md index aff5f8f3d..10f4933a8 100644 --- a/translation/pt-br/patterns/innersource-license.md +++ b/translation/pt-br/patterns/innersource-license.md @@ -88,7 +88,7 @@ Vale mencionar que até agora, o software compartilhado sob essa licença InnerS -entidade jurídica - Uma entidade que possui seus próprios direitos e obrigações legais (sinônimos: empresa, subsidiária) (por exemplo, Lufthansa Systems GmbH, Lufthansa Industry Solutions TS GmbH, ...) [db-inner-source-license]: https://github.com/dbsystel/open-source-policies/tree/master/inner-source-license -[eupl]: https://joinup.ec.europa.eu/collection/eupl/eupl-text-eupl-12 +[eupl]: https://interoperable-europe.ec.europa.eu/collection/eupl/eupl-text-eupl-12 ## Histórico de Tradução diff --git a/translation/zh/patterns/innersource-license.md b/translation/zh/patterns/innersource-license.md index 5fc1eb414..d9ee79322 100644 --- a/translation/zh/patterns/innersource-license.md +++ b/translation/zh/patterns/innersource-license.md @@ -88,7 +88,7 @@ DB AG内部的第一批法律实体（公司）正在使用他们的内源许可 - **法律实体** - 拥有自身的法律权利和义务的实体（同义词：公司，子公司）（例如汉莎系统有限公司，汉莎工业解决方案TS有限公司，...） [db-inner-source-license]: https://github.com/dbsystel/open-source-policies/tree/master/inner-source-license -[eupl]: https://joinup.ec.europa.eu/collection/eupl/eupl-text-eupl-12 +[eupl]: https://interoperable-europe.ec.europa.eu/collection/eupl/eupl-text-eupl-12 ## 翻译校对