diff --git a/.github/workflows/generate-mindmap.yml b/.github/workflows/generate-mindmap.yml new file mode 100644 index 000000000..accbbd6ee --- /dev/null +++ b/.github/workflows/generate-mindmap.yml @@ -0,0 +1,45 @@ +name: Generate Mindmap + +on: + push: + branches: + - "main" + pull_request: + paths: + - ".github/workflows/generate-mindmap.yml" + - "pattern-categorization/innersource-program-mind-map.md" + +defaults: + run: + working-directory: pattern-categorization + +jobs: + generate-mindmap: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v2 + - name: Use Node.js + uses: actions/setup-node@v2 + with: + node-version: 12.x + cache: 'npm' + cache-dependency-path: pattern-categorization/package-lock.json + - name: Install Node.js dependencies + run: npm install + - name: Run Markmap + run: npx markmap --no-toolbar innersource-program-mind-map.md -o innersource-program-mind-map.html + - name: Screenshot Markmap Website + id: screenshot-generator + uses: swinton/screenshot-website@v1.x + with: + source: pattern-categorization/innersource-program-mind-map.html + destination: innersource-program-mind-map.png + full-page: false + - name: Copy Screenshot + run: cp ${{ steps.screenshot-generator.outputs.path }} . + - name: Reduce Screenshot Size (PNG) + run: npx optipng innersource-program-mind-map.png + - name: Commit Changes + uses: stefanzweifel/git-auto-commit-action@v4 + with: + commit_message: Re-creating markmap and screenshot diff --git a/README.md b/README.md index 08914fd3c..36c2d6359 100644 --- a/README.md +++ b/README.md @@ -49,6 +49,8 @@ The below lists all known patterns. They are grouped into three [maturity levels * [Cross-Team Project Valuation](patterns/2-structured/crossteam-project-valuation.md) - *It's hard to sell the value of cross-team InnerSource projects that don't provide a direct impact on company revenue. Here's a data-driven way to represent your project that both articulates its value and amplifies it.* * [Transparent Cross-Team Decision Making using RFCs](patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md) - *InnerSource projects that want to achieve high participation rates and make the best possible decisions for everybody involved need to find ways to create participatory systems throughout the full software lifecycle. Publishing internal Requests for Comments (RFCs) documents allows for discussions early on in the design process, and increases the chances to build solutions with a high degree of commitment from all involved parties.* * [Start as an Experiment](patterns/2-structured/start-as-experiment.md) - *Start your InnerSource initiative as a time limited experiment to make it easier for managers unfamiliar with InnerSource to endorse and support the initiative.* +* [Core Team](patterns/2-structured/core-team.md) - *Even when an InnerSource project is widely needed, contributions and usage may be hindered because the project is difficult to work with. Establish a core team that is dedicated to take care of the project's fundamental items. Their work enables contributors to add and use the features that provide value to their scenarios.* +* [Document your Guiding Principles](patterns/2-structured/document-your-guiding-principles.md) - *The usual InnerSource explanation of "applying open source best practices inside an organisation" does not work well with people lacking an open source background. As a remedy the most important principles of InnerSource get documented and published widely.* ### Maturity Level 1: Initial @@ -69,7 +71,7 @@ The below lists all known patterns. They are grouped into three [maturity levels * [Unified Source Code Inventory](patterns/1-initial/source-code-inventory.md) - *In a large organization with different legal entities is often hard to get full visibility into all software assets, in particular all source code. This situation reduces the opportunities to increase business value and keep liability costs, such as software maintenance, under control across the organization as a whole. An organization-level source code inventory addresses these issues while exploiting opportunities to identify and support valuable InnerSource assets.* * [Explicit Shared Ownership](patterns/1-initial/explicit-shared-ownership.md) - *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 behaviour visible removes ambiguity. Writing a contributions document creates a natural way to evolve ownership.* * [Standarized Release Process](patterns/1-initial/release-process.md) - *Teams may be reluctant to use InnerSource projects that they are unfamiliar with when there is no clear release process apparent in the repository. Providing clear release notes and a published artifact (binary, docker image, jar, etc) gives people confidence you are publishing a quality product.* -* [Explicit InnerSource Principles](patterns/1-initial/explicit-innersource-principles.md) - *The usual InnerSource explanation of "applying open source best practices inside an organisation" does not work well with people lacking an open source background. As a remedy the most important principles of InnerSource get published widely.* +* [Overcoming the Not-Invented-Here Mindset](/patterns/1-initial/not-invented-here.md) - Perfectly good solutions are being rejected because of "Not Invented Here" (NIH). Engineers and their managers will choose to implement functionality themselves first, even if an alternative exists. A shift towards a culture of "Proudly Found Elsewhere" can help reduce the negative impact of NIH. greater chance of success, greater speed." + +* Provide template to use for code submission requirements. (Must include testing. Many companies have built-in, automated testing. Documented communication) For both host and contributors. Requires/assumes compliance. +* Mentorship (requirements can be informed via tracking above results) +* Talking is good /relationship building +* Finding incentives to drive InnerSource behavior (incentives and measures can vary at a team level) +* Shift to a "profoundly found elsewhere" culture +* Demonstrate organizational interest in outside opinions +* Identify influencers who agree to be early adopters - set the stage for others +* Contributability is a mark of quality + +## Resulting Context + +* Developers search for and leverage existing options as opposed to rewriting. This results in: + * increased efficiency + * increased reuse + * higher levels of developer satisfaction + * increased speed to market +* Developers interact with code and products produced by others with the same trust and engagement as those that they themselves have produced. + +## Known Instances + +TBD + +## Status + +* Initial (PR from [16 Mar 2017](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/64)) + +## Author(s) + +* Erin Bank, CA Technologies +* Tim Yao, Nokia +* Padma Sudarsan, Nokia +* Georg Gruetter, Bosch +* Ofer Hermoni +* Rob Mulcahy +* Max Capraro +* Jory Burson +* John McDonough +* Shola +* Becky - name only +* Russ - name only +* Nick + +## References + +* Oana-Maria Pop, Hype Innovation Blog: [Does Your Organization Have the Not Invented Here Syndrome?](http://blog.hypeinnovation.com/the-not-invented-here-syndrome) +* DSM, Open Innovation: [Proudly Found Elsewhere](https://www.youtube.com/watch?v=jNNz9poyKJs) diff --git a/patterns/1-initial/source-code-inventory.md b/patterns/1-initial/source-code-inventory.md index 8710ad78b..266104baa 100644 --- a/patterns/1-initial/source-code-inventory.md +++ b/patterns/1-initial/source-code-inventory.md @@ -4,13 +4,14 @@ Unified Source Code Inventory ## Patlet -In a large organization with different legal entities is often hard to get full visibility into all software assets, in particular all source code. This situation reduces the opportunities to increase business value and keep liability costs, such as software maintenance, under control across the organization as a whole. An organization-level source code inventory addresses these issues while exploiting opportunities to identify and support valuable InnerSource assets. +Large organizations with many legal entities often don't have visibility into all of their software assets (repositories), limiting their ability to increase businesses value and control liability costs holistically. +A unified source code inventory at organization-level addresses these issues, while exploiting opportunities to identify and support valuable InnerSource assets. ## Problem -Given situations when InnerSource stakeholders do not value source code at the same level as other organization's assets; when source code strategies are ad-hoc and different among legal entities with little consolidation at organization-level; then it becomes harder both to select and support the right InnerSource project candidates as well as maximize business value of such a key asset. +Given situations when InnerSource stakeholders do not value source code at the same level as other Organization's assets; when source code strategies are ad-hoc and different among legal entities with little consolidation at Organization-level; then it becomes harder both to select and support the right InnerSource project candidates as well as maximize business value of such a key asset. -Can you get consistent answers within the organization to questions like? +Can you get consistent answers within the Organization to questions like: * How would you find all source code touched by anyone in your legal entity? * How would you find out who else can also access each of the above? @@ -20,36 +21,37 @@ Can you get consistent answers within the organization to questions like? ## Context -* You work on Legal Entity within a complex Organization under continuous change (e.g., new acquisitions or changing business priorities). +* You work on Legal Entity within a complex Organization under continuous change (e.g. new acquisitions or changing business priorities). * You cannot find all source code touched, shared and consumed within the Organization. -* You do not have a clear policy on default sharing level when creating a new project (e.g., Open Source, InnerSource or Closed Source). +* You do not have a clear policy on default sharing level when creating a new project (e.g. Open Source, InnerSource or Closed Source). * You cannot scan significant parts of the Organization's source code looking for duplication, similarity or code smells. * You do not know the existing ratios of Open Source, innerSource and Closed Source and their trend. * You cannot measure the diversity of contributions and resulting value for a given project. * You cannot identify and optimize tech stack diversity. -* You cannot identify technical debt and determine the priorities for retirement (e.g., dead APIs/source). +* You cannot identify technical debt and determine the priorities for retirement (e.g. dead APIs/source). ## Forces -* Fragmentation of source code hosting systems in the organization. -* Ad-hoc source code strategies scattered across the different Legal Entities in the organization. +* Fragmentation of source code hosting systems in the Organization. +* Ad-hoc source code strategies scattered across the different Legal Entities in the Organization. * Continuously changing map of the relationships between: projects, repositories, products, tech stacks, domains, solutions, platforms, services, components, sub-systems, people, authors, teams, external repositories. -* Diverse software culture of teams across the organization (e.g., more open to collaboration or more siloed). +* Diverse software culture of teams across the Organization (e.g. more open to collaboration or more siloed). ## Solutions -### Set up an organization-level source code inventory live dashboard +### Set up an Organization-level source code inventory live dashboard * Combination of manual and automated input data sources to a single source of truth * API available to add new data sources and extend coverage of the source code repository * Key meta-data about each repository: * Legal Entity * URL - * Version control system (e.g., GIT or SVN). - * Hosting vendor (e.g., GitHub, Gitlab or BitBucket) and hosting type (e.g., on-prem, private cloud or public cloud). - * Sharing level (e.g., Open Source, InnerSource, Closed Source). + * Version control system (e.g. GIT or SVN) + * Hosting vendor (e.g. GitHub, Gitlab or BitBucket) + * Hosting type (e.g. on-prem, private cloud or public cloud) + * Sharing level (e.g. Open Source, InnerSource, Closed Source) * Visualization in place to list all assets with options to filter based on meta-data -* Enable access to automated source code static analysis tools (e.g., identify duplicated or similar code, flag code smells, benchmark test coverage). +* Enable access to automated source code static analysis tools (e.g. identify duplicated or similar code, flag code smells, benchmark test coverage). Mockup dashboard | Mockup questionnaire :-------------------------:|:-------------------------: @@ -69,31 +71,31 @@ Mockup dashboard | Mockup questionnaire ### For the Organization, Legal Entity and Project maintainers -* We have explicit policies at Organization and Legal Entity level on source code strategy (e.g., where to create new repository or how to select the right sharing level). +* We have explicit policies at Organization and Legal Entity level on source code strategy (e.g. where to create new repository or how to select the right sharing level). * We can find all source code touched, shared and consumed within the Organization or Legal Entity and take actions as needed. * We can measure the diversity of contributions and resulting business value for our project. -* We can identify technical debt and determine the priorities for retirement (e.g., dead APIs/source). +* We can identify technical debt and determine the priorities for retirement (e.g. dead APIs/source). ### For InnerSource governance * We can scan significant parts of our Organization's source code looking for opportunities of reuse, duplication, similarity or code smells. * We know the ratios of Open Source, InnerSource and Closed Source within the Organization so we can steer as needed. * We can identify and optimize tech stack diversity. -* We can create awareness and culture shift on certain Legal Entities as needed (e.g., ratio of Open Source and InnerSource below average). +* We can create awareness and culture shift on certain Legal Entities as needed (e.g. ratio of Open Source and InnerSource below average). ## Rationale -It creates a dynamic and extendable single source of truth for repositories to capture, visualize and act on source code repositories across the Organization. That helps to create awareness and focus efforts on the right direction. The Source Code Strategy Assessment Framework helps teams to understand the value of intentional explicit policies on how to manage source code. It helps to create both continuous improvement cycles and references within the Organization of what others are doing. +It creates a dynamic and extendable single source of truth for repositories to capture, visualize and act on source code repositories across the Organization. That helps to create awareness and focus efforts on the right direction. -## Known Instances +The Source Code Strategy Assessment Framework helps teams to understand the value of intentional explicit policies on how to manage source code. It helps to create both continuous improvement cycles and references within the Organization of what others are doing. -This is under test at scale at: +## Known Instances -* Philips +* Philips (under test at scale) ## References -* Organization and Legal Entity terms as defined in [InnerSource License Pattern Glossary](../2-structured/innersource-license.md#glossary). +* Organization and Legal Entity terms as defined in the [InnerSource License Pattern - Glossary](../2-structured/innersource-license.md#glossary). * Explore using this pattern in combination with the [InnerSource Portal](../2-structured/innersource-portal.md) pattern. ## Status diff --git a/patterns/2-structured/core-team.md b/patterns/2-structured/core-team.md index 16c3133c6..67d13820a 100644 --- a/patterns/2-structured/core-team.md +++ b/patterns/2-structured/core-team.md @@ -68,8 +68,8 @@ The core team may be composed of a small number of people on a full-time or a pa The choice depends on the amount of work needed, the availability of resources, and the culture of the organization. The most important consideration is to form the team in a way that allows the organization to empower and hold them accountable in the same way as any other team. -Due to their central role, core team members should nearly always fill the role of [Trusted Committers][tc] as well. -While the [Trusted Committer][tc] role focuses mostly on facilitating others' contribution and use of the project, a core team member regularly contributes to the project as well. +Due to their central role, core team members should nearly always fill the role of **Trusted Committers** as well (for more on that concept see [Learning Path][tc-learning-path] and [Pattern][tc-pattern]). +While the Trusted Committer role focuses mostly on facilitating others' contribution and use of the project, a core team member regularly contributes to the project as well. The core team doesn't have its own business agenda that determines its contributions. They decide what to work on based on what will help others most to use and contribute to the project. @@ -80,6 +80,8 @@ A good way to continually remind the core team of this goal is to have them repo Continual focus on these metrics will naturally drive the core team to prioritize generally the right work to create a thriving InnerSource ecosystem around the project. +![Responsibilities of Core Team and InnerSource Contributors](../../assets/img/core-team.png) + ## Resulting Context * It is easy to use and contribute to the project. @@ -103,4 +105,5 @@ Structured [Russell R. Rutledge](https://github.com/rrrutledge) -[tc]: https://innersourcecommons.org/learn/learning-path/trusted-committer/ +[tc-learning-path]: https://innersourcecommons.org/learn/learning-path/trusted-committer/ +[tc-pattern]: ../2-structured/trusted-committer.md diff --git a/patterns/2-structured/document-your-guiding-principles.md b/patterns/2-structured/document-your-guiding-principles.md new file mode 100644 index 000000000..63b1efa2d --- /dev/null +++ b/patterns/2-structured/document-your-guiding-principles.md @@ -0,0 +1,152 @@ +## Title + +Document your Guiding Principles + +## Patlet + +The usual InnerSource explanation of "applying open source best practices inside an organisation" does not work well with people lacking an open source background. +As a remedy the most important principles of InnerSource get documented and published widely. + +## Problem + +The organisation is trying to roll out InnerSource at a larger scale. +The initiative started among open source enthusiasts. +The goal is now to get buy-in from people that are lacking open source experience. +For that audience the typical slogan of "applying open source best practices" is no longer sufficient to transport the message of what InnerSource is, which problems it solves and which tools it uses for solving these issues. +As a result InnerSource adoption in the organisation slows down. +Teams develop diverging ideas of what the goals of InnerSource is about and how to best implement it leading to confusion when contributors are starting to cross team boundaries. + +## Story + +Early experiments in an organisation have shown that open source collaboration best practices can be beneficial. +The next step now is to move the initiative to teams and individuals lacking a deep background in open source. + +The goal now is to clearly communicate the goals of the InnerSource initiative +as well as a clear path towards achieving these goals. + +## Context + +* InnerSource as a term is circulating among employees. +* The initiative started among open source enthusiasts. + +## Forces + +* Teams have trouble communicating exactly what the important aspects of InnerSource are. +* People lacking open source experience fail to understand what it means to bring open source best practices into the organisation. +* On a daily basis teams trying to follow InnerSource best practices have a hard time deciding if what they are doing is inline with general InnerSource values. + +## Solution + +Those driving the InnerSource initiative in the organisation need to help the teams and individuals that are lacking a deep background in open source, and therefore have a less intuitive understanding of InnerSource. + +Clarity should be provided around these two areas: + +### Why does the organisation want to adopt InnerSource? + +In the past InnerSource has proven to be successful to solve several issues commonly found in organisations. + +However which organizational challenges does your organization hope to improve upon using InnerSource? + +Instead of going for generalizations, try to exactly identify the solutions that match the challenges of your organisation - preferably with those affected by the change you want to see. + +Some challenges that others have addressed by following InnerSource best practices: + +* Reduce development silos caused by excessive ownership culture. +* Increase innovation speed by reducing time spent solving similar issues by fostering healthy code reuse. +* Increase development speed by better cross-team collaboration. +* Solve project/ team dependencies beyond "wait it out" and "build workarounds", thereby reducing engineering bottlenecks. +* Increase quality. +* Increase employee happiness. +* To increase success of new hires. +* To build actionable documentation. + +### Which InnerSource principles will help to address these challenges? + +Once teams understand which problems InnerSource will help them address, the next step is to explain which principles help address these challenges. + +Based on basic open source development principles the following guidelines have been proven successful: + +(1) Code must be transparently hosted within the organisation + +Source code, documentation, data relevant for project development must be available and easy to find for anyone in the organisation. + +(2) Contributions over feature requests + +All stakeholders of a project act as potential contributors and are being treated and supported as such. +Contributions remain suggestions instead of requirements. +Coordination before a contribution helps avoid wasted effort. +Projects provide contribution guidelines to avoid friction. + +(3) Mistakes are opportunities for learning + +With work visible across the entire organisation any mistake is visible to everyone. +As a result a culture must be established in which mistakes are opportunities for learning instead of failure that should be avoided at all cost. + +(4) Written over verbal communication + +For projects that span multiple teams, potentially on diverging meeting schedules, it needs to be possible to collaborate asynchronously. +The goal for InnerSource projects is to recruit new contributors. +For that, potential future contributors need to be able to follow the project progress on a self serve basis with a very low barrier to entry. +If project relevant communication happens through synchronous communication, arguments discussed need to be made transparent in the written channel - decisions should be finalized only there. +As a side effect this leads to passive base documentation that is very valuable for any newcomer to the project. + +(5) Allow written advise to accumulate in a persistent, searchable archive + +All project communication, in particular decisions taken and discussions leading up to those decisions need to be archived. +It must be possible to reference communication via stable URLs. +Previous communication needs to be stored in a way that can easily be searched. + +Two caveats though: + +1. This does not replace structured documentation. It can serve as a starting point to collect structured documentation though. +2. There are exceptions to the rule of everything being written and accessible to the entire organisation: People related discussions as well as security related discussions are sensitive and should not be held in public. + +(6) Reward Trusted Committership + +All contributions (e.g. source code, documentation, bug reports, input to discussions, user support, marketing) are welcome and are being rewarded. +Those showing support for the project are being invited as [Trusted Committers](../2-structured/trusted-committer.md). +All Trusted Committers of a project are published. + +## Resulting Context + +* Organisation members understand which challenges they can address by applying InnerSource best practices. +* Organisation members lacking prior open source experience understand the basic values and principles of InnerSource projects. +* Organisation members lacking prior open source experience are able to check their daily doing against a set of common established values. +* The organisation's development practices become more similar to open source projects thus making it easier for organisation members to participate in open source projects. + +## Known Instances + +### Europace AG + +The InnerSource principles listed in the Solution above are mostly based on Europace's experience. +For more details see [Europace InnerSource Prinzipien](https://tech.europace.de/post/europace-inner-source-prinzipien/) (in German). + +### Robert Bosch GmbH + +Fostering collaboration, learning and innovation is the main focus of the Bosch InnerSource initiative (BIOS). +To that end, they applied the following principles: + +- **Openness**: We lower the barriers for entry into BIOS communities as much as we can. +- **Transparency**: We are radically transparent and share our work products, our communication, and our decision making with all associates in the company. +- **Voluntariness**: The decision to join and contribute to a BIOS community is left to each associate. Associates should work within BIOS because they are intrinsically motivated, not because their manager told them so. +- **Self-Determination**: BIOS communities are free to choose what to work on, when they work and what tools and processes they use to work. +- **Meritocracy**: Power is vested in BIOS project members based on their merits, that is, based on the quality and quantity of their contributions. + +![BIOS Principles](../../assets/img/bios-principles.png) + +The principles _Openness_, _Transparency_ and _Voluntariness_ helped grow diverse communities of intrinsically motivated associates. +_Meritocracy_ has proven to be an effective motivation for making great contributions. +_Self-Determination_ allowed the communities to use their limited time for contributions in the most effective and efficient way. + +## Status + +Structured + +## Authors + +* Isabel Drost-Fromm +* Georg Grütter + +## Alias + +Explicit InnerSource Principles diff --git a/patterns/2-structured/maturity-model.md b/patterns/2-structured/maturity-model.md index d4012eabc..e9ce8c070 100644 --- a/patterns/2-structured/maturity-model.md +++ b/patterns/2-structured/maturity-model.md @@ -175,10 +175,10 @@ InnerSource projects need a means for self assessment. Metrics can be one aspect Not only should feature development be owned by InnerSource teams - support and maintenance is also part of the teams core tasks. -* SP-0: Support given by the core dev or support team. A business contract guaranties the support. There is no knowledge about the product outside the team. -* SP-1: There are rules and regulations to formalize the support on the product, given by a dedicated supporting team. -* SP-2: Support for InnerSource contributions is formalized through InnerSource patterns like [30 Day Warranty](./30-day-warranty.md) or [Service vs. Library](./service-vs-library.md). -* SP-3: There are rules and regulations to formalize the support on the product, given by a mature community. +* SM-0: Support given by the core dev or support team. A business contract guaranties the support. There is no knowledge about the product outside the team. +* SM-1: There are rules and regulations to formalize the support on the product, given by a dedicated supporting team. +* SM-2: Support for InnerSource contributions is formalized through InnerSource patterns like [30 Day Warranty](./30-day-warranty.md) or [Service vs. Library](./service-vs-library.md). +* SM-3: There are rules and regulations to formalize the support on the product, given by a mature community. **Culture** diff --git a/patterns/2-structured/repository-activity-score.md b/patterns/2-structured/repository-activity-score.md index 559667d0e..76a94eb0a 100644 --- a/patterns/2-structured/repository-activity-score.md +++ b/patterns/2-structured/repository-activity-score.md @@ -58,17 +58,23 @@ function calculateScore(repo) { // initial score is 50 to give active repos with low GitHub KPIs (forks, watchers, stars) a better starting point let iScore = 50; // weighting: forks and watches count most, then stars, add some little score for open issues, too - iScore += repo["forks_count"] * 5 + repo["watchers_count"] + repo["stargazers_count"] / 3 + repo["open_issues_count"] / 5; - let iDaysSinceLastUpdate = (new Date().getTime() - new Date(repo.updated_at).getTime()) / 1000 / 86400; + iScore += repo.forks_count * 5; + iScore += (repo.subscribers_count ? repo.subscribers_count : 0); + iScore += repo.stargazers_count / 3; + iScore += repo.open_issues_count / 5; + // 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) - iScore = iScore * (1 + (100 - Math.min(iDaysSinceLastUpdate, 100)) / 100); + let iDaysSinceLastUpdate = (new Date().getTime() - new Date(repo.updated_at).getTime()) / 1000 / 86400; + 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(repo._InnerSourceMetadata.participation - 13).reduce((a, b) => a + b) / 13; - iScore = iScore * (1 + (Math.min(Math.max(iAverageCommitsPerWeek - 3, 0), 7)) / 7); + let iAverageCommitsPerWeek = repo._InnerSourceMetadata.participation.slice(repo._InnerSourceMetadata.participation.length - 13).reduce((a, b) => a + b) / 13; + iScore = iScore * ((1 + (Math.min(Math.max(iAverageCommitsPerWeek - 3, 0), 7))) / 7); } + // boost calculation: // all repositories updated in the previous year will receive a boost of maximum 1000 declining by days since last update let iBoost = (1000 - Math.min(iDaysSinceLastUpdate, 365) * 2.74); @@ -78,9 +84,9 @@ function calculateScore(repo) { // add boost to score iScore += iBoost; // give projects with a meaningful description a static boost of 50 - iScore += (repo["_InnerSourceMetadata"]["description"].length > 30 || repo["_InnerSourceMetadata"] && repo["_InnerSourceMetadata"]["motivation"].length > 30 ? 50 : 0); + iScore += (repo.description?.length > 30 || repo._InnerSourceMetadata.motivation?.length > 30 ? 50 : 0); // give projects with contribution guidelines (CONTRIBUTING.md) file a static boost of 100 - iScore += (repo["_InnerSourceMetadata"] && repo["_InnerSourceMetadata"]["guidelines"] ? 100 : 0); + iScore += (repo._InnerSourceMetadata.guidelines ? 100 : 0); // build in a logarithmic scale for very active projects (open ended but stabilizing around 5000) if (iScore > 3000) { iScore = 3000 + Math.log(iScore) * 100; @@ -89,6 +95,7 @@ function calculateScore(repo) { iScore = Math.round(iScore - 50); // add score to metadata on the fly repo._InnerSourceMetadata.score = iScore; + return iScore; } ``` diff --git a/patterns/2-structured/service-vs-library.md b/patterns/2-structured/service-vs-library.md index 8d046208b..1de24089c 100644 --- a/patterns/2-structured/service-vs-library.md +++ b/patterns/2-structured/service-vs-library.md @@ -23,32 +23,23 @@ reluctant to join forces even if there is significant overlap in requirements. ## Context -Teams are working in a micro-services environment. - -They are organised in full functional DevOps teams: Each team is responsible for -their contributions end-to-end, including maintenance, on-call and customer -support. - -A team is tasked with providing a service to their downstream customers that is -fairly similar to an existing service built by another team. +* Teams are working in a micro-services environment. +* They are organised in fully functional DevOps teams: Each team is responsible for their contributions end-to-end, including maintenance, on-call and customer support. +* A team is tasked with providing a service to their downstream customers that is fairly similar to an existing service built by another team. ## Forces -Organisational escalation paths may be different for each of the teams. - -Members of each team may be unwilling to answer on-call support for errors that -do not affect their own downstream customers. - -Severity levels for the same types of errors may be different across team -boundaries due to different SLA definitions per team/customer relationship. +* Organisational escalation paths may be different for each of the teams. +* Members of each team may be unwilling to answer on-call support for errors that do not affect their own downstream customers. +* Severity levels for the same types of errors may be different across team boundaries due to different SLA definitions per team/customer relationship. +* Teams may have different security or regulatory constraints governing their deployments. ## Solutions Decouple responsibility for source code from deployment: Both teams work to identify exactly where there is overlap and synergies. -Only shared source code is kept as part of the InnerSource project with shared -responsibility. +Only shared source code is kept as part of the InnerSource project with shared responsibility. The shared source should be coherent in that it includes all testing code (including integration tests if available) and as much of the CI pipeline as is possible to make contribution validation easier. Decouple configuration and deployment pipelines from actual business logic. Establish a second deployment of the service for the second team. @@ -56,6 +47,8 @@ Establish a second deployment of the service for the second team. Treat the common base as a library that is used by both teams with shared code ownership. +Deployment configurations can be included as separate projects in your InnerSource portfolio to allow teams to discuss/collaborate or a new team to copy them. + ## Resulting Context Teams are willing to collaborate, benefitting from sharing the work of @@ -71,13 +64,16 @@ The likelihood that changes are needed and made in the shared source code increases, leading to more frequent opportunities to refine, improve and optimise the implementation. +Encourages incremental operational standardisation in release packaging, telemetry, health/readiness endpoints and so on as the teams realise they can more efficiently maintain this in the shared code if they agree on standard conventions. + ## See also Related to this pattern is the [30 Day Warranty](30-day-warranty.md) pattern that takes a different approach to solving the forces described above. ## Known Instances -Europace AG +* Europace AG +* Flutter Entertainment: A [Flutter InnerSource application](https://innersource.flutter.com/start/setup-ci/) has a shared code "service" repository with cross-team contribution and CI pipeline to build and publish a shared release artefact. Each adopting team has a "deployment config" repository defining their own deployment. This is driven by varying regulatory requirements, service and incident management practices and infrastructure skill sets in different areas of the business. ## Status @@ -85,7 +81,8 @@ Europace AG ## Author(s) -Isabel Drost-Fromm +* Isabel Drost-Fromm +* Rob Tuley ## Acknowledgements