# Introduction
{% hint style="info" %}
You can help us to create the best possible book about InnerSource Patterns :). Learn how to [contribute to this book](/contribute).
{% endhint %}
Welcome to the **InnerSource Patterns Book**.
This book contains InnerSource best practices codified in a specific format to make it easy to understand, evaluate, and apply them in your context. We call this format a **pattern**.
The [InnerSource Commons](http://innersourcecommons.org) has collected these patterns over many years, publishing the most mature patterns in this book, where members of the community review each pattern, with at least one known instance of pattern use.
In this introduction we explain [what InnerSource is](#what-is-innersource), [what a pattern is](#what-are-innersource-patterns), and [how to use these patterns](#how-can-you-use-innersource-patterns) in your organization.
If you are using InnerSource in your company already and want to contribute your experiences to this book, we would love to [welcome your contributions](/contribute)!
## What is InnerSource?
We define InnerSource as:
> The use of open source principles and practices for software development within the confines of an organization.
InnerSource takes the lessons learned from developing open source software and applies them to the way companies develop software internally. As developers have become accustomed to working on world-class open source software, there is a strong desire to bring those practices back inside the firewall and apply them to software that companies may be reluctant to release.
For companies building mostly closed source software, InnerSource can be a great tool to help break down silos, encourage and scale internal collaboration, accelerate new engineer on-boarding, and identify opportunities to contribute software back to the open source world.
## What are InnerSource Patterns?
Patterns are a way of describing a repeatable, proven solution to a problem within a context. Patterns follow a simple form that assists you during the implementation of a solution to understand the constraints of the problem, understand the forces you need to balance, and the resulting context - the situation created by applying the solution.
Patterns can provide a way for the InnerSource Commons participants to concisely share information, improving the practice of InnerSource. Patterns are divided into Title, Problem Statement, Context, Forces, and Solutions as their main sections.
* [`What are patterns?` Youtube videos](http://bit.ly/innersource_patterns_videos) - Watch a set of 2-5 min youtube videos explaining InnerSource Patterns
* [Pattern Discussion Webinar](https://youtu.be/i-0IVhfRVFU) - We held a webinar 2017-03-16 to live-discuss a donut pattern (go to 24:30 for the discussion). This is an illustration of the review process we follow. Also see the [June 1, 2017 O'Reilly Webinar on InnerSource Patterns](http://www.oreilly.com/pub/e/3884).
* [Pattern Template](/appendix/pattern-template) - View a skeleton inner source pattern to get an idea on what goes into a new pattern!
* [Introduction to InnerSource Patterns (2016 Fall Summit presentation)](https://drive.google.com/open?id=0B7_9iQb93uBQbnlkdHNuUGhpTXc) - *Tim Yao and Padma Sudarsan* (PDF). Detailed pattern background and examples -- Get a detailed understanding of why and how to interact with our patterns. Also see the [Introduction to InnerSource Patterns (2017 Fall Summit)](https://drive.google.com/open?id=0B7_9iQb93uBQWmYwMFpyaGh4OFU) *Tim Yao and Bob Hanmer* (PDF).
## How can you use InnerSource Patterns?
Patterns must be used thoughtfully. They cannot be indiscriminately applied. In most cases, you will need to adapt the given solution to your situation; but the information given in the pattern, defining the context (immovable constraints) and forces (constraints that can be changed and balanced against each other), should help you do this. Note that you will also need to determine if there are additional constraints (company context and company forces) that apply to your particular company/organization that must be added to the pattern (as a kind of filter). These additional constraints may require additional solution steps to be applied.
The pattern form is useful for describing proven solutions but it can also be used for *brainstorming new solutions* where patterns are not yet established. This is because the anatomy of a pattern provides a framework for thinking about a problem in a structured manner. You could also create a *donut pattern* (filling in the problem, context, forces, and resulting context fields but leaving the solution blank) as a way of asking the InnerSource Commons community for help (to find a proven solution or to brainstorm things to try).
## How to Contribute?
Please refer to: [Contribute to this book](/contribute)
## Credits
This book is the result of many years of work from countless [Open Source Contributors](https://github.com/InnerSourceCommons/InnerSourcePatterns/graphs/contributors) from around the world. Their willingness to openly share the challenges that they faced in their companies, and how InnerSource has helped them address those challenges, make this book such a valuable resource for others on their InnerSource journey.
We want to specifically mention the InnerSource Patterns Working Group. They have nurtured the quality of the InnerSource Patterns and helped others to contribute. Lastly, they also compiled a selection of available patterns into this book.
The title image of this book was created by [Sebastian Spier](https://spier.hu) and adapted from an image by [Tony Hisgett - Alhambra 6](https://www.flickr.com/photos/hisgett/29345405788/), available under [CC BY 2.0](https://creativecommons.org/licenses/by/2.0/).
**Thank you to all contributors! And happy InnerSource Day :)**
## Licensing
InnerSourcePatterns by [InnerSourceCommons.org](http://innersourcecommons.org) is licensed under a [Creative Commons Attribution-ShareAlike 4.0 International](http://creativecommons.org/licenses/by-sa/4.0/) License.
# Table of Contents
* [Introduction](/)
* [Table of Contents](/toc)
* [Explore Patterns](/explore-patterns)
* [Contribute to this book](/contribute)
## Patterns
* [30 Day Warranty](/p/30-day-warranty) - When accepting contributions from outside of your own team, there is a natural aversion to taking responsibility for code not written by the team itself. Through the 30 Day Warranty the contributing team consents to provide bug fixes to the receiving team, which will increase the level of trust between both teams and makes it more likely that contributions get accepted.
* [Common Requirements](/p/common-requirements) - Common code in a shared repository isn't meeting the needs of all the project-teams that want to use it; this is solved through requirements alignment and refactoring.
* [Communication Tooling](/p/communication-tooling) - The users of an InnerSource project have trouble getting help and getting in touch with the host team. By consistently using asynchronous communication tooling, the project makes discussions visible, archived and searchable, leading to an improved level of support for users.
* [Contracted Contributor](/p/contracted-contributor) - Associates wanting to contribute to InnerSource are discouraged from doing so by their line management. Relief is provided by formal contracts and agreements.
* [Core Team](/p/core-team) - 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.
* [Cross-Team Project Valuation](/p/crossteam-project-valuation) - 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.
* [Dedicated Community Leader](/p/dedicated-community-leader) - Select people with both communications and technical skills to lead the communities to ensure success in starting an InnerSource initiative.
* [Document your Guiding Principles](/p/document-your-guiding-principles) - The usual InnerSource explanation of "applying open source best practices inside an organization" 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.
* [Explicit Governance Levels](/p/governance-levels) - Different teams within an organization use InnerSource practices in varying ways, leading to confusion and inefficiencies due to inconsistent expectations of collaboration and contribution rights. Establish centrally documented governance levels that define the extent of influence contributing teams can have on a project, improving clarity for contributors and host teams alike.
* [Extensions for Sustainable Growth](/p/extensions-for-sustainable-growth) - 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](/p/gig-marketplace) - 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](/p/group-support) - 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](/p/innersource-hackathon) - 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](/p/innersource-license) - 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](/p/innersource-portal) - 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](/p/issue-tracker) - 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.
* [Maturity Model](/p/maturity-model) - Teams have started adopting InnerSource. The practice is spreading to multiple departments. However, the understanding of what constitutes an InnerSource project varies. The solution is to provide a maturity model to allow for teams to go through a self check and discover patterns and practices that they are not yet aware of.
* [Praise Participants](/p/praise-participants) - When you receive an InnerSource contribution, it's important to thank the contributor for their time and effort. Extending your gratiutude not only effectively acknowledges the contribution but also engenders further engagement from the contributor and others. Praising contributors' positive contributions to your InnerSource project motivates those contributors (and their managers) to continue investing in the effort.
* [Repository Activity Score](/p/repository-activity-score) - Potential contributors want to find active InnerSource projects in need of their help. By calculating a repository activity score for each project, a ranked list of projects can be created (e.g. on the InnerSource Portal), so that potential contributors can more easily determine which project they want to contribute to.
* [Review Committee](/p/review-committee) - The InnerSource working model is a radical departure from more traditional approaches, for developers and managers alike. By establishing a review committee as an interface between the InnerSource initiative and all senior managers of business units participating in it, the latter are more likely to familiarize themselves with the initiative and support it, as it affords them a certain level of oversight and control without fostering micromanagement.
* [Service vs. Library](/p/service-vs-library) - Teams in a DevOps environment may be reluctant to work across team boundaries on common code bases due to ambiguity over who will be responsible for responding to service downtime. The solution is to realize that often it's possible to either deploy the same service in independent environments with separate escalation chains in the event of service downtime or factor a lot of shared code out into one library and collaborate on that.
* [Standard Base Documentation](/p/base-documentation) - New contributors to an InnerSource project have a hard time figuring out who maintains the project, what to work on, and how to contribute. Providing documentation in standard files like README.md/CONTRIBUTING.md/COMMUNICATION.md enables a self service process for new contributors, so that they can find the answers to the most common questions on their own.
* [Standard Release Process](/p/release-process) - Teams may hesitate to adopt an InnerSource project if they are unsure of its maturity. To address this, consistent release notes and published artifacts are crucial. These practices showcase a strong dedication to the project, instilling confidence and assuring users of ongoing commitment to sustainable and well-managed software.
* [Start as an Experiment](/p/start-as-experiment) - Start your InnerSource initiative as a time limited experiment to make it easier for managers unfamiliar with InnerSource to endorse and support the initiative.
* [Transparent Cross-Team Decision Making using RFCs](/p/transparent-cross-team-decision-making-using-rfcs) - 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.
* [Trusted Committer](/p/trusted-committer) - Many InnerSource projects will find themselves in a situation where they consistently receive feedback, features, and bug-fixes from contributors. In these situations, project maintainers seek ways to recognize and reward the work of the contributor above and beyond single contributions.
## Appendix
* [Pattern Template](/appendix/pattern-template)
* [Glossary](/appendix/glossary)
* Extras
* [README Template](/appendix/extras/readme-template)
* [CONTRIBUTING Template](/appendix/extras/contributing-template)
* [COMMUNICATION Template](/appendix/extras/communication-template)
* [RFC Template](/appendix/extras/rfc)
## Resources
* [This book on GitHub](https://github.com/InnerSourceCommons/InnerSourcePatterns)
* [InnerSource Commons](http://innersourcecommons.org)
# Explore Patterns
More and more patterns are contributed to this book by the InnerSource Commons community. That is awesome!
Now how to make it easy for readers to discover the patterns that can help them in their particular situation?
For this purpose we provide this mind map. It **categorizes patterns based on the different phases of an InnerSource Program**, and the challenges that might appear in the respective phases.
## Improve this Mind Map
If you notice anything in this mind map that looks wrong, please [open an issue](https://github.com/InnerSourceCommons/InnerSourcePatterns/issues), describing the problem and the fix that should be made.
Further if you have other ideas for improving the discoverability of these patterns, or want to make this mind map better, review the documentation of our [Pattern Categorization](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/pattern-categorization/README.md) approach, and also check how to [contribute to this book](/contribute).
## References
The idea for categorizing patterns like this is loosely based a description in [Thoughts on an InnerSource Pattern Language](https://drive.google.com/file/d/13AY8glCOdpLOVuz7cVD6QOB8d2xbHCS1/view) by Tim Yao, Bob Hanmer and Padma Sudarsan (2018). For specifics see slide 15 in that slide deck.
# Contribute to this book
You want to make this book better? That is awesome!
The InnerSource Patterns book itself is an [open source project](https://github.com/InnerSourceCommons/InnerSourcePatterns), and welcomes any form of contribution. Nothing is too small!
No matter if you want to help us fix grammar/spelling, improve the design, or contribute entirely new patterns based on the InnerSource experiences that you have made at your workplace. We love all of that! :)
If you have never made a contribution to an open source project before, know that the InnerSource Patterns community is group of friendly people and with that a safe place to try it out.
## Before you get started
The sources for the InnerSource Patterns and this book are kept in a repository on GitHub. Therefore you will need a GitHub user account to make edits and suggestions to this book. If you don't have one yet, head over to [github.com](https://github.com) and create an account for free.
## Different ways to contribute
Here a few ways in which you can contribute:
1. fix spelling, formatting, or other glitches that you notice in this book
2. improve the content of an existing pattern (e.g. by adding a short description of how you are using a pattern as a *Known Instance*)
3. contribute a new pattern, describing how you have overcome InnerSource-related challenges in your organization
For (1) and (2) above you can simply hit the **Edit on GitHub** link that you see at the top of each page in this book. This will take you straight to the respective file in our GitHub repository, where you can suggest your changes.
For (3) you need to clone the [InnerSourcePatterns](https://github.com/InnerSourceCommons/InnerSourcePatterns) repository, and add a new file with your suggested pattern. When making such larger contributions to this book please review our [CONTRIBUTING.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/tree/main/CONTRIBUTING.md) and also our [Contributor Handbook](https://github.com/InnerSourceCommons/InnerSourcePatterns/tree/main/meta/contributor-handbook.md).
## License of Contributions
The contents of this repository are licensed under [CC-BY-SA-4.0](https://github.com/InnerSourceCommons/InnerSourcePatterns/tree/main/LICENSE.txt). By contributing to this repository, you grant us (and everyone else for that matter) the right to use your contribution in accordance with that license.
# 30 Day Warranty
### Title
30 Day Warranty
### Patlet
When accepting contributions from outside of your own team, there is a natural aversion to taking responsibility for code not written by the team itself. Through the 30 Day Warranty the contributing team consents to provide bug fixes to the receiving team, which will increase the level of trust between both teams and makes it more likely that contributions get accepted.
### Problem
A team develops a component which is used throughout an organization. This team resists accepting or outright rejects contributions (feature requests). This behavior blocks progress and leads to frequent disruption from escalations.
### Context
* Teams depend on another team accepting their contributions so that a component produced by the receiving team can be used by the contributing team.
* The receiving team does not have the resources, knowledge, permission, and/or inclination to write the contributed component/feature themselves.
### Forces
* There is distrust of contributions due to a past history of cheating: teams submitted half finished contributions and subsequently filed requests for fixes that make it ready for use in production.
* If code is contributed from outside the team, the team has the natural suspicion that the other team does not know how to write code that would meet the receiving team's expectations.
* Each team looks first to help its own leaders achieve their own goals. This direction of loyalty can complicate resolution of this problem.
* There is a natural aversion to taking responsibility for code not written by oneself.
* Contributed code needs to be heavily rewritten before being accepted into the codebase.
* There is the fear of the contributors not being available for support with fixing bugs after the time on contribution.
* Teams fear contributed code will lead to high(er) maintenance costs but do not know how to control for that.
* Receiving teams may fear that teaching others how to contribute code will expose technical debt in their system and that visibility may be damaging.
* Receiving teams may not believe that they will get acceptable code no matter how much mentoring they provide.
* Either team may not feel confident in measuring risks or certifying that they are mitigated in a contribution; the system itself is somewhat brittle (may not be ways to fully test and catch all problems).
### Solution
Address the fears of both the receiving and the contributing teams by establishing a **30 day warranty period** starting with the time the contributed code goes into production. During this warranty period the contributing team consents to provide bug fixes to the receiving team.
Note that the warranty period could be 45, 60, or 100 days too. The duration may vary based upon the constraints of the project, the software life cycle of the project, commitments to customers, and other factors.
In addition it helps to provide clear [contribution guidelines](/p/base-documentation), spelling out the expectations of the receiving team and the contributing team.
### Resulting Context
* The receiving team is willing to accept contributions and able to share the workload of initial adaptations/fixes.
* Increased transparency and fairness.
* Keeps escalations from becoming too heavyweight.
### Known Instances
* **PayPal** Tried this and it was proven successful.
* **GitHub** internally uses this pattern with a modified warranty timeline of 6 weeks.
* **Microsoft** recommends this pattern as a principle - teams set their own specific time target matching their needs and confidence.
* **SAP** leverages this pattern in their InnerSource-based Everest project to transform collaboration, ensuring contributions are not just accepted but also supported, enhancing trust and driving forward the culture of shared responsibility and innovation. See: [InnerSource: First Contribution Explored](https://community.sap.com/t5/open-source-blogs/innersource-first-contribution-explored/ba-p/13644916)
### Authors
* Cedric Williams
### Acknowledgments
* Dirk-Willem van Gulik
* Padma Sudarsan
* Klaas-Jan Stol
* Georg Grütter
### Status
* Structured
* Drafted at the 2017 Spring InnerSource Summit; reviewed 18 July 2017.
### Variants
* Ensure cooperation of dependent teams by making them a community by having more than one, meritocratically appointed "[Trusted Committers](/p/trusted-committer)" (TCs) take responsibility.
# Common Requirements
### Title
Common Requirements
### Patlet
Common code in a shared repository isn't meeting the needs of all the project-teams that want to use it; this is solved through requirements alignment and refactoring.
### Problem
The common code in the shared repository isn't meeting the needs of all the projects that want to use it.
### Context
* Many projects are trying to use common code. There is a shared repository that all the projects access.
* Someone (or some project) wrote the code in the first place and contributed it to the repository.
* The common code is a small percentage of the overall deliverable from any of the projects.
* Each project has its own delivery schedule, set of deliverables and customers.
* This pattern applies in any of these situations:
* there is a **Strong Code Owner** i.e. all changes to the shared repository have to be approved by the repo owner
* there is **weak code ownership** i.e. no one really owns the code
* there is **no Benevolent Sponsor** i.e. no organization or executive is providing resources to organize the common code in an InnerSource fashion
### Forces
The project that made the code available has one set of needs. Its needs are similar to what some of the receiving organization wants, but not quite the same. Requirements on code should be derivable from real customer needs.
The needs of different customers are generally quite similar; however they might be expressed differently or weighted differently between customers. An example might be how some customers want some result presented in one way while others want it presented in the reverse order. It is simple to do the translation between them, but requires additional coding for one of the cases and as a result the module that computes the result can't be reused by both customers.
Many customers want the supplier to help them know what they need. The company has many “Systems Engineers” writing requirements for the products. These requirements are supposed to be a distillation of customer needs to guide development of the product. Reusing code is an important goal to save the company time and money.
### Solution
There are two aspects to solving this problem which should be done in parallel:
1. Align the requirements of the projects so that the code that meets the requirements for one project also meets the needs for the other projects.
2. Refactor the code into smaller pieces for which the many using projects can agree upon requirements.
Additionally, take advantage of customers expecting the supplier to help elucidate requirements. Bring about the alignment of requirements during the customer negotiations and influence the customers requirements rather than changing the component.
In the example presented above, the supplier helps both customers realize that they want the same thing, and it will save everyone effort (and money) if they agree to accept the result in the same format.
### Resulting Context
This might require negotiating requirements changes with the customer. The changes might also require involvement by the sales teams and product managers to get alignment on the requirements. The customer might need incentives, such as discounts, to agree to the changes.
A related challenge (and possible new pattern) is a circular story-writing exercise reported at one company employing InnerSource. In short:
* The developers write a story to solve a problem in one way.
* The program managers rewrite the story to better express their needs - keeping the essence the same. By the time it returns to developers though they don't recognize it as what they wanted to do in the first place and so balk at implementing it.
* The solution to this pattern is to have more seats around the planning table so that story modifications are understood across the project, not just in the developer or program manager camps.
### Known Instances
* Large telecommunications provider
### Status
* Structured
### Author
Robert Hanmer
### Acknowledgments
* Manrique Lopez
* Daniel Izquierdo
* Tim Yao
* Sebastian Spier
# Communication Tooling
### Title
Communication Tooling
### Patlet
The users of an InnerSource project have trouble getting help and getting in touch with the host team. By consistently using asynchronous communication tooling, the project makes discussions visible, archived and searchable, leading to an improved level of support for users.
### Problem
A team is open to receiving contributions from downstream users of their component. Coordination and communication happens in an ad hoc fashion though leading to incoherent information being shared, delays in answers received, contributors pinging multiple host team members before receiving a definitive answer.
### Context
* A team depends on another team's component.
* It would like to make contributions to that component.
* Even when it happens in writing, communication happens in a 1-on-1 fashion.
### Forces
* The host team is interested in receiving contributions and willing to mentor contributors.
* Teams have a strong verbal communication culture and are inexperienced with setting up project specific asynchronous communication channels.
* Communication channels may be aligned with specific groups that should be reached but not by communication purpose.
### Solution
The host team should provide company-public, archived, searchable, linkable communication channels that anyone in the company can subscribe to, as there are measurable benefits to supporting open, written communications channels.
The goal when streamlining communication channels for InnerSource projects should be to align communication around topics, not around certain sets of people.
A project should set up the following communication tooling:
1. **a dedicated issue tracker** where structured communication, decision-making and progress tracking can happen transparently for all host team members but also for downstream users and contributors to follow. For further applications of the issue tracker see [Issue Tracker Use Cases](/p/issue-tracker).
2. **public discussion channel(s)** that come with less rigid a structure. Typically, this will be mailing lists, online forums, Q\&A systems or even archived chat channels. Usually it is enough to start with just one channel for the project. If traffic increases too much it is helpful to split discussions about project usage from discussions about project development.
3. **a private channel** where communication about sensitive topics can happen between [Trusted Committers](/p/trusted-committer) - e.g. adding further Trusted Committers to the host team. This channel should be used with great care such that communication defaults to open and is kept private only under very rare circumstances.
While communication can happen outside of those written channels, as much information as possible should be brought back to the asynchronous channels.
All communication channels should be documented in the project `README.md`. For more details on the use of this file see [Standard Base Documentation](/p/base-documentation).
The host team members need to make an effort to direct questions that they receive personally (e.g. via email or private chat messages) back to official communication channels.
### Resulting Context
Setting up and consistently using official asynchronous communication channels helps create a base level of [passive documentation](https://www.oreilly.com/library/view/understanding-the-innersource/9781491986899/ch04.html) that can be referenced again when similar questions come up again.
With communication happening in the open others can easily follow project progress and get active contributing. Others lurking and reading lowers the barrier to get involved raising the likelihood of receiving contributions.
With questions being answered in public more people can add their perspective leading to a complete picture - this includes not only host team members, but also users of the project.
Keeping communication in asynchronous channels allows for participants on different schedules - either due to different time zones or due to different routines, meeting schedules, team routines - to meaningfully contribute to the project.
Answering questions in those channels means that not only other team members can listen in and provide additional information, it also means that other users with the same question see (or later find) the previous answer leading to a lower need to repeat explanations.
### Known Instances
* **Europace AG**
* **Paypal Inc.**
* **Mercado Libre**
* **Siemens** makes extensive use of communication channels accessible to all employees for all user questions and discussions around code.siemens.com, InnerSource and Open Source.
### Authors
Isabel Drost-Fromm
### Acknowledgment
Sebastian Spier (for the visual)
### Status
* Structured
* Drafted in December 2019.
### Credits
[People](https://storyset.com/people) illustrations by Storyset
# Contracted Contributor
### Title
Contracted Contributor
### Patlet
Associates wanting to contribute to InnerSource are discouraged from doing so by their line management. Relief is provided by formal contracts and agreements.
### Problem
Without support by middle management, the total number of contributors and, as a result, the amount of contributions made and value generated by the InnerSource initiative will likely fall below expectation of top-level management. This will likely be amplified if there is no adequate funding for and empowerment of [Dedicated Community Leaders](/p/dedicated-community-leader). This runs the risk of top-level management abandoning the InnerSource idea.
### Context
A large corporation has started an InnerSource initiative. Major goals for the initiative are to increase the efficiency of distributed software development and to foster innovation by allowing every associate to voluntarily contribute to InnerSource projects, regardless of topic and business unit.
Top level management is on board and supporting the InnerSource initiative. For them, the InnerSource initiative is just one of many initiatives to foster innovation and efficiency, though. They are funding InnerSource with money and capacity for community leaders and are largely giving autonomy as for how the budget is spent. They are also limiting the breadth and duration of the initiative and partake in periodic reviews until there is proof it yields the expected results (see [Review Committee](/p/review-committee)). Top level management has announced their support for InnerSource on various company-internal meetings.
However, top-level management has not yet empowered or incentivized mid-level managers to allow or even motivate their employees to participate in cross-divisional InnerSource activities. In addition to that, the capacity of every associate is usually allocated to non InnerSource projects for 100 % of their working time. Cross organizational collaboration is not yet the norm and line managers usually do not have targets outside of their own organization. Contributions to InnerSource projects are expected to be made during working hours, not during free time.
### Forces
* Managers are held responsible for the results of their business units. Letting their staff participate in InnerSource activities which might spend time making contributions outside of their business unit effectively reduces the capacity of his or her unit. This will likely make it harder for the managers to reach or exceed their goals.
* Line managers and HR will, by default, judge the performance of their subordinates against their business units goals, which might not be aligned with the goals of the InnerSource community.
* The less executive air cover a line manager perceives he has, the less likely is he or she to have his or her staff participate in InnerSource activities which contribute to another business unit.
* The less transparency and control a line manager has of work done by one of her subordinates, the less likely is she to allow her to contribute.
* The less formally work in InnerSource is managed and organized, the less likely a line manager who is accustomed to formal processes is to sign off on one of her employees contributing to InnerSource.
* The more time an associate spends on contributions to an InnerSource project which does not benefit his day-to-day work, the more will the workload for his teammates in his business unit increase.
* Individual contributors will likely consider participating in InnerSource as an opportunity to enhance their professional network within the company and to gain knowledge and experience in the technical area of her contributions.
### Solution
Set up a formal contracting between the contributor, their line manager and a centrally funded and steered InnerSource governance office (ISGO). Have the ISGO reimburse business units who contracted contributors for the contracted time.
* The contracting specifies a maximum percentage of the associates work time in InnerSource.
* The contracting clearly states that work in the contributor's business unit takes precedence over work in InnerSource.
* The contracting states that it is not required to work in InnerSource for the maximum percentage specified in the contract.
* The contracting is signed by the contributor, the contributor's line manager, the governance office and the [Dedicated Community Leader](/p/dedicated-community-leader) of the community the contributor will be contributing to.
* The governance office offers to mediate between the contributor and her line manager in case of conflict regarding the time for contributions.
* The [Dedicated Community Leader](/p/dedicated-community-leader) participates in or provides input for performance reviews of contributors contracted for more than 20 %.
### Resulting Context
A formal contracting and centrally funded reimbursements convincingly communicating the organizations support for the InnerSource initiative, thus empowering middle management to sign off on it:
* Allocation of corporate funds to business units for reimbursement of development capacity signals to line managers that InnerSource is deemed valuable by the organization, that it has executive air cover and that they are expected to support it, too.
* A formal contracting signals that work in InnerSource is managed professionally and inspires trust.
* A formal contracting increases transparency and provides a better overview about the associate's available capacity for his business unit and InnerSource projects, thus reducing the risk of "over-booked/planned capacity".
A formal contracting is also beneficial for contributors and communities:
* With a stable group of contributors, it is more likely that some of them will eventually achieve [Trusted Committer](/p/trusted-committer) status.
* A formal contracting provides a basis for resolving conflict related to participation in InnerSource activities. Note that mediation will likely be successful only for a few companies with a culture conducive to that.
### Known Instances
* BIOS at **Robert Bosch GmbH**
### Status
* Structured
### Author
* Georg Grütter (Robert Bosch GmbH)
### Acknowledgments
* Diogo Fregonese (Robert Bosch GmbH)
* Robert Hansel (Robert Bosch GmbH)
* Jim Jagielski
* Tim Yao
* Cedric Williams
* Klaas-Jan Stol
* Padma Sudarsan
* Nick Stahl
* Ofer Hermoni
* Robert C. Hanmer
### Changelog
* **2016-10-25** - first review
* **2017-05-09** - rework
* **2017-09-08** - second review, final rework and merged
* **2021-02-27** - fixing issues with display of the pattern in the book
# Core Team
### Title
Core Team
### Patlet
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.
### Problem
* It is difficult to contribute to the project. This could be due to things like:
* Can't run the project locally.
* Poor documentation.
* Convoluted code.
* Inadequate testing.
* It is difficult to use the project. Some possible causes:
* Poor documentation (again).
* Frequent bugs.
* Nonintuitive setup.
### Story
There's a central project that everyone depends on. What a great candidate for InnerSource! Unfortunately, the project has grown organically, with various contributions and additions slapped on haphazardly. Now it's an icky, thick morass of code that no one understands and everyone is afraid to touch. It's clearly due for an overhaul (e.g. refactoring, testing, documentation, etc.), but even though everyone needs and wants that work to happen, no one takes the time to do it.
### Context
* Many teams need the project.
* The project has significant tech debt.
* Slow adoption and iteration on the project.
* There is not a owner or maintainer who takes responsibility for the project and contribution ecosystem as a whole.
### Forces
* Every contributing team is busy, and therefore prioritizes work that results in an immediate payoff for themselves.
* As the project grows the natural trend is for it to become more difficult to use and to modify.
### Solution
Form a core team whose job it is to maintain this project in a state so that others can easily onboard and contribute to it. This core team does the work that is necessary for a healthy usage and contribution ecosystem. This critical work tends to not be prioritized as a contribution. Categories of this type of work include communication, local environment, and DevOps infrastructure.
Here are some specific examples:
* Production bugs
* Documentation
* On-boarding tutorials and examples
* Automated testing
* CI/CD
* Local environment
* Modularization
* Versioning
* Monitoring
* Trailblazing new classes/categories of features
Each of these items is very important to a healthy product ecosystem, yet is unlikely to be prioritized as a contribution.
The core team may be composed of a small number of people on a full-time or a part-time basis. 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** as well (for more on that concept see [Learning Path](https://innersourcecommons.org/learn/learning-path/trusted-committer/) and [Pattern](/p/trusted-committer)). 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.
A good way to continually remind the core team of this goal is to have them report regularly on:
* number of active teams using the project
* number of off-team contributions to the project.
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.
### Resulting Context
* It is easy to use and contribute to the project.
* Many teams use and contribute to the project.
* Core team has their success defined in terms of others' interaction with and response to their project.
### Rationale
Separating out a core team and tasking them in this way helps to fill the gaps that a successful project needs yet are left behind by contributors that are pursuing their own agenda only. The core team fills those gaps and greases the wheels so that the contribution ecosystem remains healthy.
### Known Instances
* **Nike** implemented this pattern to manage the InnerSource effort around its reusable CI/CD pipelines.
* **WellSky** established a Core Team for a key project. This allowed them to scale their InnerSource contributions to that project significantly - see [Wide-Scaled InnerSource with a Core Team](https://www.youtube.com/watch?v=kgxexjYdhIc).
* **BBVA AI Factory** implemented this pattern as part of an InnerSource strategy to foster contribution to and reuse of data science code - see [Mercury: Scaling Data Science reusability at BBVA](https://www.bbvaaifactory.com/mercury-acelerando-la-reutilizacion-en-ciencia-de-datos-dentro-de-bbva/).
### Status
Structured
### Author
[Russell R. Rutledge](https://github.com/rrrutledge)
# Cross-Team Project Valuation
### Title
Cross-Team Project Valuation
### Patlet
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.
### Context
* You are responsible for a cross-team that serves as a platform for others in the company.
* The cross-team project does not deliver any direct value for company revenue.
### Problem
Cross-team projects can potentially have a very large impact on the company yet are difficult to represent in a data-driven fashion. As a result, it is easy and common to either pursue projects that do not provide real value or to underfund what would otherwise produce great value.
### Forces
* Projects need to show value (objective or subjective) to company leadership in order to be funded.
* Cross-team project value is dispersed across multiple end business units.
* Due to this dispersal, cross-team project value is difficult to measure directly.
### Solution
Set in place a pattern and model of how to value cross-team projects. Such models give us the tool that we need to focus and amplify high-value collaboration for the company.
The core of all cross-team project value is the idea that we can get more done together than apart. Ascribing value to a cross-team effort is an exercise in quantifying *how much more* is getting done together. The exact delta in productivity will vary by domain and project. There is a common process, by which you can create a model to calculate it.
#### Explanation
Assemble a small team of subject matter experts in your domain. Using that team of experts, estimate 4 things about each consumer of your project output:
* How long does it take them to consume your project output?
* How long would it otherwise take them to home-roll the value of your project output for themselves?
* What percentage of your project output is actually useful for them?
* How much time on an ongoing basis (ideally per-use) would they otherwise spend maintaining their home-rolled solution?
When making these estimations, it's impossible to know with high accuracy *exactly* how long any activities take. That's not your goal. Rather than exactness, you should strive to ***set a worst-case bound*** on these estimates. The idea is for the group of experts to be able to say to each other, "We don't know exactly how long it would take, but we can all agree it's *at least* this much." Specifically, you should estimate a *maximum* reasonable time to consume your project output and *minimum* reasonable times for consumers to otherwise home-roll, use and maintain their own solutions.
One note about cost of "rolling your own solution" (home-roll). The cost to home-roll a solution is NOT necessarily (very unlikely, in fact) the same as the cost of making a shared solution. Oftentimes for the same functionality the modularity and quality involved in building a cross-team, shared solution makes it a noticeably higher investment than a quick, hard-coded implementation used just once.
#### Formula
Once you have your worst-case bounds you can value your cross-team project output during a given time frame via the simple formula:
```
[Time Saved] - [Time Invested]
([Count of New On-boardings] * [Cost to Home-Roll] * [Percent Useful Functionality] + [Count of Usages] * [Maintenance Cost Per Use]) - ([Count of New On-boardings] * [Cost to On-board])
[Count of New On-boardings] * ([Cost to Home-Roll] * [Percent Useful Functionality] - [Cost to On-board]) + [Count of Usages] * [Maintenance Cost Per Use]
```
#### Commentary
Despite the trappings of rigor, this process does not yield an exact way to measure cross-team project output. In-practice, however, it does give a framework by which you can make a sound decision at how to fund this work. After having good, reasonable data according to the above explanation, you should fund dedicated development hours toward running the project up to ***at least*** of the lesser of the following three levels:
1. The raw hours saved by the formula above. Since we're all sure that the formula will produce a number that is below the true number of hours saved, you can have confidence that funding the project up to that point is a sure win for you.
2. The amount of time that it takes to support inner sourced contributions to cross-team projects. Since the contributor would likely have done the work anyway in a one-off fashion, it is worth it to fund the time it takes to facilitate their work going into a shared location.
3. Whatever feels good to you. One intentional side effect of having a valuation formula is that it naturally forces measurement of the key points of usage that provide value to consumers.
Those measurements can be understood and consumed in their raw form to provide you with a gut-feel idea of how valuable is the project.
Some may be concerned about the lack of accuracy in this valuation approach. It's okay for this process to not give an exact measurement. It just needs to be accurate enough to accomplish 2 purposes:
1. Give a means to represent the value of what is happening to those that are organizing and funding cross-team efforts.
2. Help those involved to know what areas of cross-team effort are higher priority to pursue based on their value.
In-practice, as long as these valuations are within an order-of-magnitude of reality and one-another, they are sufficiently accurate to fill these purposes. They will provide a head-and-shoulders improvement in on-the-ground results over the ad hoc valuations (and resultant effects) described in the **Problem** section at the beginning of this document.
### Resulting Context
* Data-driven means to discuss the value and funding of the cross-team project with leadership.
* Key metrics around the cross-team project instrumented in raw form.
* Defining how the cross-team project provides value tends to lead to it actually producing greater value for the company.
* Generally-successful project and "buzz" around it.
### Known Instances
* **Nike**
### Status
* Structured
* Proven in multiple domains.
### Authors
* Russ Rutledge
### Acknowledgments
* Jeremiah Wright for teaching me to think about cross-team projects as an internal business dealing in the currency of developer time.
# Dedicated Community Leader
### Title
Dedicated Community Leader
### Patlet
Select people with both communications and technical skills to lead the communities to ensure success in starting an InnerSource initiative.
### Problem
How do you ensure that a new InnerSource initiative has the right [community leader](http://www.artofcommunityonline.org/) to grow its impact?
Selecting the wrong persons and/or not providing enough capacity for them risks wasted effort and ultimately the failure of a new InnerSource initiative.
### Story
Consider the following story. A company wants to start an InnerSource initiative in order to foster collaboration across organizational boundaries. They have decided to start with an experimental phase with limited scope. Management has selected a suitable pilot topic for the first InnerSource community and expects contributions from many business units across the organization. The company has nominated a new hire to head the community for 50 % of his work time, because he was not yet 100 % planned for. After 6 months, the community has received only a few contributions, most of which are from a single business unit. The company replaces the community leader with someone who has a longer history in the company, this time for only 30 % of his time. After another 6 months, the number of contributions has picked up only marginally. The company is no longer convinced that InnerSource helps to achieve their goal of increased, cross divisional collaboration and abandons InnerSource.
### Context
* The company is a large and old company. It has no prior experience in Open Source or other, community based working models. The company culture is best characterized as a classical top-down management style - it is generally at odds with community culture.
* While there are supporters and a sponsor in top level management, middle management in the company is not yet sold on InnerSource.
* Management was not convinced to provide more than a limited budget to fund a part time community leader, only.
* The initially selected community leader has little or no prior experience with the Open Source working model.
* The initially selected developer community leader does not have an extensive network within the company.
### Forces
If a company does not significantly invest in the initial InnerSource community in terms of budget and capacity for InnerSource, the credibility of its commitment to InnerSource might be perceived as questionable. A common impulse of a company with a traditional management culture to a project or initiative not performing as expected will be to replace its leader. Doing that without involving the community and following meritocratic principles will further undermine the company's commitment to InnerSource by highlighting the friction between the current company culture and the target culture - a community culture.
The value contribution of InnerSource projects will not be obvious for many managers which are steeped in traditional project management methods. Those managers are less likely to assign one of their top people, who are usually in high demand by non InnerSource-projects, to an InnerSource project for a significant percentage of their work time.
Communication takes up a significant percentage of a community leader's daily work. At the same time, he or she will likely also have to spearhead the initial development, too. In the face of limited capacity, inexperienced leaders will tend to focus on development and neglect communication. The barrier for potential contributors to make their first contribution and to commit to the community will be much higher if the community leader is hard to reach or is slow to respond to feedback and questions for lack of time. Furthermore, technically inexperienced leaders will most likely have a harder time to attract and retain highly experienced contributors than a top performer with a high degree of visibility within a company would have.
If a community can not grow fast enough and pick up enough speed, chances are they won't be able to convincingly demonstrate the potential of InnerSource.
If the company selects an experienced project or line manager steeped in traditional management methods to be the community leader, he or she is likely to focus on traditional management topics such as resource allocation, providing structure and reporting channels rather than leading by example through meritocratic principles. This will undermine the credibility of the InnerSource initiative in the eyes of developers.
### Solution
Select a community leader who:
* is experienced in the Open Source working model or similar community based working models,
* has the required soft-skills to act as a natural leader,
* leads by example and thus justifies his position in the community meritocracy,
* is an excellent networker,
* inspires community members,
* can communicate effectively to both executive management and developers and
* is able to handle the managerial aspects of community work.
Empower the community leader to dedicate 100 % of his time to community work including communication and development. Inform management of the need to be sensitive to the views of the community when engendering a change in community management. Ideally, empower the community to nominate a community leader themselves.
### Resulting Context
A community leader with the properties described above will lend a face and embody the company's commitment to InnerSource. It will make it more likely that other associates in his network will follow his lead and contribute to InnerSource. Over time, he or she will be able to build up a stable core team of developers and hence increase the chances of success for the InnerSource project. By convincing a large enough audience within his company of the potential of InnerSource, he or she will make an important contribution to changing the company culture towards a community culture.
Having excellent and dedicated community leaders is a precondition for the success of InnerSource. It is, however, not a silver bullet. There are many challenges of InnerSource which are above and beyond what a community leader can tackle, such as budgetary, legal, fiscal or other organizational challenges.
### Known Instances
* BIOS at **Robert Bosch GmbH**. Note that InnerSource at Bosch was, for the majority, aimed at increasing innovation and to a large degree dealt with internal facing products. This pattern is currently not used at Bosch for lack of funding.
* **Airbus**. A data scientist wanted to improve the collaboration with peers in the group and found: i) many developers (beyond data science) wanted that too and were happy someone was taking care of the issue, and ii) support from line manager and middle management to eventually act as the *de facto* community leader, on top of his regular line of duty.
### Alias
Dedicated Community Manager
### Status
* Structured
### Authors
* Georg Grütter (Robert Bosch GmbH)
* Diogo Fregonese (Robert Bosch GmbH)
### Acknowledgments
* Tim Yao
* Padma Sudarsan
* Nigel Green
* Nick Yeates
* Erin Bank
* Daniel Izquierdo
### Changelog
* **2016-11-06** - 1st review
* **2017-04-06** - 2nd review
# Document your Guiding Principles
### Title
Document your Guiding Principles
### Patlet
The usual InnerSource explanation of "applying open source best practices inside an organization" 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 organization 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 organization 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 organization 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 organization.
* 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 organization 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 to teams and individuals by documenting these two areas:
1. **Purpose** - Why does the organization want to adopt InnerSource?
2. **Principles** - Which InnerSource principles will help to address these challenges?
The following sections provide more details about both of these, meant as possible starting points to document them for your organization.
#### Why does the organization want to adopt InnerSource?
In the past InnerSource has proven to be successful to solve several issues commonly found in organizations.
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 organization - 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 organization
Source code, documentation, data relevant for project development must be available and easy to find for anyone in the organization.
(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 organization 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 advice 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 organization: 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](/p/trusted-committer). All Trusted Committers of a project are published.
### Resulting Context
* Organization members understand which challenges they can address by applying InnerSource best practices.
* Organization members lacking prior open source experience understand the basic values and principles of InnerSource projects.
* Organization members lacking prior open source experience are able to check their daily activities against a set of common established values.
* The organization's development practices become more similar to open source projects thus making it easier for organization members to participate in open source projects.
### Known Instances
* **Europace AG**
* **GitHub**
* **Robert Bosch GmbH**
* **Siemens'** InnerSource strategy is built upon the guiding principles of Documentation, Workflow, Transparency, Continuous Integration and Culture which are detailed in their InnerSource portal.
* **Mercedes-Benz**
* **SAP** - The [SAP Open Source Manifesto](https://github.com/SAP/open-source-manifesto) mentions principles that SAP follows that related both to Open Source and InnerSource
#### Europace AG
The InnerSource principles listed in the Solution section above are mostly based on Europace's experience. See [details](https://tech.europace.de/post/europace-inner-source-prinzipien/) (in German).
#### GitHub
**Purpose**
Often at GitHub we work in a model where teams contribute features to areas outside their area of responsibility. Common examples include sales engineering contributing features to unblock a sale, Special Projects contributing urgently needed, high impact features across the product, and a team working across multiple areas to deliver a feature.
**Principles**
Overall the principles outlined in this doc are to avoid increasing tech debt and support burden for the owning team. Oftentimes help is being lent to a team because they are behind due to support and maintenance costs in their area of responsibility and they do not have bandwidth to contribute to the feature. Any new features done by another team that add to that support burden or tech debt means even less time for the owning team to work on new features, so we want to make sure they are done right.
At the same time, we strive to be a company where engineers freely work across boundaries, and business priorities often require that we contribute to areas outside our core areas of ownership.
A good summary of the principles is to leave the area in as good as or better shape than you found it.
With that in mind, here are principles we agree on:
* Avoid minimum viable products (MVP) that accrue feature debt. It is ok to ship an MVP to get customer feedback, but the contributing team must be committed to finishing the feature set. Examples include:
* Commitment to go beyond MVP to a solution that will satisfy most customers.
* Full support for administration of new features (e.g. support in the settings UI vs. just doing a command line).
* Surface features in both the UI and API vs. only deliver an API (or vice versa)
* Ensuring features work in cloud and local server environments.
* Support the feature work up to and beyond its deployment to production
* Coordinate incremental rollout
* Handle support tickets
* Plan time to address customer feedback (features and bugs)
* Build features in the right way (do not accrue tech debt)
* Agree on requirements and solution with Product and Engineering teams
* Proper architecture and design
* Make sure data is stored properly to avoid later data migrations.
* Appropriate telemetry is in place
* Appropriate test coverage is in place
* Supported on cloud and local production environments (including setup, configuration, backup / restore, migrations, etc.)
* Bugs fixed
* Documentation updated
**Engagement**
We use an engagement model because we like to lay out what concrete steps can be taken by a team when contributing features to areas outside their area of responsibility.
A typical engagement model at GitHub looks like this:
* Get approval on the feature set and rollout plan from the product owner.
* Get approval on engineering design, including addressing the non-functional requirements (telemetry, test coverage, multi-environment testing and support) from the engineering owner (typically engineering manager and director).
* Do code reviews along the way, along with reviewing any new or changed requirements.
#### Robert Bosch GmbH
**Purpose**
Fostering collaboration, learning and innovation is the main focus of the Bosch InnerSource initiative (BIOS).
**Principles**
To that end, Bosch 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.
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.
#### Mercedes-Benz
Mercedes-Benz highlights the principles that they hold themselves accountable to in their [Mercedes-Benz AG - FOSS Manifesto](https://opensource.mercedes-benz.com/manifesto/). They differentiate between company principles and employee principles, which adds higher granularity. Further they combine both Open Source and InnerSource in the same manifesto, highlighting how both follow the same ideals.
### Status
Structured
### Authors
* Isabel Drost-Fromm
* Georg Grütter
### Acknowledgments
* Zack Koppert - for sharing GitHub's approach in the Known Instances
### Alias
Explicit InnerSource Principles
# Explicit Governance Levels
### Title
Explicit Governance Levels
### Patlet
Different teams within an organization use InnerSource practices in varying ways, leading to confusion and inefficiencies due to inconsistent expectations of collaboration and contribution rights. Establish centrally documented governance levels that define the extent of influence contributing teams can have on a project, improving clarity for contributors and host teams alike.
### Problem
Several teams are using InnerSource practices. However the degree to which they welcome contributions and give equal collaboration rights to contributors differ. Despite these differences, all teams refer to their way of working as "InnerSource" without any additional qualifiers.
The result is confusion and frustration when teams collaborate as the expectation of what InnerSource means in practice is different in each team. This confusion also affects strategy planning and decisions on future InnerSource intent as the term is too vague which leads to long discussions and time lost on clarifications.
### Story
#### Example of Confusion
For two projects, different InnerSource practices have been adopted. Project A has a shared ownership model with [Trusted Committers](/p/trusted-committer) from multiple teams. Project B is fully owned by one team with contributions from other teams.
New users of either project are regularly confused about the level of influence they can gain in the respective project. This leads to long discussions, escalations and time lost on clarifications.
#### Example of Delayed Decision
Project C is currently closed source and used only by team 1. Team 2 want to use project C and the leadership of the two teams negotiates options which include InnerSource practices. Agreement takes longer than expected because the "InnerSource" term did not describe a target state that could be agreed without ambiguity, and the teams had to document bespoke options for their leadership to consider before a decision could be made.
### Context
* InnerSource concepts are established within an organization with multiple projects and teams adopting InnerSource.
* Internal InnerSource practices are not prescribed in detail.
* Teams/projects have the autonomy to optimize for their local circumstances.
### Forces
* Projects adopt different InnerSource patterns and practices to optimize for their context.
* Users want clarity on the level of influence they can gain in an InnerSource project when deciding whether or how to use it.
* Leaders want clarity on InnerSource project intentions to understand the expected cost and benefits.
* Writing a detailed description of a set of InnerSource practices requires significant effort.
### Solution
Create centrally maintained documentation of the project governance levels that are used in your organization. The governance levels describe how much influence the host team of a project is willing to share with contributing teams. Or in other terms, the level of influence a contributing team can gain in the respective project.
Note: Instead of "governance levels" we might also say "operating models", or "ownership models". We stick to the term "governance levels" throughout this pattern. Feel free to use whatever terms fits your organization best.
To establish governance levels in your organization, we recommend these activities:
1. Define your governance levels - **Goal**: Have a clear written description of the governance levels, that you can refer to as a reference.
2. Promote your governance levels - **Goal**: The governance levels are known and understood throughout your organization.
We will go into more detail on each of these activities in the following sections.
#### Define your Governance Levels
The goal of this activity is to have a clear written description of the governance levels, that you can refer to as a reference.
* Document the governance levels that are commonly used in your organization.
* Document additional governance levels that you don't have yet, but that would benefit the cross-team collaboration in your organization.
* Give each of them a distinctive and descriptive name.
* Use specific projects as examples where helpful.
* Keep this documentation in a central place that you can easily reference that can be accessed by everybody.
**Commonly used Governance Levels**
The following governance levels are commonly used when practicing InnerSource.
Each of these levels adds more influence/karma to the contributing team. However each step also requires more transparency and shared communication resources between both teams.
1. **Bug Reports and Issues Welcome**:
* People outside the host team may use the code.
* They can submit feature requests and bug reports for things they would like to see changed.
* aka **Readable Source**, **Shared Source**
2. **Contributions Welcome**:
* People outside the host team may use the code.
* They can make modifications and submit them to the host team for inclusion.
* aka **Guest Contributions**
3. **Shared Write Access**:
* People outside of the host team can get write access to the project.
* The host team may give outside contributors additional leverage in the strategic direction of the project.
* Related Pattern: [Trusted Committer](/p/trusted-committer)
4. **Shared Ownership**:
* Members of different teams collaborate on the project as equal peers.
* Everyone has the ability to merge code.
* Everyone has an equal say on the project direction.
* Everyone has an equal say in who else to add to this group.
* aka **Distributed Ownership**, **Maintainers in Multiple Team**
* Related Pattern: [Group Support](/p/group-support)
Bug Reports and Issues Welcome
Contributions Welcome
Shared Write Access
Shared Ownership
#### Promote your Governance Levels
The goal of this activity is that the governance levels are known and understood throughout your organization, and that some of your higher profile InnerSource project start to adopt these governance levels explicitly.
* Present your governance levels in existing knowledge sharing forums in your organization. Make sure to explain the why, not just the what!
* Whenever talking about your governance levels, make sure to stick to he exact names/titles of your governance levels.
* Use the names of your governance levels within project documentation and contributing guides (see also [Standard Base Documentation](/p/base-documentation)).
* Label projects with the governance levels in an [InnerSource Portal](/p/innersource-portal), so that contributors can see at a glance what type of InnerSource collaboration the host team supports for the given project.
* Create training material containing examples of projects in your organization. That makes it easier for people in your organization to related to these examples and understand what these governance levels mean and how they work.
* Present the governance levels as a menu of adoption options when launching new InnerSource projects.
### Resulting Context
* Cross team communication occurs efficiently without confusion, using terms that are universally understood and centrally documented.
* Organization leaders understand the nuances within practicing InnerSource and make better informed and more precise decisions that are easier to communicate.
* Increased standardization of InnerSource practices within the organization as the named and documented building blocks are used by teams as a menu for adoption.
* Teams can adopt InnerSource best practices in a step-by-step way which makes adoption easier and less intimidating.
### Rationale
Like "InnerSource", Open Source is also a broad term.
There are projects on GitHub, published purely for the pleasure of the author with no intention of long term maintenance, not intention to fix bugs submitted by users. This would be the equivalent of "Bug Reports and Issues Welcome" - you can report the bug, but its on the owner to find the time to fix it. We call this **shared source**, which would not qualify as open source software (OSS) yet.
There are projects where the roadmap is created in-house, hidden from public view. Where commit rights come and go with the contract of the employees of one company (e.g. MongoDB, Elastic, Tensorflow). Users are welcome to submit patches, they will even be mentored through. All development happens in the open, but control and strategy is never shared. This would be the equivalent of stage "Contributions Welcome". We call this **single vendor OSS**.
There are projects that share write access, but do not share the power to decide who gets write access next. This applies to everyone who is only a committer at an Apache project.
There are projects that are fully shared across multiple independent organizations (e.g. k8s, any Apache project) - those would be "Shared Ownership". We call this **vendor neutral OS**.
The same levels make sense inside of organizations.
### Known Instances
* **BBC** - referenced in this talk: [Ownership in a DevOps and InnerSource environment - Tom Sadler (BBC)](https://www.youtube.com/watch?v=O8TK7QG3FjM)
* **Flutter Entertainment**
* **Europace AG**
#### Flutter Entertainment
Flutter Entertainment define an [InnerSource Pyramid](https://innersource.flutter.com/how/pyramid/) to describe three different operating models: Readable Source, Guest Contributions and Maintainers in Multiple Teams. Each name is centrally documented. The use of these names is encouraged via repeated usage, direct training and categorization of each InnerSource project.
### Status
* Structured
### Authors
* Isabel Drost-Fromm
* Rob Tuley
* Tom Sadler
* Sebastian Spier
### Alias
* Governance Framework (for InnerSource)
* Defined Project Governance
* Project Ownership Models
* Explicitly Defined Governance
* InnerSource Operating Models (seems a bit too broad, as readers might expect this to include CI/CD setups, code review tooling, and the like)
# Extensions for Sustainable Growth
### Title
Extensions for Sustainable Growth
### Patlet
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.
### Problem
As the number of contributions to a mature InnerSource repository rapidly increases, it adds more burden on code reviews and maintenance. This results in a large code review backlog or premature rejection of new feature contributions.
How can the host team allow for faster release of new features, encouraging innovation and experimentation; while also keeping the repository well maintained?
### Story
There is a strategic project that aims to collect the best innovations within a domain space to one common stack, allowing reuse of a common infrastructure and providing a standard user experience. Through InnerSource, various teams in the organization that work within the domain space get an opportunity to collaborate and contribute their innovations to the common codebase.
However, a large number of contributions in parallel from several developers is making maintenance of the codebase difficult. This is adding a huge burden on the project maintainers who assume ownership over the code quality standards and enable the community through various forms of communication.
Project maintainers are at risk of burnout due to:
* Everlasting backlog of pull requests from contributors that need to be reviewed.
* Job dissatisfaction: Majority of maintainers' time spent in community support leaves no room for innovation.
* Perceived lack of accomplishment: Not all contributed features have adequate user demand and result in consequent adoption.
* Time consuming releases: More features in the codebase results in long running tests.
* Increase in maintenance activities: More bugs raised as new capabilities are added.
A lot of time is spent on maturing every new feature contribution, before potential users even get an opportunity to explore the feature for their use cases. If it turns out that new feature isn't fulfilling the use case, then all that time spent on achieving the desired code quality standards are waste.
### Context
* A strategic InnerSource codebase is scaling rapidly with new feature contributions from several employees.
* The ratio of reviewers to contributions results in a growing backlog of pull requests. This is slowing down release of new features to the community.
* Quality of the codebase is degrading and user experience is adversely impacted.
* Maintainers of the codebase are burdened and cannot keep up with the influx of contributions and increased community support.
* Some of the contributed features are not gaining adoption by users, and might even turn fully dormant. However even though they are unused, these features are still adding to the maintenance overhead.
* Organization is investing heavily in hardening of new feature contributions to retain quality standards before the ideas are explored by the community.
* The pattern applies in either scenario:
* Maintainers find themselves rejecting new feature ideas to narrow down the scope of the project. This is hampering innovation in the community and restricting further expansion.
* To reduce backlog, new features are getting released without thorough documentation, hardening, or testing, creating a poor user experience. This is also bloating the size of the codebase, adding a huge dependency graph and making it difficult to maintain.
### Forces
* Maintainers and product owners want to allow for expansion, encourage innovation and experimentation without being overly restrictive on contributions, while also keeping good code and quality standards for user experience.
* A large amount of time goes into hardening and thorough testing of features to meet product standards, but product owners may want to allow for faster release of new innovations for adopting products to explore before investing time in maturing the capabilities.
* Maintainers want to encourage the community to share innovations that combine product capabilities with other use-cases without adding more dependencies to the primary repository.
### Solutions
Allowing [extensions/plugins](https://en.wikipedia.org/wiki/Extensibility) to high-scale InnerSource codebases can relieve the maintenance burden on repository maintainers and allow faster release of new features for adopting products to explore. This shifts maintenance of capabilities to extension owners and allows the primary repository to support capabilities that have been adopted more widely and are more strategic.
Extensions provide a filter for new capabilities that may eventually move into the core of the project. Extensions also act as an incubation and community hardening environment, allowing for much of that hardening to happen organically rather than in a costly review process.
In order for the extensions model to be successful, there are few architectural considerations to keep in mind:
1. **Easy to create:** To obtain community participation, extensions need to be easy to create.
* Create a repository template that extensions should use as a starting point. This allows the extensions to add their new features in new repositories, separate from the core project. The template should provide the same modular structure as the primary repository, and include the framework to package and release extensions.
* Ensure that as the primary repository changes, the template(s) are well-maintained. The primary repository maintainers are responsible for updating the template(s) to ensure it is compatible with the main project. Following good versioning conventions, e.g., [semver](https://semver.org/), makes this easier to follow.
* It is further recommended that the primary repository maintainers provide guidance on how to update extensions based on older versions of the template as newer versions are released.
* Add example extension(s) developed from the template, which project developers can reference to understand how to write a well-patterned extension.
* Loosen the requirements for contributors to create extensions by bypassing reviews to allow for faster release or experimentation.
2. **Loose coupling:** Having modular components that contain functionality can allow loose coupling, where changes to extensions do not impact the quality of the main codebase or other extensions.
3. **Dependency management:** Each extension should be careful to pin the version range of the primary repository that it is built against (the same way it would any other dependency) and should be careful in its use of other dependencies that shadow dependencies of the primary repository such that the versions it chooses for those dependencies are compatible with the primary repository versions selected. Any conflicts with primary repository will be caught in the test framework for the extension.
4. **Testing strategy:** How to test extensions both individually and in combination?
* **Testing extension individually:** Extensions template will provide a test framework to be used by the extension developers to test the capability added. This can include a framework for unit tests, runtime performance and quality tests.
* **Testing extension in combination with primary repository:** Extension developers have a well-patterned method for testing their extension against specific versions of the primary repository without involvement from the primary repository's maintainers.
* **Testing extension in combination with other extensions:** Providing a test framework for this scenario could result in being excessive especially if there are a large number of extensions that are still being explored by users and unlikely to be all used in combination. If a user runs into conflicts while using extensions in combination (which should be unlikely with sufficient loose coupling), the user can raise an issue to the respective extension owners who will sort it out. As an extension reaches later phases of the lifecycle and gets merged into the primary repository, it would be tested in combination with rest of library and any dependency conflicts will have to be resolved at the time.
5. **Discoverability and Usability:**
* Make extensions easily discoverable with a publishing page showing the extensions that users have created and want to share for product usage.
* Allow registration of extensions with the primary project for users to leverage extensions alongside the original project, thus keeping the same user experience.
6. **Lifecycle of extensions and maintainability:** Establish the lifecycle for extensions from creation to porting into the primary codebase, along with clear ownership guidelines.
* Extension creators continue maintaining the extension, providing any support and fixing defects. Any extension left unmaintained will be unlisted from the publishing page.
* Create criteria for when an extension can be ported to the primary repository, such as adoption of the extension by internal products and demand for the feature.
* Porting process of the extension to the primary repository will follow more stringent code review guidelines as set by library maintainers.
Following these principles ensures that:
* Developers can add new features to a project's ecosystem without requiring them to write large amounts of [boilerplate](https://en.wikipedia.org/wiki/Boilerplate_code) code.
* Extensions are discoverable in a repeatable manner by all users of the primary project; just because code doesn't live in the main repository yet does not mean it is not valuable.
* The maintainer burden is reduced until an extension has demonstrated that it fills an important gap in the primary project.
* The core project's common code (e.g. base classes and utility functions) can be a starting point for new development that extends project's domain. This avoids the need to port innovative work after-the-fact, thus reducing the overall burden of developing novel features for the project.
* Developers are more likely to contribute and stay involved in maintenance and building communities for their codebase, which is also good for the health of the overall project ecosystem.
### Resulting Context
* The project is able to scale with the addition of new features, without adding maintenance overhead on the primary project repository.
* Faster release of new features for the community to explore, encouraging innovation and experimentation.
* Reduced the costly code review and feature hardening process until the feature is able to prove its utility. This has cost savings benefits for the organization.
* A post problem that can be introduced - what happens if an extension can not complete the full lifecycle?
* If an extension is not adopted over a period of time and could not build a community around it to support maintenance, it would be up to the extension owner to continue maintaining it for however long they want to. If an extension is left unmaintained, it would be unpublished.
* If an extension developer is unable to further maintain their project, and other developers in the community want to continue supporting it, they may maintain the extension going forward.
### Known Instances
* **IBM Corporation** has adopted this solution to scale [InnerSource AI libraries](https://youtu.be/Lz-tIc2cyRM). Using extensions, developers are able to extend AI libraries with more algorithms and share their innovations with the company-internal community. The core libraries only contain strategic algorithms that have been adopted and validated, keeping them easier to maintain as we scale contributions.
### Alias
Extensions to Manage Contributions at Scale
### Status
Structured
### Author(s)
* Sukriti Sharma, IBM
* Alexander Brooks, IBM
* Gabe Goodhart, IBM
# Gig Marketplace
### Title
Gig Marketplace
### Patlet
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.
### Problem
Neither managers nor employees understand how they might benefit from getting involved in an InnerSource project.
It is difficult for employees to communicate to their management what commitment of time they will need to make to an InnerSource project.
Managers have no uniform way of keeping track of or rewarding their employee’s involvement in InnerSource projects.
### Story
You’ve successfully created an InnerSource program at your company and have buy-in from senior management, middle-management and developers. However, after nearly a year there have been few actual contributions made to any InnerSource projects outside of the teams that originally created them. After interviewing all the parties involved the main sticking point seems to be that it is difficult to know the time commitment developers will be asked to make if they choose to get involved in an InnerSource project and how they will personally benefit. There is also no uniform way of advertising what opportunities for contributors exist, what they’ll be asked to do and approximately how long it might take. Managers are supportive and want their employees to participate but so far have lacked a way of accounting for or rewarding their employees’ activities within InnerSource projects. What can be done to improve this situation for all the parties involved (InnerSource project owners, potential contributors and development managers)?
### Context
Employees wish they could gain exposure to activities going on within other areas of the company without having to leave their current positions. InnerSource projects exist and could provide these experiences but there are two main factors preventing employees from participating. First, is the inability to easily discover what opportunities for contribution exist within ongoing InnerSource projects and to communicate these to their managers. Second, is the inability of managers to plan and account for their employees' time commitments to these InnerSource project tasks. As a result InnerSource project owners are finding it difficult to build communities of sufficient size to fulfill their stated goals.
### Forces
* Employees have no easy way to discover what InnerSource opportunities exist
* Employees don't understand how contributing might benefit them professionally
* Managers don't understand the time/effort requirements associated with InnerSource project related tasks
#### Prerequisites
* Employees have been provided time by their managers to involve themselves in InnerSource projects
* Managers require a way for InnerSource contributions to be quantified, tracked and recorded so they can be accounted for and rewarded
### Solutions
Create a “Gig” based intranet site where individuals can advertise their skills and areas of interest and InnerSource project owners can advertise opportunities for collaboration.
Employees should be able to create a profile within the application in which they can list their skills and areas of interest. The system should leverage this information by proactively informing individuals (via email or some other means) when a Gig is posted that matches one or more of those criteria.
Each Gig posted by an InnerSource project owner should include the estimated skill and time requirements so those can be easily matched to an available employee and clearly communicated to their direct management. The description should also include a rationale as to how it will benefit the person taking on the task in order to make it as attractive as possible.
A points based system could be created to reward and track an employee’s involvement in a Gig. For instance, 10 points awarded to the Gig owner for posting a Gig once it is completed and 100 points for a developer who completes a Gig. Points accrued by completing Gigs could then be used as a gamification mechanism and as performance management criteria to garner insight in to the areas of expertise that exist within an organization.
Those wishing to accept a Gig should first be vetted by the Gig owner to determine that the employee has the prerequisite skills and allotted time from their manager to complete the Gig.
The transparency of contributions made via Gigs can help a contributor build (or detract from) her reputation thereby creating a greater likelihood that the quality of the contribution will be high. Completion of Gigs can also act as proof of expertise in a particular area.
The nature of Gigs posted to the marketplace can include both hard and soft skills such as organizing a group event, writing a report or requests for mentorship etc.
The creation of the Gig Marketplace should ideally be taken on by a team within an organization with the responsibilities to provide company-wide infrastructure and capabilities.
### Resulting Context
The InnerSource Gig Marketplace has vastly increased the number of InnerSource projects as well as the number of employees involved in them. The self-directed nature of the Gig Marketplace has enhanced job satisfaction amongst employees by allowing them a level of choice in the work they perform and with whom they can partner across the company. Employees understand exactly what they are signing up for and what they can expect from the experience. Managers are better able to estimate and track their employee’s time commitments with respect to InnerSource projects, recognize their individual efforts and use the completion of Gigs as a way of validating their specific skillsets. Managers are also able to leverage any existing downtime their employees may be experiencing by allowing them to pivot to work available in the Gig Marketplace. The data generated by the interactions within the Gig Marketplace is also helping to drive hiring and training decisions across all departments.
When used in combination with the InnerSource Portal pattern, the Gig Marketplace provides a finer level of context and detail in addition to the links to the code repositories and documentation for the project to which the Gig relates.
### Known Instances
* A large financial services organization has used the creation of an InnerSource Gig Marketplace website to foster their InnerSource program.
* **SAP** implemented the Gig Marketplace pattern - a new InnerSource program was added to the internal job platform where positions and similar offerings can be posted.
* The Gig Marketplace pattern has been proven to work extremely well with the associated [InnerSource Portal](/p/innersource-portal) pattern in this context. The InnerSource Portal increases awareness of specific projects currently underway while the Gig Marketplace advertises tasks of a certain type available to be worked on within those projects.
### Status
* Structured
### Author(s)
* Stephen McCall
* Shreyans Dugar
# Group Support
### Title
Group Support
### Patlet
What happens if a team or individual no longer supports an InnerSource project? Keep the project alive by forming a group of interested individuals.
### Problem
* A popular InnerSource project is orphaned.
* There isn't an obvious home for it to land.
### Story
A library of UI widgets is used by over 50 projects throughout the company. The funding for the team that owns the library runs out and the team disbands. At first, no one notices, but after a while whenever someone asks "who owns it" there isn't an answer. What will happen next? Will new teams shy away from using it? Will the project stagnate and linger until its users eventually are forced to move on to something else? What a shame if that were to happen to a perfectly good and useful project!
### Context
* Popular InnerSource project.
* Consumed as a build-time dependency (e.g. code module).
* No one is actively supporting it.
* The company cannot assign a team to support.
### Forces
* No one is assigned by their day job to work on it.
* Everyone is busy.
* High cost to migrate off the project.
### Solutions
Call for interested volunteers from anywhere in the company to form a group of [Trusted Committer](/p/trusted-committer)s to support the project. You may need to reach out to specific individuals based on commit or usage history. It is important that there are enough so that the burden on each can be reasonably small.
When forming, this group should identify or create [Standard Base Documentation](/p/base-documentation) and [Communication Tooling](/p/communication-tooling).
The group should do its best to manage these aspects of the project:
* **Maintenance**. If the project is flat-out broken for the standard use case, then fix it. Keep the project up-to-date as the dependencies and frameworks it uses continue to evolve.
* **Onboarding**. If someone has a question about how to use the project, make sure they get a reasonable answer.
* **Updates**. If someone wants to add new feature to the project, give them the design and technical support necessary for them to build it so that it both works for them and is a good addition to the project. Review incoming pull requests in a timely manner.
Since this group is comprised of volunteers, it is important to communicate that support is "best effort" only. Accordingly, this model of support is not well-suited for run-time critical, production projects like live APIs. It is better suited for projects that are consumed at build-time like libraries/packages/modules. The group is not expected to implement any new functionality for others.
### Resulting Context
* There is some fragile support for the InnerSource project.
* In the long-term the group support is likely to dissolve again at some point. If the project continues in the long run, then use this period of stable group support to find a long-lived way to support it (e.g. [Core Team](/p/core-team)).
### Rationale
People generally want to help. If there is personal outreach for someone to join as a [Trusted Committer](/p/trusted-committer), there are generally a number of people that will say "yes". Feeling part of a group and being given some structure and responsibility generally motivates people to try their best, which many times ends up being enough.
### Known Instances
* **WellSky**
### Status
Structured
### Author
[Russell R. Rutledge](https://github.com/rrrutledge)
# InnerSource Hackathon
### Title
InnerSource Hackathon
### Patlet
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.
### Problem
The company wants to adopt InnerSource as a software development methodology but only those familiar with open source principles or those who understand the benefits of InnerSource adopt it. It results in just a handful of InnerSource projects and is difficult to scale beyond that.
### Context
The senior leadership believes in InnerSource and wants to drive it throughout the company. The engineers who are familiar with open source principles and/or understand the benefits of InnerSource are the early adopters. There is success with these initial pilot projects and teams.
Now the next step is to drive it across the company. There might be reluctance from engineering teams due to various factors like:
* not familiar with InnerSource or open source practices
* not enough time to prioritize InnerSource, given the regular work deliverables
* reluctance to changing ways of working when everything works well already
* unclear return on investment for the upfront setup costs that an InnerSource project takes
Even when teams slowly start adopting InnerSource and open up their repositories, there are not many contributors. It is challenging to build a community around those projects, in spite of publishing the projects in an [InnerSource Portal](/p/innersource-portal). This could be due to various reasons like:
* engineers do not have time to explore new InnerSource projects and contribute, outside regular work deliverables
* no additional incentive to this effort apart from being acknowledged
* lack of motivation by middle management
In organizations where developers charge time to specific contracts or projects (e.g. consulting firms, government contractors, nonprofits), the barrier is even higher: if InnerSource is not part of the funded tasking, it simply does not happen.
### Forces
Apart from the reasons listed in the Context section, there are other factors from different entities that prevent teams from adopting InnerSource like:
* From middle management: perception of no direct benefit to the team apart from team skill development and individual growth; eventually resulting in no motivation by the middle management to the engineers in trying out InnerSource ways of working.
* From engineers: investing time to try new ways of working when there is already time and resource constraint for regular work deliverables; it is also challenging to balance both and show outcomes in both; this curbs motivation from the engineers as there is little safe space to experiment.
* From senior leadership: not prioritizing investment in InnerSource ways of working such as it being part of long term goals or objectives.
For those new to InnerSource or any technology/methodology, there is a need for safe space to try and experiment without definite outcomes in the initial stages. These factors and forces hinder such an experiment ground.
### Solution
Organize a company-wide hackathon focused on InnerSource. An InnerSource hackathon provides a safe space for engineers to try and contribute to InnerSource projects without any presumption and prejudice. It could be a 1 or 2 day event.
It can preferably be organized by an InnerSource Program Office (ISPO), if it exists in the organization, or by the Open Source Program Office (OSPO), if OSPO also drives InnerSource within the company. It can also be organized by a software best practices team, a developer experience team, or any central team or group of individuals who believe in InnerSource.
#### Preparation
A successful hackathon requires preparation in several areas:
* **Funding**: Secure a charge code or budget that participants can bill their time against, removing the barrier of contract-based time allocation. Even funding for 20-30 attendees for a single day is sufficient to start.
* **Awareness**: Send out emails, post in messaging channels, and leverage existing developer community channels. Consider sending an opening survey to gauge existing knowledge of InnerSource and understand what languages and skills participants bring.
* **Task preparation**: Reach out to maintainers of existing InnerSource projects and ask them to identify features that need to be implemented or issues that contributors could work on. Document each task with the languages involved, skills required, background context, clear definition of done, and the impact the contribution will have. Making the impact visible helps participants feel good about their contributions.
* **Task boards**: Organize all tasks in a central location (e.g. a task board) where participants can browse and select tasks. Include a task flowchart with links to all relevant repositories and resources.
* **Access**: Ensure participants have the necessary permissions to repositories and resources before the event to avoid bottlenecks on the day.
#### Participation
All engineers in the organization can participate in the hackathon. The participants can be new to InnerSource or InnerSource practitioners already. They can participate individually or as a team. Participating as a team also provides a safe environment; for example, those who are new to InnerSource can team up with InnerSource practitioners.
There could be one or more categories to participate as follows:
* **Contribute to an existing InnerSource project**: InnerSource project owners list features in issues as a prerequisite before the hackathon and participants can contribute during the event.
* **Start a new InnerSource project**: Either start a new project from scratch as InnerSource or make an existing project InnerSource ready.
* **Participate as a mentor**: Participants can also mentor new InnerSource practitioners, providing knowledge transfer or coaching during the event. Having at least one maintainer from every participating project available for Q\&A is highly valuable.
#### Event Format
The event could be held virtually, in person, or as a hybrid event. A hybrid format allows broader participation but requires extra effort to ensure collaboration across geographically dispersed sites.
A typical event day includes:
1. **Introduction**: Provide an overview of InnerSource for newcomers, introduce the available projects and tasks, and show participants where to find the task boards and resources.
2. **Work session**: Have an open communication channel (e.g. a video call or chat room) where participants can ask questions and get help. Maintainers and organizers should be available throughout.
3. **Closing**: Thank participants, share early results, and distribute a closing survey to capture feedback and metrics.
4. **Follow-up**: Work with participants who did not finish their tasks to close out remaining work. Coordinate with project maintainers to review and merge outstanding pull requests.
The winners and participants should be recognized and acknowledged in a company-wide forum at the end of the hackathon (see [Praise Participants](/p/praise-participants)). This is important as it keeps motivating them and more engineers to adopt and practice InnerSource going forward.
Such an event provides a safe space for engineers who want to adopt or contribute to InnerSource but did not have the time and motivation to do it, or for those who kept putting it off due to higher priority work deliverables. From a middle management point of view, 1 or 2 days for such an event is not much of an ask and hence they are more likely to accept.
### Resulting Context
* There is increased adoption of InnerSource by providing such a safe platform to try and experiment combined with recognition and support by the senior leadership and middle management.
* More InnerSource projects are published within the company.
* The InnerSource projects receive more contributions.
* Communities start to form around these InnerSource projects.
* This happens not only during the event but continues after the event too, with the hackathon participants acting as InnerSource ambassadors in their teams.
* It also helps ISPO and OSPO spread awareness about InnerSource best practices quickly, across the whole engineering community in the organization.
* Such an event also gives more exposure to projects that were developed to solve the needs of a specific team but turns out that many teams have similar requirements.
All these help scale InnerSource in the organization.
### Related Patterns
* [Start as an Experiment](/p/start-as-experiment) - a hackathon can serve as a low-risk experiment to demonstrate the value of InnerSource to management.
* [Praise Participants](/p/praise-participants) - recognizing contributors during and after the hackathon helps sustain momentum.
* [InnerSource Portal](/p/innersource-portal) - a portal helps participants discover projects to contribute to during the hackathon, and helps them stay engaged afterward.
* [Dedicated Community Leader](/p/dedicated-community-leader) - the hackathon organizers often serve as community leaders who sustain InnerSource adoption after the event.
* [Gig Marketplace](/p/gig-marketplace) - a gig marketplace can help match participants with tasks during the hackathon based on their skills and interests.
### Known Instances
* **IKEA** (Ingka Group)
* **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
* Structured
### Author
* Shanmugapriya Manoharan
### 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.
# InnerSource License
### Title
InnerSource License
### Patlet
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.
### Problem
When two or more legal entities within an organization want to share code with each other, they need an agreement about the terms and often a legal contract. Creating such agreements on a per project basis takes effort and creates a barrier for sharing. i.e. a team within a legal entity might decide not to share their source code with another legal entity in the organization because it seems complicated.
Barriers for sharing can lead to silos and duplication of effort in rebuilding similar solutions in multiple parts of the organization.
At the time of sharing the source code, it can not be reliably predicted what the value of sharing will be. If the activity of sharing requires significant effort (i.e. negotiating terms for the usage), the legal entities are less likely to do it, as they are concerned about the return on investment.
### Context
* A large organization with many legal entities (subsidiaries) that want to share code. When the organization gets larger, the value of this pattern increases.
* As per definition, the legal entities have their own legal rights and obligations.
* Multiple of these legal entities are developing software, and are using services of the other legal entities. They have a motivation to contribute to each other’s source code.
* A sufficient complexity of the organization and its organizational structure
### Forces
* **Level of effort** required to write formal agreements, especially if they need to take into account technical, legal, and business perspectives.
* A large organization (consisting of many legal entities) has many **internal regulations**. Any new agreements that are made have to comply with these regulations, e.g. security, privacy, procurement processes, etc. The volume of regulations can make it difficult to assess whether sharing software between two legal entities is compliant with these regulations, especially when there is no standard procedure.
* If any of the legal entities in the organization has a **business model** that depends on proprietary code and accounting of licensing fees within the organization
* **Company culture** that isn’t used to InnerSource collaboration and sharing code. This results in uncertainty about the rights and obligations when using shared code.
* Freedom over using the software leads to competition, and spread of ownership
* There are legal contracts in place which cover the sharing of source code. These contracts are not standardized, so they create additional effort in negotiating and understanding for every project. The existing contracts may also not allow sharing source code in an open enough sense to support a true InnerSource approach.
* Alternatively, there are no legal contracts in place but source code is shared informally. That might create uncertainty in cases where clarity about ownership and rights and obligations is needed.
* Choosing a restrictive and/or copyleft license can constitute a barrier for InnerSource adoption. Specifically, limiting publication to the organization might require a costly relicensing procedure prior to transitioning to Open Source.
### Solutions
Creating an **InnerSource License** customized to the needs of the organization in question (and their legal entities). This license needs to be generic enough to be applied to the most important inter-company relationships.
It is important to write the InnerSource License such that it truly allows for open source style collaboration across the boundaries of the involved legal entities. Therefore the 4 freedoms of free software should be integrated into the license.
The License is written as a formal legal document, and can be used as part of contracts between the legal entities to govern the code sharing agreements.
### Resulting Context
With the InnerSource License, we have a tool to share code between legal entities within our organization.
The license simplifies the conversations within our organization about sharing source code, and is motivating the first legal entities to do so.
**Note:** The experiment described in **Known Instances** is in an early phase. Therefore a firm **Resulting Context** has not formed yet. In a couple of months the effects of the InnerSource License on this problem space will be more clear, and this section can be updated.
### Known Instances
* **DB Systel**
* **Robert Bosch GmbH**
* **Airbus**
* **GovTech (Singapore Government)**
* **Siemens** has developed their own InnerSource license alongside other necessary legal agreements between subsidiaries.
* **Mercedes-Benz**
* **Thales Group**
#### DB Systel
DB Systel created their own InnerSource License, see [DB Inner Source License](https://github.com/dbsystel/open-source-policies/tree/master/inner-source-license). They used the [EUPL](https://interoperable-europe.ec.europa.eu/collection/eupl/eupl-text-eupl-12), as that offered an open source like starting point, and then worked out the constraints and additional rules required in their specific organizational context.
The first legal entities (companies) within the DB AG are using their InnerSource License.
One positive effect that is already showing is that it simplifies the conversation, especially if some of the involved parties don’t know the InnerSource concept that well yet. Licenses are a well-known concept, therefore having an InnerSource License is a great discussion starter.
The experiments are also uncovering that there are further collaboration challenges that need to be solved in order to lead to a true InnerSource contribution and collaboration model.
The mentioned collaboration challenges include:
* making InnerSource licensed projects discoverable
* building communities for collaboration on projects, just like in Open Source
It is worth mentioning that so far the software shared under this InnerSource license is mostly tooling, infrastructure, and tools lower in the stack.
#### Airbus
Airbus created ad hoc InnerSource licenses to enable InnerSource way of working within a large part of the group.
#### GovTech (Singapore Government)
GovTech is responsible for the delivery of the Singapore government's digital services to the public. They created the GovTech Public Sector License (GPSL) as a permissive license to ensure that code can be shared between legal entities across government. The GPSL covers both usage of code by licensees (agencies and their vendors) as well as contributions back to GovTech. Following open source practices, the GPSL `LICENSE` file is included in each repository that is made available as InnerSource.
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
* The experiment listed under **Known Instances** is running since 02/2020. The initial experience shows first positive effects but more experience is needed to fully evaluate the pattern.
### Author(s)
* Cornelius Schumacher (DB Systel GmbH)
* Schlomo Schapiro (DB Systel GmbH)
* Sebastian Spier
### References
* FOSSBack 2020 Presentation: [Cornelius Schumacher - Blending Open Source and Corporate Values](https://youtu.be/hikC6U8X_Ec) - watch 27:30 and onwards for details about the InnerSource License
* [DB Inner Source License](https://github.com/dbsystel/open-source-policies/tree/master/inner-source-license)
### Glossary
* **organization** - An umbrella for multiple legal entities. (synonyms: group, enterprise) (e.g. Lufthansa)
* **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, ...)
# InnerSource Portal
### Title
InnerSource Portal
### Patlet
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.
### Problem
InnerSource project teams are finding it difficult to attract outside contributions.
InnerSource projects at your organization are increasing but potential contributors have no easy way of discovering them.
### Story
You are attempting to establish an InnerSource practice within your organization. You are aware of some projects being run using an InnerSource model but their existence is only being communicated via word of mouth, email or sidebar conversations with other employees. As a result InnerSource project owners are finding it difficult to attract contributors.
There is no single, shared resource for employees across the organization to access which will allow them to easily discover all ongoing InnerSource projects. This is severely limiting the growth potential of every InnerSource project.
What can be done to help all InnerSource projects raise their visibility to as large an audience as possible and attract contributors organization-wide?
### Context
* Your organization is interested in adopting an InnerSource work style.
* InnerSource project owners are seeking a way to attract audiences to their projects. However, they are limited by the communication channels available to them through which they could advertise to potential contributors.
* InnerSource projects at your organization are increasing.
* Compounding this problem is the fact that the shared source control management application in use has such limited search capabilities that even developers in search of InnerSource projects find it frustrating to locate them.
#### Prerequisites
* Managers have given tacit acceptance that their employees should take part in InnerSource projects
* A shared source control management system is in use which provides programmatic access to the contents of the repositories it hosts
* There is a department within your organization with the responsibility of promoting InnerSource collaboration
### Forces
* The full potential for separate engineering teams to partner on shared challenges is not being realized
* It is difficult for individuals to discover what InnerSource projects exist
* It is difficult for InnerSource project owners to attract an audience of external contributors
### Solutions
Create an InnerSource Portal intranet website where InnerSource project owners can easily advertise the availability of their projects.
Key properties of the portal are:
* Visitors to the InnerSource Portal should be able to see all available projects as well as search for specific projects based on various criteria such as project name, technologies in use, contributor names, sponsoring business unit etc.
* The information displayed via the InnerSource Portal should be under the full control of the InnerSource project owners at all times. Preferably, by sourcing this information directly from a specific data file or meta-data stored in the project repository itself.
* Project owners should include all relevant information concerning their projects within those data files including the project name, trusted contributors' names, a brief description and links to the code repository or any supporting documentation.
* (optional) While most organizations will choose to make their portal only available on their intranet, some organizations have opted to make their portal available on the public internet. The latter can be interesting for organizations that want to show additional information about their InnerSource approach in their portal e.g. for branding and recruitment purposes.
When launching the portal, a communications campaign promoting the addition of InnerSource data files or meta-data to code repositories should be considered, to bolster the number of projects displayed within the portal.
#### Implementations
**SAP Project Portal**
A [reference implementation](https://github.com/SAP/project-portal-for-innersource) of an InnerSource portal is available on GitHub and open for contributions. It lists all InnerSource projects of an organization in an interactive and easy to use way. Projects can self-register using a dedicated GitHub topic and provide additional metadata.
**Wiki**
As a simple way to start, you can set aside a page on an internal wiki for listing out available projects. An easy way to display this information is in a table with columns giving just a little bit of extra information about the projects. Try to have just enough columns so that viewers can determine if they want to learn more about the project, but no more. Too much information will make the page overwhelming and difficult to use. Individuals and teams can self-add their projects to the page.
Here is a sample set of columns:
* **Name**. Name of the project (optionally linked to its homepage).
* **Brief Description**. Explaining the purpose of the project (which problem does it solve?)
* **Technology Pre-requisites**. You must use these technologies in order to on-board to the project.
* **Getting Started**. Link to instructions on how to start using the project.
* **Chat**. Link to a chat channel to ask questions about the project.
* **Host Team**. Seeing if a team is behind the project can help others to have the confidence to use it.
* **Production Since**. How long as the project been used in a production environment? Seeing this information is a rough proxy for its maturity.
* **Contribution**. Link to instructions on how to contribute to the project.
This solution doesn't allow for a fancy display - it is just a wiki table. If it's important for you to have a snazzy-looking UI, then this idea won't work for you. Additionally, if you end up with a lot of projects (e.g. nearing 100), this solution won't scale to allow the search and filtering or auto-updating of project entries that you'll probably need. It is a good solution for a portal with a few dozen projects, though.
### Resulting Context
* The InnerSource Portal has enabled InnerSource project owners to advertise their projects to an organization-wide audience. Due to this increased visibility they are attracting much larger communities of contributors than ever before.
* For those looking to get involved in InnerSource projects, the InnerSource Portal has allowed them to discover exactly the kind of opportunities they are interested in by searching across all available InnerSource projects simultaneously based on their specific criteria.
* Satisfying the needs of both of these audiences has helped establish InnerSource as a viable and attractive option for all areas of the organization to leverage to accomplish things together they could not have separately.
### Known Instances
* **A large financial services organization** has used the creation of an InnerSource Portal to provide a mechanism of advertising and discovering InnerSource projects in existence across different business units
* **SAP** promotes InnerSource projects in the InnerSource Portal - projects can self-register using GitHub topics. The [Repository Activity Score](/p/repository-activity-score) defines the default order of the InnerSource projects in the portal. Also see [Michael Graf & Harish B (SAP) at ISC.S11 - The Unexpected Path of Applying InnerSource Patterns](https://www.youtube.com/watch?v=6r9QOw9dcQo\&list=PLCH-i0B0otNQZQt_QzGR9Il_kE4C6cQRy\&index=6). Its codebase is published as a [reference implementation](https://github.com/SAP/project-portal-for-innersource) and open for contributions.
* **Elbit Systems** has used this pattern and added gamification on top.
* [Gamification As Means of Cultural Change and InnerSource Engagement Booster](https://www.oreilly.com/library/view/oscon-2018-/9781492026075/video321579.html) | Shelly Nizri | OSCON 2018 - Portland, Oregon
* Of Islands, Monsters & InnerSource [(slides)](https://docs.google.com/presentation/d/1P1OCEK9B6eSrVRUclVWY6meSI-qHOBjM_UAPNvCZamU/edit#slide=id.p15), [(video)](https://drive.google.com/file/d/1pM89uHMn0vhE3ayFJDGYcCO8R0tAXXZD/view?usp=drivesdk) | InnerSource Spring Summit 2019 (Galway, Ireland)
* The [code](https://gitlab.com/gilda2) realizing this platform has been open sourced.
* **American Airlines** promotes InnerSource projects via an [internal InnerSource Marketplace](https://web.archive.org/web/20240226230502/https://tech.aa.com/2020-10-30-innersource). Similarly to SAP, projects self-register by adding `innersource` as a GitHub topic. Projects are searchable and filterable by language, topics, number of open issues, etc.
* **Banco Santander** has created a public portal called "Santander ONE Europe InnerSource Community" to support and increase InnerSource adoption. In addition to the catalog of projects the portal includes relevant content such as documentation, way of working, news, and events.
* **Airbus** used the [SAP Portal](https://github.com/SAP/project-portal-for-innersource) as a Proof of Concept. It is now using the [Bazaar plugin](https://github.com/backstage/community-plugins/blob/main/workspaces/bazaar/plugins/bazaar/README.md) of [Backstage](https://backstage.io) as the latter became the official developer experience tool internally. It provides a convenient self-registering capability for all the divisions.
* **Mercado Libre** use an instance of the [SAP portal](https://github.com/SAP/project-portal-for-innersource) to discover existing InnerSource projects within the organization.
* **Mercedes-Benz** is [using](https://opensource.mercedes-benz.com/news/sponsor_innersource_commonsoss) the SAP reference implementation mentioned above for their InnerSource Portal.
* **WellSky** has a simple *Confluence Wiki* page were InnerSource and reusable projects are listed.
* **Siemens** has set up an internal portal that provides documentation for InnerSource maintainers, contributors, users and their managers. It also serves as an entry point to explore available projects and gives hints to improve project visibility.
### References
* The InnerSource Portal pattern has been proven to work extremely well with the associated InnerSource [Gig Marketplace](/p/gig-marketplace) pattern in this context
### Status
* Structured
### Author(s)
* Stephen McCall
### Acknowledgments
* Shelly Nizri
* Melinda Malmgren
* Michael Graf
* Jesús Alonso Gutierrez
# Issue Tracker Use Cases
### Title
Issue Tracker Use Cases
### Patlet
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.
### Problem
A team develops a component that many teams in the organization depend on. It uses a standard issue tracker for tracking open bugs and feature requests. However, the context in each entry is very limited. As a result potential contributors have no way of knowing what change exactly each issue is talking about.
### Context
The InnerSource project tooling is all setup. However, the project issue tracker is mainly used for sharing progress. In InnerSource projects there are many more use cases that an issue tracker can be used for that make remote, asynchronous communication easier.
### Forces
* Contributors would like to understand whether the feature that they are missing is already on the roadmap. With a lot of context missing in issues though it is impossible to decide whether existing issues match the contributing team's needs.
* As a result a lot of duplicate issues are being opened that the host team has to deal with.
* As context in open issues is so limited contributors are unable to help the host team by implementing some easier issues that are open already. As a result a lot of work remains in the hands of the host team.
* With a strong focus on verbal communication it is impossible to discern after a couple months or years why a certain feature was being chosen for implementation. As a result refactorings, in particular simplifying the component becomes an exercise in project archaeology and brain picking of people who remember what was discussed.
### Solution
Embrace the "written over verbal" philosophy not only for pure software development but also during the planning phase of new features:
* For bugs, planned features and feature ideas create separate issues. In each of those include as much information as possible so that potential external contributors are able to understand the context. Ideally, in particular for easier changes, include enough information for external contributors to support the host team by implementing the functionality in question.
* Potentially use the issue tracker as a channel to ask questions. This is in particular helpful if you are lacking other communication sources to tackle user questions.
* Make use of tags and categories in order to distinguish issues used for different purposes.
* For starting a brainstorming session asynchronously, open an issue for gathering ideas. When discussion is starting to calm down, summarize the points identified in this issue in a separate document. Post that for review as a pull request to drill deeper into individual points that still need clarification. The resulting document can be used to publish the results in other appropriate channels as well as for future reference.
* Most issue tracker implementations allow for issue templates. Make use of those not only to collect commonly needed information for bug reports but also include hints about what kind of information is needed for the other usage types.
### Resulting Context
* Making more use of the project's issue tracker for communication enables external contributors to follow along and make better decisions on what to contribute.
* A focus on structured written communication enables host team members to participate remotely.
* Consistently communicating in writing means that passive documentation on project decisions accumulates as a by-product instead of needing added attention.
* Consistently using public communication channels leads to more humans following a discussion. This means that there are more knowledgeable humans that can answer questions, chime in on open issues, or point out flaws in planned features that would otherwise be found only much later.
* Moving discussions to a public discussion medium creates an opportunity for potential future contributors to lurk, follow along, get comfortable and learn the ways of the project long before they have the first need to get involved.
### Known Instances
* **Europace AG** - See blog post [Issue Use Cases](https://tech.europace.de/post/using-issues-for-asking-questions-and-tracking-work/)
* **Siemens** manages work on their InnerSource Platform in a fully transparent way. Therefore the work on the InnerSource Platform itself is organized as an InnerSource project. This includes tracking enhancements and bugs, as well as marketing, communication activities and support requests from users.
### Authors
Isabel Drost-Fromm
### Status
Structured
# Maturity Model
### Title
Maturity Model
### Patlet
Teams have started adopting InnerSource. The practice is spreading to multiple departments. However, the understanding of what constitutes an InnerSource project varies. The solution is to provide a maturity model to allow for teams to go through a self check and discover patterns and practices that they are not yet aware of.
### Problem
When InnerSource adoption in an enterprise starts to increase, individual mentoring of each project through one evangelist becomes unfeasible. Also, more and more people are gaining at least a basic understanding of what it means to work in an InnerSource project. Looking at all InnerSource projects though, the depth of understanding for the concept will diverge. Teams may not be aware of proven patterns that would help them move to the next level and solve issues and pain points that they are dealing with.
### Context
Several teams have started adopting InnerSource practices. The exact level of understanding of the practice diverges between teams. The exact problems teams run into diverge depending on the context and working environment of each team. As a result the definition of what are important best practices in an InnerSource project differs depending on each team.
### Forces
Teams sharing InnerSource learnings run into misunderstandings as they are not aware of their respective level of InnerSource adoption.
Teams believe that "it's all about migrating to a shared software development [forge](https://en.wikipedia.org/wiki/Forge_%28software%29)" (GitLab, GitHub, or Bitbucket being well known examples of such forges).
Teams are not aware of best practices that would help them solve issues that they run into in their daily doing.
### Solution
Ask teams to self assess against the proposed maturity model.
#### Transparency
**Plans & Products**
InnerSource project benefit from planning being transparent across the organization by enabling stakeholders to better understand decisions and influence them in a way that can be followed by others.
* PP-0: Individuals and teams do not regularly disclose their plans or products to multiple stakeholders. No formal actions exists at the organization.
* PP-1: Individuals and teams give visibility to their plans or products to multiple stakeholders, before they are started. Shared roadmap.
* PP-2: There are already shared roadmaps with clear guidelines and contribution rules where stakeholders can provide feedback. However, this is not standardized across the organization and not all of the projects provide this info.
* PP-3: Roadmaps are shared by default and there is a standard process and homogeneous way to do this across the organization at the level of each InnerSource project. This contains clear rules to contribute and influence in the roadmap.
**Development Process & Tools**
InnerSource projects thrive when contributors become active and participate. As a result, making contribution easier should be balanced with pure technical goals.
* DP-0: Each team follows its own development process and tools. They are not defined to share knowledge and artifacts outside development team. Siloed development teams.
* DP-1: Development teams use shared code repositories, internally. Some teams develop their own CI process, using non corporate or standard CI tools. There is no code review process defined, although some projects teams do it internally.
* DP-2: The organization sponsors and promotes a shared repository for collective knowledge. Some teams develop their own CI process, using corporate CI tools. There are CI environments. Code review process defined, and used by some projects. Sometimes code review is done by outside team members.
* DP-3: Most teams develop their own CI process, using corporate CI tools. There are CI environments. Code review process defined, and used. Code review is done by both, internal and external team members.
**Decisions**
In order to motivate colleagues to contribute work outside of their core team they need visibility into the decision-making process of the host project - but also feel that their voices are being heard and valued.
* DC-0: Decision-makers often intentionally or accidentally withhold data and resources related to project decisions.
* DC-1: Materials that are part of decision-making practices become available for review after decisions are finalized.
* DC-2: People feel like they know about—and are helping to shape—most (but not all) important decisions as those decisions are unfolding. Materials that are part of decision-making practices are available at defined project milestones.
* DC-3: People feel like they are a part of a shared, standard process for collective decision-making that the organization endorses. Materials that are part of decision-making practices are continuously accessible during work processes.
**Helpful Resources**
In order to attract contributors helpful supporting material needs to be easily accessible.
* RS-0: Individuals and teams neither contribute to nor draw upon a shared repository of knowledge.
* RS-1: Individuals and teams release project materials for review internally, after they've finished their work. Individuals and teams share resources, but in disconnected, fragmented, or individualized/siloed systems or repositories. Individuals and teams share resources, but there is no commonly expressed or shared understanding of the criteria used to determine whether information is sensitive or not. Do not "share thinking on others".
* RS-2: Individuals and teams make project-related materials accessible to some members of project teams according to clearly defined and shared formats and/or protocols. Individuals and teams withhold sensitive data and resources, provide limited details, context, and scope.
* RS-3: Individuals and teams make project-related materials broadly accessible to the organization—and possibly outside the organization as well—according to clearly defined and shared formats and/or protocols. Individuals and teams who must withhold sensitive data and resources are clear about what they're not sharing, and others understand why those materials are not available to them.
**Stories**
When working in host teams mistakes will automatically be widely visible. In order keep contribution levels up, corporate culture needs to celebrate failure as an opportunity for growth and learning.
* ST-0: Individuals and teams do not share successes or failures for others to learn.
* ST-1: Individuals and teams are comfortable sharing stories about successes, but not about failures.
* ST-2: Individuals and teams are comfortable sharing stories of successes and failures during retrospectives and reviews.
* ST-3: Individuals and teams are comfortable sharing stories of successes and failures, and learn from failures according to formal protocols.
#### Collaboration
**Channels for Providing Feedback**
For silos to be reduced colleagues need to be comfortable sharing feedback openly. One easy way to support that is to use the same communication principles across hierarchies.
Ideally you will end up with proper communication channels that are known by anyone in the organization - with channels focused on different goals (announcements, user support, development channels, infra discussions, etc.). Some of the best practices you will establish as your InnerSource projects mature: Adoption of netiquette guidelines, opening a proven set of standard channels (which are being archived, publicly accessible, searchable) for each new InnerSource project.
* CF-0: There are no processes nor established channels. Some members of the organization share materials via private channels or discussions.
* CF-1: The organization is in the process of establishing internal guidelines and channels for encouraging diverse points of view about company/departmental decisions, so that anyone belonging to the organization can use them. Some members of the organization share decision-making materials informally using unofficial platforms. Leaders maintain at least one clear and direct channel for organization members to share opinions constructively on some matters relevant to their work.
* CF-2: The organization has established internal guidelines and channels, and provides specific resources (training programs, access to content, etc.), for encouraging and soliciting diverse points of view on team or decisions.
* CF-3: Members of the organization share decision-making materials on officially sanctioned platforms Members of the organization share materials openly via multiple channels and methods for feedback. Leaders use those channels themselves, openly encourage others to use them, and maintain team-facing or public-facing records of the feedback they've received and/or the actions they've taken to address this feedback.
**Leadership**
InnerSource projects encourage employees to contribute to projects outside of the direct influence of their direct line manager. This needs a culture of trust.
* LS-0: Command & control culture, within a highly hierarchical organization.
* LS-1: Some leaders are open to receiving feedback and creating an environment where people feel safe providing it.
* LS-2: Most leaders in the organization are open to receiving feedback and creating an environment where people feel safe providing it. Leaders show passivity about understanding whether all members feel empowered and enabled to share. Organization encourages leaders to actively seek voices not present in dialog out for inclusion.
* LS-3: Members feel empowered and enabled to share opinions constructively on any matter relevant to their work or about which they feel passionate.
**Organizational and Functional Structure**
When InnerSource leaves the pure coding level and enters the community and working group level, there is potential for reducing silos even where direct code collaboration is not possible.
* OF-0: Working groups tend to be static in terms of membership and skill sets.
* OF-1: Cross-functional teams exist, but team roles are often unclear and governance structures are vague.
* OF-2: Cross-functional teams are common, and teams post their roles and goals publicly.
* OF-3: Cross-functional teams are common and make their activities known broadly to the organization; in turn, the organization promotes best practices for working together.
**Contribution**
The goal with designing contributions patterns needs to keep collaboration in mind if it's to reduce silos.
* CB-0: Completely siloed, no collaboration outside the teams. Just some collaborations due to cross-functional teams.
* CB-1: Members of the organization and teams collaborate but frequently say it's "too difficult". Teams infrequently revisit the outcomes of their collaborations.
* CB-2: Members of the organization and teams actively seek opportunities to collaborate. Teams routinely discuss, revisit and debate the outcomes of their collaborative efforts, and make these outcomes available by default.
* CB-3: Members of the organization collaborate both internally and externally in ways that benefit all involved. Teams routinely discuss, revisit and debate the outcomes of their collaborative efforts, and share their learnings outside the organization, and make these outcomes externally available by default.
#### Community
**Sharing Policies**
Having a baseline of shared values makes it easier to work across team boundaries. Crossing boundaries becomes easier if a limited set of baseline rules and guidelines apply everywhere and can easily be referenced.
* SP-0: No sharing culture nor written policies.
* SP-1: Some members of the organization unite to define values and principles, but are not clearly supported when they do.
* SP-2: Members of the organization collectively document shared visions and agreements like mission statements and codes of conduct, make them easily accessible, and reference them often. On-boarding materials and orientation rituals provide adequate context for helping new members understand how the organization will benefit from their contributions.
* SP-3: Shared values and principles inform decision-making, conflict resolution, and assessment processes among members of the organization, who reference these values and principles consistently in both verbal and written formats.
**Feel part of the Organization**
One of the possible reasons for introducing InnerSource into organizations can be increased engagement. This point tracks how engagement is changing while adopting InnerSource.
* PA-0: Low engagement, no collaboration and people do not feel comfortable sharing with others.
* PA-1: Members of the organization feel comfortable sharing their thoughts and opinions without fear of retribution, but only in familiar domains. People understand that the best ideas win, and leadership responsibilities accrue to people with histories of contribution and commitment.
* PA-2: Members of the organization feel comfortable sharing their thoughts and opinions without fear of retribution. Leaders demonstrate dedication to the organization's shared values.
* PA-3: The organization is proactive in telling members that it benefits from their contributions; as such, members demonstrate shared consciousness and empowered execution, and feel a sense of responsibility to the community. Leaders understand that they grow by helping others grow, and they mentor junior members of the organization.
#### Governance
**Rewards**
In order to drive adoption, extrinsic motivators can be used to increase cross team collaboration.
* RW-0: No rewards.
* RW-1: Leaders are encouraged to reward exceptional collaborations, but there are no policies or processes established.
* RW-2: Standard processes are established to reward collaborations outside the developers' teams. Team leaders or boards decide who has to be rewarded.
* RW-3: Rewards are not only proposed by the organization, but the communities are able to define their more valuable rewards. The community is responsible to decide who has to be rewarded.
**Monitoring Policies**
InnerSource projects need a means for self assessment. Metrics can be one aspect to facilitate this assessment. Also, in organizations with a mature InnerSource adoption level we expect adoption of the method to be tracked based on clear, agreed upon metrics.
* MP-0: No existing monitoring policies at any level in the organization.
* MP-1: Metrics are important for certain teams, and they start using them in an isolated way.
* MP-2: There is a strategy at the organizational level with respect to metrics that help to validate specific policies across the organization. This monitoring policy exists at the level of some InnerSource projects.
* MP-3: There are clear guidelines, recommendations, and trainings about the use of metrics with certain infrastructure provided by the organization. This works at both levels: InnerSource program to understand the general InnerSource adoption within the organization, and at the level of InnerSource projects.
**Support and Maintenance**
Not only should feature development be owned by InnerSource teams - support and maintenance is also part of the teams core tasks.
* SM-0: Support given by the core development 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](/p/30-day-warranty) or [Service vs. Library](/p/service-vs-library).
* SM-3: There are rules and regulations to formalize the support on the product, given by a mature community.
**Culture**
There are multiple levels moving towards a collaborative culture.
* CL-0: Silos - teams work independently but also in isolation.
* CL-1: Reactive - teams work independently, but know how to react to flaws in dependencies.
* CL-2: Contributive - teams actively help improve their dependencies by contributing.
* CL-3: Activist - teams actively seek help, mentor and recruit new contributors.
**InnerSource Roles**
InnerSource comes with explicit roles. While in early stages some patterns may be useable without adopting those roles, communicating within projects using explicit role titles becomes easier.
* RO-0: There are no specific roles helping InnerSource adoption. Only common development roles are present: developer, analyst, tester, etc.
* RO-1: Occasionally some individuals and teams contribute to other projects. These are technical contributions, where the user/contributor role is seen. For some teams, it can be identified at least one member being a technical reference, who explains the development process to other development team members. He/she could be a candidate for covering the trusted committer role.
* RO-2: An InnerSource Officer role is in charge of governance and support, including processes, etc. Identifies the education needs and ensures it is provided to the organization. Leads and mentors the organization in the engagement in IS projects. Is the first formal step in the way, defining the IS vision and roadmap. The organization has defined a trusted committer role, being a point of contact/reference not only for development team members but also for external contributors. There is a standard process describing how to contribute to the community, contributor role is present. Data Scientist role is in charge of managing the traces of activity left by the InnerSource initiative, needed to measure the IS evolution. Trusted committer role will evolve to a more technical profile, and a community manager will be in charge of "energizing" the community, being his main responsibility to attract and retain new developers/users (contributors/community members).
* RO-3: Evangelists are moving inside organization, to let others know about the current work, what InnerSource does and how to do it, and help others to understand and become part of the initiative. Non technical contributors appear.
### Resulting Context
All teams are aware of available best practices.
Teams understand their level of InnerSource adoption.
Prior to adopting InnerSource as a working model, teams are aware of the practices that are expected of them - both in the short term and in the long term.
### Known Instances
* **Entelgy**
* **Zylk**
* **Bitergia**
* **Airbus**
* **Adyen**
### Authors
* Daniel Izquierdo Cortazar
* Isabel Drost-Fromm
* Jorge
* Nerea
### Acknowledgments
* Alexander Andrade (special thanks for the spelling fixes)
### Alias
Maturity model: Learn about InnerSource best practices
### Status
* Structured
* Drafted in September 2019
# Praise Participants
### Title
Praise Participants
### Patlet
When you receive an InnerSource contribution, it's important to thank the contributor for their time and effort. Extending your gratiutude not only effectively acknowledges the contribution but also engenders further engagement from the contributor and others. Praising contributors' positive contributions to your InnerSource project motivates those contributors (and their managers) to continue investing in the effort.
### Problem
How can we properly express our gratitude to a contributor for their contribution to an InnerSource project? We may not know precisely which words or communication channels we should use to express ourselves sincerely. But recognizing and thanking contributors is critical for keeping those contributors (and their managers) engaged in the work. Luckily, effective praise for participants follows a pattern, and following this pattern helps ensure that our messages of thanks come across clearly and graciously. It also makes us less likely to forget to praise our contributors, which is unfortunately too easy to do.
### Context
* You are the [Trusted Committer](/p/trusted-committer) or maintainer on an InnerSource project.
* You value the community of contributors and want to maintain and grow it.
### Forces
* You are busy, which makes forgetting some soft touches (like praise and thanks) easier.
* You may not be someone that is comfortable in social situations or good with words.
* Peer recognition is very important to job satisfaction and career development.
### Solutions
Being recognized by others feels good. And in a professional setting, recognition from peers can also increase your organizational influence and career growth. Any time someone contributes to your InnerSource project, recognize them with an authentic, sincere "thank you." Be sure to highlight specific examples of ways these contributions have impacted the project positively.
For non-trivial contributions (all code contributions and significant time contributions), say "thank you" via the following mechanisms:
(1) Call out the person by name in any chat location (e.g. *Slack*) where you organize your project activity. Let everyone know what they did and thank them publicly.
Example:
> Everyone @here give a high-five to @andrew\.clegg for updating the *rcs-viewer* to the latest version of the *hebo-client* (). Thanks for helping keep this library up-to-date, Andy!
(2) Email them and their manager (cc'd) privately, thanking them for the contribution. For code contributions, consider forwarding the merge notification mail.
Example:
> Hi, Andy, I want to thank you again for making this update. It may have been a small amount of time, but it's attention like this from each person that make the RCS project work for all of us. Thanks for solving your own problem in a way that also makes the *rcs-viewer* better for everyone.
### Resulting Context
Feedback like this leaves the contributor with a fantastic feeling and ready to re-engage in the project. Combining **both** forms of thanks gives them recognition in front of their peers (breadth) and in front of their direct manager (depth). There's a subtle encouragement for those peers in chat to consider contributing themselves and for that manager to look for appropriate circumstances to encourage their other direct reports to do the same. Additionally, awareness of the InnerSource project spreads to the manager, who may have previously not known of the team's use and involvement with it.
One caveat: keep it real. Make sure that your words stem from the sincere thanks that you feel inside for what they've done. Keep the level and verbosity of praise appropriate to their level of involvement. Overdoing it may feel insincere and mechanical and defeat your purpose in reaching out.
### Related Patterns
* *Just Say Thanks* (from the book [*Fearless Change*](https://fearlesschangepatterns.com/))
### Known Instances
* **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
* Structured
### Author(s)
* Russ Rutledge
### Acknowledgments
* [Todd Lisonbee](https://github.com/tlisonbee) for encouraging to "keep it real."
* [Isabel Drost-Fromm](https://github.com/MaineC) for [this extra explanation](https://youtu.be/h3MPewsk5PU?t=357) of the importance of providing specific examples of how the contribution has positively impacted the project.
# Repository Activity Score
### Title
Repository Activity Score
### Patlet
Potential contributors want to find active InnerSource projects in need of their help. By calculating a repository activity score for each project, a ranked list of projects can be created (e.g. on the [InnerSource Portal](/p/innersource-portal)), so that potential contributors can more easily determine which project they want to contribute to.
### Problem
**In which order** shall InnerSource projects be presented? Typical ranking KPIs like *GitHub Stars*, *Number of Forks*, *Number of Commits*, *Lines of Code*, *Last Update* aren't sufficient to concisely indicate the activity of a project.
Active projects with a lot of traction, but also fairly new and enthusiastic projects that are in need of new contributors should be ranked higher than matured projects with little activity or in maintenance mode.
A new metric derived from several KPIs is needed to define a reliable and versatile score for a project's activity level. It can be used to sort projects according to their activity level.
### Story
When InnerSource is practiced for a long time or scales beyond a certain number of projects (let's say 50 to give a meaningful threshold) it is hard to find the currently most popular and active InnerSource projects. Projects that exist for a long time are well-known but may no longer be very active. Fairly new projects on the other hand don't have a reputation or an active community yet.
A list of InnerSource projects should not be considered a static resource, but an exciting place to discover and explore new and active projects, just like a news page listing the most interesting topics of the day first. Thus it is beneficial when the order of the projects is regularly updated and changes according to the project's popularity and activity.
These considerations led to a first prototype to calculate a repository activity score, which worked surprisingly well and determines an ever-changing order of projects according to their activity.
### Context
Discovering InnerSource projects can be facilitated with the [InnerSource Portal](/p/innersource-portal) and the [Gig Marketplace](/p/gig-marketplace) pattern, or by promoting projects on other communication channels and platforms. The activity score defines a default order in which projects are presented to the community.
### Forces
Automated KPIs that can be fetched by querying the GitHub API are only part of the truth. What about code quality, the availability of good documentation, or an active and helping community that makes the project a fun place to contribute?
Such "soft" KPIs would have to be manually or semi-automatically added to the calculation and the resulting score. If tools exist that provide more context for the repository, like a code coverage reporting, they can easily be worked in.
### Sketch
A centralized approach for calculating and applying the repository activity score. For more details, see [Resulting Context](#resulting-context)
### Solutions
The repository activity score is a numeric value that represents the (GitHub) activity of an InnerSource project. It is derived automatically from repository statistics like GitHub stars, watches, and forks and may be enriched with KPIs from other tools or manual evaluations.
In addition, it considers activity parameters like last update and creation date of the repo to give young projects with a lot of traction a boost. Projects with contributing guidelines, active participation stats, and issues (public backlog) receive a higher ranking as well.
All of this can be fetched and calculated automatically using the result set of the [GitHub search API](https://docs.github.com/en/rest/search#search-repositories) and [GitHub statistics API](https://docs.github.com/en/rest/metrics/statistics). Other code versioning systems like Bitbucket, GitLab, Gerrit can be integrated as well if a similar API is available.
The code below assumes the variable `repo` contains an entity fetched from the GitHub `search` API and the `participation` object contains an entity from the GitHub `stats/participation` API.
Manual adjustments according to soft KPIs (see [Forces](#forces)) can be made on top if needed.
```javascript
// calculate a virtual InnerSource score from stars, watches, commits, and issues
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;
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)
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(-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);
// gradually scale down boost according to repository creation date to mix with "real" engagement stats
let iDaysSinceCreation = (new Date().getTime() - new Date(repo.created_at).getTime()) / 1000 / 86400;
iBoost *= (365 - Math.min(iDaysSinceCreation, 365)) / 365;
// add boost to score
iScore += iBoost;
// give projects with a meaningful description a static boost of 50
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.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;
}
// final score is a rounded value starting from 0 (subtract the initial value)
iScore = Math.round(iScore - 50);
// add score to metadata on the fly
repo._InnerSourceMetadata.score = iScore;
return iScore;
}
```
### Resulting Context
Contributors are free to commit a part of their time to InnerSource project. They may choose to contribute to a project that they depend on for the work in their regular team anyways. However they may also choose to contribute to something completely different, based on their interests and personal development goals.
Projects can be sorted and presented by repository activity score to give a meaningful order in a portal presenting projects to potential new contributors. The score can be calculated on the fly or in a background job that evaluates all projects on a regular basis and stores a list of results.
A crawler that regularly searches all InnerSource repositories (e.g. tagged with a certain [topic](https://github.com/topics) in GitHub) can be a helpful addition as well. It provides a ranked list of projects that can be used as an input for tools like the [InnerSource Portal](/p/innersource-portal), a search engine, or an interactive chat bot.
### Rationale
The repository activity score is a simple calculation based on the GitHub API. It can be fully automated and easily adapted to new requirements.
### Known Instances
* **SAP** - Used in SAP's InnerSource project portal to define the default order of the InnerSource projects. It was first created in July 2020 and is fine-tuned and updated frequently ever since. When proposed to the InnerSource Commons in July 2020, this pattern emerged. Also see [Michael Graf & Harish B (SAP) at ISC.S11 - The Unexpected Path of Applying InnerSource Patterns](https://www.youtube.com/watch?v=6r9QOw9dcQo\&list=PLCH-i0B0otNQZQt_QzGR9Il_kE4C6cQRy\&index=6).
* **Airbus** took a lot of inspiration from this pattern to create an "InnerSource score" that combines the activity score together with checks from the [Standard Base Documentation](/p/base-documentation) and the [InnerSource License](/p/innersource-license).
* **Siemens** includes repository activity in their InnerSource project quality score. Maintainers can use the quality score to improve their project and communicate their score via badges.
### Status
* Structured
### Author(s)
[Michael Graf (SAP)](mailto:mi.graf@sap.com)
### Acknowledgments
Thank you to the InnerSource Commons Community for lightning-fast advice, and a lot of helpful input to feed this pattern! Especially:
* Johannes Tigges
* Sebastian Spier
* Maximilian Capraro
* Tim Yao
# Review Committee
### Title
Review Committee
### Patlet
The InnerSource working model is a radical departure from more traditional approaches, for developers and managers alike. By establishing a review committee as an interface between the InnerSource initiative and all senior managers of business units participating in it, the latter are more likely to familiarize themselves with the initiative and support it, as it affords them a certain level of oversight and control without fostering micromanagement.
### Problem
Managers will perceive the InnerSource working model as a radical departure from the working models they are accustomed to and have experience with. As a consequence, it is likely that they will either reject or micro manage the InnerSource initiative in order to try to minimize the perceived risk of this change. In both cases, the benefits of InnerSource can not be realized. As a result, InnerSource is subsequently discredited.
### Context
Company A wants to introduce its first InnerSource initiative. Most managers in company A are not familiar with the Open Source working model and are instead accustomed to hierarchical, top-down control style management.
### Forces
* The more perceived control a manager has over the work in the InnerSource initiative, the more likely it is that she or he will support the initiative without prior experience.
* The less experience a manager has with the open source working model the more likely it is that she or he will want to control the risk of the initiative.
* The more heavy handed and micro managerial InnerSource initiatives are managed, the less likely it is that the open source working model can be adopted to the required extent. As a result, the benefits of InnerSource will not be realized.
### Solution
* Establish a review committee comprised of senior managers of all business units which participate in the InnerSource initiative.
* The review committee members are given the authority to decide as a group which InnerSource projects will receive support in general and funding in particular.
* Applicants can be elected by review committee members before meetings to present their proposed InnerSource project during review committee meetings for consideration.
* Leaders of InnerSource projects currently funded by the review committee are obliged to report on the status of their project during every review committee meeting.
* Review committee members are obliged to provide constructive feedback to both new applicants and current project leaders during review committee meetings.
* Every InnerSource project is to be given the chance to react to feedback received on one session of the review committee until the next session in order to avoid shutting down the project prematurely.
* An InnerSource project leader can also present the motion to be shut down on its own initiative on a review committee. The review committee then has to decide whether or not the business units using the software need to be given time to put measures in place to ensure that development and/or maintenance of the codebase continues until an alternative solution to development by the InnerSource community is found (if business relevant or mission critical).
* The review committee should convene regularly. A cadence of two meetings per year has proven successful.
* The review committee can become optional, if InnerSource has been widely adopted and understood by the organization.
### Resulting Context
* Managers apply a tool they are comfortable with to InnerSource in order to get the required amount of information about and control over the inner workings of the InnerSource initiative. This familiarity will make it more likely for them to sign off on the InnerSource initiative and grant the required degree of freedom for InnerSource projects.
* Developers can still self organize to a sufficient degree. Micro management does not happen because the review committee convenes rather infrequently.
### Known Instances
* BIOS at **Robert Bosch GmbH** (in the early stages of adoption, only - 2009-2012)
### Status
* Structured
* *Finalized and Reviewed* as of 8/31/17.
### Authors
* Georg Grütter, Robert Bosch GmbH
* Diogo Fregonese, Robert Bosch GmbH
### Alias
Cheese Interface
# Service vs. Library
### Title
Service vs. Library
### Patlet
Teams in a DevOps environment may be reluctant to work across team boundaries on common code bases due to ambiguity over who will be responsible for responding to service downtime. The solution is to realize that often it's possible to either deploy the same service in independent environments with separate escalation chains in the event of service downtime or factor a lot of shared code out into one library and collaborate on that.
### Problem
When teams are working in a DevOps environment developers are responsible for a feature end-to-end: From the customer down to deployment, maintenance and support. This poses a challenge when working across team boundaries: Escalation chains may not be the same for errors happening in either team. Coupling source code and deployment leaves the teams with the question of who is responsible for on-call support in the event of errors. As a result teams are reluctant to join forces even if there is significant overlap in requirements.
### Context
* Teams are working in a micro-services environment.
* They are organized 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
* Organizational 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. 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.
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, benefiting from sharing the work of implementing the business logic.
A service that originally was built specifically to work in one environment is converted into a more general solution based on a specific business requirement.
Both teams get to know their respective escalation policy and deployment setup, potentially identifying improvements for their own setup.
The likelihood that changes are needed and made in the shared source code increases, leading to more frequent opportunities to refine, improve and optimize the implementation.
Encourages incremental operational standardization in release packaging, telemetry, health/readiness endpoints and so on as the teams realize 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](/p/30-day-warranty) pattern that takes a different approach to solving the forces described above.
### Known Instances
* **Europace AG**
* **Flutter Entertainment**: A [Flutter InnerSource application](https://innersource.flutter.com/sdlc/) has a shared code "service" repository with cross-team contribution and CI pipeline to build and publish a shared release artifact. 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.
* **WellSky** (see [Continuous InnerSource in Production - 5 Times](https://www.youtube.com/watch?v=loSTj4yIG9Q\&pp=ygUkY29udGludW91cyBpbm5lcnNvdXJjZSBpbiBwcm9kdWN0aW9u))
### Status
* Structured
### Author(s)
* Isabel Drost-Fromm
* Rob Tuley
### Acknowledgments
Thank you Tobias Gesellchen for review internal to Europace AG.
### Alias
Service vs. library: It's inner source, not inner deployment
# Standard Base Documentation
### Title
Standard Base Documentation
### Patlet
New contributors to an InnerSource project have a hard time figuring out who maintains the project, what to work on, and how to contribute. Providing documentation in standard files like `README.md`/`CONTRIBUTING.md`/`COMMUNICATION.md` enables a self service process for new contributors, so that they can find the answers to the most common questions on their own.
### Problem
A team wants to share either a freshly started or a preexisting project with the wider organization and receive contributions to it. Potential contributors often are lost: They are failing to identify the team's preferred communication channels. They have trouble quickly making a judgment about whether a new feature makes sense to be added or not. They have a hard time understanding exactly which colleagues are currently actively maintaining the project.
### Context
A project is to be shared with others as an InnerSource project. In order for others to be able to understand what the project is about as well as how to contribute, the project needs to provide some base level documentation. So far the project is lacking either all documentation or some aspects needed for users to try it out in a self-service manner as well as for contributors to get up to speed quickly.
### Forces
* The project was converted into an InnerSource project only recently. Before, users were either only internal or on-boarded in personal face-to-face sessions. Equally, people working on the project went through personal on-boarding sessions which do not scale with growing numbers of contributors or remote contributors. As a result, self service documentation is lacking.
* The project was newly created as an InnerSource project. However the host team lacks experience with InnerSource. As a result they need guidance on which information to include in their documentation, where to put that documentation so others can find it and which types of readers to address in their documentation.
* The project was converted into an InnerSource project only recently, the host team has limited experience with InnerSource. As a result, existing documentation addresses a lot of technical aspects. It does not cover communication, coordination, information needed to facilitate transparent planning.
* The project was converted into an InnerSource project only recently. As a result, a lot of implicit knowledge that exists within the team is neither written down nor obvious to contributors.
* A lack of documentation leads to potential contributors taking a long time to get setup and get started. Producing documentation (and keeping it up to date) requires a time investment. Even if the host team relies on contributors to help with lacking documentation, those contributions still need time to review.
* Project members are spending a lot of time answering getting started questions. Maintaining a comprehensive database of what could be considered support questions requires a lot of time and effort though.
* Different teams within the organization have diverging standards for how to format source code and which software patterns to use. As a result contributions often end up getting re-written to a large part or even entirely. Standardizing all of that and enforcing the standard often would require a lot of time and work.
* The added work for repeated explanations and re-writes diminishes the usefulness of the InnerSource approach.
* Frequent escalations due to extra work and delays due to re-writes lead to a big cheese situation.
### Solution
Address the need for clearer documentation for new contributors. The goal when creating this documentation should be to make getting started as much a self service process as possible with frequently asked questions answered in standard documentation format.
#### README.md
If it does not yet exist, create a `README.md` for your project. It should contain:
* The [mission of the project](https://producingoss.com/en/producingoss.html#mission-statement) in as a concise format as possible. It should answer what the project's purpose is and enable contributors to make a good first guess whether a suggested feature will likely be in scope for the project, or not.
* A "Getting Started" section for downstream users of the project. It should explain how to setup/ integrate the project artifacts as well as an explanation of some of the first typical steps for first time users.
* Deeper documentation for project users - or a link to that.
* Documentation needed for making modifications to the project - or a link to that.
* Documentation on how to contribute to the project - or a link to that.
* A "Getting involved" section that explains which public, archived, linkable communication channels the project uses. This should include a link to the project issue tracker, but also to any further discussion media used.
* A "Who we are" section explaining who the [Trusted Committers](/p/trusted-committer) behind the project are - with an explanation that instead of contacting these people privately the public communication channels above should be used for communication.
* An explanation of what the criteria are for the project to turn contributors into Trusted Committers - if that path exists.
#### CONTRIBUTING.md
If the explanation of the steps to make a contribution are too involved, create a separate `CONTRIBUTING.md` document. This document should answer frequently asked questions that contributors have asked in the past. There is no need to provide a comprehensive book up front. Rather, share information that has proven needed by contributors. Likely it will touch upon one or more of the following topics:
* How to checkout the project source code from version control.
* How to make modifications to the project (potentially including information on coding guidelines).
* How to build the project.
* How to run tests to make sure the above modifications aren't introducing new bugs.
* How to submit your modifications back to the project.
* Some information on which turnaround time to expect for modifications made.
#### COMMUNICATION.md
Create a separate `COMMUNICATION.md` document. Link this document to your `README.md` so comprehensive contact information can be provided and not take up the extra space in your README. This document should answer frequently asked questions about communicating with your team that contributors need to know. The goal is to streamline communications so users and contributors reach out to the correct person through a single channel. This reduces unnecessary distractions for team members and organizes communications so they do not get lost.
Sections in the `COMMUNICATION.md` include points of contact for incoming communications and information about outgoing communications from the project's ownership team. See some examples below.
Points of contact for incoming communication and how to contact those users:
* Reporting a bug
* Following up on a PR
* Feature requests
* Questions about documentation
* Escalations
How and when the team communicates outbound with users and how to get added to those communications:
* Planned and unplanned outages
* Feature releases
* Code freezes
* Breaking changes
There are many of good examples for how to write a `README.md` and what kind of information to include in a `CONTRIBUTING.md` file in various open source projects. Pages like [how to write a readme that rocks](https://m.dotdev.co/how-to-write-a-readme-that-rocks-bc29f279611a), [Open Source Guide from GitHub](https://opensource.guide/) as well as the book [Producing Open Source](https://producingoss.com/en/producingoss.html) all have valuable information on what kind of information to provide. While Producing Open Source does not have a chapter on writing a good README per se, the [Getting Started chapter](https://producingoss.com/en/producingoss.html#starting-from-what-you-have) does provide a fairly extensive list of things that fellow host team members, users and contributors will need. InnerSource projects likely will not cover all of those aspects right from the start, the list itself is helpful for inspiration for what one could cover.
In addition to that, this pattern comes with three very basic templates to get you started right away: [README-template.md](/appendix/extras/readme-template), [CONTRIBUTING-template.md](/appendix/extras/contributing-template), and [COMMUNICATION-template.md](/appendix/extras/communication-template).
### Resulting Context
* The time for contributors to get up to speed is significantly reduced.
* Time spent on answering initial questions for [Trusted Committers](/p/trusted-committer) is significantly reduced, leaving them more time to work on other tasks.
* Escalations due to misunderstandings and misalignment are significantly reduced.
### Known Instances
* **Europace AG** - See blog post [InnerSource: Adding base documentation](https://tech.europace.de/post/innersource-base-documentation/)
* **Paypal Inc.**
* **Mercado Libre** - create a documentation site that contains how to get started with InnerSource and also define the basic artifacts that a repository must have to be InnerSource (README, CONTRIBUTING, CODING\_GUIDELINES, etc).
* **Analog Devices Inc.**
* **Airbus**
* **Siemens** automatically creates a checklist issue for every new InnerSource project to make maintainers aware of mandatory requirements (e.g. business approval, license & copyright, export control, contributing guidelines, maintainer maturity) as well as best practices (e.g. documentation as code, semantic versioning, continuous integration/deployment).
### Authors
* Isabel Drost-Fromm
* Katie Schueths - added the `COMMUNICATION.md` concept
### Alias
Provide standard base documentation through a README
### Status
* Structured
* Drafted in December 2019.
### References
* [README-template.md](/appendix/extras/readme-template)
* [CONTRIBUTING-template.md](/appendix/extras/contributing-template)
* [COMMUNICATION-template.md](/appendix/extras/communication-template)
### Credits
[Web](https://storyset.com/web) and [People](https://storyset.com/people) illustrations by Storyset
# Standard Release Process
### Title
Standard Release Process
### Patlet
Teams may hesitate to adopt an InnerSource project if they are unsure of its maturity. To address this, consistent release notes and published artifacts are crucial. These practices showcase a strong dedication to the project, instilling confidence and assuring users of ongoing commitment to sustainable and well-managed software.
### Problem
When a team is deciding whether to use an InnerSource project, one of their considerations is whether they can rely on the given project for an extended period. Switching the tools/projects that they are using has a cost, so they only want to make those investments when necessary and has tangible benefits.
It is common practice for Open Source projects to have versioned releases, with notes documenting breaking changes, and new features along with either a published binary or link to a Docker image. This practice may not be as transparent or well documented/visible for InnerSource projects, modules, etc.
InnerSource projects that don't have a published artifact or release process reduces trust. Teams won't know when they can expect the next release, when breaking changes are introduced, etc.
### Context
Large organizations produce a lot of internal software, much of which could be reused by teams across the company. Operational tooling, software libraries, and infrastructure as code (IaC) modules are common examples of this type of software. Most large organizations, however, don't publish internal software to be consumed by other teams in the company. This can occur either because they are to busy to provide documentation or don't realize the projects value to others.
An internal or public source repository should be available where source code is stored, but teams lack a process for making software consumable by outside teams.
As an organization grows and more internal software is written, the value of this pattern grows.
### Forces
#### Difficult for organizations that don't have a central CI/CD system
For organizations that don't provide engineers a centralized CI/CD system, automating a build and release process can be challenging. The team may need to stand up their own tool (Jenkins, Drone, etc). Without a CI/CD system, builds and release notes can still be produced, however, it may require a local build of the software and manual upload to whichever tool is hosting build artifacts.
#### Added burden of publishing release notes
In addition to building your source code, writing release notes can be tedious without the ability to auto-generate a list of git commits. This would be left for someone to do manually, in addition to writing more high level details on a release.
#### Increased difficulty without a location to host artifacts
If a company does not provide a centralized location for storing build artifacts (jars, npm modules, etc.) and docker images, engineers may be left deciding for themselves where is appropriate to store versioned software. Tools like GitHub provide this for you, however, if a company is not using one of these popular tools, this could pose a burden.
### Solution
By providing clear **release notes** and a published artifact you increase people's confidence that you are publishing a quality product that they can rely on.
The following are key elements to achieve this:
* A CI/CD pipeline is located within your repository that [automates the release process](https://opensource.guide/best-practices/#use-tools-to-automate-basic-maintenance-tasks)
* Build artifacts are generated by the CI/CD system (binary, docker image, jar, etc)
* Releases are clearly labeled and tagged with [semantic versioning](https://github.com/semantic-release/semantic-release)
* Releases include notes on New Features, Bug Fixes, and any "Breaking Changes"
A good example of quality release notes can be found in the [jaeger project](https://github.com/jaegertracing/jaeger/releases).
### Resulting Context
Teams who come across your project will see published release notes and gain confidence in your tool. Published artifacts also make using your product easier and quicker to adopt. Having well-defined and visible processes such as these also help with cross-team collaboration and new contributors. Folks can be confident that their contributions are made available and distributed in a reasonable amount of time with a clear usage path.
Release notes are also a great opportunity to [praise participants](/p/praise-participants)! As we know, [documentation is extremely important](/p/base-documentation) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.
### Known Instances
* **Comcast** (multiple projects)
* **GitHub** (multiple projects)
### Authors
David Grizzanti
### Status
Structured
# Start as an Experiment
### Title
Start as an Experiment
### Patlet
Start your InnerSource initiative as a time limited experiment to make it easier for managers unfamiliar with InnerSource to endorse and support the initiative.
### Problem
An InnerSource initiative is considered but not started because management is unsure about its outcome and, as a result, is not willing to commit to an investment.
### Context
The company is considering InnerSource to increase the efficiency of collaboration on software projects. However, most managers are not familiar with the Open Source working model and are instead accustomed to hierarchical, top-down control style management. The idea of InnerSource is very popular with software developers in the company, not the least because many developers use or are actively developing Open Source software.
### Forces
* Managers will want to validate the claims of improved collaboration through InnerSource before making a long term investment. This usually involves measuring the improvements.
* If the InnerSource initiative will likely have a huge uptake among developers and if many projects are likely to rely on it, a decision to shut it down will be very unpopular and therefore hard to make. The perceived resulting loss of control might deter some managers to even start with InnerSource.
* Implementing InnerSource style working models are often a radical departure from previously practiced working models. It is therefore likely, that existing, mandatory processes are no longer applicable and that appropriate governing processes are missing. The result might be that one has to operate in a regulatory, sometimes legal no-mans land. Examples are tax and export control related regulations in large corporations with multiple legal entities in multiple countries.
### Solution
Declare the InnerSource initiative as a time limited experiment. Define and communicate the criteria for projects to join the InnerSource experiment. Choose criteria that will maximize the chances of building a healthy community. A set of criteria is a good one if the insights generated from it within the context of the experiment can intuitively be applied to contexts involving other potential InnerSource projects.
Examples for such criteria are:
* Sufficient geographical distribution of developers
* Sufficient departmental mix of developers
* Openness of communication within community
* Career path based on merit within community
* Democratic decision making within community
Consider designating the end of the experiment a *pivot*, *change* or *pause* point to re-evaluate. Also consider establishing a [Review Committee](/p/review-committee) to increase the chances of management buy-in through participation. Depending on company culture, it might be helpful to accompany the experiment with appropriate metrics [First Steps With Metrics](https://github.com/InnerSourceCommons/InnerSourcePatterns/tree/main/patterns/1-initial/introducing-metrics-in-innersource.md). If the projects in the experiment don't provide a direct impact on the companies revenue, consider introducing [Cross-Team Project Valuation](/p/crossteam-project-valuation) to highlight their value contributions.
### Resulting Context
Managers are able to kick start InnerSource for the following reasons:
* The experimental setup eases the need for managers to scrutinize the InnerSource program numbers in the same way that they would for typical projects.
* The possibility of failure of the experiment is understood and accepted. The personal risk for the supporting managers is minimized.
* Even in case of a failure, the setup ensures that the company will learn from the experiment.
* In case of success, the data gathered during the experiment will allow managers to make a longer lasting commitment to InnerSource.
Participants in the InnerSource experiment are now conscious that they have to prove to management that InnerSource yields the promised benefits. It will therefore help to focus work on those activities which provide the most demonstrable value thus increasing the chances of success.
Finally, starting as an experiment makes it much easier to sidestep regulations and forces such as tool and process policies which could decrease the chances of success.
### Related Patterns
* *Trial Run* (from the book [Fearless Change](https://fearlesschangepatterns.com/))
### Known Instances
* **Robert Bosch GmbH** (globally distributed software development)
* **Airbus**: the data science community collaborated on shared Python libraries that eventually lead to a group-wide InnerSource scheme for any software.
* **Siemens** started their [InnerSource Platform](https://about.gitlab.com/customers/siemens/) code.siemens.com from a single department with a few hundred users. Over the years they scaled it to a company-wide service with 50,000 active users.
### Status
* Structured
### Author
* Georg Grütter (Robert Bosch GmbH)
### Acknowledgments
* Jason Zink (Robert Bosch GmbH)
* Diogo Fregonese (Robert Bosch GmbH)
* Robert Hansel (Robert Bosch GmbH)
* Hans Malte Kern (Robert Bosch GmbH)
* Russ Rutledge (Nike)
* Tim Yao (Nokia)
* Clint Cain (Optum)
# Transparent Cross-Team Decision Making using RFCs
### Title
Transparent Cross-Team Decision Making using RFCs
### Patlet
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.
### Problem
For an InnerSource project to be healthy, it needs a substantial amount of contributors. These contributors (or teams) maybe have different requirements for the given project. e.g. they may want to add features to the project that are not compatible with one another or lead to an unhealthy bloat in the architecture.
Discovering such disagreements or misunderstanding late in the process, e.g. once the software has already been built, is very costly. These disagreements may lead to frustrations by all parties involved, and can even be disruptive to the health of the collaboration culture in the project. A common situation where such a disagreement surfaces is a change request (pull request) which is open for a very long time because the author of the change request and the maintainers of the project essentially don’t agree that the proposed change should be made at all.
For an InnerSource project this situation happens more frequently when the project is maintained by multiple teams in the company i.e. shared ownership.
### Story
A project, or application made up of multiple projects, is maintained by a number of different teams, with each team owning different areas of the project or application. These teams do make InnerSource contributions to each other's areas, but larger, cross-cutting changes are only ever driven by the teams' technical leads working together, or don't happen at all. This results in most engineers unable to effect large scale, cross-cutting change, reducing innovation and opportunities for collaboration.
By implementing a process and template for RFCs, teams and individuals are empowered to propose large, cross-cutting changes via a transparent decision making process, with consultation across teams done asynchronously. This results in greater innovation, closer collaboration, and more knowledge spread. This is dependent on buy-in from all disciplines at all levels, and an environment of psychological safety so that people can openly propose and debate ideas.
Like with any process, this must be continually improved upon. There may need to be changes to the RFC template or process to ensure it is inclusive, collaborative, and effective.
### Context
* shared ownership by many teams of an InnerSource project
* overarching design decisions cannot be made from a central body all the time (e.g. a group of architects) as they have neither enough time, nor sufficient domain-specific knowledge to make good decisions in all the cases
* various types of users have input on the direction that a certain project is taking. Such user may be: Developers, Product Owners, Product Managers, etc
* decisions need to be made in a asynchronous fashion, at least partly, as it isn’t feasible to call frequent synchronous meetings with all participants
* there is a desire to document the decisions made, i.e. making sure that they are made in writing, rather than just verbally
### Forces
* most of the times, the involved parties want to make a decision fairly quickly (e.g. the up-front design time is fairly limited)
* writing things down (without already implementing things) is often a new skill for many of the people involved
### Sketch
### Solutions
We chose an RFC-like process for increasing the transparency of our cross-team decision making process (also see IETF's [Requests for Comments](https://en.wikipedia.org/wiki/Request_for_Comments)).
Important elements of the solution are:
* a description of when to publish an RFC (and when not to)
* a template for RFC documents
* should provoke RFC author to consider their proposal from multiple angles
* should prompt both high level accessible overview, and detailed in-depth explanation
* a well known, lightweight process surrounding RFCs e.g.
* how to publish RFC and share it with all stakeholders (e.g. Slack, mailing list)
* how to collect feedback for the RFC
* how to work in the feedback
* how to move the RFC towards a conclusion or decision (e.g. relevant nominated maintainers to sign off)
* appropriate tooling chosen (e.g. non-engineers may not have access to source control tools)
* a commitment to iterate on the RFC template and process
#### Examples/Templates
* [Rust](https://github.com/rust-lang/rfcs) is a good Open Source example of RFC template and process, and has been the basis for many other RFC processes.
* [Generalized BBC iPlayer & Sounds RFC template](/appendix/extras/rfc), originally based on the [Rust](https://github.com/rust-lang/rfcs) template
* [jakobo/rfc](https://github.com/jakobo/rfc) outlines how to set up a company-internal RFC process. It contains a [detailed explanation](https://github.com/jakobo/rfc/blob/master/text/0001-using_rfcs.md) of why RFCs are important and an [RFC template](https://github.com/jakobo/rfc/blob/master/0000-template.md) to help you write your first RFC. It contains information such as motivation/rational, guide implementation, a reference implementation, drawbacks, as well as alternatives to the RFC approach. Bonus: The description itself is an RFC, so while reading it you are already getting a sense of how an RFC works.
### Resulting Context
Implementing an RFC-like process has proven to be valuable, as it makes the cross-team decision making process more transparent for everybody, allowing for all voices to be heard.
Observable positive effects:
* **democratization of the decision making process** for decisions that impact many teams (also offloading team leads from that burden)
* **a open asynchronous communication method** that works well across multiple teams and geographies
* **empowers individuals and teams** to effect large scale change
* **record of decisions made** for people to refer back to for context
* **scales impact of experienced engineers** as they can contribute to solutions asynchronously and remotely, rather than needing to be present in a meeting
* **terminology alignment** e.g. by spelling out our testing terminology such as “what is a system test?”
* **process alignment** e.g. by spelling out the out-of-hours support process
* **greater clarity of thought**, as writing an RFC makes the author challenge herself more than they would normally
The RFC approach also has risk that we want to call out:
* It doesn’t always work! e.g. some people might still argue against a decision that was already made via an RFC. However having the decision making process in writing is still beneficial in these scenarios, as you can point people to when and why a certain decision was made.
* Writing up design proposals (architecture, protocols, etc) upfront has an element of waterfall-like design that does not fit the iterative development approach that many development teams favor. Remember: “Working software over comprehensive documentation” ([Agile Manifesto](https://agilemanifesto.org/)). The RFC process should be as lightweight as possible.
* An RFC may become big and too unwieldy. This often shows in long comment threads and discussions surrounding it. In those situations we may decide to complement the RFC with synchronous communication such as a working group and in-person meetings. But time is still saved, as people can read the RFC before the meeting rather than having all the information shared during the meeting.
### Rationale
RFCs haven proven themselves in the Open Source world for many years. This is true both for the Internet as a whole where RFCs have been instrumental in developing standards (e.g. see [30 Years of RFCs](https://www.rfc-editor.org/rfc/rfc2555.txt)), as well for other Open Source projects that have adapted this method to promote transparent decision making in their community (e.g. [RUST](https://github.com/rust-lang/rfcs), [ZeroMQ](https://rfc.zeromq.org)).
In the context of InnerSource, other companies have shared their experiences with RFC-like approaches too, such as [Uber](https://blog.pragmaticengineer.com/scaling-engineering-teams-via-writing-things-down-rfcs/) and [Europace](https://github.com/open-organization/open-org-distributed-work-guide/blob/master/drostfromm-remote-first-through-openess.md#setting-cross-team-standards-and-best-practices-in-the-open).
Also for decision making outside of pure software design decisions, transparent decision making models can be effective e.g. when working towards an Open Organization. For an example see Red Hat’s [Open Decision Framework](https://www.redhat.com/en/about/press-releases/red-hat-releases-open-decision-framework-spur-transparent-and-inclusive-leadership) (released publicly on June 7, 2016).
### Known Instances
* **BBC iPlayer & Sounds** - As presented at the ISC Fall Summit 2020 [Using Internal RFCs to Enhance Collaboration](https://www.youtube.com/watch?v=U6zlghE0HcE).
* **Europace** - As described in Open Organization: [Setting cross-team standards and best practices in the open](https://github.com/open-organization/open-org-distributed-work-guide/blob/master/drostfromm-remote-first-through-openess.md#setting-cross-team-standards-and-best-practices-in-the-open).
* **Uber** - According to this blog post by Gergely Orosz: [Scaling Engineering Teams via RFCs: Writing Things Down](https://blog.pragmaticengineer.com/scaling-engineering-teams-via-writing-things-down-rfcs/).
* **Google Design Docs** - As described in this blog post by Malte Ubl [Design Docs at Google](https://www.industrialempathy.com/posts/design-docs-at-google/)
* **DAZN** (10/2021) - One way that DAZN makes technical decisions is via RFCs. RFCs are used for decisions that apply to engineering-wide processes only! The RFCs live in a GitHub repository, and technical standards are then gradually adopted within their tools and by their engineers. An RFC can be raised by any engineer, and voted on by all engineers. If upvotes exceed downvotes, the RFC is adopted. It’s worth noting, that the RFC voting process hasn’t yet been “stress-tested” by any contentious decisions. - As described in this blog post by Lou Bichard: [Building A DX Team: Lessons Learned](https://medium.com/dazn-tech/building-a-dx-team-lessons-learned-4a66446088bc)
* **SAP** (03/2024) - SAP has a mature tool-assisted process for document review across teams. It is primarily used for the review of Architecture Decision Records (ADR) originating from cross-team work done on the Cross-Product Architecture collaboration model. Some noteworthy implementation differences from this pattern: The review process is not easily available for decisions on small projects. Also, the documents are not restricted to InnerSource projects only. - As described in the blog post [Cross-Product Architecture: Embracing Conway's Law for Better Software Architecture](https://community.sap.com/t5/technology-blogs-by-sap/cross-product-architecture-embracing-conway-s-law-for-better-software/ba-p/13648600).
### Status
Structured
### Author(s)
* Tom Sadler
* Sebastian Spier
### Aliases
* [Design Docs](https://www.industrialempathy.com/posts/design-docs-at-google/)
* Architecture Decision Record (ADRs) - Not necessarily a direct alias, as they can sometimes be used very differently e.g. RFCs for seeking input and building consensus, ADRs for recording decisions and implementation detail
# Trusted Committer
### Title
Trusted Committer
### Patlet
Many InnerSource projects will find themselves in a situation where they consistently receive feedback, features, and bug-fixes from contributors. In these situations, project maintainers seek ways to recognize and reward the work of the contributor above and beyond single contributions.
### Problem
* Project maintainers want to find ways to scale their ability to support a project
* Project maintainers want to find ways to lengthen the value delivered by a project
* Project maintainers want to visibly reward frequent contributors and empower them to amplify their value contribution.
* Lack of mechanism and language for recognizing contributions across teams within an organization
### Context
* You are the maintainer of a cross-team library, service, or shared resource
* You receive regular contributions
* You receive regular feature requests
* You receive regular bug-fix requests
* There are motivated contributors looking to build expertise through InnerSource projects
### Forces
* Over the lifecycle of a project, the focus of the maintainers may shift away to accommodate changing business priorities
* Contributors seek visible recognition of their contributions, demonstrating value
* Maintaining a project of reasonable complexity is taxing for a small team
* Developing project features at scale is taxing for a small team
### Solution
#### Defining the Trusted Committer Role for a Project
What a Trusted Committer handles is up to each project and its maintainers. Ensure you document within the project the scope of your Trusted Committer role. Clear documentation sets expectations for new community members and establishes the role for future candidates.
The following are a few guidelines for identifying a potential Trusted Committer:
* An active participant in community channels (Slack, JIRA issue triaging, etc.) becomes a Trusted Committer, thereby formalizing their role in community support.
* Someone who frequently submits code, documentation, or other repository changes. Start by including this person on pull requests. If they are actively engaging in pull requests, consider approaching them about opportunities for further collaboration on the project.
#### Formalizing Trusted Committers
The first step is to approach candidates about becoming a Trusted Committer. Maintainers should educate candidates on the role of a Trusted Committer. There is no expectation that candidates will accept the role of Trusted Committer. Each candidate should assess if they have the available bandwidth to take on the responsibilities.
When a candidate accepts the role, it is up to the project maintainers to publicly recognize the transition from user to Trusted Committer. It is also a good idea to add their name to a Trusted Committers section in your project's README. As an example:
```markdown
# project-name
... your project's readme ...
## Project Leaders
### Maintainers
- Your team
### [Trusted Committers]
- The name of the new trusted committer
[Trusted Committers]: https://example.com/link/to/your/trusted/committer/documentation.md
```
#### Maintaining Trusted Committer Relationships
Once you formalize a new Trusted Committer, it is a good idea to keep them in the loop as you continue to iterate on your project. Keeping them in the loop can be as simple as inviting them to your project channel or as involved as including them in your planning sessions. More opportunities for involvement gives Trusted Committers a path to Maintainer if they so desire.
Besides keeping Trusted Committers informed, it is good to check in on a regular basis. A suggested cadence is to start with every week before gradually progressing to every few weeks. The purpose of these check-ins is to make sure the Trusted Committer feels supported in their new role. Analogous to a 1:1 with your manager, if there are any issues, listen and empathize to try and understand what is preventing the Trusted Committer from being successful. Always [thank the Trusted Committer for their continued effort](/p/praise-participants) in making the project successful and set a new date to check-in.
#### Sunsetting a Trusted Committer
There are times which necessitate removing a Trusted Committer, such as if the Trusted Committer is:
* No longer willing to take part
* No longer able to perform their duties
* No longer employed by the company
A plan for removing access to project resources should be agreed upon by both parties, including transitioning their entry in a project's **Trusted Committer** section to a list of past contributors.
Upon removing access, [thank the Trusted Committer for their participation publicly](/p/praise-participants). Public acknowledgment ensures clear communication of transition and continuity within the community.
### Resulting Context
#### For Contributors
Achieving Trusted Committer status for a project demonstrates initiative in contributing to the community project. Recognition for these efforts can be used during annual reviews with managers.
#### For Maintainers
As a project matures, maintainers can become less familiar with key aspects of a project. Trusted Committers fill in these gaps, ensuring that all aspects of the project are better served over time.
A healthy set of Trusted Committers ensures that if project maintainers move on there is a plan for responsible stewardship.
### Known Instances
* **Nike**
* **PayPal**
* **Mercado Libre** - adds a section in the `CONTRIBUTING.md` file to inform who the Trusted Committers are.
* **Robert Bosch GmbH** - we didn't call the role 'Trusted Committer' but we had this role at the beginning of our InnerSource journey. Trusted Committers would be funded for 100 % of their time to be able to focus on this role.
### Status
* Structured
* Published internally at Nike; drafted via pull-request in June of 2018.
### Authors
* [Fernando Freire](https://github.com/dogonthehorizon)
### Acknowledgments
* [Russell Rutledge](https://github.com/rrrutledge)
* [Loren Sanz](https://github.com/mrsanz)
* [Noah Cawley](https://github.com/utanapishtim)
* [Jeremy Hicks](https://github.com/greatestusername)
* [Doron Katz](https://github.com/doronkatz)
# Pattern Template
### Title
Short Title Here
### Patlet
Concise 2 sentence description of the problem and solution. The 1st sentence describes the problem. The 2nd sentence describes the solution. Readers may quickly review dozens of these patlets (aka summaries) to discover and browse the larger library of patterns. From .
### Problem
What is the problem - crisp definition of the problem. Short description, usually not more than a couple sentences, that describes what the issues and challenges are. Be careful not to morph into information found in other sections below.
### Story (optional)
Sometimes there is a story that helps people understand the pattern better.
### Context
Where does the problem exist? What are the pre-conditions? **Unchangeable** before the solution goes into place. The content here is often tied to the applicability of the pattern for other readers: "Do I have this same particular situation?"
### Forces
What makes the problem difficult? What are the trade-offs? These are constraints that **can be changed** at a cost. The solution might change one or more of these forces in order to solve the problem, while also in-turn changing the context.
### Sketch (optional)
visual illustration
### Solutions
Verified resolutions and possible resolutions to the problem.
### Resulting Context
What is the situation after the problem has been solved? The original context is changed indirectly by way of the solution. Often this section can include discussion of the next possible Patterns/problems introduced. This section can be short in content - the solution may not introduce new problems or change much context.
### Rationale (optional)
Explains why this is the right solution; using totally different words WHY this solution balances these forces and this context to solve this problem. Can expand on what-if's or theories.
### Known Instances (optional)
Where has this been seen before? Helps to reinforce that this is a REAL pattern and that you match the context.
May mention:
* A particular business
* Anonymized instances ex: "3 companies have proven that this is a good solution" or "A large financial services org...".
### Status (optional until merging)
General pattern status is stored in GitHub's Label tagging - see any pull request. Note that this GitHub label tagging becomes less visible once the pattern is finalized and merged, so having some information in this field is helpful.
You might store other related info here, such as review history: "Three of us reviewed this on 2/5/17 and it needs John's expertise before it can go further."
### Author(s) (optional)
Often, this is yourself. If you need to, find someone in the InnerSource Commons to be the nominal author (As Told To). Could also be no-one if you do not want to take on authorship (common with a donut looking for a solution).
### Acknowledgments (optional)
Include those who assisted in helping with this pattern - both for attribution and for possible future follow up. Though optional, most patterns should list who helped in their creation.
### Alias (optional)
If this pattern is also known under a different name than what is listed under **Title**, please list those alternative titles here. e.g. if the pattern is named after the problem it solves, a helpful alias might be one that describes the solution that is applied.
# Glossary
This glossary defines essential terms that are commonly used when writing new patterns. It focuses on key terms and resolves ambiguities where necessary.
Through this the glossary helps members of the Patterns Working Group to use consistent language when writing and reviewing patterns.
* **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, ...)
* **organization** - An umbrella for multiple legal entities. (synonyms: group, enterprise) (e.g. Lufthansa)
* **project** - Projects serve as a planning and tracking tool that can integrate with the issues and pull requests within one or more repositories. In [GitHub documentation](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects), projects are described as an adaptable spreadsheet, task-board, and road map that integrates with your issues and pull requests to help you plan and track your work effectively. A single project can include items (e.g. issues and pull requests) from multiple repositories.
* **repository** - A repository is a central location for source code, files, where each file's revision history is stored and managed. It enables version control and collaboration among multiple contributors. Repositories are designed to facilitate collaboration, discussion, and management of work through features like issues, pull requests, and project boards. A single repository can be associated with multiple projects.
*Note that his glossary is far from complete. If you see terms that are used frequently in our patterns and should be defined in this glossary, please add them.*
# Extras
# README Template
## Mission
This should contain a brief (3-5 sentences) description of the mission of your project. The goal is to state what you are planning to work on and help external contributors understand roughly which types of features will likely be welcome for this project.
See also [mission statement chapter](https://producingoss.com/en/producingoss.html#mission-statement) in Producing Open Source Software.
## Getting Started
This section should contain brief documentation written for first time users on how to get started using the project. Further more detailed documentation can be linked to from here.
## Further information
This section can list any or all of the following:
* A list of features, use cases that the software addresses.
* Information on design principles that are used to resolve trade-offs
* Links to further user level documentation
* Answers to frequently asked questions (FAQ), preferably in a format that allows to link to specific questions and their answers for easier reference.
## Getting help
This section should contain a brief documentation on how to get help for the project as a user. This could be as simple as pointing users to the issue tracker if this is how your project would like to answer questions. It could also point to an archived and searchable chat channel, some archived searchable mailing list, some online user forum.
## Getting involved
This section should include information on how to get in touch with the project: Typically this will contain links to archived, searchable and linkable communication channels.
## Who we are
This is a good place to give credit to Trusted Committers of the project.
It's also a good place to include information on what being a Trusted Committer means for this project - although ideally all projects in an organization use the same definition that is only linked to from here. The reason to keep the link here is for colleagues who have no or little experience with working in and contributing to InnerSource projects to have a direct link back to company wide information from the technological projects they need for their daily work.
## Contributing
This section should document (or link to documentation) on all things that a first time contributor needs to know to get started. Typically not all of the topics below will be covered. Focus on what differs in your project from standard setup and what previous contributors found hard to understand.
* Finding the source code.
* Finding a list of issues that your project needs help with - these can be both, technical and non-technical issues. Typically you will keep those in an issue tracker accessible to contributors.
* Links to further documentation e.g. about the architecture of the project, general coding conventions, testing conventions...
* For technical contributions: Making changes, building the project and testing your changes.
* Submitting your changes back to the project.
Ideally you also include information on what the preferred process for changes looks like for the project: Should contributors first open an issue and submit a proposal, or are they welcome to submit changes right away? What is important to you when reviewing contributions?
In addition you should outline any design values you want to follow in the project. Making those explicit often helps resolve trade-offs more quickly and more easily. In addition it helps making changes to otherwise implicit assumptions transparent.
Over time you will notice that this section grows substantially. In that case think about moving the information to separate files, e.g. a `CONTRIBUTING.md` and `TESTING.md`.
# CONTRIBUTING Template
## Types of contributions
Provide information on what kinds of contributions your project is looking for here. For example these can be bug reports, help with answering user questions, improving documentation, fixes to bugs, as well as new feature implementations.
## Bug reports
Add information on how to submit bug reports here. This should include hints about which type of information the project will need in order to reproduce and fix issues. It can also include information on commonly found misconfigurations that look like bugs.
Also include information on what contributors can expect in terms of time to first response and process after that.
## Feature requests
Add information on how to submit feature requests here. Also include information on what contributors can expect in terms of time to first response and process after that.
## Contributing documentation
Include information on any documentation best practices your project follows as well as how to build documentation, checks to run and how to submit the changes made back to the project.
## Contributing source code
This section should contain information on
* How to access the project source code,
* General project layout,
* Any requirements to the development environment,
* Code formatting guidelines,
* How to run the test suite.
## How to become a Trusted Committer
This section should make the process for becoming a Trusted Committer explicit if that route is open to contributors.
## How to nominate Trusted Committers
This section serves as a reminder to existing and explanation for new Trusted Committers detailing how to add others to the host team. Again ideally this information is identical for all projects in the organization so central information can be linked to from here.
# COMMUNICATION Template
***
Put an individual COMMUNICATION.md file tailored to the project in each repo. If project repo ownership is transferred to a different team in the future, they need to be able to access and edit documentation related to the project. This includes documentation that outlines the communication processes that users should use to contact the team.
**Delete top paragraph when this section is filled out.**
## Team Communication
Team Slack channel:
Special Slack Channels: (topic specific and accessible to anyone who would be an external contributor)
Team Email:
## How to Contact Us
The following types of actions can be moved to the appropriate section and more added.
| Action | (General team contact) |
| ------------------------------- | ------------------------ |
| Contact Method | (email or slack channel) |
| Bug report | |
| Feature request | |
| Contribution process questions | |
| Merge Requests after submission | |
| Add more here… | |
| Special Situations: | Direct point of contact (Role) |
| ------------------- | ------------------------------ |
| Status updates | |
| other | |
| other | |
| Add more here... | |
## Roles and Responsibilities
Managers or roles and specific situations they should be contacted for outside the team channel.
(this is set up this way so that the document can easily be changed if there are new members on the team)
| Role | Name | Preferred contact method |
| ---- | ---- | ------------------------ |
| | | |
| | | |
| | | |
## Outbound Communication
| Scenarios | When users will receive communication | Stakeholders who will receive | Action - how to receive these communications |
| ------------------------------------------------------------------------------ | ------------------------------------- | ----------------------------- | -------------------------------------------- |
| Breaking changes (for e.g. any changes to our API or messaging contracts) | | | |
| Extended/planned outages (service downtime for maintenance related activities) | | | |
| Unexpected Outages | | | |
| Traffic specific changes (e.g. team to team, etc.) | | | |
| New Feature rollout | | | |
| As per product guidelines | | | |
| Month end and company wide code freeze | | | |
| Internal team and any other teams who contribute to team project repos | | | |
| Add more… | | | |
## Documentation Contacts
Tell how to find the owner, responsible party, or group people should contact if they have questions about documentation in the repo.
Describe this communication process.
For example:
* If you have questions on a specific piece of documentation, you can find the team member responsible for the information by looking here:
* You can contact the responsible party by sending a message in the xyz channel, send them a direct message in chat, email, etc. The individual who last certified the documentation is the responsible party.
***
# RFC Template
* Feature Name: (fill me in with a unique identifier, `my_awesome_feature`)
* Start Date: (fill me in with today's date, YYYY-MM-DD)
* Nominated owners: (Representatives of technical ownership areas affected by the RFC. This will often be tech leads, but they may delegate. RFCs cannot be accepted until all nominated owners have signed off.)
## Summary
One paragraph explanation of the feature.
## Retrospective
This section is essential to allow us to learn from the things we are implementing.
*When is the retrospective?*
\[ ] Retro completed?
(where/how it will be held, how can people get involved, where are the results?)
## Motivation
Why are we doing this? What use cases does it support? What is the expected outcome?
## Guide-level explanation
Explain the proposal as if it was already existing and you were teaching it to another engineer. That generally means:
* Introducing new named concepts.
* Explaining the feature largely in terms of examples.
* Explaining how engineers should think about the feature. It should explain the impact as concretely as possible.
* If applicable (e.g. code/architecture proposal), provide sample error messages, deprecation warnings, or migration guidance.
* If applicable, describe the differences between teaching this to existing engineers and new engineers.
For implementation-oriented RFCs, this section should focus on how contributors should think about the change, and give examples of its concrete impact. For policy/process RFCs, this section should provide an example-driven introduction to the policy/process, and explain its impact in concrete terms.
## Reference-level explanation
This is the technical portion of the RFC. Explain the design in sufficient detail that:
* Its interaction with other features is clear.
* It is reasonably clear how the feature would be implemented.
* Corner cases are dissected by example.
The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work.
## Drawbacks
Why should we *not* do this?
## Rationale and alternatives
* Why is this design the best in the space of possible designs?
* What other designs have been considered and what is the rationale for not choosing them?
* What is the impact of not doing this?
## Prior art
Discuss prior art, both the good and the bad, in relation to this proposal. A few examples of what this can include are:
* For language, library, tools etc: Does this feature exist in other places and what experience have their community had?
* For community proposals: Is this done by some other community and what were their experiences with it?
* For other teams: What lessons can we learn from what other communities have done here?
* Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background.
This section is intended to encourage you as an author to think about the lessons from other places, provide readers of your RFC with a fuller picture. If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if it is an adaptation from other places.
## Unresolved questions
* What parts of the design do you expect to resolve through the RFC process before this gets merged?
* What parts of the design do you expect to resolve through the implementation of this feature before stabilization?
* What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC?
## Future possibilities
Think about what the natural extension and evolution of your proposal would be and how it would affect the teams and projects as a whole in a holistic way. Try to use this section as a tool to more fully consider all possible interactions with the project and teams in your proposal. Also consider how the this all fits into the roadmap for the project and of the relevant sub-team. This is also a good place to "dump ideas", if they are out of scope for the RFC you are writing but otherwise related. If you have tried and cannot think of any future possibilities, you may simply state that you cannot think of anything. Note that having something written down in the future-possibilities section is not a reason to accept the current or a future RFC; such notes should be in the section on motivation or rationale in this or subsequent RFCs. The section merely provides additional information.
# イントロダクション
{% hint style="info" %}
あなたが読んでいるインナーソースパターンは初期のリリースフェイズです。リンクが壊れていたりスペルミスやエラーがある可能性があります。 できる限りベストな本を作成するために是非修正にご協力ください。[本へのコントリビューション](/ja/contribute)方法についてはこちらをご参照ください。
{% endhint %}
**インナーソースパターンブック**へようこそ。
この本では、インナーソースのベストプラクティスを理解しやすい特定のフォーマットで体系化し、評価し、あなたの環境で適用しやすくまとめています。このフォーマットを私たちは "パターン" と読んでいます。
[インナーソース](http://innersourcecommons.org) は、長年にわたってこれらのパターンを収集し、この本で最も成熟したパターンを公開しています。また、コミュニティのメンバーが、少なくとも一つの事例をもって、それぞれのパターンをレビューしています。
このイントロダクションでは、[インナーソースとは何か](#innssutohaka)、[パターンとは何か](#innssupatntohaka)、そしてあなたの組織における[これらのパターンの使い方](#donoyouniinnssupatnwouka) について説明します。
もしあなたが既に会社でインナーソースを使っていて、その経験を本書に提供したいのであれば、ぜひ[本書へのコントリビューション](/ja/contribute)をよろしくお願いします！
## インナーソースとは何か
私たちはインナーソースを次のように定義しています。
> 組織という限られた環境において、ソフトウェア開発におけるオープンソースの原則とプラクティスを活用すること
インナーソースは、オープンソースソフトウェアの開発から得た教訓を、企業の社内でのソフトウェア開発のあり方に応用します。 開発者は世界トップクラスのオープンソースソフトウェアに慣れるにつれて、これらの手法をファイアウォールの内側に戻し、企業がリリースを躊躇するようなソフトウェアに適用したいと強く思うようになりました。
インナーソースは、主にクローズドソースのソフトウェアを構築している企業にとって、サイロの解消、社内コラボレーションの促進および拡大、新しいエンジニアのオンボーディングの促進、そしてオープンソースの世界にソフトウェアを還元するチャンスを探るのに役立つ役立つ素晴らしいツールです。
## インナーソースパターンとは何か
パターンとは、ある状況の中で、問題に対する再現可能で実績のある解決策を記述する方法です。 パターンは、ソリューションを適用する際に、問題の制約を理解し、バランスをとる必要のある力を理解し、ソリューションを適用した結果生じる状況を理解することをたすけるシンプルなフォーマットに従っています。
パターンは、インナーソース・コモンズ の参加者が情報を簡潔に共有し、インナーソースのプラクティスを磨く方法を提供しており、タイトル、問題提起、状況、フォース、ソリューションを主要なセクションとして分けて構成してあります。
* [`パターンとは何か` Youtube ビデオ](http://bit.ly/innersource_patterns_videos) - インナーソースパターンを説明する2-5分のyoutubeビデオのセットをご覧ください
* [パターンディスカッション ウェビナー](https://youtu.be/i-0IVhfRVFU) - 2017年3月16日にウェビナーを開催し、ドーナツパターンをライブディスカッションしました（ディスカッションは24:30から）。これは、私たちが行うレビュープロセスの実例です。
* 合わせてこちらもご覧下さい [2017年6月1日 インナーソースパターンに関する O'Reilly ウェビナー](http://www.oreilly.com/pub/e/3884).
* [パターンテンプレート](/ja/appendix/pattern-template) - インナーソースパターンの概略を見て、新しいパターンの中身を知ることができます
* [インナーソースパターンの紹介 (2016 Fall Summit presentation)](https://drive.google.com/open?id=0B7_9iQb93uBQbnlkdHNuUGhpTXc) - *Tim Yao and Padma Sudarsan* (PDF) 「パターンとの付き合い方 - 手法と理由を詳しく理解する」合わせてこちらもご覧ください - [インナーソースパターン入門 (2017 Fall Summit)](https://drive.google.com/open?id=0B7_9iQb93uBQWmYwMFpyaGh4OFU) *Tim Yao and Bob Hanmer* (PDF)
## どのようにインナーソースパターンを使うか
パターンは無差別に適用するのではなく、よく考えて使わなければなりません。
ほとんどの場合、与えられたソリューションを自分達の状況に合わせる必要がありますが、パターンで与えられている情報、コンテキスト（動かせない制約）とフォース（変更可能な制約、相互にバランスをとる制約）の定義は、ソリューションを適用するのに役立つはずです。 またパターンに追加すべき項目として、あなたの特定の企業/組織に適用さる追加の制約があるかを決定する必要があることにも注意してください。 これらの追加の制約のためには、追加のソリューションステップを適用する必要があるかもしれません。
パターンのフォーマットは実績のあるソリューションを記述するのに便利ですが、パターンがまだ確立されていない新しいソリューションに関する *ブレインストーミング* にも使用できます。これは、パターンの構造が、構造化された方法で問題について考えるためのフレームワークになっているからです。
また、インナーソース・コモンズのコミュニティに助けを求める方法として、ドーナツ・パターン（問題、状況、フォース、結果の状態のフィールドを記載し、ソリューションの欄は空白にする）を作ることもできます。(実証済みのソリューションを見つけるために、または試してみるためにブレインストーミングを実施します)
## コントリビュートするには
こちらをご参照ください。 [この本にコントリビュートするには](/ja/contribute)
## クレジット
この本は、世界中の無数の[オープンソースコントリビューター](https://github.com/InnerSourceCommons/InnerSourcePatterns/graphs/contributors)の方々による長年のワークの結果です。
この本は、彼らの会社で直面した課題を率直に共有することや、どのようにそのチャレンジに InnerSource が役立ったかをオープンに共有ことに対する彼らの意欲によって素晴らしいものになっています。インナーソースの旅を始めようとしている方々にとって、とても貴重なリソースになるでしょう。
またインナーソース・パターンのワーキンググループに関しても言及させてください。彼らは、インナーソース・パターンのクオリティを育て、他の人がコントリビュートするのを支援してきました。
最後に、彼らはこの本に利用可能なパターンを選択してまとめています。この本のタイトル画像は、[CC BY 2.0](https://creativecommons.org/licenses/by/2.0/)で利用可能な [Tony Hisgett - Alhambra 6](https://www.flickr.com/photos/hisgett/29345405788/) による画像を基に [Sebastian Spier氏](https://spier.hu)によって作成されています。
**コントリビューターのみなさま、ありがとうございます！そして、良いインナーソースの日をお送りください😃**
## ライセンス
インナーソース・パターンは [InnerSourceCommons.org](http://innersourcecommons.org) によりライセンスされ、[Creative Commons Attribution-ShareAlike 4.0 International](http://creativecommons.org/licenses/by-sa/4.0/) ライセンスで提供されています。
## 翻訳の履歴
* **2022-05-23** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
* **2022-06-15** - レビュー [@johtani](https://github.com/johtani)
# 目次
* [イントロダクション](/ja)
* [目次](/ja/toc)
* [パターンの一覧](/ja/explore-patterns)
* [この本へのコントリビューション](/ja/contribute)
## パターン
**何から準備する？**
* [実験として始める](/ja/p/start-as-experiment) - インナーソースイニシアチブを期間限定の実験として開始し、インナーソースに慣れていないマネージャーがイニシアチブを承認およびサポートしやすくします。
* [正式なコミュニティリーダー](/ja/p/dedicated-community-leader) - インナーソースの取り組みを成功させるために、コミュニケーションとテクニカルの両方のスキルを持つ人をコミュニティのリーダーとして選ぶ。
* [基本原則ガイダンスの文書化](/ja/p/document-your-guiding-principles) - 「オープンソースのベストプラクティスを組織内に適用する」という通常のインナーソースの説明は、オープンソースのバックグラウンドがない人々にはうまく機能しません。 解決策として、インナーソースの最も重要な原則を文書化し広く公開しましょう。
**README.md、CONTRIBUTING.md、コミュニケーションツールなど用意するには？**
* [スタンダード・ベース・ドキュメンテーション](/ja/base-documentation) - インナーソースプロジェクトへの新しいコントリビューターは、誰がプロジェクトを維持し、何に取り組み、どのようにコントリビューションすればよいかを理解するのに苦労しています。README.md/CONTRIBUTING.md のような標準ファイルでドキュメントを提供することで、新しいコントリビューターのためのセルフサービスなプロセスを可能にし、よくある質問に対する答えを自分自身で見つけることができるようにします。
* [コミュニケーションツーリング](/ja/communication-tooling) - インナーソースのプロジェクトは、開発チームの外で使用されていますが、ユーザーはヘルプを得たり、プロジェクトチームと連絡を取ったりするのに苦労しています。 このアイデアは、ディスカッションが可視化され、アーカイブされ、検索可能になることを可能にする標準的なコミュニケーションツールを設定し、文書化することです。
* [イシュートラッカーの使い方を多様化する](/ja/issue-tracker) - インナーソースのホストチームは、計画や進捗だけでなく、変更の背景も透明化することができていません。これは、プロジェクトのイシュートラッカーのユースケースを増やし、ブレーンストーミング、実装の議論、機能設計にも使えるようにすることで解決することができます。
**インナーソースを本格導入しよう！**
**インナーソースの価値を評価するには？**
* [クロスチームプロジェクト評価](/ja/crossteam-project-valuation) - 会社の収益に直接的な影響を提供していないクロスチームのインナーソースプロジェクトの価値を評価して社内に売り込むことは困難です。 ここでは、あなたのプロジェクトの価値を明確に表現し、それを大きくするためのデータ駆動型の方法を紹介します。
**感謝を伝えるには？**
* [コントリビューションの功労を称える](/ja/praise-participants) - インナーソースのコントリビューションの後、その時間と努力に対してコントリビューターに感謝することは重要です。 このパターンは、コントリビューションを効果的に認めるだけでなく、コントリビューターや他の人たちのさらなる関与を引き出すためのガイダンスを提供します。
**技術的な問題に対しては？**
* [共通要件](/ja/common-requirements) - 共有リポジトリにある共通のコードは、それを使いたいすべてのプロジェクトチームのニーズを満たしていません。これは、要件の調整とリファクタリングによって解決されます。
* [サービス対ライブラリ](/ja/service-vs-library) - DevOps環境のチームは、サービスのダウンタイムに対応する責任が誰にあるのかが曖昧になるため、チームの境界を越えて共通のコードベースで作業することに消極的になる場合があります。解決策としては、同じサービスを独立した環境で展開し、サービスダウン時のエスカレーション・チェーンを別々に構築するか、多くの共有コードを1つのライブラリに集約し、その上で共同作業を行うことが挙げられます。
* [コアチーム](/ja/core-team) - インナーソースのプロジェクトが広く必要とされていても、プロジェクトが難しいためにコントリビューションや活用に支障をきたす場合があります。プロジェクトの基本的な項目を専門に担当するコアチームを設立してください。コアチームの作業により、コントリビューターは自分のシナリオに価値をもたらす機能を追加し、使用することができます。
**組織的な挑戦の仕方は？**
* [コントラクトコントリビューター](/ja/contracted-contributor) - インナーソースにコントリビュートしたい社員がいますが、彼らの直属の上司はその活動に抵抗を示しています。正式な契約と合意をすることによって救済することができるかもしれません。
* [30日の保証期間](/ja/30-day-warranty) - 自分のチーム以外からのコントリビューションを受け入れる場合、チームが書いていないコードの責任を持つことに抵抗があることは自然なことでしょう。 「30日の保証期間」プラクティスを利用すると、コードにコントリビュートしたチームはコードを受け取ったチームに対してバグフィックスを提供することを承諾することになります。 そうすることで、両チーム間の信頼度が高まり、コントリビューションが受け入れられる可能性が高くなります。
* [レビュー委員会](/ja/review-committee) - インナーソースの作業モデルは、開発者と管理者のための、より伝統的なアプローチからの抜本的な変革です。インナーソースイニシアチブとそれに参加するビジネスユニットのすべてのシニアマネージャーの間のインタフェースとしてレビュー委員会を確立することにより、マイクロマネジメントを助長することなく、監視と制御の一定レベルを与えるように、イニシアチブに慣れ親しみ、それをサポートできるようになる可能性が高くなります。
* [トラステッドコミッター](/ja/trusted-committer) - 多くのInnerSourceプロジェクトは、コントリビューターからフィードバック、機能、バグフィックスを一貫して受け取る状況にあります。このような状況で、プロジェクトのメンテナーは、単一のコントリビューションを越えてコントリビューターの仕事を認識し、報酬を与える方法を模索します。
* [RFCを用いたチーム横断的な意思決定の透明化](/ja/transparent-cross-team-decision-making-using-rfcs) - 高い参加率を達成し、関係者全員にとって最良の意思決定を行いたいインナーソースプロジェクトは、ソフトウェアのライフサイクル全体を通して参加型のシステムを構築する方法を見つける必要があります。内部のRFC(Requests for Comments)ドキュメントを公開することで、設計プロセスの早い段階から議論を行うことができ、関係者全員が高いコミットメントを持ってソリューションを構築できる可能性が高まります。
**インナーソースライセンスとは？**
* [インナーソースライセンス](/ja/innersource-license) - 同じ組織に属する2つの法人は、ソフトウェアのソースコードを互いに共有したいと考えていますが、法的責任や会社間の会計処理の観点からの影響を懸念しています。
**インナーソースを成長させよう！**
**組織内のインナーソースを探しやすくするには？**
* [ギグマーケットプレイス](/ja/gig-marketplace) - イントラネットのウェブサイトを作成し、特定のインナーソースプロジェクトのニーズを、時間とスキルの要件を明示した「ギグ」としてリストアップすることで、マーケットプレイスを確立する。 これにより、管理者がインナーソースのコントリビューションを行うための承認を与え可能性が増え、従業員の時間のコミットメントと専門的な利点をよりよく理解することができます。
* [インナーソースポータル](/ja/innersource-portal) - 潜在的なコントリビューターは、彼らが興味を持っているインナーソースプロジェクトを簡単に見つけることができません。すべての利用可能なインナーソースプロジェクトの情報をインデックス化するイントラネットのウェブサイトを作成することにより、あなたはコントリビューターが彼らに興味があるかもしれないプロジェクトについて知ることができ、インナーソースプロジェクトのオーナーは、外部のオーディエンスを引き付けることができます。
* [リポジトリアクティビティスコア](/ja/repository-activity-score) - 潜在的なコントリビューターは、彼らの助けを必要とするアクティブなインナーソースプロジェクトを見つけたいと思っています。各プロジェクトのリポジトリのアクティビティスコアを計算することで、プロジェクトのランク付けされたリストを作成することができます (参考: インナーソースポータル )、そのため、潜在的コントリビューターは、彼らがコントリビュートしたいプロジェクトをより簡単に決定できます。
**インナーソースを拡大させよう！**
**インナーソースの拡大を評価するには？**
* [成熟度モデル](/ja/maturity-model) - チームはインナーソースを採用し始めました。このプラクティスは、複数の部門に広がっています。しかし、インナーソースプロジェクトを構成する概念への理解は様々です。解決策は、チームがセルフチェックを経て、まだ気づいていないパターンやプラクティスを発見できるよう、成熟度モデルを提供することです。
**インナーソースプロジェクトを持続的に成長させていくためには？**
* [持続可能な成長のためのエクステンション](/ja/extensions-for-sustainable-growth) - インナーソースプロジェクトは多くのコントリビューションを受けており、メンテナンスが難しくなっています。メンテナは、プロジェクトのコア部分から離れた拡張機構を提供することで、最小のコストとメンテナンスオーバーヘッドでプロジェクトの能力をスケールアップすることを可能にします。
## Appendix
* [パターンテンプレート](/ja/appendix/pattern-template)
* その他
* [README テンプレート](/ja/appendix/sono/readme-template)
* [CONTRIBUTING テンプレート](/ja/appendix/sono/contributing-template)
## Resources
* [GitHub](https://github.com/InnerSourceCommons/InnerSourcePatterns)
* [InnerSource Commons](http://innersourcecommons.org)
# パターンの一覧
とても素晴らしいことに、インナーソース・コモンズのコミュニティから、どんどんパターンが寄稿されています！
さて、ではどのように特定の自分の状況に役立つパターンを読者は簡単に見つけられるでしょうか？ そこで私たちはこのマインドマップを提供します。このマインドマップは、**インナーソースプログラムのさまざまなフェーズと、それぞれのフェーズで現れる可能性のある課題に基づいてパターンを分類しています。**
## このマインドマップを改善する
もし、このマインドマップを何かおかしいと感じた場合、その問題点と修正すべき点を記述した[イシューを作成](https://github.com/InnerSourceCommons/InnerSourcePatterns/issues)してください。
さらに、これらのパターンの発見性を向上させるための他のアイデアや、このマインドマップをより良くしたい場合は、[パターン分類](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/pattern-categorization/README.md)アプローチのドキュメントを確認し、[この本へのコントリビューション](/ja/contribute)の方法も確認してみてください。
## リファレンス
このようにパターンを分類するアイデアは、Tim Yao さん、Bob Hanmer さん、Padma Sudarsanshi さんによる[Thoughts on an InnerSource Pattern Language](https://drive.google.com/file/d/13AY8glCOdpLOVuz7cVD6QOB8d2xbHCS1/view) (2018) の記述を大まかに元にしています。具体的な内容はそのスライドデックの15ページ目をご覧ください。
## 翻訳の履歴
* **2022-05-23** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
* **2022-06-15** - レビュー [@johtani](https://github.com/johtani)
# この本へのコントリビューション
この本をもっと良くしたいですか？ 素敵ですね、やりましょう！
インナーソース・パターンブックは[オープンソースプロジェクト](https://github.com/InnerSourceCommons/InnerSourcePatterns)ですので、どんな形でのコントリビューションでも、そしてどんな些細なことでもかまいません！ 文法やスペルの修正やデザインの改善から、あなたの職場で行われたインナーソースの経験に基づいた全く新しいパターンの提案まで、私たちはどんなコントリビューションでも喜んで歓迎します！ あなたがオープンソースプロジェクトにコントリビュートしたことがない場合でも大丈夫ご心配なく。インナーソース・パターンのコミュニティはフレンドリーな人々のグループですので、コントリビュートするのに安全な場所です。
## 始める前に
インナーソース・パターンとこの本のソースは、GitHub のリポジトリで保管されています。そのため、この本の編集や提案を行うには、GitHub のユーザーアカウントが必要です。もしまだそれを持っていないなら、[github.com](https://github.com) で無料のアカウントを作成してください。
## コントリビュートするさまざまな方法
ここでは、あなたがコントリビュートできるいくつかの方法を紹介します。
1. この本で気づいたスペルやフォーマットなどの不具合を修正する
2. 既存のパターンの内容を改善する（例えば、 *既知の例* としてパターンを使用している方法についての短い説明を追加する）
3. 新しいパターンを投稿し、あなたの組織でインナーソースに関する課題をどのように克服したかを説明する
上記の(1)と(2)については、本書の各ページの上部にある **Edit on GitHub** のリンクを押すだけです。この操作では、私たちの GitHub リポジトリ内のそれぞれのファイルに直接移動し、各ページであなたの変更を提案することができます。
(3) については、[インナーソース・パターン](https://github.com/InnerSourceCommons/InnerSourcePatterns) リポジトリをクローンし、あなたの提案するパターンを新しいファイルに追加する必要があります。このような大きなコントリビュートする場合は、私たちの [CONTRIBUTING.md(英語)](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/CONTRIBUTING.md) と [Contributor Handbook(英語)](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/meta/contributor-handbook.md) を確認してください。
## コントリビューションにかかるライセンス
このリポジトリのコンテンツは [CC-BY-SA-4.0](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/LICENSE.txt) の下でライセンスされています。このリポジトリにコントリビュートすることは、私たち(そして他のすべての人)に対して、このライセンスに従ってあなたのコントリビューション物を使用する権利を与えることになります。
## 翻訳の履歴
* **2022-05-23** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
* **2022-06-15** - レビュー [@johtani](https://github.com/johtani)
# 実験として始める
### Title
実験として始める
### Patlet
インナーソースイニシアチブを期間限定の実験として開始し、インナーソースに慣れていないマネージャーがイニシアチブを承認およびサポートしやすくします。
### 問題
インナーソースイニシアチブは検討されているものの、経営陣がその結果について確信が持てず、その結果として投資にコミットする意思がないため、なかなか開始されません。
### 状況
会社は、ソフトウェアプロジェクトにおけるコラボレーションの効率を高めるために、InnerSourceを検討しています。しかし、ほとんどの管理者は、オープンソースの作業モデルに精通しておらず、代わりに階層的な、トップダウンの制御スタイルの管理に慣れています。InnerSourceのアイデアは、社内のソフトウェア開発者に非常に人気があり、少なくとも多くの開発者がオープンソースソフトウェアを使用しているか、積極的に開発しているためです。
同社は、ソフトウェアプロジェクトでのコラボレーションの効率を高めるためにインナーソースを検討しています。 ただし、ほとんどのマネージャーはオープンソースの作業モデルに精通しておらず、代わりに階層的なトップダウンの制御スタイル管理に慣れています。インナーソースのアイデアは、社内のソフトウェア開発者に非常に人気があります。その理由は特に、多くの開発者がオープンソースソフトウェアを使用または積極的に開発しているためです。
### 組織に働く力学
* マネージャーは長期的な投資を行う前に、インナーソースを用いたコラボレーションにおいて効果が期待できるかを検証する必要があります。これには通常、改善したかを測定することが含まれます。
* インナーソースイニシアチブが開発者の間で大きな支持を得る可能性が高く、多くのプロジェクトがそれに依存する可能性が高い場合、それをシャットダウンする決定は非常に不人気であり、実施するのは困難でしょう。導入した結果、コントロールを失う可能性が認識される場合、一部のマネージャーはインナーソースを始めることさえ思いとどまる可能性があります。
* インナーソーススタイルの作業モデルの実装は、以前に実践されていた作業モデルからの根本的な逸脱であることがよくあります。したがって、既存の必須プロセスはもはや適用できず、適切な管理プロセスが失われてしまう可能性があります。その結果、規制や、時には法的規制のない場所で活動しなければならなくなるかもしれません。例えば、複数の国に複数の法人を持つ大企業では、税金や輸出管理関連の規制があります。
### ソリューション
インナーソースイニシアチブを期間限定の実験として宣言します。インナーソース実験に参加するプロジェクトの基準を定義し、伝達します。健全なコミュニティを構築する可能性を最大化する基準を選択してください。実験の文脈の中でそこから生み出された洞察が、他のインナーソースプロジェクトの可能性を含む文脈に直感的に適用できるならば、一連の基準は良いものであると言えるでしょう。 このような基準の例は次のとおりです。
* 開発者の十分な地理的分布
* 開発者の十分な部門別構成
* コミュニティ内の風通しの良さ
* コミュニティ内での能力に応じたキャリアパス
* コミュニティ内での民主的な意思決定
再評価するために、実験のおわりを *ピボット*、 *変更* 、または *一時停止* のポイントに指定することを検討してください。また、参加を通じて経営陣の賛同の機会を増やすために、[レビュー委員会](/ja/review-committee)を設立することを検討してください。企業の文化によっては、[適切なメトリック](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/introducing-metrics-in-innersource.md)を使用して実験を行うことが役立つ場合があります。実験のプロジェクトが企業の収益に直接影響を与えない場合は、[チーム間のプロジェクト評価](/ja/crossteam-project-valuation)を導入して、その価値への貢献を強調することを検討してください。
### 結果の状況
マネージャーが、インナーソースをキックスタートできる理由になりうるのは以下です。
* インナーソースプログラムを以前の典型的なプロジェクトのように精査することが実験的なセットアップにより緩和されます。
* 実験の失敗の可能性が理解され、受け入れられているので、サポートするマネージャーの個人的なリスクが最小限に抑えられます。
* 失敗した場合でも、実験的なセットアップにより、会社は失敗から学ぶことができます。
* 成功した場合、実験中に収集されたデータによって、マネージャーはインナーソースに対してより長期的なコミットメントを行うことができます。
インナーソースの実験参加者は、インナーソースが約束された利益をもたらすことを経営陣に証明する必要があることを認識しています。 したがって、最も実証可能な価値を提供し、成功の可能性を高める活動に集中するのに役立ちます。 また最後に、実験として開始すると、成功の可能性を減らすかもしれないツールやプロセスポリシーなどの規制や力を回避することがはるかに簡単になります。
### Related Patterns
* *Trial Run* (書籍 [Fearless Change](https://fearlesschangepatterns.com/) より)
### 事例
* Robert Bosch GmbH (グローバルな分散型ソフトウェア開発組織を有する)
### ステータス
* Structured
### 著者
* Georg Grütter (Robert Bosch GmbH)
### 謝辞
* Jason Zink (Robert Bosch GmbH)
* Diogo Fregonese (Robert Bosch GmbH)
* Robert Hansel (Robert Bosch GmbH)
* Hans Malte Kern (Robert Bosch GmbH)
* Russ Rutledge (Nike)
* Tim Yao (Nokia)
* Clint Cain (Optum)
### 翻訳の履歴
* **2022-06-03** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
* **2023-06-18** - 最終更新
# 正式なコミュニティリーダー
### Title
正式なコミュニティリーダー
### Patlet
インナーソースの取り組みを成功させるために、コミュニケーションとテクニカルの両方のスキルを持つ人をコミュニティのリーダーとして選ぶ。
### 問題
新しいインナーソースのイニシアチブがその影響を拡大するために適切な[コミュニティリーダー](http://www.artofcommunityonline.org/)を持っていることを確認するにはどうすればよいか 間違った人を選択し、またはそれらのために十分なキャパシティを提供しないことは、無駄な努力と、最終的に新しいインナーソースイニシアチブの失敗を引き起こすリスクになる
### ケーススタディ
次のようなストーリーを考えてみましょう。ある企業が、組織の境界を越えたコラボレーションを促進するために、インナーソースイニシアチブを始めたいと考えています。彼らは、範囲を限定した実験的な段階から始めることを決定しました。経営陣は、最初のインナーソースコミュニティに適したパイロットトピックを選択し、組織全体の多くのビジネスユニットからのコントリビューションを期待しています。会社はまだ完全に計画をできていなかったので、新入社員をコミュニティの責任者に指名し、業務時間の50％を割り当てました。6か月後、コミュニティにはわずかなコントリビューションしかなく、そのほとんどはひとつのビジネスユニットからのものでした。そこで、コミュニティリーダーを社歴の長い人物に代え、今度は30%の時間しか割かないようにしました。さらに6ヶ月後の結果は、コントリビュートがわずかに増加したのみでした。同社は、部門を超えたコラボレーションを増やす目標を達成するのに、インナーソースが役立つと確信できなくなり、インナーソースを放棄しました。
### 状況
* この会社は大企業で古い会社で、またオープンソースやその他のコミュニティベースのワークモデルの経験がありません。企業文化は古典的なトップダウン経営スタイルとして最もよく特徴づけられています - それは一般的にコミュニティ文化とは相反するものです。
* トップレベルの支持者とスポンサーがいる一方で、会社の中間管理職はまだインナーソースの価値を納得できていません。
* 経営陣は、パートタイムのコミュニティ・リーダーに対し、限られた予算以上のリソースを提供することに納得していませんでした。
* 最初に選ばれたコミュニティのリーダーは、オープンソースの作業モデルについてほとんど、あるいは全く経験がありません。
* 最初に選ばれた開発者コミュニティのリーダーは、社内に広いネットワークを持っていません。
### 組織に働く力学
もし、企業がインナーソースの予算とキャパシティの面で初期のインナーソースコミュニティに大幅に投資していない場合、インナーソースへのコミットメントの信頼性は疑わしいと認識されるかもしれません。期待通りに実行されていないプロジェクトやイニシアチブに対する伝統的な管理文化を持つ企業の一般的な動きは、そのリーダーを交換することでしょう。コミュニティを巻き込むことなく、そして功績至上主義の原則に従わずに活動を行うことは、現在の企業文化とコミュニティ文化との間の摩擦を強調することにつながり、インナーソースへの企業のコミットメントをさらに弱体化させます。 インナーソースプロジェクトにおける価値の貢献は、従来のプロジェクト管理方法に慣れ親しんでいる多くのマネージャーにとっては明らかではありません。これらのマネージャーは、通常は非インナーソースプロジェクトから高い需要があるトップクラスの人物の1人を、作業時間のかなりの割合でインナーソースプロジェクトに割り当てる可能性が低くなります。 コミュニケーションは、コミュニティリーダーの日常業務のかなりの割合を占めています。同時に、担当者は初期開発の先頭に立つ必要があるでしょう。限られたキャパシティに直面して、経験の浅いリーダーは開発に集中し、コミュニケーションを怠る傾向があります。コミュニティリーダーが連絡を取りにくい場合や、時間不足のためにフィードバックや質問への回答が遅い場合、潜在的なコントリビューターが最初のコントリビューションをしてコミュニティにコミットするための障壁ははるかに高くなります。さらに技術的に経験の浅いリーダーは、企業で目立つトップパフォーマーと比べると、経験豊富なコントリビューターを引き付けて維持するのに苦労する可能性があります。 もしコミュニティが十分に速く成長し、十分なスピードを手に入れることができなければ、インナーソースの可能性を説得力を持って示すことができない可能性があります。 もし会社が伝統的な管理手法に慣れた経験豊富なプロジェクトマネージャーやラインマネージャーをコミュニティリーダーに選んだ場合、その人は功績至上主義で模範を示すのではなく、リソース配分、構造、報告ルートといった伝統的な管理テーマに焦点を当てる可能性が高いです。これは、開発者の目から見たインナーソースイニシアチブの信頼性を損ねることになります。
### ソリューション
以下のようなコミュニティリーダーを選択します。
* オープンソースの作業モデル、または類似のコミュニティベースの作業モデルの経験がある
* 自然なリーダーとして活動するために必要なソフトスキルを持っている
* 模範を示して指導し、コミュニティの功績至上主義において自分の立場を正当化することができる
* 優れたネットワーカーであること
* コミュニティーのメンバーにインスピレーションを与えることができる
* 経営陣と開発者の両方に効果的にコミュニケーションをとることができる
* コミュニティ活動の経営的な面を扱うことができる
コミュニティリーダーには、コミュニケーションや開発など、自分の時間の100％をコミュニティ活動に捧げることができるよう、権限を与えましょう。コミュニティ運営に変化をもたらす際には、コミュニティの意見に耳を傾ける必要があることを経営陣に伝え、理想的には、コミュニティが自らコミュニティリーダーを指名できるようにすることが望ましいです。
### 結果の状況
上記の能力を持つコミュニティのリーダーは、会社のインナーソースへのコミットメントを人前に出て体現することになります。彼のネットワーク内の他の同僚は彼のリードに従い、インナーソースに貢献する可能性が高くなります。
時間が経つにつれて、リーダーは、開発者の安定したコアチームを構築することができ、したがって、インナーソースプロジェクトの成功の可能性を高めることができます。 インナーソースの可能性について社内の十分な数のオーディエンスを納得させることによって、リーダーは企業文化をよりコミュニティ中心のものにする変革に大きく貢献することになります。
優秀で熱心なコミュニティリーダーを持つことは、インナーソースを成功させるための前提条件です。しかし、それは銀の弾丸ではありません。インナーソースには、予算、法律、財政、あるいはその他の組織的な課題など、コミュニティリーダーが取り組める以上の課題がたくさんあります。
### 事例
*Robert Bosch GmbH における BIOS*。Bosch社のインナーソースは、大半の場合、イノベーションを高めることを目的としており、かなりの割合で内部向けのプロダクトを扱っていました。このパターンは、資金不足のため、現在Bosch社では使われなくなりました。
### その他の呼び方
Dedicated Community Manager
### ステータス
* Structured
### 著者
* Georg Grütter (Robert Bosch GmbH)
* Diogo Fregonese (Robert Bosch GmbH)
### 謝辞
* Tim Yao
* Padma Sudarsan
* Nigel Green
* Nick Yeates
* Erin Bank
* Daniel Izquierdo
### Changelog
* **2016-11-06** - 1st review
* **2017-04-06** - 2nd review
### 翻訳の履歴
* **2022-06-01** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
* **2022-06-21** - レビュー [@hirotakatoya](https://github.com/hirotakatoya)
* **2023-06-18** - 最終更新
# 基本原則ガイダンスの文書化
### Title
基本原則ガイダンスの文書化
### Patlet
「オープンソースのベストプラクティスを組織内に適用する」という通常のインナーソースの説明は、オープンソースのバックグラウンドがない人々にはうまく機能しません。 解決策として、インナーソースの最も重要な原則を文書化し広く公開しましょう。
### 問題
この組織は、インナーソースをより大規模に展開しようとしています。この取り組み自体はオープンソース愛好家のなかで始まりました。現段階の目標は、オープンソースの経験がない人たちからの賛同を得ることです。その人たちに伝えるためのツールとして「オープンソースのベストプラクティスを適用する」という典型的なスローガンは最適ではありません。この伝え方では、そもそもインナーソースがなんであるか、また問題の解決のためにどのようなツールを使うべきなのかは伝わりません。結果として、組織におけるインナーソースの適用が遅くなることにつながります。 チームはインナーソースのゴールが何であるか、そしてどうやったら最適の実装方法を見出せるのかを場当たり的なアイデアをもとに解決しようと試みます。しかしそれはコントリビューターがチームの境界を越え始めたときに混乱を引き起こす結果にも繋がってしまいます。
### ケーススタディ
ある組織での初期の実験では、オープンソースコラボレーションのベストプラクティスが有益であることが示されました。次のステップは、オープンソースの深いバックグラウンドがないチームや個人にそのイニシアチブを移すことです。 そして今の目標は、インナーソースイニシアチブの目標と、これらの目標達成に向けた明確な道筋を明確に伝えることです。
### 状況
* インナーソースという言葉が社員の間で広がり始めています。
* イニシアチブ自体はオープンソースの愛好家の間で始まった取り組みでした。
### 組織に働く力学
* チームは、インナーソースの重要な側面が何であるかを正確に伝えるのに苦労しています。
* オープンソースの経験が不足している人々は、オープンソースのベストプラクティスを組織にもたらすことの意味を理解することができません。
* 日常的にインナーソースのベストプラクティスに従おうとするチームは、自分たちがやっていることが一般的なインナーソースの典型例に沿っているのかを判断するのに苦労しています。
### ソリューション
組織内でインナーソースの取り組みを推進する人は、オープンソースの深いバックグランドを持たず、インナーソースを直感的に理解できていないチームや個人を支援する必要があります。
以下の2つの分野を文書化することで、チームや個人に対して明確な情報を提供する必要があります。
1. **目的** - なぜ組織はインナーソースを採用するのか？
2. **原則** - どのインナーソースの原則は、これらの課題に対処するのに役立つのか？
以下のセクションでは、この2つの詳細について説明します。あなたの組織が目的と原則を文書化するために、このセクションはよい出発点になるでしょう。
#### なぜ組織はインナーソースを採用したいのか？
かつてよりインナーソースは、組織で発生する一般的な問題を解決するのに役立つことが証明されています。しかし幾多ある組織的な課題のうち、あなたの組織がインナーソースを用いて解決したい課題はなんでしょうか。その問題を特定するためには一般化するのではなく、組織の課題に一致するソリューションを正確に特定するようにしてください。できれば、目に見える変化を求めているチャレンジを特定するのが好ましいです。
他の個人や組織がインナーソースのベストプラクティスに従うことによって対処しているいくつかの課題があるので、見ていきましょう。
* 強力なオーナーシップを求める文化によって引き起こされる開発のサイロを減らすため
* 健全なコードの再利用を促進することにより、類似の問題の解決に費やす時間を短縮し、イノベーションの速度を向上させるため
* より良いクロスチームのコラボレーションによって開発速度を向上させるため
* 依存関係があるプロジェクトやチームの連携を、ワークアラウンドを開発したり、ただ単純に待つのではなくエンジニアリングにおけるボトルネックを減らすことによって解決するため
* 品質を向上させるため
* 従業員の幸福度を高めるため
* 新入社員の成功の数を増やす
* アクショナブルなドキュメントをつくる
#### どのインナーソースの原則がこれらの課題を解決するのに役立つのか？
チームがインナーソースがどのような問題に対処するのに役立つかをひとたび理解したら、次のステップは、これらの課題に対処するのに役立つ原則を説明することです。 基本的なオープンソース開発の原則に基づき、以下のガイドラインが成功に役立つと証明されています。
(1) コードは、組織内で透明性を持ってホストされなければなりません。 ソースコード、ドキュメント、プロジェクト開発に関連するデータは、組織内の誰もが利用でき、簡単に見つけることができる必要があります。
(2)機能リクエストよりもコントリビューション
プロジェクトのすべての関係者は、潜在的なコントリビューターとして扱われ、サポートされます。コントリビューションはリクエストではなく、提案にとどめましょう。 コントリビューション前にきちんと連携をしておくことにより、無駄な労力を省くことができます。 プロジェクトは摩擦を避けるためにコントリビューションのガイドラインを提供します。
(3) 失敗することは学習をするチャンスであるということ
組織全体で仕事が見えるため、どんなミスもメンバーに見えてしまいます。「ミスは何としても避けなければならない失敗」ではなく「学習のための機会である」という文化が確立されなければなりません。
(4) 口頭より文字で伝える
複数のチームにまたがるプロジェクトでは、潜在的に会議のスケジュールが異なるため、非同期でのコラボレーションを可能にする必要があります。インナーソースのプロジェクトのゴールは、新しいコントリビューターを集めることです。そのため潜在的な将来のコントリビューターがプロジェクトに参加するハードルを下げることが必要であり、セルフサービスでプロジェクトの進捗状況を追跡することができるようにしておく必要があります。プロジェクトに関連するコミュニケーションが同期的なコミュニケーションを介して行われる場合、議論された内容は、ドキュメンテーションのチャネルで透明化しておく必要があります - 最終的な意思決定はそのコミュニケーションチャネルでのみ決定されるべきです。 このことは副次的な効果として、プロジェクトに新しく参加する人にとって非常に価値のある受動的なベースドキュメンテーションにつながります。
(5) 書面によるアドバイスを永続的で検索可能なアーカイブに蓄積できるようにする
プロジェクトのすべてのコミュニケーション、特に決定事項やその決定に至るまでの議論はアーカイブされる必要があります。また、コミュニケーションは安定したURLで参照できるようにする必要があり、過去のコミュニケーションも、簡単に検索できる形で保存される必要があります。
ただし、2つの注意点があります。
1. これは構造化された文書に取って代わるものではありません。しかし一方で、構造化されたドキュメントを収集するための出発点として機能もします。
2. すべてを文書化し、組織全体がアクセスできるようにするというルールには例外があります。人に関する議論やセキュリティに関する議論は機密事項であり、人前で行うべきではありません。
(6) **トラステッドコミッター** に対するリワード
すべての貢献(ソースコード、ドキュメント、バグレポート、議論への意見、ユーザーサポート、マーケティングなど) は歓迎され、リワードの対象になります。プロジェクトをサポートする人は、[トラステッドコミッター](/ja/trusted-committer)としてプロジェクトに招待され、全てのトラステッドコミッターのリストは公開されます。
### 結果の状況
* 組織のメンバーは、インナーソースのベストプラクティスを適用することによって、どのような課題に対処することができるのかを理解しています。
* オープンソースの経験がないメンバーが、インナーソースプロジェクトの基本的な価値観や原則を理解することができます。
* オープンソースの経験がないメンバーが、自分たちが日々行っていることを、共通の価値観に照らして確認することができる。
* 組織の開発手法がオープンソースプロジェクトと類似しているため、組織のメンバーがオープンソースプロジェクトに参加しやすくなります。
### 事例
#### Europace AG
上記のソリューションに記載されているインナーソースの原則は、ほとんどが Europace の経験に基づいています。 詳細は[Europace のインナーソース原則](https://tech.europace.de/post/europace-inner-source-prinzipien/)(ドイツ語)をご覧ください。
#### GitHub
**目的**
GitHub ではしばしば、チームが自分の担当外の領域に機能を提供するモデルで作業をします。よくある例としては、セールスエンジニアリングが営業におけるブロッカー要素を排除するために機能を提供したり、緊急なニーズに対する特別なプロジェクトがあり、インパクトの強い機能をプロダクト全体に提供したり、チームが複数のエリアにまたがって機能を提供したりすることです。
**原則**
全体として、このドキュメントで説明されている原則は、オーナーとなるチームの技術的負債とサポートの負担を増加させないようにすることに焦点を当てています。
多くの場合、チームは責任範囲内のサポートとメンテナンスのコストのために遅れており、機能に貢献するための余裕がないため、チームにヘルプが求められています。しかし別のチームによって新機能にかかるサポートの負担や技術的負担が追加されることになると、所有するチームが新機能に取り組む時間がさらに短縮されることを意味するため、それらが正しく行われていることを確認する必要があります。 同時に、私たちはエンジニアが境界を越えて自由に仕事ができる会社を目指しており、ビジネスの優先事項では、コアオーナーシップ以外の分野にコントリビュートすることが求められることがよくあります。
これらの原則をまとめると、「見つけたときと同じか、それ以上の状態で残す」ということになります。
それを踏まえて、私たちが賛同する原則を以下に紹介します。
* 機能負債を抱えるようなMVP（Minimum Viable Product）は避ける。顧客からのフィードバックを得るためにMVPを出荷することは構いませんが、コントリビュートするチームはその機能セットを完成させることを約束しなければなりません。例えば、以下のようなことです。
* MVP を越えて、ほとんどの顧客を満足させるソリューションにするためのコミットメント
* 新機能の管理を完全にサポートすること (例: コマンドラインの操作のみを提供するのではなく、設定のための UI を提供する）
* APIのみを提供するのではなく UI と API の両方のインタフェースを提供する（またはその逆）
* クラウドとやサーバー環境での動作保証 (補足: GitHub Enterprise Server と GitHub Enterprise Cloud の両方で動く)
* 本番環境へのデプロイまで、またそれ以降も機能作業をサポートする
* インクリメンタルなロールアウトの連携
* サポートチケットをハンドルする
* 顧客からの(機能やバグに関する)フィードバックに対応するための時間をプランニングする
* 正しい方法で機能を構築する(技術的負債を作らない)
* プロダクトチームおよびエンジニアリングチームとの要件およびソリューションの合意
* 適切なアーキテクチャと設計
* 後のデータマイグレーションを避けるために、データが適切に保存されていることを確認する
* 適切なテレメトリの計測が行われていること
* 適切なテストカバレッジが確保されている
* クラウドおよびローカルの本番環境でサポートされている（セットアップ、設定、バックアップ/リストア、マイグレーションなどを含む）
* バグの修正
* ドキュメントの更新
**エンゲージメント**
エンゲージメントモデルを使用するのは、チームが責任範囲外の領域に機能を提供するときに、チームが実行できる具体的な手順を示すためです。 GitHubの一般的なエンゲージメントモデルは以下です。
* プロダクトオーナーから、機能のセッティングとロールアウトプランの承認を得る
* エンジニアリングオーナー(通常、エンジニアリングマネージャーとディレクター)から、非機能要件(テレメトリ、テストカバレッジ、マルチ環境テストとサポート) への対応を含むエンジニアリング設計の承認を得る
* 新規または変更された要件のレビューとともに、コードレビューを実施する。
#### Robert Bosch GmbH
**目的**
Bosch のインナーソース・イニシアチブ (BIOS: Bosch Internal Open Source) は、コラボレーション、学習、イノベーションを促進することに主眼を置いています。
**原則**
ボッシュは以下の原則を適用しました。
* **オープン性**: BIOS コミュニティへの参入障壁を可能な限り低くします。
* **透明性**: 徹底的に透明性を高め、仕事上の成果物、コミュニケーション、意思決定を社内の全社員と共有します。
* **自発性**: BIOSコミュニティに参加し、コントリビュートするかどうかの判断は、各人に任されています。社員は上司に言われたからではなく、自発的な動機で BIOS に参画すべきです。
* **自己決定**: BIOS コミュニティは、何に取り組むか、いつ取り組むか、どのようなツールやプロセスを使って取り組むかを自由に選択することができます
* **功績至上主義**: BIOSプロジェクトメンバーには、その功績に基づいて、つまりコントリビューションの質と量に基づいて権力が付与されます
オープン性、透明性、自発性の原則は、本質的な動機によって動く仲間の多様なコミュニティを成長させるのに役立ちました。功績至上主義は、多大な貢献をするための効果的な動機であることが証明されています。 自己決定により、コミュニティは限られた時間を最も効果的かつ効率的な方法でコントリビューションに使用することができました。
### ステータス
Structured
### 著者
* Isabel Drost-Fromm
* Georg Grütter
### 謝辞
* Zack Koppert - GitHub のアプローチを提供していただき感謝いたします。
### その他の呼び方
インナーソース減速の明示 - Explicit InnerSource Principles
### 翻訳の履歴
* **2022-06-02** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
* **2022-06-13** - レビュー [@kanazawazawa](https://github.com/kanazawazawa)
* **2023-06-18** - 最終更新
# スタンダード・ベース・ドキュメンテーション
### Title
スタンダード・ベース・ドキュメンテーション
### Patlet
インナーソースプロジェクトへの新しいコントリビューターは、誰がプロジェクトを維持し、何に取り組み、どのようにコントリビューションすればよいかを理解するのに苦労しています。`README.md`/`CONTRIBUTING.md` のような標準ファイルでドキュメントを提供することで、新しいコントリビューターのためのセルフサービスなプロセスを可能にし、よくある質問に対する答えを自分自身で見つけることができるようにします。
### 問題
あるチームは、新しく始めたプロジェクトや既存のプロジェクトをより広い組織で共有し、それに対するコントリビューションを受けたいと考えています。潜在的なコントリビューターは、しばしば迷ってしまいます。チームの好ましいコミュニケーションチャネルを特定できない。新しい機能が追加されることに意味があるのかどうか、すぐに判断することはできません。また現在、どの同僚が活発にプロジェクトをメンテナンスしているのかを正確に理解するのに苦労しています。
### 状況
プロジェクトは、インナーソースプロジェクトとして他の人と共有されることになります。他の人がプロジェクトが何であるか、また、どのようにコントリビュートするかを理解できるようにするために、プロジェクトはいくつかの基本的なレベルのドキュメントを提供する必要があります。これまでのところ、プロジェクトは、すべてのドキュメントまたはユーザーがセルフサービス方式でそれを試してみるだけでなく、コントリビューターが迅速にスピードアップするために必要な項目がいくつか不足しています。
### 組織に働く力学
* プロジェクトがインナーソースのプロジェクトになったのは、つい最近のことです。以前は、ユーザーは社内のみ、または個人的な対面セッションでオンボーディングされていました。同様に、プロジェクトで働く人々は、コントリビューターやリモートコントリビューターの数の増加に伴いスケールしない個人的なオンボーディングセッションを通過しました。その結果、セルフサービスの文書が不足しています。
* プロジェクトは、インナーソースプロジェクトとして新しく作成されました。しかし、ホストチームには、十分なインナーソースの経験がありません。その結果、彼らはどのような情報についてのガイダンスをドキュメントに含める必要があるのか、他の人がどこでそれを見つけることができるようにすべきか、どのような人に対してそのドキュメントを提供すべきなのかがわかりません。
* プロジェクトは、つい最近インナーソースプロジェクトになりました。ホストチームは、インナーソースに関して限られた経験を持っています。その結果として既存のドキュメントは、技術的な側面の多くに対応していますが、コミュニケーション、調整、透明性の高い計画を促進するために必要な情報をカバーしていません。
* プロジェクトは、ごく最近インナーソースのプロジェクトになりました。その結果、チーム内に存在する多くの暗黙の知識が書き留められることはなく、コントリビューターにとっても明らかではありません。
* ドキュメントの欠如は、潜在的なコントリビューターがセットアップをして作業を開始するのに長い時間がかかることにつながります。ドキュメントを作成する(そしてそれを最新に保つ)には、時間的な投資が必要です。たとえホストチームがドキュメントの欠如に関してコントリビューターに頼ったとしても、それらのコントリビューションはレビューする時間を必要とします。
* プロジェクト・メンバーは、使い始めの質問に答えるために多くの時間を費やしています。しかし、サポートに関する質問の包括的なデータベースを維持することは、多くの時間と労力を必要とします。
* ソースコードのフォーマットやソフトウェアのパターンについて、組織内の異なるチームが異なる基準を持っています。その結果、コントリビューションはしばしば、大部分または全体が書き直されてしまうこともあります。そのすべてを標準化し、その標準を強制するには、多くの時間と労力が必要になるケースがあります。
* このように、説明と書き直しを繰り返す作業は、インナーソースアプローチの有用性を低下させます。
* 余分な仕事と書き直しのための遅延による頻繁なエスカレーションは、ビッグチーズ問題(\*)に発展します。 (\*ビッグチーズ問題について-和: ビッグチーズとは「お偉いさん」のことを指します。現場がわからない上の人同士でコミュニケーションをとることによる問題をさします。例として、政治的にコードベースへの統合が実施されることで、例えそのコードが要件を満たしていなくても統合しなければいけない状況が起こり、コントリビューションを受け入れる側が多くの作業をかかえることになります)
### ソリューション
新しいコントリビューターのために、より明確なドキュメント作成の作業に取り組む。このドキュメントを作成する際の目標は、よくある質問に標準的なドキュメント形式で回答することで、可能な限りセルフサービスのプロセスを開始できるようにすることです。
#### README.md
まだ存在しない場合は、あなたのプロジェクトの `README.md` を作成してください。それには以下の内容が含まれていなければなりません。
* [プロジェクトのミッション](https://producingoss.com/en/producingoss.html#mission-statement) できるだけ簡潔な形式にしてください。これは、プロジェクトの目的が何であるかに答え、提案された機能がプロジェクトの範囲内にあるかどうかを、コントリビューターが最初に推測できるようにする必要があります。
* プロジェクトで実働をするユーザーに向けた "Getting Started" セクション。プロジェクトの成果物をどのようにセットアップし、統合するかを説明し、初めてのユーザーのためのファーストステップに関する説明も必要です。
* プロジェクトユーザーのための詳細なドキュメント - またはそれへのリンク
* プロジェクトを修正するために必要なドキュメント - またはそれへのリンク
* プロジェクトにコントリビュートする方法に関するドキュメント - またはそれへのリンク
* プロジェクトがどのようなアクセス可能なパブリックもしくはアーカイブのコミュニケーションチャネルを用いているかを説明する "Getting involved" セクション。このリンクには、プロジェクトのイシュー・トラッカーへのリンクだけでなく、さらなるディスカッションメディアへのリンクも含めるべきです。
* プロジェクトを支える [トラステッドコミッター](/ja/trusted-committer)が誰であるかを説明する "Who we are" のセクション。これらの人々と個人的に連絡を取る代わりに、上記の公開コミュニケーションチャンネルを使用して連絡を取るべきであるという説明も必要です。
* プロジェクトが貢献者を信頼されるコミッターにするための基準（もしそのような道があるならば）の説明です。
* コントリビューターがそのプロジェクトにおけるトラステッドコミッターになるための基準及び、そのパスが存在するならばそのパス
#### CONTRIBUTING.md
コントリビューションを行うための手順の説明が複雑すぎる場合は、`CONTRIBUTING.md` というドキュメントを別に作成します。この文書では、コントリビューターが過去によく聞かれた質問に答えるようにします。前もって包括的なドキュメントを提供する必要はありません。むしろ、コントリビューターが必要としていることが証明された情報を共有しましょう。おそらく、以下のトピックのうちの1つ以上に触れることになるでしょう。
* プロジェクトのソースコードをバージョン管理からチェックアウトする方法
* プロジェクトに変更を加える方法 (コーディングガイドラインに関する情報を含む可能性があります)
* プロジェクトをビルドする方法
* 上記の修正が新しいバグを引き起こしていないことを確認するためのテストの実行方法
* プロジェクトにあなたの修正をサブミットする方法
* 修正が行われた場合、変更が取り込まれるまでに必要な所要時間に関する情報
様々なオープンソースプロジェクトにおいて、 `README.md` の書き方や、 `CONTRIBUTING.md` ファイルにどのような情報を含めるべきかについての良い例がたくさんあります。[How to write a readme that rocks](https://m.dotdev.co/how-to-write-a-readme-that-rocks-bc29f279611a), [Open Source Guide from GitHub](https://opensource.guide/) や書籍 [Producing Open Source](https://producingoss.com/en/producingoss.html)などのページには、どのような情報を提供すべきなのかについての貴重な情報が掲載されています。Producing Open Source には、良い README を書くための章はありませんが、[Getting Started chapter](https://producingoss.com/en/producingoss.html#starting-from-what-you-have) には、ホストチームのメンバー、ユーザー、コントリビューターが必要とするもののかなり広範なリストがあります。インナーソースのプロジェクトは、おそらく最初からこれらの側面のすべてをカバーする必要はありませんが、リスト自体は README.md がカバーできるものを想起するために有効です。 このパターンには、すぐに始められるように、2つの非常に基本的なテンプレートが付属しています。[README-template.md](/ja/appendix/sono/readme-template) と [CONTRIBUTING-template.md](/ja/appendix/sono/contributing-template) をご参照ください
### 結果の状況
* コントリビューターがスピードを上げるまでの時間が大幅に短縮されます
* [トラステッドコミッター](/ja/trusted-committer) が初歩の質問に答える時間が大幅に短縮され、他の作業に時間を割くことができるようになります
* 誤った理解や、同じ方向を向いていないことによるエスカレーションが大幅に削減されます
### 事例
* Europace AG - こちらのブログをご覧ください [InnerSource: Adding base documentation](https://tech.europace.de/post/innersource-base-documentation/)
* Paypal Inc.
### 著者
* Isabel Drost-Fromm
### その他の呼び方
Provide standard base documentation through a README
### ステータス
* Structured
* Drafted in December 2019.
### リファレンス
* [README-template.md](/ja/appendix/sono/readme-template) and
* [CONTRIBUTING-template.md](/ja/appendix/sono/contributing-template)
### 翻訳の履歴
* **2022-06-01** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
* **2022-06-13** - レビュー [@kanazawazawa](https://github.com/kanazawazawa)
* **2023-06-18** - 最終更新
# コミュニケーションツーリング
### Title
コミュニケーションツーリング
### Patlet
インナーソースのプロジェクトは、開発チームの外で使用されていますが、ユーザーはヘルプを得たり、プロジェクトチームと連絡を取ったりするのに苦労しています。 このアイデアは、ディスカッションが可視化され、アーカイブされ、検索可能になることを可能にする標準的なコミュニケーションツールを設定し、文書化することです。
### 状況
チームは別のチームのコンポーネントに依存しており、そのコンポーネントにコントリビュートしたいと思いっています。コミュニケーションは文書で行われる場合でも、1対1で行われています。
### 問題
チームは、そのコンポーネントのダウンストリームユーザーからのコントリビューションを受け入れることができます。しかし、調整とコミュニケーションはアドホックな方法で行われ、支離滅裂な情報が共有されたり、回答が遅れたり、コントリビューターが明確な回答を受け取る前に複数のホストチームのメンバーに問い合わせをしたりすることがあります。
### 組織に働く力学
* ホストチームはコントリビューションを受けることに興味があり、コントリビューターを指導することに積極的です。
* チームは口頭でのコミュニケーション文化が強く、プロジェクト特有の非同期コミュニケーションチャンネルを設定する経験は浅いです。
* コミュニケーションチャネルは、連絡を取るべき特定のグループと連携しているかもしれませんが、コミュニケーションの目的によって連携しているわけではありません。
### ソリューション
ホストチームは、社内で公開され、アーカイブされ、検索可能で、リンク可能なコミュニケーション・チャネルを提供することの利点を明確にする必要があります。
インナーソースプロジェクトのコミュニケーションチャネルを合理化する際の目標は、特定の人々の周りではなく、トピックの周りのコミュニケーションを調整することであるべきです。
* プロジェクトは、ホストチームのメンバーだけでなく、ダウンストリームユーザーやコントリビューターもフォローできるように、構造化されたコミュニケーション、意思決定、進捗追跡が透過的に行われる独自のイシュートラッカーを持っている必要があります。
* プロジェクトは、あまり厳密でない構造を持つ1つ以上のディスカッションチャンネルを持つべきです。一般的に、これはメーリングリスト、オンラインフォーラム、あるいはアーカイブされたチャットチャンネルになります。通常、プロジェクトのためのチャンネルは1つで十分ですが、トラフィックが増えすぎた場合は、プロジェクトの使用に関する議論とプロジェクトの開発に関する議論を分けることが有用です。
* さらに、プロジェクトは[トラステッドコミッター](/ja/trusted-committer) の間で機密のやりとりができるプライベートチャンネルを一つ持つべきです - たとえば、ホストチームにさらにトラステッドコミッターを追加するなどです。このチャンネルは、デフォルトではオープンで、非常に稀な状況下でのみ非公開になるように、細心の注意を払って使用されるべきです。
文章での共有のチャンネル以外でもコミュニケーションは可能ですが、できるだけ多くの情報を非同期チャンネルにつなぐべきです。
すべてのコミュニケーション・チャンネルはプロジェクトの `README.md` で文書化されるべきです。ホストチームのメンバーは、個人的に受けた質問を公式のコミュニケーションチャンネルに戻すよう努力する必要があります。
### 結果の状況
公式の非同期コミュニケーションチャネルを設定し、一貫して使用することで、同様の質問が再び出てきたときに再び参照できる受動的なドキュメントのベースレベルを作成することができます。
コミュニケーションがオープンに行われることで、他の人も簡単にプロジェクトの進捗を追うことができ、積極的に貢献することができます。また、他の参加者が潜んで読んでいることで、参加するための障壁が低くなり、コントリビューションを受ける可能性が高くなります。
質問に対する回答が公開されることで、より多くの人が自分の視点を追加し、全体像を把握することができます。これは、ホストチームのメンバーだけでなく、プロジェクトのユーザーも含みます。
非同期チャネルでコミュニケーションをとることで、タイムゾーンや会議のスケジュール、チームのルーチンなど、異なるスケジュールの参加者がプロジェクトに有意義に貢献することができます。
このようなチャンネルで質問に答えることは、他のチームメンバーがそれを聞いて追加情報を提供できるだけでなく、同じ質問をした他のユーザーが前回の回答を見る(または後で見つける)ことで、説明を繰り返す必要性を低くすることを意味します。
### 事例
* Europace AG
* Paypal Inc.
### 著者
Isabel Drost-Fromm
### ステータス
* Structured
* Drafted in December 2019.
### 翻訳の履歴
* **2022-06-06** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
* **2022-06-13** - レビュー [@kanazawazawa](https://github.com/kanazawazawa)
# イシュートラッカーの使い方を多様化する
### Title
イシュートラッカーの使い方を多様化する
### Patlet
インナーソースのホストチームは、計画や進捗だけでなく、変更の背景も透明化することができていません。これは、プロジェクトのイシュートラッカーのユースケースを増やし、ブレーンストーミング、実装の議論、機能設計にも使えるようにすることで解決することができます。
### 問題
あるチームが、組織内の多くのチームが依存するコンポーネントを開発しています。このチームは、未解決のバグや機能要求を追跡するために、標準的なイシュートラッキングシステムを使用しています。しかし、各エントリのコンテキストは非常に限られています。その結果、潜在的なコントリビューターは、各課題がどのような変更について話しているのかを知る術がありません。
### 状況
インナーソースのプロジェクトツールはすべてセットアップされています。しかし、プロジェクトのイシュートラッキングシステムは、主に進捗の共有のために使用されます。インナーソースプロジェクトでは、リモートでの非同期通信を容易にするために、イシュートラッカーが使用できるユースケースは他にもたくさんあります。
### 組織に働く力学
* コントリビューターは、自分たちが必要としている機能がすでにロードマップにあるかどうかを理解したいと思っています。しかし、イシューには多くの文脈が欠落しており、既存のイシューがコントリビューターのニーズに合致しているかどうかを判断することは不可能です。
* その結果、多くの重複したイシューがオープンされ、ホストチームがそれに対処しなければならなくなります。
* オープンなイシューの文脈は非常に限られているため、コントリビューターはすでにオープンになっている簡単なイシューを実装して、ホストチームを助けることができません。その結果、多くの作業がホストチームの手に委ねられることになります。
* 口頭でのコミュニケーションに重点を置いているため、数ヶ月後や数年後に、なぜとある機能が実装に選ばれたのかを見極めることができません。その結果、リファクタリング、特にコンポーネントの簡略化は、プロジェクト考古学そのものとなり、議論されたことを覚えている人たちの脳を巻き戻して考えるしかなくなります。
### ソリューション
純粋なソフトウェア開発だけでなく、新機能の企画段階でも「言葉より文字」の哲学を受け入れましょう。
* バグ、計画された機能、機能のアイデアについては、それぞれ別のイシューを作成します。それぞれのイシューには、外部の潜在的なコントリビューターが文脈を理解できるように、可能な限り多くの情報を含めるようにします。理想的には、特に簡単な変更については、外部のコントリビューターが問題の機能を実装することでホストチームをサポートできるよう、十分な情報を含めることです。
* 質問するためのチャネルとして、イシュートラッキングシステムを利用することができます。これは、ユーザーの質問に対応するための他のコミュニケーション源が不足している場合に、特に有用です。
* 異なる目的で使用されるイシューを区別するために、タグやカテゴリーを使用します。
* 非同期でブレーンストーミングを始めるには、アイデアを集めるためにイシューを開きます。議論が落ち着いてきたら、このイシューで指摘されたことを別の文書にまとめます。それをプルリクエストとして投稿し、まだ説明が必要な個々のポイントについて掘り下げます。出来上がった文書は、他の適切なチャンネルで結果を公表したり、将来の参考資料として使用したりすることができます。
* ほとんどのイシュートラッキングシステムで、イシューのテンプレートを作成することができます。バグレポートに必要な情報を集めるだけでなく、他の用途でどのような情報が必要なのかのヒントも含めて活用しましょう。
### 結果の状況
* プロジェクトのイシュートラッキングシステムをコミュニケーションに活用することで、外部のコントリビューターがプロジェクトの動向を把握し、何をコントリビュートすべきかをより的確に判断することができるようになります。
* 文書によるコミュニケーションに重点を置くことで、ホストチームのメンバーがリモートで参加できるようになった。
* 常に文書でコミュニケーションすることで、プロジェクトの決定事項に関する受動的な文書が副産物として蓄積され、特別な注意を必要としなくてすみます。
* 公開コミュニケーションチャネルを一貫して使用することで、より多くの人間が議論に参加することになります。つまり、質問に答えたり、未解決の問題を指摘したり、計画中の機能の欠点を指摘したりできる、より多くの知識を持った人間を巻き込むことができるようになります。
* ディスカッションを公開の場に移すことで、将来のコントリビューターとなる可能性のあるメンバーがが、プロジェクトに参加する必要が生じるずっと前に、プロジェクトに潜り込み、フォローし、慣れ親しみ、プロジェクトのやり方を学ぶ機会を作ることができます。
### 事例
* Europace AG - ブログをご覧ください [Issue Use Cases](https://tech.europace.de/post/using-issues-for-asking-questions-and-tracking-work/)
### 著者
Isabel Drost-Fromm
### ステータス
Structured
### 翻訳の履歴
* **2022-06-06** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
* **2022-06-13** - レビュー [@kanazawazawa](https://github.com/kanazawazawa)
# クロスチームプロジェクト評価
### Title
クロスチームプロジェクト評価
### Patlet
会社の収益に直接的な影響を提供していないクロスチームのインナーソースプロジェクトの価値を評価して社内に売り込むことは困難です。 ここでは、あなたのプロジェクトの価値を明確に表現し、それを大きくするためのデータ駆動型の方法を紹介します
### 状況
* あなたは、社内のプラットフォームとして機能するクロスチームを担当しています。
* クロスチームプロジェクトは、企業の収益に直接的な価値をもたらすものではありません。
### 問題
チーム横断的なプロジェクトは、会社に非常に大きな影響を与える可能性がありますが、データに基づいた形で表現することは困難です。 その結果、真の価値を生み出さないプロジェクトを追求してしまったり、本来なら大きな価値を生むはずのプロジェクトに資金を投入しなかったりすることがよくあることはご存知の通りでしょう。
### 組織に働く力学
* プロジェクトが資金を得るためには、会社のリーダーシップに価値(客観的または主観的)を示す必要があります。
* チーム横断的なプロジェクトの価値は、複数の最終事業部門に分散しています。
* このように分散しているため、クロスチーム・プロジェクトの価値を直接測定することは困難になっています。
### ソリューション
チーム間のプロジェクトを評価する方法のパターンとモデルを設定します。このようなモデルは、会社にとって価値の高いコラボレーションに焦点を合わせて拡大するために必要なツールを提供します。 チームをまたがるすべてのプロジェクトにおける価値の核となるのは、離れるよりも一緒に多くのことを成し遂げることができるという考えかたです。 チーム間の取り組みに価値を与えることは、一緒に行われていることの量を定量化するための演習にもなります。 生産性に関する実際の差は、ドメインやプロジェクトによって異なります。ここではモデルを作成して計算できる一般的なプロセスがありますので以下で紹介します。
#### 解説
まずあなたのドメインにおける特定分野の専門家からなる小さなチームを編成します。その専門家チームで、プロジェクトの成果物を利用するそれぞれの人について、以下の4つのことを見積もってください
* プロジェクトの成果物をユーザーが使うのにどのくらい時間がかかりますか？
* そうでなければ、あなたのプロジェクトのアウトプットの価値をユーザー自分たちのものにするために、どれくらいの時間がかかりますか？
* プロジェクトの成果物の何パーセントが、実際に彼らにとって有用ですか？
* 自社で開発したソリューションのメンテナンスに、継続的(理想は使用ごと)にどれだけの時間を費やすことになりますか？
これらの見積もりを行う場合、アクティビティにかかる時間を正確に知ることは不可能です。また、それはあなたの目標ではありません。 正確さではなく、これらの見積もりに最悪の場合の限界を設定するように努める必要があります。専門家のグループがお互いに「どれくらいの時間がかかるかは正確にはわかりませんが、少なくともこれだけだということには同意できます」と言うことができるという考えです。 具体的には、プロジェクトのアウトプットを消費するための最大の妥当な時間と、消費者が独自のソリューションを自分のものとして使用、および維持するための最小の妥当な時間を見積もる必要があります。
自前でソリューションを開発する(ホームロール)場合のコストについては、一つ注意点があります。ソリューションの自作にかかるコストは、必ずしも共有ソリューションの作成コストと同じとは限りません(実際、非常にまれです)。 同じ機能であれば、チーム横断的な共有ソリューションの構築に必要なモジュール性と品質により、一度だけ使用する迅速でハードコードされた実装よりも明らかに高い投資となることがよくあるのです。
#### 数式
ワーストケースを設定すると、単純な計算式でチーム横断的なプロジェクトの成果物を評価することができます。
```
[節約した時間] - [投資した時間]
([新しいオンボーディングの数] * [自分のものにするためのコスト] * [成果物のうち使える機能の割合] + [利用数] * [利用ごとのメンテナンスコスト]) - ([新しいオンボーディングの数] * [オンボーディングのコスト])
[新しいオンボーディングの数] * ([自分のものにするためのコスト] * [成果物のうち使える機能の割合] - [オンボーディングのコスト]) + [利用数] * [利用ごとのメンテナンスコスト]
```
#### 解説
一見このプロセスには厳密さがあるように見えますが、チーム横断的なプロジェクトの成果を正確に測定する方法を提供するものではありません。 ただし、実際には、この作業に資金を提供する方法を適切に決定するためのフレームワークが提供されます。 上記の説明に従って適切で妥当なデータを取得したら、少なくとも次の3つのレベルのうち、小さい方までプロジェクトを実行するための専用の開発時間に資金を提供する必要があります。
1. 上記の式によって節約された実際の時間。 公式が実際に節約された時間数よりも少ない数を生み出すと私たちは皆確信しています。そのため、その時点までのプロジェクトへの資金提供はあなたにとって確実な勝利であると確信することができます。
2. チーム間のプロジェクトへのインナーソースのコントリビューションをサポートするためにかかる時間。コントリビューターは、一度限りのワークを提供することが多いでしょう。そのワークを共有の場所に持っていくための時間に投資することには価値があります。
3. あなたが心地よく進められるものなら何でもかまいません。評価式を持つことの意図的な副次効果として、ユーザーに価値を提供する重要ポイントの測定を自然に強制することができます。
それらの測定値を理解し、そのまま使うことで、プロジェクトの価値を直感的に理解することができます。 この評価手法が正確さに欠けることを心配される方もいらっしゃるかもしれません。このプロセスでは正確な測定値が得られなくてもかまいません。ただ、以下2つの目的を達成するのに十分な精度があることが重要です。
1. チーム横断的な取り組みを組織し、資金を提供している人々に、起こっていることの価値を表す手段を提供します。
2. チーム横断的な取り組みのうち、どの分野がより高い価値を持ち、優先的に追求されるべきかを関係者が知ることができるようにします。
実際には、これらの評価が現実と一桁以内の誤差である限り、これらの目的を満たすのに十分な精度であると言えます。 ドキュメント冒頭の「**問題**」で述べたような場当たり的な評価（およびその結果生じる影響）に比べ、現場での結果は頭一つ抜きん出たものになるでしょう。
### 結果の状況
* チーム横断型プロジェクトの価値と資金調達について、リーダーシップと議論するためのデータ駆動型の手段になります。
* クロスチーム・プロジェクトに関する主要な指標を素のデータの形で計測することができます。
* クロスチーム・プロジェクトがどのように価値を提供するかを定義することで、実際に企業にとってより大きな価値を生み出すことにつながる傾向があります。
* 一般的に成功したプロジェクトの周辺でバズが生まれます。
### 事例
* Nike
### ステータス
* Structured
* Proven in multiple domains.
### 著者
* Russ Rutledge
### Acknowledgement
* Jeremiah Wright さんは、クロスチーム・プロジェクトを、開発者の時間という"通貨"を扱う社内ビジネスとして考えるように教えてくれました。
### 翻訳の履歴
* **2022-06-03** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
* **2023-06-18** - 最終更新
# コントリビューションの功労を称える
### Title
コントリビューションの功労を称える
### Patlet
インナーソースのコントリビューションの後、その時間と努力に対してコントリビューターに感謝することは重要です。 このパターンは、コントリビューションを効果的に認めるだけでなく、コントリビューターや他の人たちのさらなる関与を引き出すためのガイダンスを提供します。
### 問題
プロジェクトにコントリビュートしてくれたインナーソースのコントリビューターに対して、どのように感謝の気持ちを表せばいいのでしょうか? 感謝の気持ちを伝えることを忘れてしまったり、十分な効果や誠意を示すための言葉や場所がわからなくなってしまったりすることがあります。 賞賛と感謝は、楽しさやコントリビューターとそのマネージャーのモチベーションを維持し、継続するための簡単で使いやすい方法です。 このパターンがあれば、簡単に実行でき、メッセージが明確かつ誠実に伝えることができるようになります。
### 状況
* あなたはインナーソースプロジェクトの [トラステッドコミッター](/ja/trusted-committer) あるいはメンテナーです。
* あなたは、コントリビューターのコミュニティを大切にし、それを維持・発展させたいと考えています。
### 組織に働く力学
* あなたは忙しいので、賞賛や感謝のようなソフトタッチを忘れがちです。
* あなたは、人付き合いが苦手だったり、口下手だったりするかもしれません。
* 仕事への満足度やキャリア開発には、仲間からの評価が非常に重要です。
### ソリューション
他人から認められることは、誰にとっても気持ちの良いことです。 プロフェッショナルな場では、認知度の向上は、影響力や成長への道筋にもなります。 誰かがあなたのインナーソースプロジェクトにコントリビュートしたときはいつでも、誠実で適格な「ありがとう」の言葉でその人を認めてあげてください。
自明でないコントリビューション(すべてのコードコントリビューションと多大な時間的コントリビューション)に対しては、以下の方法でお礼を言いましょう。
(1) あなたがプロジェクト活動を組織しているチャットの場所 (例: *Slack*) で、その人の名前を呼びます。 その人が何をしたかを皆に知らせ、公に感謝します。
例 (意訳):
> みなさん、@andrew\.clegg が *rcs-viewer* を *hebo-client* の最新版 () にアップデートしてくれました！ Andyさん、ライブラリを最新に保つ活動をお手伝いしていただきましてありがとうございます！！
(2) 彼らとそのマネージャー(cc'd)に、個人的にお礼のメールを送ります。 コードのコントリビューションでは、しばしばマージ通知メールを転送するだけでよい場合があります。
例 (意訳):
> Andy さん、先日はアップデートを手伝っていただきまして本当にありがとうございました！ Andy さんの活動の中で修正していただいた *rcs-viewer* は、おかげさまでより良いものになり、組織の皆さんがその恩恵を享受しています。 お忙しい中とは存じますが、このような配慮があるからこそ、RCSプロジェクトは会社全体のために機能しています。 改めまして、誠にありがとうございます！
### 結果の状況
このようなフィードバックは、コントリビューターに素晴らしい気持ちを残し、また貢献しようと戻ってくることにもつながります。 仲間の前でも、直属の上司の前でも、幅と深さの両方の側面の感謝の言葉を組み合わせることで、認めてもらうことができます。 またその上司は、他の直属の部下に同じことをするよう促す適切な状況を模索します。 さらに、インナーソースプロジェクトの意識は、以前はチームの使用とそれとの関わりを知らなかったかもしれないマネージャーにも広がります。
一つ注意点があります。 あなたの言葉は、彼らがしてくれたことに対して、あなたが心の中で感じている心からの感謝からきていることを確認してください。 褒め言葉も、その人のレベルに合わせて冗長になりすぎないようにしましょう。 やり過ぎると、不誠実で機械的な印象を与え、せっかく声をかけた意味がなくなってしまいます。
### 類似パターン
* *Just Say Thanks* ([*Fearless Change*](https://fearlesschangepatterns.com/)より)
### 事例
* Nike (multiple projects)
### ステータス
* Structured
### 著者
* Russ Rutledge
### 謝辞
* [Todd Lisonbee](https://github.com/tlisonbee) for encouraging to "keep it real".
* [Isabel Drost-Fromm](https://github.com/MaineC) for [this extra explanation](https://youtu.be/h3MPewsk5PU?t=357) of a "qualified" thank you.
### 翻訳の履歴
* **2022-06-06** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
* **2022-06-15** - レビュー [@hirotakatoya](https://github.com/hirotakatoya)
* **2023-06-18** - 最終更新
# 共通要件
### Title
共通要件
### Patlet
共有リポジトリにある共通のコードは、それを使いたいすべてのプロジェクトチームのニーズを満たしていません。これは、要件の調整とリファクタリングによって解決されます。
### 問題
共有リポジトリにある共通コードは、それを使いたいすべてのプロジェクトのニーズを満たしていません。
### 状況
* すべてのプロジェクトがアクセスする共有リポジトリがあり、多くのプロジェクトが共通のコードを使おうとしています。
* 誰かが(またはどこかのプロジェクトが)最初にコードを書き、リポジトリにコントリビュートしました。
* 共通コードは、どのプロジェクトにおいても、成果物全体のうちのわずかな割合になります。
* 各プロジェクトには、それぞれ独自の納期、成果物があり、別の顧客がいます。
* このパターンは、これらの状況のいずれにも当てはまります。
* **強いコードへのオーナーシップ**: つまり、共有リポジトリへのすべての変更は、リポジトリの所有者によって承認されなければなりません。
* **弱いコードオーナーシップ**: つまり、誰も本当にコードを所有していません。
* **慈善のスポンサー**が**いない**: つまり、インナーソースの方法で共通コードを整理するためのリソースを提供する組織や幹部がいません。
### 組織に働く力学
コードを利用可能にしたプロジェクトには、ひとつのニーズがあります。そのニーズは、一部の受けての組織が望んでいるものと似ていますが、まったく同じではありません。コードに関する要件は、実際の顧客のニーズから導き出される必要があります。
異なる顧客のニーズが非常によく似ることはよくありますが、顧客によって表現が異なったり、重みが異なったりすることがあります。例えば、ある顧客はとある方法で結果を表示し、他の顧客は逆の順序で結果を表示することを望むような場合があります。両者の変換は簡単ですが、一方のケースで追加のコーディングが必要になり、その結果として、結果を計算するモジュールを両方の顧客で再利用することができなくなります。
多くの顧客は、サプライヤーに何が必要かを知るための手助けを望んでいます。この会社では、多くの「システムエンジニア」が製品の要求事項を書いています。これらの要件は、製品の開発を導くために顧客のニーズを抽出したものであると考えられています。コードの再利用は、会社の時間とお金を節約するための重要な目標になっています。
多くの顧客は、サプライヤーが必要なものを知るのを手伝ってくれることを望んでいます。同社には、製品の要件を作成するための多くのシステムエンジニアがおり、それらの要件は製品開発の指針となる顧客ニーズの抽出物であるとされています。コードの再利用は、会社の時間とお金を節約するための重要な目標です。
### ソリューション
この問題を解決するには、2つの側面があり、並行して行う必要があります。
1. あるプロジェクトの要件を満たすコードが、他のプロジェクトのニーズも満たすように、プロジェクトの要件を調整する
2. コードをリファクタリングして、多くの使用プロジェクトが要件に同意できるような小さな断片にする。
さらに、サプライヤーに要件の解明を助けてほしい顧客を活用します。 コンポーネントを変更するのではなく、顧客との交渉中に要件の調整を行い、顧客の要件に影響を与えます。 上記の例では、サプライヤーは両方の顧客が同じことを望んでいることを認識できるように支援し、同じ形式で結果を受け入れることに同意すれば、すべての人の労力(およびお金)を節約できます。
### 結果の状況
これには、要件の変更について顧客と交渉する必要がある場合があります。そして、変更には要件を調整するために営業チームと製品マネージャーの関与が必要になる場合もあります。また、顧客は変更の同意の代わりに、割引などのインセンティブが必要になる場合があります。
これに関連する課題(新しいパターンの可能性)として、インナーソースを採用しているとある企業で報告されている「循環型ストーリーライティングの試行」があります。 これは、端的に言うと以下のようなことです。
* 開発者は、ある方法で問題を解決するためにストーリーを書きます。
* プログラムマネージャーはそのストーリーを自分たちのニーズをよりよく表現するために書き直します。しかし、開発者のもとに戻ってきたときには、開発者はそれが自分たちが最初にやりたかったことだと認識しておらず、そのため実装に躊躇してしまいます。
* このパターンの解決策は、開発者やプログラムマネージャーの陣営だけでなく、プロジェクト全体でストーリーの修正が理解されるように、プランニングの際により多くの人を巻き込むことが挙げられます。
### 事例
* 大手通信事業者
### ステータス
* Structured
### 著者
Robert Hanmer
### 謝辞
* Manrique Lopez
* Daniel Izquierdo
* Tim Yao
* Sebastian Spier
### 翻訳の履歴
* **2022-06-02** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
* **2023-06-18** - 最終更新
# サービス対ライブラリ
### Title
サービス対ライブラリ
### Patlet
DevOps環境のチームは、サービスのダウンタイムに対応する責任が誰にあるのかが曖昧になるため、チームの境界を越えて共通のコードベースで作業することに消極的になる場合があります。解決策としては、同じサービスを独立した環境で展開し、サービスダウン時のエスカレーション・チェーンを別々に構築するか、多くの共有コードを1つのライブラリに集約し、その上で共同作業を行うことが挙げられます。
### 問題
チームがDevOps環境で作業しているとき、開発者は機能をエンドツーエンドで担当することになります。顧客からデプロイメント、メンテナンス、サポートに至るまでです。このことは、チームの境界を越えて作業する際に課題となります。エスカレーションチェーンは、どちらのチームでも発生するエラーに対して同じではないかもしれません。ソースコードとデプロイメントを結合すると、エラーが発生した場合に誰がオンコールサポートの責任を負うのかという疑問がチームに残ります。その結果、要件に大きな重複がある場合でも、チームは協力し合うことに消極的になってしまいます。
### 状況
* チームはマイクロサービス環境で働いています。
* チームは完全に機能する DevOps チームによって編成されています。各チームは、メンテナンス、オンコール、カスタマーサポートを含むエンドツーエンドのコントリビューションに責任があります。
* あるチームは、他のチームが構築した既存のサービスとよく似たサービスを下流の顧客に提供することを任務としています。
### 組織に働く力学
* 組織的なエスカレーション経路は、各チームで異なる可能性があります。
* 各チームのメンバーは、自分たちの顧客に影響を与えないエラーのオンコールサポートに応じないことがあります。
* 同じ種類のエラーでも、チームや顧客との関係によって SLA の定義が異なるため、深刻度レベルが異なる場合があります。
* チームによって、セキュリティや規制の制約が異なる場合があります。
### ソリューション
ソースコードとデプロイメントの責任を切り離します。両チームは、重複と相乗効果がある場所を正確に特定するために働きます。
共有されたソースコードのみが、責任を共有したインナーソースプロジェクトの一部として保持されます。共有ソースは、すべてのテストコード(可能であれば統合テストを含む)と、コントリビューションの検証を容易にするために可能な限りCIパイプラインを含むという点で、首尾一貫している必要があります。
設定とデプロイのパイプラインを、実際のビジネスロジックから切り離します。 共有したチーム用に、サービスの2つめのデプロイメントを確立します。
共通基盤を、両チームで使用するライブラリとして扱い、コードの所有権を共有します。
デプロイメント設定をインナーソースポートフォリオの別プロジェクトとして含めることで、チームが議論/共同作業を行ったり、新しいチームがそれをコピーしたりすることができるようになります。
### 結果の状況
チームは積極的に協力し、ビジネスロジックを実装する作業を共有することで利益を得ることができます。
ある環境で動作するように特別に構築されたサービスが、特定のビジネス要件に基づき、より一般的なソリューションに変換されます。
両チームは、それぞれのエスカレーションポリシーと展開設定を知ることができ、自分たちの設定に対する改善点を見出すことができる可能性があります。
共有されたソースコードに変更が必要な可能性が高まり、実装を改良、改善、最適化する機会がより頻繁に発生するようになる。
リリースのパッケージング、遠隔測定、ヘルス/レディネス エンドポイントなど、運用の標準化を段階的に進めることができるようになります。
### その他の情報
このパターンに関連するものとして、上記を解決するために異なるアプローチをとる[30日の保証期間](/ja/30-day-warranty) パターンがあります。
### 事例
* ユーロスペース AG
* Flutter Entertainment: [Flutter インナーソースの応用](https://innersource.flutter.com/sdlc/)には、チーム横断的にコントリビュートする共有コードの"サービスリポジトリ"と、共有リリース成果物をビルドして公開するためのCIパイプラインがあります。各チームは、独自のデプロイメントを定義する"デプロイメント設定"リポジトリを持っています。これは、さまざまな規制要件、サービスおよびインシデント管理の実践、ビジネスの各領域におけるインフラストラクチャのスキルセットによって異なる運用がされています。
### ステータス
* Structured
### 著者
* Isabel Drost-Fromm
* Rob Tuley
### 謝辞
Tobias Gesellchenさん、Europace AGの内部レビューをありがとうございました。
### その他の呼び方
サービス対ライブラリ: インナーデプロイメントではなくインナー**ソース**
### 翻訳の履歴
* **2022-06-06** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
* **2022-06-13** - レビュー [@kanazawazawa](https://github.com/kanazawazawa)
* **2023-06-18** - 最終更新
# コアチーム
### Title
コアチーム
### Patlet
インナーソースのプロジェクトが広く必要とされていても、プロジェクトが難しいためにコントリビューションや活用に支障をきたす場合があります。プロジェクトの基本的な項目を専門に担当するコアチームを設立してください。コアチームの作業により、コントリビューターは自分のシナリオに価値をもたらす機能を追加し、使用することができます。
### 問題
* プロジェクトにコントリビュートすることが困難な場合、以下のようなことが原因として考えられます。
* ローカルでプロジェクトを実行できない。
* ドキュメントが貧弱
* コードが複雑
* テストが不適切である
* プロジェクトを使用するのが困難な場合、以下のようなことが原因として考えられます。
* ドキュメントに不備がある
* バグが頻繁に発生する
* セットアップが直感的でない
### ケーススタディ
誰もが依存する中心的なプロジェクトがあります。「なんて素晴らしいインナーソースのための候補でしょうか！」 しかし残念ながらこれまでプロジェクトは有機的に成長し、様々なコントリビューションと追加が無計画に行われてきました。今では、誰も理解できず、誰もが触れることを恐れている、厄介で厚いコードの沼になっています。 明らかにオーバーホール（リファクタリング、テスト、ドキュメンテーションなど）を行うべきなのに、誰もがその作業を必要とし、望んでいるにもかかわらず、誰もそのための時間を取らないのです。
### 状況
* 多くのチームがそのプロジェクトを必要としています。
* プロジェクトに大きな技術的負債があります。
* プロジェクトの採用やイテレーションは遅いです。
* プロジェクトとコントリビューションのエコシステム全体に対して責任を持つオーナーやメンテナが存在しません。
### 組織に働く力学
* コントリビュートするチームは皆忙しいので、自分たちにすぐに利益が出る仕事を優先します。
* プロジェクトが成長するにつれ、使用や変更が難しくなるのは当然の傾向です。
### ソリューション
他の人が簡単に参加でき、コントリビュートできるようにこのプロジェクトを維持することを仕事とするコアチームを形成します。このコアチームは、健全な利用やコントリビューションのエコシステムに必要な作業を行います。この重要な仕事は、コントリビューションとして優先されない傾向があります。この種の作業のカテゴリには、コミュニケーション、ローカル環境、DevOpsインフラストラクチャが含まれます。 以下はその具体例です。
* 本番環境のバグ
* ドキュメンテーション
* オンボーディングチュートリアルとサンプル
* 自動化されたテスト
* CI/CD
* ローカル環境
* モジュール化
* バージョニング
* モニタリング
* 新しいクラス/機能のカテゴリを開拓する
これらの各項目は、健全な製品エコシステムにとって非常に重要であるにもかかわらず、貢献として優先されることはまずないでしょう。 コアチームは少人数の、フルタイムまたはパートタイムで構成することができます。その選択は、必要な作業量、リソースの利用可能性、組織の文化に依存します。最も重要な考慮点は、組織が他のチームと同じように権限を与え、責任を負わせることができるようにチームを編成することです。 その中心的な役割から、コアチームのメンバーはほぼ常に**トラステッドコミッター**の役割も果たすべきです (この概念については、[ラーニングパス](https://innersourcecommons.org/ja/learn/learning-path/trusted-committer/)と [パターン](/ja/trusted-committer) を参照してください)。トラステッドコミッター の役割は、他のメンバーがプロジェクトに貢献したり利用したりするのを促進することに主眼が置かれていますが、コアチームのメンバーは定期的にプロジェクトにも貢献します。コアチームには、貢献を決定するような独自のビジネスアジェンダはありません。彼らは、他の人がプロジェクトを利用し貢献するために何が最も役に立つかを考えて、取り組むべきことを決定します。
この目標を継続的にリマインドさせるためには、コアチームに定期的に以下の項目を報告してもらうのがよいでしょう。
* そのプロジェクトを使用しているアクティブなチームの数
* プロジェクトに対するチーム外からの貢献の数
これらのメトリックに継続的に焦点を当てることで、コアチームは自然と、プロジェクトの周りに繁栄するインナーソースエコシステムを作成するための適切な作業に優先順位を付けるようになります。
### 結果の状況
* プロジェクトを利用しコントリビュートすることが容易になります
* 多くのチームがこのプロジェクトを利用し、貢献するようになります
* コアチームの成功は、他のプロジェクトとの相互作用とプロジェクトへの対応という観点から定義されています。
### 理論的解釈
コアチームを分離し、このようにタスクを与えることで、プロジェクトを成功させるために必要なギャップを埋めることができます。 コアチームはそのギャップを埋め、コントリビューションのエコシステムが健全であるよう、潤滑油の役割をします。
### 事例
Nike は、再利用可能なCI/CDパイプラインを中心としたインナーソースの取り組みを管理するためにこのパターンを導入しました。
### ステータス
Structured
### 著者
[Russell R. Rutledge](https://github.com/rrrutledge)
### 翻訳の履歴
* **2022-06-01** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
* **2022-06-21** - レビュー [@hirotakatoya](https://github.com/hirotakatoya)
* **2023-06-18** - 最終更新
# コントラクトコントリビューター
### Title
コントラクトコントリビューター
### Patlet
インナーソースにコントリビュートしたい社員がいますが、彼らの直属の上司はその活動に抵抗を示しています。正式な契約と合意をすることによって救済することができるかもしれません。
### 問題
中間管理職によるサポートがなければ、コントリビューターの総数や、インナーソースイニシアチブによって生み出されたコントリビューションの量と価値は、トップレベルの経営陣の期待を下回る可能性が高いでしょう。これは、[正式なコミュニティリーダー - Dedicated Community Leader](/ja/p/dedicated-community-leader)への十分な資金提供や権限付与がない場合、さらに増幅される可能性が高くなります。 これでは、トップレベルの経営陣がインナーソースの活動やアイデアを放棄してしまう危険性があります。
### 状況
ある大企業が、インナーソースイニシアチブを開始しました。このイニシアチブの主な目標は、分散ソフトウェア開発の効率を高め、トピックやビジネスユニットに関係なく、すべての社員がインナーソースプロジェクトに自発的にコントリビュートできるようにすることで、イノベーションを促進することです。
トップレベルの経営陣は、インナーソースイニシアティブを支持し、ボード上にあります。彼らにとって、インナーソースイニシアチブは、イノベーションと効率性を促進するための多くのイニシアチブの1つに過ぎませんが。彼らは、インナーソースに資金とエリアリーダーに対するキャパシティを提供し、予算がどのように使用されるかについて主に自治を与えています。また、取り組みの幅と期間を限定し、期待通りの成果が得られることが証明されるまで、定期的な見直しも行っています ([レビュー委員会](/ja/review-committee)を参照)。 経営トップ層は、様々な社内会議でインナーソースを支持することを表明しています。
しかし経営トップは、中間管理職に対して、従業員が部門横断的なインナーソースの活動に参加することを許可したり、動機付けるような権限を与えたり、インセンティブを与えるまでには至っていません。さらに、すべてのアソシエイトのキャパシティは、通常、勤務時間の100％をインナーソース以外のプロジェクトに割り当てられています。組織横断的なコラボレーションはまだ一般的ではなく、直属マネージャーは通常、自分の組織外に目標を持っていません。 一方で、インナーソースのプロジェクトに貢献するのは、自由時間ではなく、勤務時間内に行われることが期待されています。
### 組織に働く力学
* マネージャーは、ビジネスユニットの結果に対して責任を負います。 スタッフをインナーソースアクティビティに参加させると、ビジネスユニットの外部でコントリビューションすることに時間を費やす可能性があり、ユニットのキャパシティが効果的に減少します。 これにより、マネージャーが目標を達成または超えることが難しくなる可能性があります。
* 直属のマネージャーと人事は、一般的に部下のパフォーマンスをビジネスユニットの目標に対して判断します。これは、インナーソースコミュニティの目標と一致していない可能性があります。
* 直属のマネージャーがトップ層の後方支援を受けていると思っていない場合、他のビジネスユニットに貢献するインナーソースアクティビティにスタッフを参加させる可能性は低くなります。
* 直属のマネージャーがコントロールしにくく、さらに作業の透明性が低い場合、彼ら・彼女らの部下がインナーソースのプロジェクトにコントリビュートできる可能性は低くなります。
* インナーソースでの正式な作業が管理および整理されていないほど、正式なプロセスに慣れている直属のマネージャーが、従業員のインナーソースの活動へのコントリビューションを承認する可能性は低くなります。
* 社員はインナーソースプロジェクトへのコントリビューションに多くの時間を費やしますが、それらの活動は彼・彼女の日常業務に利益をもたらすことはありません。そのため、彼のビジネスユニットのチームメイトの作業負荷が増加してしまいます。
* 個々のコントリビューターは、おそらく社内の専門的なネットワークを強化し、彼ら・彼女らのコントリビューションの技術分野における知識と経験を得るための機会としてインナーソースに参加することを検討しています。
### ソリューション
コントリビューター、その直属のマネージャー、および中央で資金提供され運営されているインナーソースガバナンスオフィス(ISGO) の間で正式な契約を締結します。 ISGO に、契約期間内にコントリビューターと契約したビジネスユニットに払い戻しを依頼します。
* 契約では、インナーソースで社員の作業時間の最大割合を指定します。
* 契約では、コントリビューターのビジネスユニットでの作業がインナーソースでの作業よりも優先されることを明確に述べています。
* 契約では、契約で指定された最大割合の作業量をインナーソースプロジェクトでで必要はないことを述べています。
* 契約では、コントリビューター、コントリビューターの直属の上司、ガバナンスオフィス、コントリビューターがコントリビュートするコミュニティの[正式なコミュニティリーダー](/ja/p/dedicated-community-leader)によって署名されています。
* ガバナンスオフィスは、コントリビューターと直属のマネジャーの間で時間に関するコンフリクトが生じた場合、その仲介を行うことを提案します。
* [正式なコミュニティリーダー](/ja/p/dedicated-community-leader)は、20%以上の活動をインナーソースに充てている契約コントリビューターのパフォーマンスレビューに参加するか、意見を提供します。
### 結果の状況
正式な契約と中央資金による払い戻しは、インナーソースイニシアチブのための組織のサポートを説得力を持って伝えることになり、またそれに署名するために中間管理職の権限を与えることになります。
* 開発キャパシティを払い戻すための企業資金のビジネスユニットへの割り当ては、インナーソースが組織によって価値があると見なすことになります。また、エグゼクティブの後方支援があり、彼らもそれをサポートすることが期待されていることを直属のマネージャーにに伝えることにもなります。
* 正式な契約は、インナーソースで仕事が専門的に管理されていることを意味し、信頼につながります。
* 正式な契約により、透明性が向上し、社員のビジネスユニットおよびインナーソースプロジェクトで利用可能なキャパシティの概要がわかりやすくなるため、「過剰なリソースの提供/計画キャパシティ」に関するリスクが軽減されます。
正式な契約は、コントリビューターやコミュニティにとっても有益です。
* 安定したコントリビューターのグループがあれば、そのうちの何人かが最終的に[トラステッドコミッター](/ja/trusted-committer) のロールに到達する可能性が高くなります。
* 正式な契約は、インナーソースの活動への参加に関連するコンフリクトを解決するための基礎を提供します。(注: 調停は、対応する文化を持つ一部の企業のみに成功する可能性が高いことにご注意ください)
### 事例
* BIOS at Robert Bosch GmbH
### ステータス
* Structured
### 著者
* Georg Grütter (Robert Bosch GmbH)
### 謝辞
* Diogo Fregonese (Robert Bosch GmbH)
* Robert Hansel (Robert Bosch GmbH)
* Jim Jagielski
* Tim Yao
* Cedric Williams
* Klaas-Jan Stol
* Padma Sudarsan
* Nick Stahl
* Ofer Hermoni
* Robert C. Hanmer
### Changelog
* **2016-10-25** - first review
* **2017-05-09** - rework
* **2017-09-08** - second review, final rework and merged
* **2021-02-27** - fixing issues with display of the pattern in the book
### 翻訳の履歴
* **2022-06-06** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
* **2023-06-18** - 最終更新
# 30日の保証期間
### Title
30日の保証期間
### Patlet
自分のチーム以外からのコントリビューションを受け入れる場合、チームが書いていないコードの責任を持つことに抵抗があることは自然なことでしょう。 「30日の保証期間」プラクティスを利用すると、コードにコントリビュートしたチームはコードを受け取ったチームに対してバグフィックスを提供することを承諾することになります。 そうすることで、両チーム間の信頼度が高まり、コントリビューションが受け入れられる可能性が高くなります。
### 問題
あるチームが、組織全体で使用されるコンポーネントを開発しています。 このチームはコントリビューション(機能への要求を含む) を受け入れることに抵抗したり、完全に拒否したりします。 この振る舞いは進行を妨げたり、エスカレーションによる頻繁な混乱につながります。
### 状況
* コントリビューションを受け入れる側のチームによって生み出されたコンポーネントを、コントリビュートした側のチームが使えるかどうか、それは他のチームが受け入れてくれるかに依存してしまいます。
* 受け入れる側のチームが、コントリビュートされたコンポーネントや機能に対するリソース・知識・許可を持っていないか、もしくは(それに加えて) それらのコンポーネントや機能を自分自身で書く意欲がない場合があります。
### 組織に働く力学
* 過去に不正行為があったため、コントリビューションに対する不信感があります。例として、チームは中途半端にしたコントリビューションを提供し、その後に本番で使えるように修正するよう要求してきました。
* チーム外からコードを提供された場合、他のチームはチームの期待に沿うようなコードの書き方を知らないのではないかという疑念を持つことは自然なことです。
* 各チームは、自分のリーダーが目標を達成するための活動を第一に考えます。この忠誠心の方向性が、この問題の解決を複雑にすることがあります。
* 自分で書いていないコードに責任を持つことに抵抗があることは自然なことです。
* コントリビュートされたものは、コードベースに受け入れる前に大きく書き換える必要があります。
* コントリビュートした後、バグフィックスなどのサポートが受けられなくなる恐れがあります。
* コントリビュートされたコードが高いメンテナンスコストにつながることを恐れているが、それをどのように管理すればよいのかわかりません。
* 受け入れ側のチームは、他の人にコードを提供する方法を教えることで、自分たちのシステムの技術的負債が露呈し、それによって損害が発生することを恐れています。
* 受け手のチームは、いくら指導しても納得のいくコードが得られるとは思っていないかもしれません。
* どちらのチームも、リスクを測定したり、コントリビューションの中でリスクが軽減されていることを証明することに自信を持てないかもしれません。例えば、システム自体がややもろいなどの理由が挙げられます。(テストが完全でなかったり全ての問題を拾いきれてないかもしれません。）
### 解決策
コントリビュートしたコードが本番稼動した時点から **30日の保証期間** を設けることで、受け入れた側とコントリビュートした側の双方の不安に対処します。この保証期間中、コントリビュートしたチームは受け入れたチームにバグフィックスを提供することに同意します。
なお、保証期間は45日、60日、100日のいずれでもかまいません。この期間は、プロジェクトの制約、プロジェクトのソフトウェアライフサイクル、顧客との約束事項、その他の要因に基づいて変化される可能性があります。
さらに、受け入れ側のチームとコントリビュートする側のチームの期待値を明記した、明確な[コントリビューションのガイドライン](/ja/base-documentation)を提供することも役に立ちます。
### 結果の状況
* 受け入れ側のチームがコントリビューションを受け入れ、初期適応/修正の作業負担を分担することができます
* 透明性と公平性が高まります
* エスカレーションが重荷になりすぎないようになります
### 事例
* これは PayPal で試みられ、成功したことが証明されています。
* GitHub は社内でこのパターンを使っており、6週間という修正された保証タイムラインを使っています。
* Microsoft はこのパターンを原則として推奨しています。チームは自分たちのニーズと自信にマッチするよう具体的な時間目標を設定します。
### 著者
* Cedric Williams
### 謝辞 (Acknowledgment)
* Dirk-Willem van Gulik
* Padma Sudarsan
* Klaas-Jan Stol
* Georg Grütter
### ステータス
* Structured
* Drafted at the 2017 Spring InnerSource Summit; reviewed 18 July 2017.
### 同種の例
* 複数の、功績至上主義的に任命された[トラステッドコミッター](/ja/trusted-committer)が責任を持つことで、依存するチームの協力をコミュニティ化することで保証する。
### 翻訳の履歴
* **2022-05-26** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
* **2023-06-18** - 最終更新
# レビュー委員会
### Title
レビュー委員会
### Patlet
インナーソースの作業モデルは、開発者と管理者のための、より伝統的なアプローチからの抜本的な変革です。インナーソースイニシアチブとそれに参加するビジネスユニットのすべてのシニアマネージャーの間のインタフェースとしてレビュー委員会を確立することにより、マイクロマネジメントを助長することなく、監視と制御の一定レベルを与えるように、イニシアチブに慣れ親しみ、それをサポートできるようになる可能性が高くなります。
### 問題
管理職は、インナーソースの作業モデルを、彼らが慣れ親しんできた作業モデルからの根本的な逸脱として認識することになるでしょう。その結果、彼らはこの変化のリスクを最小限にしようとするために、インナーソースイニシアチブを拒否またはマイクロマネジメントする可能性があります。 どちらの場合も、インナーソースの利点を実現することができません。その結果、インナーソースは信用を失うことになります。
### 状況
A社は、最初のインナーソースの取り組みを導入したいと考えています。A社のほとんどのマネージャーは、オープンソースの作業モデルに慣れておらず、代わりに階層的な、トップダウンのコントロールスタイルの管理に慣れています。
### 組織に働く力学
* マネージャーがインナーソースイニシアチブでのワークをコントロールしている認識を持てば持つほど、マネージャーは事前の経験がなくてもイニシアチブをサポートする可能性が高くなります。
* マネージャーは、オープンソースのワークモデルの経験が少ないほど、マネージャーがイニシアチブのリスクを制御したいと思う可能性が高くなります。
* インナーソースの取り組みがより重労働でマイクロマネジメントされているほど、 オープンソースの作業モデルを必要な範囲で採用できる可能性は低くなります。その結果、InnerSourceのメリットは実現されません。
### ソリューション
* インナーソースイニシアチブに参加するすべてのビジネスユニットのシニアマネージャーで構成されるレビュー委員会を設立します。
* レビュー委員会メンバーには、どのインナーソースプロジェクトが一般的な支援を受け、特に資金援助を受けるかをグループとして決定する権限が与えられています。
* 申請者は、会議の前にレビュー委員によって選出され、レビュー委員会の会議でインナーソースプロジェクト案を提示することができます。
* 現在、レビュー委員会が資金を提供しているインナーソースプロジェクトのリーダーは、毎回のレビュー委員会でプロジェクトの状況について報告することが義務付けられています。
* レビュー委員は、レビュー委員会において、新規申請者と現在のプロジェクト・リーダーの両方に対して建設的なフィードバックを行う義務があります。
* すべてのインナーソースプロジェクトは、プロジェクトの早期終了を避けるために、レビュー委員会のあるセッションで受け取ったフィードバックに対して、次のセッションまで反応する機会を与えられることになっています。
* インナーソースプロジェクトのリーダーは、レビュー委員会で自発的に停止させるための動議を提示することもできます。レビュー委員会は、次に、ソフトウェアを使用するビジネスユニットが、インナーソースコミュニティによる開発の代替ソリューションが見つかるまで、コードベースの開発またはメンテナンスを継続するための手段を講じる時間を与える必要があるかどうかを決定しなければなりません (ビジネス関連またはミッションクリティカルである場合)。
* レビュー委員会は、定期的に開催されるべきです。年に2回のペースで開催するのが効果的であることが証明されています。
### 結果の状況
マネージャーは、インナーソースイニシアチブのために必要な量の情報を取得し、制御するために、使い慣れたツールをインナーソースに適用します。この親しみやすさにより、マネージャーはインナーソースイニシアチブを承認し、インナーソースプロジェクトに必要な自由度を付与する可能性が高くなります。 開発者は十分に自己組織化することができます。 レビュー委員会はあまり頻繁に招集されないため、マイクロマネジメントは行われません。
### 事例
* BIOS at Robert Bosch GmbH
### ステータス
* Structured
* *Finalized and Reviewed* as of 8/31/17.
### 著者
* Georg Grütter, Robert Bosch GmbH
* Diogo Fregonese, Robert Bosch GmbH
### その他の呼び方
Cheese Interface
### 翻訳の履歴
* **2022-06-02** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
* **2022-06-15** - レビュー [@kanazawazawa](https://github.com/kanazawazawa)
* **2023-06-18** - 最終更新
# トラステッドコミッター
### Title
トラステッドコミッター
### Patlet
多くのInnerSourceプロジェクトは、コントリビューターからフィードバック、機能、バグフィックスを一貫して受け取る状況にあります。このような状況で、プロジェクトのメンテナーは、単一のコントリビューションを越えてコントリビューターの仕事を認識し、報酬を与える方法を模索します。
### 問題
* プロジェクトメンテナーは、プロジェクトをサポートする力をスケールする方法を探しています
* プロジェクトメンテナーは、プロジェクトが提供する価値を高める方法を見つけたいと思っています
* プロジェクトメンテナーは、頻繁に貢献している人に目に見える形で報い、彼らの価値貢献を拡大させる力を与えたいと考えています
* 組織内のチーム間の貢献を認識するための仕組みや言語がない
### 状況
* あなたはチーム横断的なライブラリ、サービス、または共有リソースのメンテナーです
* あなたは定期的にコントリビューションを受けます
* あなたは定期的に機能のリクエストを受けます
* あなたは定期的にバグフィックスのリクエストを受けます
* InnerSource プロジェクトを通じて専門知識を身につけようとする意欲的なコントリビューターがいます
### 組織に働く力学
* プロジェクトのライフサイクルの中で、変化するビジネスの優先順位に対応するため、メンテナーのフォーカスがずれることがあります
* コントリビューターは、自分たちのコントリビューションが目に見える形で認められ、その価値が示されることを求めています
* 小規模なチームにとって、それなりに複雑なプロジェクトを維持することは大きな負担になります
* プロジェクトの機能を大規模に開発することは、小規模なチームにとって負担になります
### ソリューション
#### プロジェクトの トラステッドコミッターの役割を定義する
トラステッドコミッターが何を担当するかは、各プロジェクトとそのメンテナー次第です。トラステッドコミッターの役割の範囲について、プロジェクト内で文書化することを忘れないようにしましょう。明確な文書化によって、新しいコミュニティのメンバーに対する期待値を設定し、将来の候補者のために役割を確立します。 トラステッドコミッターの候補者を特定するためのガイドラインは以下のとおりです。
* コミュニティチャネル (Slack、JIRA issue triaging など) に積極的に参加している人はトラステッドコミッターになり、コミュニティサポートにおける役割を正式に決定することができます
* コード、ドキュメント、その他のリポジトリの変更を頻繁に提供する人をプルリクエストに参加させることから始めましょう。この人が積極的にプルリクエストに参加している場合、プロジェクトにおけるさらなるコラボレーションの機会についてアプローチすることを検討してください
#### 信頼できるコミッターを正式に認定する
最初のステップは、トラステッドコミッターになることについて候補者にアプローチすることです。メンテナーは候補者にトラステッドコミッターの役割について理解してもらう必要があります。候補者がトラステッドコミッターの役割を引き受けることを期待してはいけません。各候補者は、自分がその責任を果たすために必要な余剰リソースを持っているかどうかを判断する必要があります。
候補者がその役割を引き受けた場合、"ユーザー" からトラステッドコミッターへの移行を公の場でアナウンスするかはプロジェクトのメンテナー次第です。また、プロジェクトの README にある \[トラステッドコミッター] セクションに名前を追加することもお勧めします。
例としては以下のようなものがあります。
```markdown
# プロジェクト名
... Readme ...
## プロジェクトリーダー
### メンテナー
- チームメンバー
###トラステッドコミッター
- 新しいトラステッドコミッター
[トラステッドコミッター]: https://example.com/link/to/your/trusted/committer/documentation.md
```
#### トラステッドコミッターとの関係を維持する
トラステッドコミッターを正式に決めたら、 その人たちをプロジェクトの輪の中に入れておくとよいでしょう。プロジェクトの輪を保つには、プロジェクトチャンネルに招待するといった簡単なものから、企画セッションに参加させるといったものまであります。参加する機会を増やすことで、トラステッドコミッターが望めばメンテナーになる道も開けます。 トラステッドコミッターに情報を提供するだけでなく、定期的にチェックインをするのもよいでしょう。最初は一週間に一度、そして徐々に数週間に一度のペースをおすすめします。 これらのチェックインの目的は、トラステッドコミッターが新しい役割において自分が周囲からのサポートを受けていると感じられるようにすることです。上司との1:1ミーティングと同じように、何か問題があれば、耳を傾け、共感して、トラステッドコミッターが成功するのを妨げているものを理解しようと努めましょう。プロジェクトを成功に導くための[トラステッドコミッターのチームへの継続的な貢献に感謝し](/ja/praise-participants)、新しいチェックインの日付を設定しましょう。
#### トラステッドコミッターの退任
トラステッドコミッターが以下のような場合、トラステッドコミッターを退任させなければならないことがあります。
* 参加する意思がなくなった
* 責任を果たせなくなった
* 会社の従業員ではなくなった
プロジェクトのリソースへのアクセス権を解除するプロセスについては、プロジェクトの **トラステッドコミッター** セクションにあるエントリを"過去のコントリビューター"のリストに移行させるなど、両者で事前に合意しておく必要があります。 アクセス権を解除する際には、[トラステッドコミッターの参加に対して公の場で感謝の意を表する](/ja/praise-participants)ことで、移行と継続性をコミュニティ内で明確に周知することができます。
### 結果の状況
#### コントリビューターに対して
プロジェクトのトラステッドコミッターとなることは、コミュニティプロジェクトにコントリビュートするイニシアチブを示すことになります。このような貢献は、上司との年次レビューでの評価に組み込むなどの利用が可能です
#### メンテナーに対して
プロジェクトが成熟するにつれて、 メンテナーはプロジェクトの重要な側面についてあまりよく知らなくなることがあります。トラステッドコミッターはこのようなギャップを埋め、プロジェクトのあらゆる側面をより良くすることができます。 トラステッドコミッターを健全に組織に配置することは、メンテナンス担当者が進むにあたり、職務遂行のための責任がある管理計画の所在を保証することになります。
### 事例
この事例は、試行錯誤のすえ以下の企業で成功しています。
* Nike
* PayPal
### ステータス
* Structured
* Nike の社内で公開、2018年6月にプルリクエストで起草
### 著者
* [Fernando Freire](https://github.com/dogonthehorizon)
### 謝辞
* [Russell Rutledge](https://github.com/rrrutledge)
* [Loren Sanz](https://github.com/mrsanz)
* [Noah Cawley](https://github.com/utanapishtim)
* [Jeremy Hicks](https://github.com/greatestusername)
* [Doron Katz](https://github.com/doronkatz)
### 翻訳の履歴
* **2022-05-30** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
* **2023-06-18** - 最終更新
# RFCを用いたチーム横断的な意思決定の透明化
### Title
RFCを用いたチーム横断的な意思決定の透明化
### Patlet
高い参加率を達成し、関係者全員にとって最良の意思決定を行いたいインナーソースプロジェクトは、ソフトウェアのライフサイクル全体を通して参加型のシステムを構築する方法を見つける必要があります。内部のRFC(Requests for Comments)ドキュメントを公開することで、設計プロセスの早い段階から議論を行うことができ、関係者全員が高いコミットメントを持ってソリューションを構築できる可能性が高まります。
### 問題
インナーソースプロジェクトが健全であるためには、相当な数のコントリビューターが必要です。しかし、コントリビューターが増えると、例えば互いに互換性のない機能をプロジェクトに追加したり、アーキテクチャを不健全に肥大化させたりする可能性があります。 このような意見の相違や誤解をプロセスの後半で発見した場合、特にソフトウェアがすでに構築された後では、修正に非常にコストがかかってしまいます。このような意見の相違は、関係者全員のフラストレーションにつながり、プロジェクトにおけるコラボレーション文化の健全性を損なう可能性さえあります。 このような不一致が表面化する時によくあるケースとして、変更リクエストの作成者とプロジェクトのメンテナーが、提案された変更を行うべきであるということに本質的に同意していないために、非常に長い間オープンになっている変更リクエスト(プルリクエスト) が存在するなどがあります。
インナーソースプロジェクトでは、社内の複数のチームによってプロジェクトが維持されている場合、このような状況がより頻繁に発生します(共有オーナーシップ)。
### ケーススタディ
プロジェクト、または複数のプロジェクトで構成されるアプリケーションは、多くの異なるチームによって維持され、各チームはプロジェクトまたはアプリケーションの異なる領域を所有し管理します。これらのチームは、お互いの領域にインナーソースの貢献をしますが、より大きな分野横断的な変更は、チームの技術リーダーが協力することによってのみ推進されるか、もしくはそもそもまったく発生しません。その結果、ほとんどのエンジニアは大規模で分野横断的な変更を行うことができなくなり、イノベーションとコラボレーションの機会が減少します。
ここで RFC のプロセスとテンプレートを導入することで、チームや個人は、透明性のある意思決定プロセスを通じて、大規模で横断的な変更を提案する権限を与えられ、チーム間で非同期的に協議が行われます。その結果、イノベーションが促進され、コラボレーションが緊密になり、知識がより広まることになります。このためには、あらゆるレベルのあらゆる分野から賛同を得ること、そして人々がオープンにアイデアを提案し、議論できるような心理的安全性の高い環境を整えることが必要です。
どのようなプロセスでもそうですが、これは継続的に改善されなければなりません。RFC のテンプレートやプロセスを変更して、包括的、協調的、かつ効果的なものにする必要があるかもしれません。
### 状況
* インナーソースプロジェクトは多くのチームによって共有されています。
* アーキテクトグループは十分な時間がなく、またすべてのケースで適切な判断を下すのに十分なドメイン固有の知識もないため、包括的な設計上の決定を常に中央の組織(アーキテクトグループなど)から行うことはできません。
* あるプロジェクトの方向性については、さまざまなタイプのユーザーが意見を述べます。そのようなユーザーには開発者、プロダクトオーナー、プロダクトマネージャーなどがいます。
* 参加者全員と頻繁に同期ミーティングを開くことが不可能なため、少なくとも部分的には非同期で意思決定を行う必要があります。
* 決定事項を文書化したい、つまり口頭だけでなく文書で確認したいと感じています。
### 組織に働く力学
* ほとんどの場合、関係者はかなり迅速に決定を下したいと思っています (例: 事前の設計時間はかなり限られています)
* 関係者の多くにとって、(すでに実装されていない)物事を書き留めることは新しいスキルであることが多いです。
### スケッチ
### ソリューション
チーム横断的な意思決定プロセスの透明性を高めるために、RFC的なプロセスを採用します。([Requests for Comments](https://en.wikipedia.org/wiki/Request_for_Comments)もご参照ください)
このソリューションの重要な要素は以下の通りです。
* RFC を発行する場合(および発行しない場合)の説明
* RFCドキュメントのテンプレート
* RFC の作成者に、自分の提案を多角的に検討するよう促す必要があります。
* ハイレベルでアクセスしやすい概要と、詳細で深い説明の両方を促す必要があります。
* RFC を取り巻くよく知られた軽量なプロセス
* RFC を公開し、すべての関係者と共有する方法 (例: Slack、メーリングリスト)
* RFC に対するフィードバックをどのように収集するか
* どのようにフィードバックを取り込むか
* 結論や決定に向けて RFC をどのように進めるか (例: 関連する指名されたメンテナーが承認すること)
* 適切なツールの選択 (例: 非エンジニアはソースコントロールツールにアクセスできないかもしれません)
* RFC のテンプレートとプロセスを繰り返し使用することを約束すること
#### Examples/Templates
* [Rust](https://github.com/rust-lang/rfcs) は RFC テンプレートとプロセスの優れたオープンソース例であり、他の多くの RFC プロセスの基礎となっています。
* [一般化された BBC iPlayer & Sounds RFC テンプレート](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/2-structured/templates/rfc.md) (元々はRustテンプレートに基づいています)
### 結果の状況
RFC のようなプロセスを導入することで、チーム横断的な意思決定プロセスがより透明化され、すべての人の声を聞くことができるようになり、価値があることが証明されました。
観察できるポジティブな効果
* 多くのチームに影響を与える**意思決定プロセスを民主化**します(チームリーダーの負担を軽減)。
* 複数のチームや地域にまたがって機能する**オープンな非同期コミュニケーション手法**になります。
* **個人とチーム**が大規模な**変化を起こせるように**します。
* **決定事項を記録**し、その内容を参照することができます。
* **経験豊富なエンジニア**が、ミーティングに出席する必要がなく、非同期かつリモートでソリューションに貢献できるため、その**影響力を拡大**することができます。
* 例えば、"システムテストとは何か" などのテスト用語を定義しておくことで、**用語の整合性を図る**ことができます。
* **プロセスの整合性**を図ります。 例えば時間外サポートのプロセスを明示するなどが挙げられます。
* RFC を書くことで、著者が自分自身に挑戦することになり、**思考がより明確に**なります。
一方で RFC のアプローチにはリスクも存在しますので、以下に注意も喚起したいと思います。
* この方法はいつもうまくいくとは限りません。例えば、RFCを通じてすでになされた決定に対して異議を唱える人がいるかもしれません。しかし、意思決定のプロセスを文書化しておくことは、このようなシナリオでも有益です。ある決定がいつ、なぜなされたかを人々に示すことができるからです。
* 設計案 (アーキテクチャ、プロトコルなど) を前もって書き上げることは、ウォーターフォールのような設計の要素があり、多くの開発チームが好む反復的なアジャイルの開発アプローチには適さない場合があります。[アジャイルマニュフェスト](https://agilemanifesto.org/)に存在する「括的なドキュメントよりも、動くソフトウェアを」という項目は覚えておいてください。RFC プロセスは可能な限り軽量であるべきです。
* RFC は大きくなりすぎて扱いにくくなる可能性があります。これはしばしば、長いコメントスレッドやそれをめぐる議論に表れます。そのような状況では、ワーキンググループや直接のミーティングなど、同期的なコミュニケーションで RFC を補完することを決定することもあります。しかし、ミーティング中にすべての情報を共有するのではなく、ミーティングの前に RFC を読むことができるので、時間はいずれにせよ節約されていることになります。
### 理論的解釈
RFCは、長年にわたってオープンソースの世界でその効果が証明されてきました。これは、RFCが標準の開発に役立ってきたインターネット全体にも当てはまるほか([例: RFCの30年を参照](https://www.rfc-editor.org/rfc/rfc2555.txt))、コミュニティにおける透明な意思決定を促進するためにこの方法を適応させてきたその他のオープンソースプロジェクト([RUST](https://github.com/rust-lang/rfcs), [ZeroMQ](https://rfc.zeromq.org))にも当てはまります。
インナーソースの文脈では、[Uber](https://blog.pragmaticengineer.com/scaling-engineering-teams-via-writing-things-down-rfcs/) や [Europace](https://github.com/open-organization/open-org-distributed-work-guide/blob/master/drostfromm-remote-first-through-openess.md#setting-cross-team-standards-and-best-practices-in-the-open) など、様々な企業が RFC のようなアプローチの経験を有しており、共有しています。
また、純粋なソフトウェア設計の決定以外にかかる意思決定においても、透明性のある意思決定モデルは、例えばオープンな組織に向けて取り組む際に効果的です。例として、Red Hatの [Open Decision Framework](https://www.redhat.com/en/about/press-releases/red-hat-releases-open-decision-framework-spur-transparent-and-inclusive-leadership) (2016年6月7日に公開)をご覧ください。
### 事例
* **BBC iPlayer & Sounds** - ISC Fall Summit 2020 のプレゼンテーションをご参照ください - [Using Internal RFCs to Enhance Collaboration](https://www.youtube.com/watch?v=U6zlghE0HcE)
* **Europace** - Open Organizationの項目で述べられています - [Setting cross-team standards and best practices in the open](https://github.com/open-organization/open-org-distributed-work-guide/blob/master/drostfromm-remote-first-through-openess.md#setting-cross-team-standards-and-best-practices-in-the-open).
* **Uber** - Gergely Orosz さんの記事をご覧ください [Scaling Engineering Teams via RFCs: Writing Things Down](https://blog.pragmaticengineer.com/scaling-engineering-teams-via-writing-things-down-rfcs/).
* **Google Design Docs** - Malte Ublさんの記事をご覧ください [Design Docs at Google](https://www.industrialempathy.com/posts/design-docs-at-google/)
### ステータス
Structured
### 著者
* Tom Sadler
* Sebastian Spier
### その他の呼び方
* [デザインとキュメント](https://www.industrialempathy.com/posts/design-docs-at-google/)
* アーキテクチャの決定記録(ADR: Architecture Decision Record) - 意見を求め、合意を形成するための RFCです。決定と実装の詳細を記録するための ADR など、非常に異なる使い方をすることがあるため、必ずしも直接的な類例ではありません。
### 翻訳の履歴
* **2022-06-07** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
* **2022-06-13** - レビュー [@kanazawazawa](https://github.com/kanazawazawa)
* **2023-06-18** - 最終更新
# インナーソースライセンス
### Title
インナーソースライセンス
### Patlet
同じ組織に属する2つの法人は、ソフトウェアのソースコードを互いに共有したいと考えていますが、法的責任や会社間の会計処理の観点からの影響を懸念しています。
**インナーソースライセンス**は、組織内でソースコードを共有するための再利用可能な法的枠組みを提供します。これにより、新しいコラボレーションの選択肢が広がり、関係する法人 の権利と義務が明確になります。
### 問題
組織内の2つ以上の法人が互いにコードを共有したい場合、条件についての合意が必要であり、多くの場合で法的契約が必要になります。プロジェクトごとにこのような契約を作成するには手間がかかり、それは共有における障壁になってしまいます。たとえば、ある法人のチームは複雑そうだからという理由で、組織内の別の法人とソースコードを共有しないことに決めるかもしれません。
共有における障壁は、組織の複数で同様のソリューションを再構築する際のサイロ化と車輪の再発明につながる可能性があります。
ソースコードを共有する時点では、共有の価値を確実に予測することはできません。共有の活動に(使用条件の交渉などの)多大な労力が必要な場合、法人は投資に対する収益率を懸念しているため、一連の活動を行う可能性は低くなります。
### 状況
* コードを共有したい大量の子会社を持つ大組織。組織が大きくなればなるほど、このパターンの価値は高くなります。
* 定義によると、法人は独自の法的権利と義務を持っています。
* 複数の法人はソフトウェアを開発しており、他の法人のサービスを使用しています。彼らには、お互いのソースコードに貢献する動機があります。
* 組織とその組織構造は十分に複雑です。
### 組織に働く力学
* 特に、技術、法律、ビジネスの観点を考慮する必要がある場合、正式な契約書を書くのに必要な**労力のレベル**があります。
* 大きな組織(特に多くの法人から成る組織)には、多くの**内部規制**があります。新たに締結される契約は、セキュリティ、プライバシー、調達プロセスなど、これらの規制に準拠しなければなりません。規制が多いため、特に標準的な手順がない場合、2つの法人間でソフトウェアを共有することについてこれらの規制に準拠しているかどうかを評価することが困難になる場合があります。
* 組織内のいずれかの法人が、独占的なコードと組織内のライセンス料の会計処理に依存する **ビジネスモデル** を有している場合があります。
* インナーソースのコラボレーションとソースコードの共有に**企業文化**が慣れていない場合があります。これは、共有ソースコードを使用する場合の権利と義務についての不確実性をもたらします。
* ソフトウェアの使用を自由にすることが、競争と所有権の拡大につながります。
* ソースコードの共有に関する事項を含む法的なルールが存在します。しかしこれらのルールは標準化されていないため、プロジェクトごとに交渉と理解のための追加的な労力が発生します。また既存の契約では、真のインナーソースのアプローチをサポートするために十分オープンな意味でのソースコードの共有ができない場合があります。
* あるいは、法的な契約は結ばれていないものの、ソースコードが非公式に共有されている場合もあります。その場合、所有権や権利・義務の明確化が必要なケースにおいて不確実性が生じるかもしれません。
### ソリューション
対象組織(およびその法人)のニーズに合わせてカスタマイズした **インナーソース ライセンス** を作成します。このライセンスは、最も重要な企業間関係に適用できるような汎用的なものである必要があります。
インナーソース ライセンスは、関係する法的実体の境界を越えて、本当にオープンソースのような共同作業を可能にするように書くことが重要です。したがって、フリーソフトウェアの4つの自由(\*)は、ライセンスに統合されるべきです。
このライセンスは正式な法的文書として書かれており、コード共有契約を管理するために法人間の契約の一部として使用することができるようにします。
(\*「4つの自由」の補足: 使用する自由, 変更する自由, 共有する自由, 変更したソフトウェアを再配布する自由)
### 結果の状況
インナーソースライセンスにより、組織内の法人間でコードを共有するためのツールを手に入れることができます。
このライセンスは、ソースコードの共有に関する組織内の会話を簡素化し、法人が最初に使う動機づけにもなっています。
**注:** 事例で説明されている実験は初期段階にあります。したがって、しっかりとした**結果の状況**はまだ形成されていません。数ヶ月後には、この問題に対するインナーソースライセンスの効果がより明確になり、このセクションは更新されるでしょう。
### 事例
DB Systel社は彼ら自身のインナーソースライセンスを作りました、内容は[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)を使用し、その後、彼らの特定の組織のコンテキストに必要な制約と追加のルールを作り出しました。
DB 社の中で最初の法人(企業) は、このインナーソース ライセンスを使用しています。
すでに現れているポジティブな効果のひとつは、特に関係者の中にまだインナーソースのコンセプトをよく知らない人がいる場合、会話がシンプルになることです。ライセンスはよく知られた概念なので、インナーソースライセンスがあることは、議論のきっかけになります。
この実験では、真のインナーソースのコントリビューションとコラボレーションモデルにつながるために解決しなければならない、さらなるコラボレーションの課題があることも明らかになりました。
その課題とは、以下のようなものです。
* インナーソースのライセンスプロジェクトを発見できるようにする
* オープンソースのように、プロジェクトでコラボレーションするためのコミュニティを構築すること。
これまでのところ、このインナーソースライセンスの下で共有されるソフトウェアは、ほとんどがツール、インフラ、およびスタックの下位にあるツールであることは言及に値します。
### ステータス
* Structured
* **事例**に記載されている実験は、2020年2月から実施されています。最初の経験では、最初のポジティブな効果を示していますが、パターンを完全に評価するためには、より多くの経験が必要になります。
### 著者
* Cornelius Schumacher (DB Systel GmbH)
* Schlomo Schapiro (DB Systel GmbH)
* Sebastian Spier
### リファレンス
* FOSSBack 2020 Presentation: [Cornelius Schumacher - Blending Open Source and Corporate Values](https://youtu.be/hikC6U8X_Ec) - インナーソース ライセンスの詳細については、27:30以降をご覧ください
* [DB Inner Source License](https://github.com/dbsystel/open-source-policies/tree/master/inner-source-license)
### 単語の解説
* **組織** - 複数の企業の母体(同義語: グループ、ホールディング、エンタープライズ) (例: Microsoft Corporation)
* **法的エンティティ** - 独自の法的権利と義務を有するエンティティ (同義語: グループ子会社、子会社、関連会社) (例: Microsoft Japan, GitHub, LinkedIn)
### 翻訳の履歴
* **2022-06-05** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
* **2022-06-13** - レビュー [@kanazawazawa](https://github.com/kanazawazawa)
* **2023-06-18** - 最終更新
# ギグマーケットプレイス
### Title
ギグマーケットプレイス
### Patlet
イントラネットのウェブサイトを作成し、特定のインナーソースプロジェクトのニーズを、時間とスキルの要件を明示した「ギグ」としてリストアップすることで、マーケットプレイスを確立する。 これにより、管理者がインナーソースのコントリビューションを行うための承認を与え可能性が増え、従業員の時間のコミットメントと専門的な利点をよりよく理解することができます。
### 問題
マネージャーも従業員も、インナーソースプロジェクトに参加することでどのように利益が得られるかを理解していません。
従業員がインナーソースプロジェクトに対してどのような時間を費やす必要があるかを経営陣に伝えることは困難です。
マネージャーには、インナーソースプロジェクトへの従業員の関与を追跡したり報酬を与えたりするための統一された方法がありません。
### ケーススタディ
あなたは、会社でインナーソースプログラムを成功させ、上級管理職、中間管理職、開発者から賛同を得ています。 しかし、約1年後、最初にそれらを作成したチーム以外の任意のインナーソースプロジェクトに行われた実際のコントリビューションはほとんどありませんでした。 関係者にヒアリングしたところ、インナーソースプロジェクトに参加する場合、開発者がどの程度の時間を割く必要があるのか、また、個人的にどのようなメリットがあるのかが分かりにくいことが主な原因であるようです。また、貢献者のためのどのような機会が存在し、彼らは何をするように求められてもおおよその時間を示すための統一された方法がありません。管理職は協力的で、従業員が参加することを望んでいますが、これまでのところ、インナーソースプロジェクト内の従業員の活動のための会計処理や報酬の方法が欠けています。 すべての関係者（インナーソースプロジェクトの所有者、潜在的な貢献者と開発マネージャー）のためにこの状況を改善するには何ができるのでしょうか？
### 状況
社員は、現在のポジションを離れることなく、会社の他の領域で行われている活動に触れることができればと願っています。しかし、インナーソースのプロジェクトには、社員の参加を阻む2つの要因があります。まず、現在進行中のインナーソースプロジェクトにどのような貢献の機会があるのかを容易に発見し、上司に伝えることができないこと。 つぎに、マネージャーがこれらのインナーソースプロジェクトタスクに対する従業員の時間的コミットメントを計画および説明できないことです。その結果、インナーソースプロジェクトのオーナーは、彼らの目標を達成するために十分な規模のコミュニティを構築することができません。
### 組織に働く力学
* 社員にはインナーソースのチャンスを見つける簡単な方法が用意されていません。
* 社員は、貢献が専門的にどのように役立つかを理解していません
* マネージャーは、インナーソースプロジェクトに関連するタスクにかかる時間/労力の要件を理解していません
### 前提条件
* 従業員は、マネージャーからインナーソースプロジェクトに参加する時間を提供されています。
* マネージャーは、インナーソースのコントリビューションを定量化、追跡、記録して、説明と報酬を得る方法を必要としています。
### ソリューション
個人が自分のスキルや興味のある分野を示すことができ、インナーソースプロジェクトのオーナーがコラボレーションのための機会を宣伝することができます "ギグ" ベースのイントラネットサイトを作成します。
従業員は、アプリケーション内に自分のスキルと関心のある分野をリストできるプロファイルを作成できる必要があります。システムは、これらの基準の1つ以上に一致するギグが投稿されたときに、(電子メールまたはその他の手段を介して)個人に積極的に通知することにより、この情報を活用することができる必要があります。
インナーソースのプロジェクト・オーナーが投稿する各ギグには、スキルや時間の要件が含まれており、稼働可能な従業員と簡単にマッチングでき、直属の上司に明確に伝えられるようになっていなければなりません。説明は、可能な限り魅力的なようにするために、タスクを引き受ける人にどのように役立つかについての理論的根拠を含める必要があります。
従業員のギグへの関与を評価し、追跡するために、ポイントベースのシステムを作成することができます。 例えば、完成したギグを投稿するとギグのオーナーに10ポイント、ギグを完成させた開発者には100ポイントを付与するなどの仕組みを適用します。ギグを完了することで得られるポイントは、ゲーミフィケーションの仕組みとして、また、組織内に存在する専門分野を把握するためのパフォーマンス管理の基準として利用することができます。
ギグを受けたい人は、まずギグの所有者が、その従業員がギグを完了するために必要なスキルと割り当てられた時間を有しているかどうかを判断する必要があります。
ギグを通じたコントリビューションの透明性は、コントリビューターの評判を高め(あるいは下げ)、コントリビューションの質が高くなる可能性を高めるのに役立ちます。 また、ギグを完成させることで、その分野の専門性を証明することができます。
マーケットプレイスに投稿されるギグの内容は、グループイベントの運営、レポートの作成、メンターへの依頼など、ハードスキル、ソフトスキルの両方を含むことができます。
ギグマーケットプレイスの構築は、全社的なインフラと機能を提供する責任を持つ組織内のチームによって行われることが理想的です。
### 結果の状況
インナーソースギグマーケットプレイスは、インナーソースのプロジェクトの数だけでなく、それに関わる社員の数も大幅に増加させます。 ギグマーケットプレイスの自主的な性質は、社員が実行する作業のレベルを選択し、会社全体でパートナーとなることができるようにすることで、社員の仕事の満足度を高めています。 社員は、自分が何にサインアップしているか、そしてその経験から何を期待できるかを正確に理解することができます。 マネージャーは、インナーソースプロジェクトに関する従業員の時間的コミットメントをより適切に推定および追跡し、個々の取り組みを認識し、特定のスキルセットを検証する方法としてギグの成果を使用することができます。 またマネージャーは、社員がギグマーケットプレイスで利用可能な仕事にピボットできるようにすることで、従業員が経験しているかもしれない既存のダウンタイムを活用することができます。 ギグマーケットプレイスでのやり取りによって生成されたデータは、すべての部署で雇用とトレーニングの決定を促進するのにも役立っています。
インナーソースポータルのパターンと組み合わせて使用すると、ギグマーケットプレイスは、ギグが関連するプロジェクトのコードリポジトリとドキュメントへのリンクに加えて、より細かいレベルのコンテキストと詳細を提供することができます。
### 事例
* 大手金融サービスの組織は、インナーソースプログラムを育成するためにインナーソースギグマーケットプレイスのウェブサイトの作成をしました。
* SAP はギグマーケットプレイスパターンを実装しました - 新しいインナーソースプログラムは、ポジションと同様の提供を掲載することができ、内部のジョブプラットフォームに追加されています。
* ギグマーケットプレイスパターンは、関連する[インナーソースポータル](/ja/innersource-portal)パターンと非常によく機能することが証明されています。 インナーソースポータルは、現在進行中の特定のプロジェクトの認知度を高め、ギグマーケットプレイスは、それらのプロジェクト内で作業可能な特定のタイプのタスクを広告します。
### ステータス
* Structured
### # 著者
* Stephen McCall
* Shreyans Dugar
### 翻訳の履歴
* **2022-06-06** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
* **2022-06-13** - レビュー [@kanazawazawa](https://github.com/kanazawazawa)
# インナーソースポータル
### Title
インナーソースポータル
### Patlet
潜在的なコントリビューターは、彼らが興味を持っているインナーソースプロジェクトを簡単に見つけることができません。すべての利用可能なインナーソースプロジェクトの情報をインデックス化するイントラネットのウェブサイトを作成することにより、あなたはコントリビューターが彼らに興味があるかもしれないプロジェクトについて知ることができ、インナーソースプロジェクトのオーナーは、外部のオーディエンスを引き付けることができます。
### 問題
インナーソースプロジェクトチームは、外部からのコントリビューションを集めることが難しいと感じています。
あなたの組織のインナーソースプロジェクトは増えているものの、潜在的なコントリビューターにとって、それらのプロジェクトを見つけるための簡単な方法がありません。
### ケーススタディ
あなたは、組織内のインナーソースプラクティスを確立しようとしています。 あなたは、いくつかのプロジェクトがインナーソースモデルを使用して運用されていることを知っていますが、それらの存在は、他の社員の口コミ、電子メールまたは立ち話を介してのみ伝達されています。 結果としてインナーソースプロジェクトのオーナーは、コントリビューターを引き付けることに困難を感じています。
現在、組織全体の従業員がアクセスできる単一の共有リソースはなく、進行中のすべてのインナーソースプロジェクトを簡単に見つけることはできません。このことは、すべてのインナーソースプロジェクトの成長の可能性を大幅に制限しています。
すべてのインナーソースプロジェクトが、できるだけ多くのオーディエンスにビジビリティを発揮し、組織全体のコントリビューターを引き付けるためには何ができるでしょうか？
### 状況
* あなたの組織は、インナーソースワークスタイルを採用することに興味を持っています。
* インナーソースプロジェクトのオーナーは、彼らのプロジェクトにオーディエンスを引き付けるための方法を探しています。しかし、潜在的なコントリビューターに宣伝するために利用できる通信チャネルはなく、活動が制限されてしまっています。
* あなたの組織でインナーソースプロジェクト自体は増加しています。
* この問題をさらに深刻にしているのは、使用されている共有ソース管理アプリケーションの検索機能が非常に限られているためです。インナーソースプロジェクトを探すのに慣れた開発者でさえ、その場所を特定するのに苦労しているという事実です。
### 前提条件
* マネージャーは、従業員がインナーソースプロジェクトに参加することを暗黙の了解としています。
* ホストするリポジトリのコンテンツは共有ソース管理システムによって提供されていますが、プログラムによるアクセス制限がついています。
* 組織内にインナーソースコラボレーションの促進を担当する部門があります。
### 組織に働く力学
* 別々のエンジニアリングチームが、共通の課題に対してパートナーとして取り組むことのポテンシャルが十分に発揮されていません。
* インナーソースプロジェクトが存在することを、個人が知ることは困難になっています。
* インナーソースプロジェクトのオーナーが外部のコントリビューターを引き付けることは困難です。
### ソリューション
インナーソースプロジェクトのオーナーがプロジェクトの利用可能性を簡単に宣伝できるインナーソースポータルイントラウェブサイトを作成します。
ポータルの主要な内容は次のとおりです。
* インナーソースポータルにアクセスした人は、すべての利用可能なプロジェクトを見るだけでなく、プロジェクト名、使用中の技術、コントリビューター名、スポンサー事業部などの様々な条件に基づいて、特定のプロジェクトを検索することができるようになっています。
* インナーソースポータルを通じて表示される情報は、常にインナーソースプロジェクトのオーナーの完全な制御下にある必要があります。プロジェクトリポジトリ自体に格納されている特定のデータファイルまたはメタデータから直接この情報をソーシングすることによって実現されるのが好ましいです。
* プロジェクトのオーナーは、プロジェクト名、トラステッドコミッターの名前、簡単な説明とコードリポジトリまたは任意のサポートドキュメントへのリンクを含むそれらのデータファイル内のプロジェクトに関するすべての関連情報を含める必要があります。
* (\*オプション)ほとんどの組織は、ポータルをイントラネットでのみ利用できるようにすることを選択しますが、いくつかの組織は、ポータルを公共のインターネット上で利用できるようにすることを選択しました。後者は、例えばブランディングや採用の目的で、ポータルにインナーソースのアプローチに関する追加情報を表示したい組織にとって興味深いものになるでしょう。
ポータルを立ち上げる際には、ポータル内に表示されるプロジェクトの数を増やすために、インナーソースのデータファイルやコードリポジトリへのメタデータの追加を促進するコミュニケーションキャンペーンを検討する必要があります。
インナーソースポータルの[参考実装](https://github.com/SAP/project-portal-for-innersource)はGitHub上で公開されており、コントリビューションを受け付けています。これは、インタラクティブで使いやすい方法で、組織のすべてのインナーソースプロジェクトを一覧表示します。プロジェクトはGitHubの専用トピックを使って自己登録し、追加のメタデータを提供することができます。
### 結果の状況
* インナーソースポータルは、インナーソースプロジェクトのオーナーが組織全体のオーディエンスにプロジェクトを広告することが可能になりました。ビジビリティがあがったため、彼らはこれまで以上に大きなコントリビューターのコミュニティを惹きつけています。
* インナーソースプロジェクトに参加したい人のために、インナーソースポータルは、社員が特定の条件に基づいてすべての利用可能なインナーソースプロジェクトを横断検索することによって、興味を持っている種類を正確に発見することを可能にしました。
* インナーソースプロジェクトへの参加を検討している場合、インナーソースポータルでは、特定の基準に基づいて利用可能なすべてのインナーソースプロジェクトを一度で検索することにより、関心のある機会の対象を正確に見つけることができます。
* これらの両方のニーズを満たすことで、組織のすべての領域において個別に実現できないことを一緒に達成するために活用できる魅力的な手段として、インナーソースを確立するのに役立ちました。
### 事例
* **大手金融サービス組織**は、異なるビジネスユニット間で存在するインナーソースプロジェクトを宣伝し、発見する仕組みを提供するためにインナーソースポータルを使用しています。
* **SAP**はインナーソースポータルでインナーソースプロジェクトを推進しています。 プロジェクトはGitHubトピックを使用して自己登録することができます。[リポジトリアクティビティスコア](/ja/repository-activity-score) は、ポータル内のインナーソースプロジェクトのデフォルトの順序を定義しています。 また、SAP における事例はこちらもご参照ください[Michael Graf & Harish B (SAP) at ISC.S11 - The Unexpected Path of Applying InnerSource Patterns](https://www.youtube.com/watch?v=6r9QOw9dcQo\&list=PLCH-i0B0otNQZQt_QzGR9Il_kE4C6cQRy\&index=6)。 コードベースは[リファレンス実装](https://github.com/SAP/project-portal-for-innersource) として公開されており、コントリビューションのためにオープンになっています。
* **Elbit Systems**はこのパターンを使い、さらにゲーミフィケーションを上乗せしています。
* [文化変革の手段としてのゲーミフィケーションとインナーソースのエンゲージメントブースター](https://www.oreilly.com/library/view/oscon-2018-/9781492026075/video321579.html) | Shelly Nizri | OSCON 2018 - Portland, Oregon
* Of Islands, Monsters & InnerSource [(slides)](https://docs.google.com/presentation/d/1P1OCEK9B6eSrVRUclVWY6meSI-qHOBjM_UAPNvCZamU/edit#slide=id.p15), [(video)](https://drive.google.com/file/d/1pM89uHMn0vhE3ayFJDGYcCO8R0tAXXZD/view?usp=drivesdk) | InnerSource Spring Summit 2019 (Galway, Ireland)
コードはオープンソース化されており、[gitlab.com/gilda2](https://gitlab.com/gilda2)にて公開されています。
* **アメリカン航空**は、[インターナルインナーソースマーケットプレイス](https://web.archive.org/web/20240226230502/https://tech.aa.com/2020-10-30-innersource)を介してInnerSourceプロジェクトを推進しています。SAPと同様に、プロジェクトはGitHubのトピックとして `innersource` を追加することで自己登録されます。プロジェクトは、言語、トピック、オープンイシューの数などで検索やフィルタリングが可能です。
* **Banco Santander**社は、インナーソースをサポートして増やすために、Santander ONE Europe InnerSource Communityという公開ポータルを作成しました。このポータルには、プロジェクトのカタログに加え、ドキュメント、仕事の進め方、ニュース、イベントなどの関連コンテンツが含まれています。
### リファレンス
* インナーソースポータルパターンは[インナーソースギグマーケットプレイス](/ja/gig-marketplace) のパターンと一緒に使うと非常によく機能することが証明されています。
### ステータス
* Structured
### 著者
* Stephen McCall
### 謝辞
* Shelly Nizri
* Melinda Malmgren
* Michael Graf
* Jesús Alonso Gutierrez
### 翻訳の履歴
* **2022-06-06** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
* **2022-06-13** - レビュー [@kanazawazawa](https://github.com/kanazawazawa)
* **2023-06-18** - 最終更新
# リポジトリアクティビティスコア
### Title
リポジトリアクティビティスコア
### Patlet
潜在的なコントリビューターは、彼らの助けを必要とするアクティブなインナーソースプロジェクトを見つけたいと思っています。各プロジェクトのリポジトリのアクティビティスコアを計算することで、プロジェクトのランク付けされたリストを作成することができます (参考: [インナーソースポータル](/ja/innersource-portal) )、そのため、潜在的コントリビューターは、彼らがコントリビュートしたいプロジェクトをより簡単に決定できます。
### 問題
**インナーソースのプロジェクトはどのような順番で表示されるべきでしょうか？** *GitHubのスター数*, *フォーク数*, *コミット数*, *コードの行数*, *最終更新日時* などの典型的なKPI は、プロジェクトの活動状況を簡潔に示すには十分ではありません。
活発なプロジェクトはもちろん、新しいコントリビューターを必要としているかなり新しく熱心なプロジェクトも、成熟したプロジェクトで活動が少ないものやメンテナンス中のものよりも上位にランクされるべきでしょう。
プロジェクトのアクティビティレベルについて、信頼性が高く汎用性のあるスコアを定義するために、いくつかのKPIから派生した新しい評価指標が必要になります。この指標は、プロジェクトのアクティビティレベルに応じて、プロジェクトを分類するために使用されます。
### ケーススタディ
インナーソースが長期間実践されている場合、または特定の数のプロジェクト(意味のあるしきい値を与えるために50としましょう)を超えて拡がっている場合、現在最も人気がありアクティブなインナーソースプロジェクトを見つけるのは困難です。 長い間存在するプロジェクトはよく知られていますが、もはやあまり活発ではないかもしれません。 一方、かなり新しいプロジェクトには、まだ評判や活発なコミュニティがありません。
インナーソースプロジェクトのリストは、静的なリソースと考えるべきではありませんが、ちょうどその日の最も興味深いトピックを最初にリストするニュースページのように、新しいアクティブなプロジェクトを発見し探索するためのエキサイティングな場所です。したがって、プロジェクトの順序が定期的に更新され、プロジェクトの人気と活動に応じて変更された場合、それは有益であると言えます。
これらの考慮事項を加味し、リポジトリアクティビティスコアを計算する最初のプロトタイプが開発されました。 このプロトタイプは驚くほどよく機能し、プロジェクトの活動状況に応じて常に変化する順序を決定することができます。
### 状況
インナーソースプロジェクトの発見は、[インナーソースポータル](/ja/innersource-portal) と [ギグマーケットプレイス](/ja/gig-marketplace) パターンで促進されるか、他のコミュニケーションチャネルやプラットフォームでプロジェクトを促進することで可能になります。アクティビティスコアは、プロジェクトがコミュニティに提示されるデフォルトの順序を定義しています。
### 組織に働く力学
GitHub API で取得できる自動化された KPI は、全ての事柄のうち一部しか示せていません。コードの品質や優れたドキュメントの有無、活発で助け合うコミュニティなど、そのプロジェクトが楽しくコントリビュートできる場所であるかどうかも重要な事項です。
このような「ソフトなKPI」は、手動または半自動で計算と結果のスコアに追加する必要があります。もし、コードカバレッジレポートのような、リポジトリにより多くのコンテキストを提供するツールがあれば、簡単に取り入れることができます。
### スケッチ
こちらはリポジトリアクティビティスコアの計算と適用をまとめたものです。詳しくは、[結果の状況](#no)をご覧ください。
### ソリューション
リポジトリアクティビティスコアは、インナーソースプロジェクトの(GitHub)活性度を表す数値です。GitHubスター、ウォッチ、フォークなどのリポジトリ統計から自動的に導き出され、他のツールからのKPIや手動評価で付加情報が足されることもあります。
さらに、最終更新日やレポの作成日などの活動パラメータを考慮し、多くのトラクションを持つ若いプロジェクトに活力を与えます。 コントリビューションガイドライン、積極的な参加統計、課題(公開バックログ)を持つプロジェクトも、より高いランキングを受け取ります。
これらはすべて、[GitHub search API](https://docs.github.com/en/rest/search#search-repositories) と [GitHub statistics API](https://docs.github.com/en/rest/metrics/statistics) の結果を使って自動的に取得・計算することが可能です。BitBucket、Gitlab、Gerritのような他のコード・バージョニング・システムも、同様のAPIがあれば統合することが可能です。
以下のコードでは、変数 `repo` に GitHub `search` API から取得したエンティティを、`Participation` オブジェクトに GitHub `stats/participation` API から取得したエンティティを格納することを仮定しています。
必要であれば、ソフトKPI([組織に働く力学](#niku)を参照)に従って手動で調整することもできます。
```javascript
// スター数、ウォッチ数、コミット数、およびイシュー数から仮想のInnerSourceスコアを計算します。
function calculateScore(repo) {
// 初期スコアは 50 にします。GitHub の KPI (フォーク数、ウォッチャ数、スター数) が低い、アクティブなレポジトリをより良いスタート地点にするためです。
let iScore = 50;
// 重み付け：フォーク数とウォッチ数で最もポイント付けし、次にスター数でポイント付け。オープンなイシューの数でも若干のスコアを加える。
iScore += repo.forks_count * 5;
iScore += (repo.subscribers_count ? repo.subscribers_count : 0);
iScore += repo.stargazers_count / 3;
iScore += repo.open_issues_count / 5;
// 過去3ヶ月以内に更新されたもの：総合スコアに0～1の乗数を加える（1＝本日更新、0＝100日以上前に更新されたもの）
let iDaysSinceLastUpdate = (new Date().getTime() - new Date(repo.updated_at).getTime()) / 1000 / 86400;
iScore = iScore * ((1 + (100 - Math.min(iDaysSinceLastUpdate, 100))) / 100);
// 過去3ヶ月の参加状況を評価する
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);
}
// 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);
// gradually scale down boost according to repository creation date to mix with "real" engagement stats
let iDaysSinceCreation = (new Date().getTime() - new Date(repo.created_at).getTime()) / 1000 / 86400;
iBoost *= (365 - Math.min(iDaysSinceCreation, 365)) / 365;
// add boost to score
iScore += iBoost;
// give projects with a meaningful description a static boost of 50
iScore += (repo.description?.length > 30 || repo._InnerSourceMetadata.motivation?.length > 30 ? 50 : 0);
// 貢献ガイドライン(CONTRIBUTING.md)ファイルを持つプロジェクトに、100の加算点を固定して加える。
iScore += (repo._InnerSourceMetadata.guidelines ? 100 : 0);
// 非常に活発なプロジェクトは、対数スケールで構成する（発散的だが5000前後で安定する）
if (iScore > 3000) {
iScore = 3000 + Math.log(iScore) * 100;
}
// 最終スコアは0から始まる四捨五入された整数とする（初期値を差し引いた値）
iScore = Math.round(iScore - 50);
// メタデータにスコアを直接追加する
repo._InnerSourceMetadata.score = iScore;
return iScore;
}
```
### 結果の状況
コントリビューターは、時間の一部をインナーソースプロジェクトに自由にコミットできます。 彼らはまっさきに彼ら自身のチームの仕事において使っているプロジェクトへのコントリビューションを選ぶかもしれません。しかし、人によってはそれぞれの興味や個人的な開発目標に基づいて、まったく異なる何かにコントリビュートすることを選択するかもしれません。
プロジェクトはリポジトリアクティビティスコアで並べ替えて表示できるため、ポータルで意味のある順序を指定して潜在的な新しいコントリビューターに見てもらうことができます。スコアは、プロジェクト進行中に計算することも、すべてのプロジェクトを定期的に評価して結果のリストを保存するバックグラウンドジョブで計算することもできます。
定期的にすべてのインナーソースリポジトリ(例: GitHubで特定の[トピック](https://github.com/topics)でタグ付けされたもの）を検索するクローラーも有用な追加機能になりえます。これは、[インナーソース ポータル](/ja/innersource-portal)のようなツール、検索エンジン、または対話型チャットボットでランク付けされたプロジェクトリストを探せるようにするツールも候補になり得ます。
### 理論的解釈
リポジトリアクティビティスコアは、GitHub API に基づくシンプルな計算です。完全に自動化することができ、新しい要件にも簡単に対応することができます。
### 事例
* SAPのインナーソースポータルで、インナーソースプロジェクトのデフォルトの順序を定義するために使用されています。2020年7月に初めて作成され、それ以来、頻繁に微調整や更新が行われています。2020年7月にこのことを InnerSourceCommons に提案したところ、このパターンが確立しました。また、[Michael Graf & Harish B (SAP) at ISC.S11 - The Unexpected Path of Applying InnerSource Patterns](https://www.youtube.com/watch?v=6r9QOw9dcQo\&list=PLCH-i0B0otNQZQt_QzGR9Il_kE4C6cQRy\&index=6) もご参照ください。
### ステータス
* Structured
### # 著者
[Michael Graf (SAP)](mailto:mi.graf@sap.com)
### 謝辞
InnerSource Commons Community の迅速なアドバイス、そしてこのパターンを養うための多くの有益な意見に感謝します!
* Johannes Tigges
* Sebastian Spier
* Maximilian Capraro
* Tim Yao
### 翻訳の履歴
* **2022-06-07** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
* **2022-06-21** - レビュー [@hirotakatoya](https://github.com/hirotakatoya)
* **2023-06-18** - 最終更新
# 成熟度モデル
### Title
成熟度モデル
### Patlet
チームはインナーソースを採用し始めました。このプラクティスは、複数の部門に広がっています。しかし、インナーソースプロジェクトを構成する概念への理解は様々です。解決策は、チームがセルフチェックを経て、まだ気づいていないパターンやプラクティスを発見できるよう、成熟度モデルを提供することです。
### 問題
企業におけるインナーソースの導入が進み始めると、一人のエバンジェリストを通じて各プロジェクトを個別に指導することは不可能になります。また、インナーソースプロジェクトで働くことの意味について、少なくとも基本的な理解を深めている人が増えてきています。すべてのインナーソースプロジェクトを見てみると、コンセプトに対する理解の深さは異なります。チームは、彼らが次のレベルに移動し、彼らが扱っている問題やペインのポイントを解決するのに役立つだろう実績のあるパターンを認識していない可能性があります。
### 状況
いくつかのチームがインナーソースのプラクティスを採用し始めています。プラクティスの正確な理解度は、チームによって異なります。また、各チームが直面する問題も、各チームの状況や作業環境に応じて異なります。その結果、インナーソースプロジェクトにおける重要なベストプラクティスの定義は、各チームによって異なっています。
### 組織に働く力学
インナーソースのラーニングを共有するチームは、インナーソース採用の各レベルを認識していません。そのため誤解につながることがあります。
チームは、「ソフトウェアの[共有プラットフォーム(フォージ)](https://en.wikipedia.org/wiki/Forge_%28software%29)への移行がすべてだ」と考えています（GitLab、GitHub、Bitbucketがそのようなフォージのよく知られた例です）。
チームは、日々の業務で遭遇する問題を解決するためのベストプラクティスを知りません。
### ソリューション
提案された成熟度モデルに照らして、チームに自己評価をしてもらいましょう。
#### 透明性
**プランとプロダクト (PP)**
インナーソースプロジェクトは、ステークホルダーが決定をよりよく理解し、他の人が従うことができる方法で決定に影響を与えることができるようにすることで、組織全体で透明性のある計画を立てることができ、そのことから恩恵を受けます。
* PP-0: 個人やチームが、複数のステークホルダーに対して定期的にプランやプロダクトを開示していません。組織内に正式なアクションが存在しません。
* PP-1: 個人やチームは、プランやプロダクトが開始される前に、複数のステークホルダーにたいして可視化します。またロードマップは共有されています。
* PP-2: 明確なガイドラインと貢献ルールを持つ共有ロードマップが既に存在し、ステークホルダーがフィードバックを提供できます。しかし、これは組織全体で標準化されておらず、すべてのプロジェクトがこの情報を提供しているわけではありません。
* PP-3: ロードマップはデフォルトで共有され、各インナーソースプロジェクトのレベルで、組織全体でこれを行うための標準的なプロセスとスタンダードな方法があります。これには、ロードマップにコントリビュートして影響を与えるための明確なルールが含まれています。
**開発プロセスとツール (DP)**
インナーソースプロジェクトは、コントリビューターがアクティブになって参加するときに成長します。 結果として、コントリビューションを容易にすることは、純粋な技術的目標とバランスを取る必要があります。
* DP-0：各チームが独自の開発プロセスやツールに従っています。 しかしそれらは、開発チームの外部で知識や成果物を共有するように設定されていません。開発チームはサイロ化されています。
* DP-1: 開発チームは、内部で共有リポジトリを使用します。しかし一部のチームは、企業標準ではないCIツールを使用して、独自のCIプロセスを開発しています。コードレビューのプロセスは定義されていませんが、プロジェクトチーム内部で行っているところもあります。
* DP-2: 組織は、集合知のための共有リポジトリを後援し、推進しています。チームによっては、企業の定めたCIツールを使って、独自のCIプロセスを開発しています。CIの環境があるり、またコードレビュープロセスが定義されており、いくつかのプロジェクトで使用されています。コードレビューが外部のチームメンバによって行われることもあります。
* DP-3: ほとんどのチームが、企業が定めたCIツールを使って独自のCIプロセスを開発しています。CI環境はあり、コードレビュープロセスが定義され利用されています。コードレビューがチーム内外のメンバーによって行われています。
**意思決定(DC)**
同僚にコアチーム以外の仕事へのコントリビューション意欲を持たせるためには、ホストプロジェクトの意思決定プロセスを可視化し、さらに自分たちの声が聞き入れられ評価されていると感じてもらうことが重要です。
* DC-0: 意思決定者はしばしば、プロジェクトの決定に関連するデータや資料を意図的または偶発的に非公開にすることがあります。
* DC-1: 意思決定プロセスの一部である資料は、意思決定が確定した後に閲覧できるようになります。
* DC-2: メンバーは、重要な意思決定のほとんど(すべてではない)について知っており、その意思決定の形成に役立っていると感じています。 意思決定の実践の一部となる資料が、プロジェクトの節目節目で利用できるようになっています。
* DC-3: メンバーは、組織が承認する集合的な意思決定のための共有された標準プロセスの一部であると感じています。意思決定プロセスの一部である資料は、プロセス中に継続的にアクセス可能になっています。
**役立つリソース** コントリビューターを引きつけるために、役立つサポート資料に簡単にアクセスできる必要があります。
* RS-0: 個人およびチームは、ナレッジに関する共有リポジトリにコントリビュートしたり、それを利用したりすることはありません。
* RS-1: 個人およびチームは、作業が終了した後、内部でレビューするためにプロジェクト資料をリリースします。個人とチームはリソースを共有しますが、それは切断された、断片化された、または個別化/サイロ化されたシステムまたはリポジトリにあります。 個人とチームはリソースを共有しますが、情報が機密であるかどうかを判断するために使用される基準について、一般的に表現され共有されているものはありません。「他人と考えを共有する」こともしていません。
* RS-2: 個人およびチームは、明確に定義および共有された形式および/またはプロトコルに従って、プロジェクトチームの一部のメンバーがプロジェクト関連の資料にアクセスできるようにします。個人およびチームは、機密データおよびリソースを差し控え、限定された詳細、コンテキスト、および範囲を提供します。
* RS-3: 個人およびチームは、明確に定義および共有された形式および/またはプロトコルに従って、プロジェクト関連の資料を組織に広くアクセスできるようにします。機密データやリソースを差し控えなければならない個人やチームは、共有しないものについて明確に知っており、他の人はそれらの資料が利用できない理由を理解しています。
**ストーリー** ホストチームの中で働くと、ミスが自動的に目立ってしまうようになります。そのため、失敗を成長の機会としてとらえる企業文化が必要です。
* ST-0: 学習の目的でも、成功や失敗を他者が学ぶために共有しません。
* ST-1: 成功体験は共有しやすい一方で、失敗体験は共有していません。
* ST-2: 個人とチームは、レトロスペクティブやレビューの際に、成功や失敗のストーリーを共有することに抵抗はありません。
* ST-3: 個人とチームは、成功や失敗のストーリーを共有することに抵抗がなく、正式なプロトコルに従って失敗から学ぶことができます。
#### コラボレーション
**フィードバックのためのチャネル**
サイロをなくすには、同僚がオープンにフィードバックを共有することに対する抵抗をなくす必要があります。それをサポートする簡単な方法のひとつは、階層を越えて同じコミュニケーション原則を使用することです。
理想的には、組織の誰もが知っている適切なコミュニケーション・チャネルを持つことになります。チャネルは、異なるターゲット(お知らせ、ユーザーサポート、開発チャネル、インフラ・ディスカッションなど)に焦点を当てます。 インナーソースプロジェクトが成熟するにつれて確立するベストプラクティスには以下のようなものがあります。
* ネチケットガイドラインの採用
* 新しいインナーソースプロジェクトごとに実証済みの（アーカイブされ、一般にアクセス可能で、検索可能な）標準チャネルの開設
* CF-0: プロセスも確立されたチャネルもありません。組織の一部のメンバーは、プライベートチャネルまたはディスカッションを介して資料を共有しています。
* CF-1: 組織は、組織に属する誰もがそれらを使用できるように、会社/部門の決定に関する多様な視点を奨励するための内部ガイドラインとチャネルを確立する過程にあります。 一方で組織の一部のメンバーは、非公式のプラットフォームを使用して非公式に意思決定資料を共有しています。リーダーは、組織のメンバーが自分の仕事に関連するいくつかの問題について建設的に意見を共有するための、少なくともひとつの明確で直接的なチャネルを維持しています。
* CF-2: 組織は内部ガイドラインとチャネルを確立し、チームまたは決定に関する多様な視点を奨励および要請するための特定のリソース（トレーニングプログラム、コンテンツへのアクセスなど）を提供しています。
* CF-3: 組織のメンバーは、公式に認可されたプラットフォームで意思決定資料を共有します。組織のメンバーは、フィードバックのための複数のチャネルと方法を介して資料をオープンに共有します。リーダーはそれらのチャネルを自分で使用し、他の人にそれらを使用するように公に奨励し、受け取ったフィードバックやこのフィードバックに対処するために取った行動のチーム向けまたは公開向けの記録を維持します。
**リーダーシップ**
インナーソースプロジェクトは、従業員が直属のラインマネージャーの直接の影響を受けないプロジェクトにコントリビュートすることを奨励しています。これには信頼の文化が必要です。
* LS-0: 高度に階層化された組織内の命令系統とコントロールのカルチャーがあります。
* LS-1: 一部のリーダーは、フィードバックを受け取り、メンバーが安全にフィードバックを提供できる環境を構築することに積極的です。
* LS-2: 組織のほとんどのリーダーは、フィードバックを受け取り、メンバーが安全にフィードバックを提供できる環境を作ることに積極的です。しかしリーダーは、すべてのメンバーが権限を与えられ、共有できるようになったかどうかを理解することに消極的です。組織は、リーダーが対話のなかに存在しない声を積極的に求めて含めることを奨励しています。
* LS-3: メンバーは、自分の仕事に関連する問題や情熱を持っている問題について建設的に意見を共有できるようになり、力を与えられたと感じています。
**組織的、そして機能的な構造**
インナーソースが純粋なコーディングレベルを離れ、コミュニティやワーキンググループレベルに入ると、直接的なコードコラボレーションが不可能な場合でも、サイロを減らす可能性があります。
* OF-0: ワーキンググループでは、メンバーやスキルセットが固定される傾向にあります、
* OF-1: 機能横断的なチームは存在するものの、チームの役割が不明確で、ガバナンス体制が曖昧であることが多いです。
* OF-2: 機能横断的なチームが一般的であり、チームはその役割と目標を公表しています。
* OF-3: 機能横断的なチームは一般的であり、その活動は組織内に広く知られ、その結果、組織は協業のためのベストプラクティスを推進しています。
**コントリビューション**
コントリビューションパターンを設計する際の目標が、サイロを減らすことである場合、コラボレーションを念頭に置く必要があります。
* CB-0: 完全にサイロ化されており、チーム外でのコラボレーションはありません。コラボレーションはクロスファンクショナルチームによるものがいくつかあります。
* CB-1: 組織のメンバーとチームは協力していますが、「難しすぎる」とよく言われます。 チームは、コラボレーションの結果をめったに再評価しません。
* CB-2: 組織のメンバーとチームは、積極的に協力する機会を求めています。チームは、共同作業の結果について定期的に話し合い、再評価し、議論し、これらの結果をデフォルトで利用できるようにします。
* CB-3: 組織のメンバーは、関係者全員に利益をもたらす方法で、内部と外部の両方で協力します。 チームは共同作業の結果について定期的に話し合い、再評価し、議論し、組織外で学んだことを共有し、これらの結果をデフォルトで外部で利用できるようにします。
#### コミュニティ
**共有ポリシー**
共有値に関するベースラインがあると、チームの境界を越えて作業しやすくなります。限られたベースラインルールとガイドラインのセットがどこにでも適用され、簡単に参照できる場合は、境界を越えることが容易になります。
* SP-0: 共有する文化もドキュメント化されたポリシーもありません。
* SP-1: 組織の一部のメンバーは、価値観や原則を定義するために団結するものの、その際に明確に支持されることはありません。
* SP-2: 組織のメンバーは、ミッションステートメントや行動規範などの共有ビジョンと合意をまとめてドキュメント化し、簡単にアクセスできるようにし、頻繁に参照します。 オンボーディング資料とオリエンテーションの慣例は、新しいメンバーが組織がコントリビューションからどのように利益を得るかを理解するのに役立ちます。
* SP-3: 共有された価値観と原則は、組織のメンバー間で意思決定、コンフリクトの解決、および評価プロセスに情報を提供します。メンバーは、これらの価値観と原則を口頭とドキュメントの両方の形式で一貫して参照します。
**組織の一員であると実感できる**
インナーソースを組織に導入する理由のひとつとして、エンゲージメントの向上が考えられます。このポイントでは、インナーソースを採用している間にエンゲージメントがどのように変化しているかを追跡します。
* PA-0: エンゲージメントが低く、コラボレーションがなく、人々は他の人と共有することに抵抗を感じます。
* PA-1: 組織のメンバーは、報復を恐れることなく自分の考えや意見を共有することに抵抗を感じませんが、それはあくまでも慣れ親しんだ領域でのみです。ただしメンバーは、最高のアイデアが勝ち、コントリビューションとコミットメントの実績を持つ人々にリーダーシップの責任が生じることを理解しています。
* PA-2: 組織のメンバーは、報復を恐れることなく、自分の考えや意見を快適に共有できます。リーダーは、組織の共有価値への献身を示します。
* PA-3: 組織はメンバーにコントリビューションの恩恵を受けていることを積極的に伝えています。このように、メンバーは共有された意識と権限を与えられた実行を示し、コミュニティへの責任感を感じます。リーダーは、他の人の成長を支援することで成長することを理解し、組織のジュニアメンバーを指導します。
#### ガバナンス
**リワード**
チーム横断的なコラボレーションを促進するために、外発的モチベーションを利用することができます。
* RW-0: 報酬が設定されていません。
* RW-1: リーダーは例外的なコラボレーションに対して報酬を与えるよう奨励されていますが、方針やプロセスは確立されていません。
* RW-2: 開発者チーム以外のコラボレーションに報酬を与えるための標準的なプロセスが確立されています。チームリーダーや役員会が報酬を決定しています。
* RW-3: 報奨は組織から提案されるだけでなく、コミュニティがより価値のある報奨を定義することができます。コミュニティが責任を持って報酬を決定しています。
**モニタリングポリシー**
インナーソースのプロジェクトは、自己を評価のための手段を必要とします。メトリクスは、この評価を容易にするための一つです。またインナーソースの導入レベルが成熟している組織では、明確で合意された測定基準に基づいて、この手法の導入が追跡されることが期待されています。
* MP-0: 組織内のどのレベルにおいても、既存の監視ポリシーがありません。
* MP-1: メトリクスは特定のチームにとって重要であり、独立した方法でそれらは使用が始まっています。
* MP-2: 組織全体で特定の方針を検証するのに役立つ測定基準に関して、組織レベルでの戦略があります。このモニタリング方針は、いくつかのインナーソースプロジェクトのレベルでも存在します。
* MP-3：組織が提供する特定のインフラストラクチャでのメトリックの使用に関する明確なガイドライン、推奨事項、およびトレーニングがあります。これは組織内での一般的なインナーソース採用を理解するためのインナーソースプログラムと、インナーソースプロジェクトの2つのレベルで機能します。
**サポートとメンテナンス**
インナーソースチームは機能開発のみを担当するのではなく、サポートとメンテナンスもチームのコアタスクの一部です。
* SM-0: コア開発またはサポートチームによるサポートが存在します。ビジネスサイドはサポートを保証します。チーム外には製品についての知識がありません。
* SM-1: 専任のサポートチームによってサポートが提供されます。製品のサポートを形式化するための規則と規制があります。
* SM-2: インナーソースコントリビューションのサポートは、[30日の保証期間](/ja/30-day-warranty)や[ライブラリよりもサービス](/ja/service-vs-library)などのインナーソースパターンによって形式化されています。
* SM-3: 成熟したコミュニティによって提供される、製品のサポートを形式化するための規則と規制があります。
**カルチャー**
協調的な文化に対する複数のレベルがあります。
* CL-0: サイロ - チームは独立して機能しますが、単独でも機能します。
* CL-1: リアクティブ - チームは独立して動きますが、うまくいかない依存関係に対応する方法を知っています。
* CL-2: コントリビューション - チームはコントリビュートすることで依存関係の改善を積極的に支援します。
* CL-3: アクティビスト - チームは積極的に助けを求め、メンタリングをし、新しいコントリビューターを募集します。
**インナーソースにおける役割**
インナーソースにはいくつかの明示的な役割があります。初期の段階では、これらの役割を採用しなくても一部のパターンを使用できる場合がありますが、明示的な役割のタイトルを使用してプロジェクト内でコミュニケーションする方が簡単になります。
* RO-0: インナーソースの採用を支援する特定の役割はありません。開発者、アナリスト、テスターなど一般的な開発の役割のみが存在します。
* RO-1: 時折、一部の個人やチームが他のプロジェクトにコントリビュートします。これらは技術的なコントリビューションであり、ユーザー/コントリビューターの役割が見られます。 チームによっては、少なくとも一人のメンバーが、他の開発チームのメンバーに開発プロセスを説明する技術的なリファレンスであることが確認されています。このメンバーはトラステッドコミッターの役割をカバーするための候補者となりえます。
* RO-2: 「インナーソースオフィス」が存在します。インナーソースオフィサーの役割は、ガバナンスとサポートを担当します。プロセスなどを含みます。教育ニーズを特定し、組織に提供されることを確認します。ISプロジェクトへの組織の参加をリードし、メンタリングします。インナーソースのビジョンとロードマップを定義するための最初の公式ステップです。組織は、開発チームのメンバーだけでなく、外部の貢献者に対しても連絡先/参照先となる信頼できるコミッターの役割を定義しています。コミュニティへの貢献方法を説明する標準的なプロセスがあり、貢献者の役割が存在します。データサイエンティストの役割は、インナーソースイニシアチブによって残されたアクティビティの痕跡を管理し、インナーソースの進化を測定するために必要です。信頼できるコミッターの役割は、より技術的なプロフィールに進化し、コミュニティマネージャーはコミュニティを「活性化」する役割を担当し、主な責任は新しい開発者/ユーザー（貢献者/コミュニティメンバー）を引き付け、維持することです。
* RO-3: 「エバンジェリスト」は組織内を移動し、現在の作業、インナーソースの機能とその方法を他の人に知らせ、他の人がイニシアチブを理解して参加できるように支援します。この段階では「非技術的なコントリビューター」の存在も出現します。
### 結果の状況
すべてのチームが、利用可能なベストプラクティスを認識しています。
チームは、インナーソースの採用のレベルを理解しています。
作業モデルとしてインナーソースを採用する前に、チームは短期的にも長期的にも、チームに期待されるプラクティスを認識しています。
### 事例
* Entelgy
* Zylk
* Bitergia
### 著者
* Daniel Izquierdo Cortazar
* Isabel Drost-Fromm
* Jorge
* Nerea
### 謝辞
* Alexander Andrade (スペルの修正に特に感謝します)
### その他の呼び方
成熟度モデル: インナーソースのベストプラクティスについて学ぶ
### ステータス
* Structured
* Drafted in September 2019
### 翻訳の履歴
* **2023-06-18** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
* **2023-06-18** - 最終更新
# 持続可能な成長のためのエクステンション
### Title
持続可能な成長のためのエクステンション
### Patlet
インナーソースプロジェクトは多くのコントリビューションを受けており、メンテナンスが難しくなっています。メンテナは、プロジェクトのコア部分から離れた拡張機構を提供することで、最小のコストとメンテナンスオーバーヘッドでプロジェクトの能力をスケールアップすることを可能にします。
### 問題
成熟したインナーソースリポジトリへのコントリビューションが急速に増えると、コードレビューやメンテナンスの負担が増大します。これにより、大量のコードレビューのバックログが生じたり、新しい機能のコントリビューションが早期に拒否されたりする結果となります。
ホストチームは、新しい機能のリリースをより早く行い、イノベーションと実験を奨励しつつ、リポジトリを適切にメンテナンスするためにはどのようにすればよいのでしょうか？
### ストーリー
特定のドメインスペース内での最高のイノベーションを一つの共通スタックに集め、共通のインフラストラクチャの再利用を可能にし、標準的なユーザーエクスペリエンスを提供することを目指す戦略的なプロジェクトが存在します。インナーソースを通じて、組織内の各チームは、そのドメインスペース内で働きながら、共通のコードベースにイノベーションをコントリビューションする機会を得ます。
しかし、複数の開発者からの並行したコントリビューションが多くなると、コードベースのメンテナンスが難しくなります。 それは、プロジェクトのメンテナはコードの品質基準に対するオーナーシップを引き受けることになり、さまざまな形式のコミュニケーションを通じてコミュニティを支えるという大きな負担がかかるからです。
プロジェクトのメンテナは以下のようなリスクに直面しています:
* コントリビューターからのプルリクエストのバックログが絶えず存在する
* 職業の不満: メンテナの時間の大部分がコミュニティサポートの支援に使われてしまい、新しいことに挑戦する時間がない
* 成果感の欠如: 提供されたすべての機能が適切なユーザー需要を満たすわけではなく、それによって結果的に採用されるとは限らない
* リリースに時間がかかる: コードベースに多くの機能があると、テストに時間がかかる
* メンテナンス活動の増加: 新しい機能が追加されると、バグが増える
可能性のあるユーザーがその機能を自分のユースケースに適用する機会を得る前に、新しい機能のコントリビューションが成熟するまでに多くの時間が費やされています。もし新しい機能がユースケースを満たさなければ、求められていたコード品質基準を達成するために費やした全ての時間が無駄になります。
### 状況
* 戦略的なインナーソースコードベースが、多数の従業員からの新機能のコントリビューションで急速にスケールアップしています。
* レビュアーとコントリビューションの比率により、プルリクエストのバックログが増加しています。これにより、新機能のリリースがコミュニティに対して遅くなっています。
* コードベースの品質が劣化し、ユーザーエクスペリエンスが悪化しています。
* コードベースのメンテナが負荷を感じ、コントリビューションの増加とコミュニティサポートの増加に対応できなくなっています。
* 提供された機能の一部はユーザーに採用されず、完全に不活動になる可能性があります。しかし、それらが使用されていないにもかかわらず、これらの機能は依然としてメンテナンスのオーバーヘッドを増やしています。
* 組織は、新しい機能のコントリビューションを品質基準を保持するために厳しく対応している一方で、コミュニティがアイデアを探求する前に大量の投資を行っています。
* 次の2つのシナリオのどちらかでパターンが適用されます:
* メンテナがプロジェクトの範囲を絞り込むために、自身で新しい機能のアイデアを拒否することにより、コミュニティのイノベーションを阻害し、さらなる拡大を制限しています。
* バックログを減らすために、新しい機能が十分なドキュメンテーション、ハードニング、テストなしにリリースされ、ユーザー体験が悪化します。これにより、コードベースのサイズが大きくなり、依存関係が大きくなり、メンテナンスが難しくなります。
### 組織に働く力学
* メンテナとプロダクトオーナーは、拡張、イノベーション、実験を促進しつつ、コントリビューションに対して過度に制限を設けずに、良好なコードと品質基準を保持したいと考えています。
* 特性を製品基準に適合させ、徹底的にテストするために多くの時間が費やされますが、製品オーナーは新しいイノベーションを機能が成熟する前に製品が探求できるように、新しいイノベーションのリリースを早めたいかもしれません。
* メンテナは、プライマリリポジトリにより多くの依存関係を追加せずに、コミュニティが製品の機能と他のユースケースを組み合わせたイノベーションを共有することを奨励したいと考えています。
### ソリューション
高規模なインナーソースコードベースへの[拡張/プラグイン(英語)](https://en.wikipedia.org/wiki/Extensibility)を許可することで、リポジトリのメンテナに対するメンテナンスの負担を軽減し、新機能のリリースを探求する製品のリリースを早めることができます。これにより、機能のメンテナンスを拡張所有者に移し、プライマリリポジトリがより広範に採用され、より戦略的にサポートされる機能を支援することが可能になります。
拡張機能は、最終的にプロジェクトのコアに移動する可能性のある新たな機能のフィルターとして機能します。また、拡張機能はインキュベーションとコミュニティのハードニング環境としても機能し、そのハードニングが高価なレビュープロセスではなく、自然に行われるようにします。
拡張モデルを成功させるためには、いくつかのアーキテクチャ上の考慮事項が必要です:
1. **作成が簡単:** コミュニティの参加を得るためには、拡張機能を簡単に作成できる必要があります。
* 拡張機能がスタートポイントとして使用するべきリポジトリテンプレートを作成します。これにより、拡張機能は新しいリポジトリに新機能を追加することができ、コアプロジェクトとは別になります。テンプレートはプライマリリポジトリと同じモジュール構造を提供し、拡張機能のパッケージ化とリリースのフレームワークを含むべきです。
* プライマリリポジトリが変更されると、テンプレートが適切に保守されていることを確認します。プライマリリポジトリのメンテナがテンプレートを更新し、メインプロジェクトとの互換性を保証します。良いバージョニング規則を守ること、例えば、[semver](https://semver.org/)の使用がこれを容易にします。
* さらに、新しいバージョンがリリースされると、プライマリリポジトリのメンテナが古いバージョンのテンプレートに基づく拡張機能の更新方法についてのガイドラインを提供することを推奨します。
* テンプレートから開発された拡張機能の例を追加します。これにより、プロジェクトの開発者は、どのようにして良いパターンの拡張機能を書くべきかを理解することができます。
* レビューをバイパスして拡張機能を作成する寄稿者の要件を緩和し、リリースや実験を早めることを許可します。
2. **疎結合:** 機能を含むモジュラーなコンポーネントを持つことで、拡張機能への変更がメインコードベースや他の拡張機能の品質に影響を与えない疎結合を可能にすることができます。
3. **依存性管理:** 各拡張は、それが構築されるプライマリリポジトリのバージョン範囲をピン留めするように注意する必要があります（他の依存関係と同じように）。また、それがプライマリリポジトリの依存関係をシャドーする他の依存関係の使用についても注意深くなければなりません。選択した依存関係のバージョンがプライマリリポジトリの選択したバージョンと互換性があるようにします。プライマリリポジトリとの任意の競合は、拡張のテストフレームワークで検出できます。
4. **テスト戦略:** 拡張機能を個別に、または組み合わせてテストする方法は？
* **拡張機能を個別にテストする:** 拡張機能のテンプレートは、拡張機能の開発者が追加した機能をテストするためのテストフレームワークを提供します。これには、ユニットテスト、ランタイムパフォーマンステスト、品質テストのフレームワークが含まれることがあります。
* **拡張機能をプライマリリポジトリと組み合わせてテストする:** 拡張機能の開発者は、プライマリリポジトリの特定のバージョンに対して自分の拡張機能をテストするための良好なパターンの方法を持つべきで、これにはプライマリリポジトリのメンテナの関与は必要ありません。
* **拡張機能を他の拡張機能と組み合わせてテストする:** このシナリオのためにテストフレームワークを提供することは、特に、ユーザによってまだ調査中であり、すべての拡張機能を組み合わせて使用する可能性が低い多数の拡張機能がある場合、過剰になる可能性があります。もしユーザが拡張機能を組み合わせて使っているときにコンフリクトに遭遇した場合 (十分な疎結合であればありえないはずです)、ユーザはそれぞれの拡張機能の所有者に問題を提起することができます。拡張機能がライフサイクルの後半に達し、プライマリリポジトリにマージされるようになると、ライブラリの残りの部分と組み合わせてテストされるようになり、依存関係の衝突はその時点で解決されなければならなくなります。
5. **発見性と利便性:**
* ユーザーが作成し、製品の使用に共有したいと思っている拡張機能を表示する公開ページで、拡張機能を容易に発見できるようにします。
* ユーザーが元のプロジェクトと一緒に拡張機能を利用できるように、プライマリプロジェクトに拡張機能の登録を許可します。これにより、同じユーザーエクスペリエンスが維持されます。
6. **拡張機能のライフサイクルと保守性:** 拡張機能の作成からプライマリコードベースへの移植までのライフサイクルを確立し、明確な所有権ガイドラインを作成します。
* 拡張機能の作成者は、拡張機能のメンテナンスを続け、サポートを提供し、欠陥を修正します。保守されていない拡張機能は、公開ページからリストから削除されます。
* 内部製品による拡張機能の採用と機能への需要など、プライマリリポジトリへの移植が可能になる基準を作成します。
* 拡張機能のプライマリリポジトリへの移植プロセスは、ライブラリメンテナによって設定されたより厳格なコードレビューガイドラインに従います。
これらの原則に従うことで、以下が確保されます:
* 開発者は、大量の[ボイラーテンプレート(定型)](https://en.wikipedia.org/wiki/Boilerplate_code)コードを書くことなく、プロジェクトのエコシステムに新しい機能を追加することができます。
* 拡張機能は、プライマリプロジェクトの全てのユーザーによって反復可能な方法で発見できます。コードがまだメインリポジトリに存在していないとしても、それが価値がないわけではありません。
* メンテナの負担は、拡張機能がプライマリプロジェクトで重要なギャップを埋めていることを示すまで軽減されます。
* コアプロジェクトの共通コード（例えば、ベースクラスやユーティリティ関数）は、プロジェクトの領域を拡張する新しい開発の出発点となります。これにより、革新的な作業を後から移植する必要がなくなり、プロジェクトにとって新しい機能を開発する全体的な負担を軽減します。
* 開発者は、コードベースのためのコミュニティのメンテナンスとコミュニティ構築にコントリビューションし、関与し続ける可能性が高くなります。これは全体のプロジェクトエコシステムの健康にも良い影響を与えます。
### 結果の状況
* プロジェクトは、新しい機能の追加により拡大することができ、プライマリプロジェクトリポジトリにメンテナンスのオーバーヘッドを追加することなく、拡大することができます。
* コミュニティが探求する新機能のリリースが早まり、革新と実験を奨励します。
* 機能がその有用性を証明するまで、高額なコードレビューと機能強化プロセスが削減されます。これにより、組織に対するコスト節約の利益が得られます。
* 一つの問題が導入される可能性があります - 拡張機能がフルライフサイクルを完了できない場合、何が起こりますか？
* 拡張機能が一定期間採用されず、それをサポートするコミュニティを形成できなかった場合、そのメンテナンスを続けるかどうかは拡張機能のオーナー次第です。もし拡張機能がメンテナンスされなくなった場合、それは非公開になります。
* 拡張機能の開発者がそれ以上のプロジェクトを維持できなくなり、コミュニティ内の他の開発者がそれを引き続きサポートしたい場合、彼らはその拡張機能の維持を進めていくことができます。
### 事例
* **IBM社**は、[インナーソース AIライブラリ](https://youtu.be/Lz-tIc2cyRM)を拡大するためにこの解決策を採用しています。拡張機能を使用することで、開発者はAIライブラリに更に多くのアルゴリズムを追加し、彼らの革新を企業内のコミュニティと共有することができます。コアライブラリには、採用されて検証された戦略的なアルゴリズムのみが含まれており、これにより我々はコントリビューションをスケールするにつれてそれらをより簡単に維持することができます。
### エイリアス
大規模にコントリビューションを管理するための拡張
### ステータス
* Structured
### 著者
* Sukriti Sharma, IBM
* Alexander Brooks, IBM
* Gabe Goodhart, IBM
# パターンテンプレート
### Title
Short Title Here
### Patlet
Concise 2 sentence description of the problem and solution. The 1st sentence describes the problem. The 2nd sentence describes the solution. Readers may quickly review dozens of these patlets (aka summaries) to discover and browse the larger library of patterns. From .
### Problem
What is the problem - crisp definition of the problem. Short description, usually not more than a couple sentences, that describes what the issues and challenges are. Be careful not to morph into information found in other sections below.
### Story (optional)
Sometimes there is a story that helps people understand the pattern better.
### Context
Where does the problem exist? What are the pre-conditions? **Unchangeable** before the solution goes into place. The content here is often tied to the applicability of the pattern for other readers: "Do I have this same particular situation?"
### Forces
What makes the problem difficult? What are the trade-offs? These are constraints that **can be changed** at a cost. The solution might change one or more of these forces in order to solve the problem, while also in-turn changing the context.
### Sketch (optional)
visual illustration
### Solutions
Verified resolutions and possible resolutions to the problem.
### Resulting Context
What is the situation after the problem has been solved? The original context is changed indirectly by way of the solution. Often this section can include discussion of the next possible Patterns/problems introduced. This section can be short in content - the solution may not introduce new problems or change much context.
### Rationale (optional)
Explains why this is the right solution; using totally different words WHY this solution balances these forces and this context to solve this problem. Can expand on what-if's or theories.
### Known Instances (optional)
Where has this been seen before? Helps to reinforce that this is a REAL pattern and that you match the context.
May mention:
* A particular business
* Anonymized instances ex: "3 companies have proven that this is a good solution" or "A large financial services org...".
### Status (optional until merging)
General pattern status is stored in GitHub's Label tagging - see any pull request. Note that this GitHub label tagging becomes less visible once the pattern is finalized and merged, so having some information in this field is helpful.
You might store other related info here, such as review history: "Three of us reviewed this on 2/5/17 and it needs John's expertise before it can go further."
### Author(s) (optional)
Often, this is yourself. If you need to, find someone in the InnerSource Commons to be the nominal author (As Told To). Could also be no-one if you do not want to take on authorship (common with a donut looking for a solution).
### Acknowledgments (optional)
Include those who assisted in helping with this pattern - both for attribution and for possible future follow up. Though optional, most patterns should list who helped in their creation.
### Alias (optional)
If this pattern is also known under a different name than what is listed under **Title**, please list those alternative titles here. e.g. if the pattern is named after the problem it solves, a helpful alias might be one that describes the solution that is applied.
# その他
# README テンプレート
## ミッション
あなたのプロジェクトのミッションについての簡潔な(3〜5行の)説明が含まれている必要があります。このセクションのゴールは、あなたが何に取り組む予定かを述べ、外部のコントリビューターがこのプロジェクトに歓迎されそうな機能の種類をおおよそ理解できるようにすることです。 Producing Open Source Software の [Mission Statement Chapter](https://producingoss.com/en/producingoss.html#mission-statement) も参照してください。
## はじめに
このセクションには、初めてプロジェクトを使う人に向けた、使い始めるための簡単な説明を記載します。さらに詳細なドキュメントにはここからリンクをさせましょう。
## 詳細
このセクションでは、以下のいずれか、またはすべてを列挙することができます。
* ソフトウェアが対応する機能、ユースケースのリスト
* トレードオフを解決するために使用される設計原理に関する情報
* ユーザーレベルのドキュメントへのリンク
* よくある質問(FAQ)に対する回答。できれば、特定の質問とその回答にリンクして、簡単に参照できるようにした形式が望ましいです。
## ヘルプ
このセクションには、ユーザーとしてプロジェクトのヘルプを得る方法についての簡単なドキュメントを記述します。 イシュートラッカーをユーザーに対して指し示すようにシンプルなディレクションでもかまいません。また、アーカイブされ検索可能なチャットチャネルとメーリングリスト、オンラインのユーザーフォーラムを紹介することもできます。
## 参加するには
このセクションには、プロジェクトと連絡を取る方法に関する情報を含める必要があります。通常これにはアーカイブされた検索可能およびアクセス可能なコミュニケーションチャネルへのリンクが含まれます。
## 私たちについて
このページは、プロジェクトのトラステッドコミッターに謝意を表すのに良い場所です。 また、このプロジェクトにおいてトラステッドコミッターであることが何を意味するのかについての情報を含めるのにも良い場所です。 理想的には、組織内のすべてのプロジェクトが同じ定義を使用のが良いでしょう。その場合、すべての README が同じ定義へのリンクを貼ることになります。 このリンクを残す理由は、インナーソースのプロジェクトで働いたり貢献した経験がない、もしくは少ない同僚が、日々の仕事に必要な技術プロジェクトから会社全体の情報へのダイレクトリンクを持てるようにするためです。
## コントリビューションについて
このセクションでは、初めての人がコントリビュートを始めるために知っておく必要があるすべての事柄についてドキュメント化(もしくはリンクを貼る)する必要があります。 以下のトピックのすべてがカバーされることは希ですが、あなたのプロジェクトが標準的なセットアップと何が違うのか、以前のコントリビューターが理解しにくいと感じたことに重点を置いて書いてください。
* ソースコードを見つける方法
* プロジェクトで助けを必要としている問題のリストを見つける方法。これらの問題は、技術的・非技術的な両方の問題になりえます。通常、これらの問題は、コントリビューターがアクセスできるイシュートラッキングシステムも掲載されます。
* プロジェクトのアーキテクチャ、一般的なコーディング規約、テスト規約など、さらなるドキュメントへのリンク
* 技術的なコンとリビューションについて、変更を加え、プロジェクトをビルドし、変更をテストする方法
* 変更した内容をプロジェクトにサブミットする。
理想的には、プロジェクトにとって望ましい変更プロセスがどのようなものであるかについての情報も含めてください。コントリビューターはまずイシューを作成して提案を提出すべきなのか、それともすぐにでも変更を提出することができるのか。投稿をレビューする際に重要なことは何ですか?
さらに、プロジェクトで守りたい設計の価値観についても概要を説明しておく必要があります。これらを明示することで、トレードオフをより早く、より簡単に解決できることがよくあります。さらに、暗黙の前提に対する変更を透明化するのにも役立ちます。
時間が経つにつれて、このセクションがかなり大きくなっていることに気がつくと思います。その場合は、例えば `CONTRIBUTING.md` と `TESTING.md` のように、情報を別のファイルに移動することを考えてみてください。
# CONTRIBUTING テンプレート
## コントリビューションの種類
プロジェクトがどのような種類のコントリビューションを求めているのか、ここに情報を提供してください。例えば、バグレポート、ユーザーの質問に対する回答、ドキュメントの改善、バグの修正、新機能の実装などです。
## バグレポート
バグレポートの提出方法に関する情報をここに追加してください。これには、問題を再現し修正するためにプロジェクトがどのような情報を必要とするかについてのヒントが含まれるべきです。また、よく見られるバグのような設定ミスの情報も含めることができます。
また、初動までの時間やその後のプロセスなどに関して、コントリビューターが期待すべき情報についても記載してください。
## 機能リクエスト
機能リクエストを提出する方法についての情報をここに追加してください。また、初動までの時間やその後のプロセスなど、コントリビューターが期待すべき情報についても記載してください。
## ドキュメントに対するコントリビューション
プロジェクトが遵守しているドキュメントのベストプラクティスや、ドキュメントの構築方法、チェック方法、プロジェクトに変更を戻す方法などの情報を含めてください。
## ソースコードに対するコントリビューション
このセクションでは、以下の情報を提供します。
* プロジェクトのソースコードにアクセスする方法
* プロジェクトの一般的なレイアウト
* 開発環境に対する要求事項
* コードの書式に関するガイドライン
* テストの実行方法
## トラステッドコミッターになるには
このセクションでは、トラステッドコミッターになるためのプロセスがコントリビューターに開かれている場合、そのプロセスを明示する必要があります。
## トラステッドコミッターをノミネーションする方法
このセクションは、既存の トラステッドコミッターへのリマインダーと、新しい トラステッドコミッターへの説明として、他のメンバーをホストチームに追加する方法について説明するものです。繰り返しになりますが、この情報は組織内のすべてのプロジェクトで同じものであることが理想的で、ここから中央の情報にリンクさせることができます。
# 介绍
{% hint style="info" %}
你正在阅读《内源模式》的早期版本，可能仍然会发现破碎的链接、拼写错误或其他错误。 请帮助我们解决这些问题，以便尽可能制作出最好的图书:)。了解如何[为这本书做贡献](/zh/contribute).
{% endhint %}
欢迎来到**内源模式**。
这本书包含了内源的最佳实践，并以特定的格式进行编纂，以便于理解、评估和在你的环境中应用它们。我们称这种格式为**模式**。
[InnerSource Commons](http://innersourcecommons.org)多年来收集了这些模式，在本书中发布了最成熟的模式，社区成员对每个模式进行了评审，至少有一个已知的模式使用实例。
在这篇介绍中，我们解释了[内源是什么](#nei-yuan-shi-shen-me)，[内源模式是什么](#nei-yuan-mo-shi-shi-shen-me)，以及[如何在你的组织中使用这些模式](#ru-he-shi-yong-zhe-xie-mo-shi) 。
如果你已经在你的公司使用内源，并想把你的经验贡献给本书，我们很乐意[欢迎你的贡献](/zh/contribute)!
## 内源是什么?
我们将内源定义为。
> 在一个组织的范围内使用开源的原则和实践进行软件开发。
内源从开发开源软件中吸取经验教训，并将其应用于企业内部开发软件的方式。由于开发人员已经习惯于在世界级的开源软件上工作，人们强烈希望将这些实践带回防火墙内，并将其应用于公司可能不愿意公开发布的软件。
对于那些主要构建闭源软件的公司来说，内源可以成为一个很好的工具，帮助打破孤岛，鼓励和扩大内部协作，加速新工程师的入职成长，并找到机会将软件贡献给开源世界。
## 内源模式是什么?
模式是一种描述在某一背景下对某一问题的可重复的、经过验证的解决方案的方式。模式遵循一种简单的形式，在实施解决方案的过程中，协助你了解问题的限制，了解你需要平衡的限制条件，以及由此产生的结果--应用解决方案所创造的情况。
模式可以为InnerSource Commons的参与者提供一种简明的信息分享方式，改善内源的实践。模式分为标题、问题陈述、背景、约束和解决方案，作为其主要部分。
* ["什么是模式？"Youtube视频](http://bit.ly/innersource_patterns_videos) - 观看一组2-5分钟的Youtube视频，解释内源模式。
* [模式讨论网络研讨会](https://youtu.be/i-0IVhfRVFU) - 我们在2017-03-16举行了一次网络研讨会，现场讨论一个甜甜圈模式(进入24:30的讨论)。这是对我们所遵循的评审过程的说明。也可参见[2017年6月1日O'Reilly网络研讨会上的内源模式](http://www.oreilly.com/pub/e/3884) 。
* [模式模板](/zh/fu-lu/pattern-template) --查看一个内源模式的骨架，了解新模式的内容!
* [内源模式介绍（2016年秋季峰会演讲）](https://drive.google.com/open?id=0B7_9iQb93uBQbnlkdHNuUGhpTXc) - *Tim Yao和Padma Sudarsan* (PDF)。详细的模式背景和例子 -- 详细了解为什么以及如何与我们的模式互动。也可参见[内源模式介绍(2017年秋季峰会)](https://drive.google.com/open?id=0B7_9iQb93uBQWmYwMFpyaGh4OFU) *Tim Yao和Bob Hanmer* (PDF)。
## 如何使用这些模式?
模式的使用必须经过深思熟虑。它们不能被不加区分地应用。在大多数情况下，你需要根据你的情况来调整给定的解决方案；但模式中给出的信息，定义了背景（不可移动的约束）和力量（可以改变和相互平衡的约束），应该有助于你应用这些模式。请注意，你还需要确定是否有额外的约束（公司背景和公司力量）适用于你的特定公司/组织，必须添加到模式中（作为一种过滤器）。这些额外的制约因素可能需要额外的解决步骤来应用。
模式的形式对于描述成熟的解决方案是很有用的，但它也可以用于*脑力激荡的新解决方案*，创建哪些尚未建立的模式。这是因为模式的解剖提供了一个以结构化方式思考问题的框架。你也可以创建一个*甜甜圈模式*（填写问题、背景、约束和结果等字段，但在解决方案留空），作为向InnerSource Commons社区寻求帮助的一种方式（找到一个成熟的解决方案或做一次集思广益的尝试）。
## 如何贡献?
请参考: [为这本书做贡献](/zh/contribute)
## 致谢
本书是世界各地无数[开源贡献者](https://github.com/InnerSourceCommons/InnerSourcePatterns/graphs/contributors)多年工作的成果。他们愿意公开分享他们在公司所面临的挑战，以及内源如何帮助他们解决这些挑战，使本书成为其他人在内源旅程中的宝贵资源。
我们要特别提到内源模式工作组。他们孕育了内源模式的质量，并帮助其他人作出贡献。最后，他们还将一些可用的模式汇编成了这本书。
本书的标题图片由[Sebastian Spier](https://spier.hu)创作，并改编自[Tony Hisgett - Alhambra 6](https://www.flickr.com/photos/hisgett/29345405788/)的图片，可根据[CC BY 2.0](https://creativecommons.org/licenses/by/2.0/)获得。
**感谢所有的贡献者! 并祝内源日快乐 :)**
## Licensing
InnerSourcePatterns by [InnerSourceCommons.org](http://innersourcecommons.org) is licensed under a [Creative Commons Attribution-ShareAlike 4.0 International](http://creativecommons.org/licenses/by-sa/4.0/) License.
## 翻译校对
* **2022-12-21** 翻译[姜宁](https://github.com/willemjiang)
* **2022-12-28** 校对[龙文选](https://github.com/hncslwx)
# 目录
* [介绍](/zh)
* [目录](/zh/toc)
* [模式探索](/zh/explore-patterns)
* [为这本书做贡献](/zh/contribute)
## 模式
* [30天保修](/zh/p/30-day-warranty) - 当接受来自自己团队以外的贡献时，人们自然不愿意为非本团队自己编写的代码负责。通过30天保证，贡献团队同意向接受团队提供错误修复，这将增加两个团队之间的信任度，使贡献更有可能被接受。
* [Trusted Committer](/zh/p/trusted-committer) - 许多内源项目会发现自己处于这样一种情况：他们不断收到来自贡献者的反馈、功能和错误修正。 在这种情况下，项目维护者会想方设法对贡献者的工作进行认可和奖励，而不仅仅是对单一的贡献认可。
* [不要吝啬对参与者的夸奖](/zh/p/praise-participants) - 及时感谢贡献者对内源项目贡献的时间和付出是很重要的。 这种模式不仅提供了有效地承认了贡献的指导，而且还吸引贡献者和其他人的进一步参与。
* [专职的社群领导](/zh/p/dedicated-community-leader) - 选择同时具备沟通和技术能力的人领导社群，以确保成功推动内源倡议。
* [交流工具](/zh/p/communication-tooling) - 一个内源项目正在原始开发团队之外使用，但用户在寻求帮助和与项目团队联系时遇到困难。 我们的想法是建立和记录标准的通信工具，使讨论变得可见、存档和可搜索。
* [代码仓活跃度评分](/zh/p/repository-activity-score) - 潜在的贡献者希望找到需要他们帮助的活跃的内源项目。通过计算每个项目的代码库活跃度评分，可以创建一个项目的排名列表（例如在内源门户网站上），这样潜在的贡献者可以更容易地确定他们想要贡献的项目。
* [以实验的方式开始](/zh/p/start-as-experiment) - 将内源实践倡议作为一个有时间限制的实验开始，使不熟悉内源的管理人员更容易认可和支持该倡议。
* [共同的需求](/zh/p/common-requirements) - 共享代码库中的通用代码不能满足所有想要使用它的项目团队的需要；这一点可以通过需求调整和重构来解决。
* [内源许可证](/zh/p/innersource-license) - 属于同一组织的两个法律实体希望彼此共享软件源代码，但他们担心在法律责任或跨公司会计方面的影响。
* [内源门户网站](/zh/p/innersource-portal) - 潜在的贡献者很难找到他们感兴趣的内源项目。你可以通过创建一个索引所有可用的内源项目信息的内部网站，可以让贡献者了解他们可能感兴趣的项目，也可以让内源项目的负责人发展外部受众。
* [利用RFC进行透明的跨团队决策](/zh/p/transparent-cross-team-decision-making-using-rfcs) - 内源项目如果想实现高参与率，并为每个参与者做出最好的决定，就需要想办法在整个软件生命周期中建立易于参与式的环境。发布内部征求意见稿（RFC）文件，可以在设计过程的早期就进行讨论，并促进在参与各方在高参与度下建立解决方案的机会。
* [基准级的文档](/zh/p/base-documentation) - 内源项目的新贡献者很难搞清楚谁在维护这个项目，该做什么，以及如何贡献。在标准文件中提供文档，如README.md/CONTRIBUTING.md，可以为新的贡献者提供一个自助服务流程，这样他们就可以自己找到最常见问题的答案。
* [小组支持](/zh/p/group-support) - 如果某个团队或个人不再支持 InnerSource 项目怎么办？ 由一群感兴趣的个人组成小组来保持项目活跃。
* [成熟度模型](/zh/p/maturity-model) - 各个团队已经开始采用内源。这种做法正在向多个部门蔓延。然而，人们对什么是内源项目的理解各不相同。解决方案是提供一个成熟度模型，让团队通过自我检查，发现他们还没有意识到的模式和做法。
* [服务 vs. 库](/zh/p/service-vs-library) - 由于对服务宕机责任的模糊不清，DevOps团队都不太愿意基于公共代码进行跨团队工作。 解决办法是让大家认识到通常情况下：要么在独立的环境中部署相同的服务，在服务宕机时有独立的问题处理兜底机制；要么将大量的共享代码纳入一个库，大家在此基础上进行协作。
* [标准发布流程](/zh/p/release-process) - 如果团队不确定 InnerSource 项目的成熟度，他们可能会犹豫是否采用该项目。为了解决该问题，一致的发布说明和已发布制品至关重要。这些做法展示了对项目的坚定承诺，为用户提振了信心，并向他们保证了对可持续和管理良好的软件的持续承诺。
* [核心团队](/zh/p/core-team) - 即使一个内源项目被广泛应用，但也可能因为项目难以协作而阻碍项目的贡献和使用。 建立一个核心团队，专门负责处理项目的基本事务。 他们的工作可以确保贡献者能够增加和使用满足他们自己使用场景需要的特性。
* [签约贡献者](/zh/p/contracted-contributor) - 想为内源做贡献的同事被他们的直线管理层劝阻。正式的合同和协议为这种困境提供援助。
* [记录你的指导原则](/zh/p/document-your-guiding-principles) - 通常内源对 "在组织内部应用开源最佳实践 "的解释对缺乏开源背景的人来说效果并不好。 作为一种补救措施，内源最重要的原则被记录下来并广泛宣传。
* [评审委员会](/zh/p/review-committee) - 对于开发人员和管理人员来说，内源的工作模式与更多的传统方法截然不同。通过建立一个评审委员会，作为内源计划和所有参与该计划的业务部门高级管理人员之间的接口，后者更有可能更加熟悉并支持该计划，因为评审委员会为他们提供了一定程度的监督和控制，而不会助长微管理。
* [跨团队的项目评估](/zh/p/crossteam-project-valuation) - 要推销跨团队的内源项目的价值是很难的，因为这些项目并没有对公司的收入产生直接影响。 这里有一个数据驱动的方法来展示和凸显你的项目价值。
* [通过扩展实现可持续增长](/zh/p/extensions-for-sustainable-growth) - InnerSource 项目收到了太多的贡献，这会导致维护变得困难。通过在核心项目之外提供扩展机制，维护者可以用最小的成本和维护开销扩展项目功能。
* [问题追踪器使用案例](/zh/p/issue-tracker) - 内源东道主团队不仅没有使计划和进展，而且也没有将变化背景信息变透明。这可以通过增加项目问题跟踪器的使用案例来解决，它也可以为头脑风暴、实施讨论和功能设计服务。
* [零工市场](/zh/p/gig-marketplace) - 建立一个市场，创建一个内部网站，将特定的内源项目需求列为 "任务"，并提出明确的时间和技能要求。 这将使管理人员能够更好地了解员工的时间承诺和专业利益，从而增加获得批准做出内源贡献的可能性。
## 附录
* [模式模板](/zh/fu-lu/pattern-template)
* 额外
* [README 模板](/zh/fu-lu/e-wai/readme-template)
* [CONTRIBUTING 模板](/zh/fu-lu/e-wai/contributing-template)
* [RFC 模板](/zh/fu-lu/e-wai/rfc)
## 资源
* [本书在 GitHub 代码仓地址](https://github.com/InnerSourceCommons/InnerSourcePatterns)
* [InnerSource Commons](http://innersourcecommons.org)
# 模式探索
越来越多的模式是由InnerSource Commons社区贡献给本书的。这真是太棒了!
现在，如何让读者更容易发现那些能在特定情况下帮助他们的模式？
为此，我们提供了这个思维导图。它**根据内源项目的不同阶段对模式进行了分类**，以及在各个阶段可能出现的挑战。
## 改进这个思维导图
如果你注意到这个思维导图中的任何问题，请[打开一个问题](https://github.com/InnerSourceCommons/InnerSourcePatterns/issues)，描述这个问题以及应该做的修正。
此外，如果你有其他想法来提高这些模式的可发现性，或者想让这个思维导图变得更好，请查看我们的[模式归类](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/pattern-categorization/README.md)方法的文档，也可以查看如何[为本书做贡献](/zh/contribute)。
## 参考文献
像这样对模式进行分类的想法大致是基于Tim Yao、Bob Hanmer和Padma Sudarsan（2018）在[有关内源模式语言的思考](https://drive.google.com/file/d/13AY8glCOdpLOVuz7cVD6QOB8d2xbHCS1/view)中的描述。具体内容见该幻灯片中的第15张幻灯片。
## 翻译校对
* **2022-12-21** 翻译[姜宁](https://github.com/willemjiang)
* **2022-12-28** 校对[龙文选](https://github.com/hncslwx)
# 为这本书做贡献
你想让这本书变得更好？那真是太棒了!
《内源模式》这本书本身就是一个[开源项目](https://github.com/InnerSourceCommons/InnerSourcePatterns)，欢迎任何形式的贡献。没有什么是微不足道的!
不管你是想帮助我们修正语法/拼写，改进设计，还是根据你在工作场所的内源经验贡献全新的模式。我们喜欢所有这些（贡献）! :)
如果你以前从未为一个开源项目做出过贡献，请知道内源模式社区是一个由友好的人组成的团体，并且有一个安全的地方可以尝试这些贡献。
## 在你开始之前
内源模式和本书的源代码都保存在GitHub上的一个仓库中。因此，你需要一个GitHub用户账户来对本书进行编辑和提交建议。如果你还没有，请前往[github.com](https://github.com)，免费创建一个账户。
## 贡献的不同方式
这里有几种你可以做出贡献的方式。
1. 修复你在本书中发现的拼写、格式或其他小问题
2. 改进现有模式的内容（例如，通过添加一个简短的描述，说明你是如何使用一个模式作为\_已知实例的）。
3. 贡献一个新的模式，描述你如何在你的组织中克服内源相关的挑战。
对于上述（1）和（2），你可以简单地点击本书每页顶部的**Edit on GitHub**链接。这将使你直接进入我们GitHub仓库中的相应文件，在那里你可以提出你的修改意见。
对于（3），你需要克隆[内源模式](https://github.com/InnerSourceCommons/InnerSourcePatterns)资源库，并将你建议的模式添加到一个新文件中。当对本书做出这种较大的贡献时，请查看我们的[CONTRIBUTING.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/CONTRIBUTING.md)和我们的[贡献者手册](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/meta/contributor-handbook.md)。
## 贡献的许可
本资源库的内容以[CC-BY-SA-4.0](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/LICENSE.txt)授权。通过向这个资源库贡献，你授予我们（以及其他所有人）根据该许可使用你的贡献的权利。
## 翻译校对
* **2022-12-21** 翻译[姜宁](https://github.com/willemjiang)
* **2022-12-28** 校对[龙文选](https://github.com/hncslwx)
# 30天保修
### Title
30天保修
### Patlet
当接受来自自己团队以外的贡献时，人们自然不愿意为非本团队自己编写的代码负责。通过30天保证，贡献团队同意向接受团队提供错误修复，这将增加两个团队之间的信任度，使贡献更有可能被接受。
### 问题
一个团队开发了一个在整个组织中使用的组件。 这个团队抵制接受或直接拒绝贡献（功能请求）。 这种行为阻碍了正常的项目研发，并导致了事态升级使得项目开发受到影响。
### 上下文
* 团队依赖另一个团队接受他们的贡献，以便接收团队生产的组件能够被贡献团队使用。
* 接收团队没有资源、知识、许可和/或倾向于自己编写贡献的组件/功能。
### 约束
* 由于过去的作弊历史，人们对贡献存在不信任：团队提交了半成品的贡献之后，通过提出后续的修复请求，使其可以在生产中使用。
* 如果代码是由团队以外的人贡献的，团队自然会怀疑其他团队不知道如何编写符合接收团队期望的代码。
* 每个团队首要考虑的是帮助自己的领导实现自己的目标。这样忠诚度会使这个问题的解决变得复杂。
* 人们对承担非自己编写的代码的责任有一种自然的厌恶。
* 贡献的代码在被代码库接纳之前需要进行大量的重写。
* 人们担心贡献者在贡献被接纳之后无法提供修复错误的支持。
* 团队担心贡献的代码会导致高额的维护成本，并担心如何控制这些维护成本。
* 接收团队可能会担心，教别人如何贡献代码会暴露他们系统中的技术债务，并引发其他的伤害。
* 接收团队可能不相信，无论他们提供何种程度的指导，都能得到可接受的代码。
* 大家对衡量风险或证明风险在贡献中得到缓解缺乏信心；系统本身的脆弱性（可能没有办法完全测试和捕捉所有问题）。
### 解决方案
通过建立一个**30天的保证期**来解决接收团队和贡献团队的担忧，保证期从贡献的代码投入生产时开始计算。在这个保证期内，贡献团队承诺向接收团队提供问题修复。
请注意，保证期也可以是45、60或100天。持续时间可以根据项目的限制、项目的软件生命周期、对客户的承诺和其他因素而变化。
此外，提供明确的[贡献指南](/zh/p/base-documentation)，阐明接收团队和贡献团队的期望，也是有帮助的。
### 结果
* 接收团队愿意接受贡献，并能分担初步改编/修复的工作量。
* 增加透明度和公平性。
* 使得维护工作不至于变得过于沉重。
### 已知实例
* 这在 PayPal 得到了成功的尝试和证明。
* GitHub 内部使用这种模式，修改后的保证时间线为6周。
* 微软推荐这种模式作为一个内部原则--团队设定自己的具体时间目标，与他们的需求和信心相匹配。
### 作者
* Cedric Williams
### 致谢
* Dirk-Willem van Gulik
* Padma Sudarsan
* Klaas-Jan Stol
* Georg Grütter
### 状态
* 结构化
* 在2017年春季内源峰会上起草；2017年7月18日审查。
### 变体
* 确保相互由依赖关系团队的合作，让他们成为一个社区，由一个以上的、以择优任命的"[trusted-committer](/zh/p/trusted-committer)"（TCs）负责。
### 翻译校对
* **2022-12-01** 翻译[姜宁](https://github.com/willemjiang)
* **2022-12-09** 校对[龙文选](https://github.com/hncslwx)
* **2023-06-18** 最后更新日期
# Trusted Committer
### Title
Trusted Committer
### Patlet
许多内源项目会发现自己处于这样一种情况：他们不断收到来自贡献者的反馈、功能和错误修正。 在这种情况下，项目维护者会想方设法对贡献者的工作进行认可和奖励，而不仅仅是对单一的贡献认可。
### 问题
* 项目维护者希望找到方法来扩大他们支持项目的能力
* 项目维护者希望找到方法来延长项目所提供的价值。
* 项目维护者希望能明显地奖励经常性的贡献者，并授权他们扩大其价值贡献。
* 缺乏对组织内各团队贡献的认可机制和语言
### 上下文
* 你是一个跨团队的运行库、服务或共享资源的维护者
* 你经常收到别人的贡献
* 您定期收到功能请求
* 您经常收到修复错误的请求
* 有积极的贡献者希望通过内源项目培养专业技能
### 约束
* 在一个项目的生命周期中，维护者可能因为自己的商业需要会转移工作重点。
* 贡献者寻求对其贡献的明显认可，以证明其价值。
* 对于一个小团队来说，维护一个具有合理复杂性的项目是很费力的。
* 对一个小团队来说，大规模地开发项目功能是很费时费力的。
### 解决方案
#### 为项目定义一个 Trusted Committer 角色
Trusted Committer 处理什么是由每个项目和它的维护者决定的。确保你在项目中记录下你的 Trusted Committer 角色的范围。清晰的文件为新的社群成员设定了期望，并为未来的候选人确定了角色。
以下是识别潜在 Trusted Committer 的一些准则：
* 积极参与社区渠道（Slack、JIRA问题分流等）的人成为 Trusted Committer，从而正式确定他们在社群支持中的角色。
* 经常提交代码、文档或其他版本库修改的人。可以先从提交 Pull Request 人群中筛选。如果他们积极地提交 Pull Request，可以考虑与他们接触，探讨在项目上进一步合作的机会。
#### 正式确定 Trusted Committers
第一步是与 Trusted Committer 候选人接触。维护者应该对候选人进行教育，使其了解受 Trusted Committer 的角色。我们并不期望候选人会接受 Trusted Committer 的角色。每个候选人应该评估他们是否有足够的空余时间来承担这些责任。当候选者接受了这个角色，项目维护者就应该向公众发布会从用户到 Trusted Committer 转变的消息。并将他们的名字添加到项目README中的 Trusted Committer 一栏中。如下所示：
```markdown
# 项目名
... 项目的readme ...
## 项目成员
### 维护者
- 你的团队
### [Trusted Committers]
- 新的 trusted committer成员
[Trusted Committers]: https://example.com/link/to/your/trusted/committer/documentation.md
```
#### 维护 Trusted Committer 关系
一旦你正式确定了一个新的Trusted Committer，在你持续迭代项目的时候需要保证Trusted Committer也能持续获得项目进展的信息。 让他们真正参与到项目进来，可以是简单地邀请他们加入你的项目沟通群，也可以是让他们参与你的计划会议。 更多的参与机会使 Trusted Committer 有机会成为维护者，如果他们愿意的话。
除了让 Trusted Committers 了解情况外，还需要定期检查 （Trusted Committers 的状态）。建议的节奏是先从每周开始，然后逐渐发展到每隔几周。 这些检查的目的是为了确保 Trusted Committers 在他们的新角色中感到被支持。就像与你的经理进行1对1的交流一样，如果有任何问题，倾听和同情，试图了解是什么阻碍了受托承诺者的成功。 始终[感谢 Trusted Committers 在使项目成功方面的持续努力](/zh/p/praise-participants)，并确定一个新的检查日期。
#### Trusted Committer的退出
有些时候，Trusted Committer需要退出 ，例如如果 Trusted Committer。
* 不再愿意参与
* 不再能够履行其职责
* 不再受雇于该公司
双方应商定一个取消项目资源访问权的计划，包括将他们在项目的 **Trusted Committer** 部分的条目进行修改，将其加入到过去的贡献者名单。 在取消访问权时，[公开感谢 Trusted Committer 的参与](/zh/p/praise-participants)。公开承认可以确保社群内过渡和连续性的清晰沟通。
### 结果
#### 对于项目贡献者
获得一个项目的 Trusted Committer 资格，表明了对社区项目的主动贡献。对这些努力的认可可以在与经理的年度评审中使用。
#### 对于项目维护人员
随着项目的成熟，维护者对项目的关键方面可能变得不那么熟悉。Trusted Committers 可以填补这些空白，确保项目的各个方面随着时间的推移可以得到更好的服务。一组健康的 Trusted Committer 可以确保在项目维护者转行时有一个负责任的管理计划。
### 已知实例
已经在以下公司尝试并证明是成功的
* Nike
* PayPal
* Mercado Libre - 在 `CONTRIBUTING.md` 文件加入了一段，用来描述谁是Trusted Committer。
### 状态
* 结构化
* 在耐克公司内部发布；2018年6月通过 pull-request 草案.
### 作者
* [Fernando Freire](https://github.com/dogonthehorizon)
### 鸣谢
* [Russell Rutledge](https://github.com/rrrutledge)
* [Loren Sanz](https://github.com/mrsanz)
* [Noah Cawley](https://github.com/utanapishtim)
* [Jeremy Hicks](https://github.com/greatestusername)
* [Doron Katz](https://github.com/doronkatz)
### 翻译
* **2022-12-01** 翻译[姜宁](https://github.com/willemjiang)
* **2022-12-03** 校对[龙文选](https://github.com/hncslwx)
* **2023-06-18** 最后更新日期
# 不要吝啬对参与者的夸奖
### Title
不要吝啬对参与者的夸奖
### Patlet
及时感谢贡献者对内源项目贡献的时间和付出是很重要的。 这种模式不仅提供了有效地承认了贡献的指导，而且还吸引贡献者和其他人的进一步参与。
### 问题
我们怎样才能正确地表达我们对贡献者对项目的内源贡献的感谢？ 我们很容易忘记这样做，或者不知道该用什么样的语言或方式来达到足够的效果和诚意。 赞扬和感谢是简单的、低成本的方法，可以激励贡献者和他们的经理保持持续贡献动力。 这方面的模式使赞扬很容易做到，并确保信息能清晰和真诚地传达出来。
### 背景
* 你是 [Trusted Committer](/zh/p/trusted-committer) 或内源项目的维护者。
* 你重视贡献者的社群，并希望维护和发展它。
### 约束
* 你很忙，这使得你很容易忘记一些柔软的能触动人心的表达，例如赞美和感谢。
* 你可能不是一个在社交牛人或善于言辞的人。
* 同行的认可对工作满意度和职业发展非常重要。
### 解决方案
对任何人来说，被他人认可的感觉都很好。 在职业环境中，增加认可也是增加影响力和成长的途径。 任何时候，当有人为你的内源项目做出贡献时，请用一句真诚的、沉甸甸的 "谢谢 "来认可他们。
对于有价值的贡献（所有的代码贡献和重要的时间贡献），通过以下机制说谢谢。
(1) 在你组织项目活动的任何聊天地点（例如 *Slack*），叫出这个人的名字。 让大家知道他们做了什么并公开感谢他们。
示例：
> 每个人都@这里给@andrew\.clegg击掌，因为他把 *rcs-viewer* 更新到 *hebo-client* 的最新版本（ 谢谢你帮助更新这个库，Andy!
(2) 给他们和他们的经理（抄送）发邮件，感谢他们的贡献。 对于代码贡献，很多时候你可以直接转发合并通知邮件。
示例：
> 嗨，安迪，我想再次感谢你的这次更新。 这可能只是一小部分时间，但正是每个人这样的关注才使得RCS项目为我们所有人工作。 感谢你解决了自己的问题，同时也使 *rcs-viewer* 更加好用。
### 结果
这样的反馈让贡献者有一种奇妙的感觉，并准备回来继续努力。 **同时**结合两种形式的感谢，让他们在同行面前（广度）和在直接经理面前（深度）得到认可。 在聊天中，有一种微妙的鼓励，让那些同行考虑自己做出贡献，也让那个经理寻找适当的环境，鼓励他们的直接报告下属也这样做。 此外，不知道团队已经开始的使用和参与内源项目的经理也会了解到内源项目的进展。
有一点需要注意的是--保持真实。 确保你的话来自于你内心对他们所做的事情的真诚感谢。 保持赞美的水平和言辞与他们的参与程度相称。 过度的赞美可能会让人觉得不真诚和机械，并使你寻求援手的目的落空。
### 相关模式
* *只是说声谢谢*（摘自《*无畏的改变*》一书）（
### 已知实例
* Nike (multiple projects)
### 状态
* 结构化
### 作者
* Russ Rutledge
### 致谢
* [Todd Lisonbee](https://github.com/tlisonbee)，鼓励 "保持真实"。
* [Isabel Drost-Fromm](https://github.com/MaineC)为"合格 "感谢进行的[这个额外的解释](https://youtu.be/h3MPewsk5PU?t=357) 。
### 翻译校对
* **2022-12-07** 翻译[姜宁](https://github.com/willemjiang)
* **2022-12-19** 校对[谭中意](https://github.com/tanzhongyi003)
* **2023-06-18** 最后更新日期
# 专职的社群领导
### Title
专职的社群领导
### Patlet
选择同时具备沟通和技术能力的人领导社群，以确保成功推动内源倡议。
### 问题
你如何确保一个新的内源倡议有合适的[社群领导](http://www.artofcommunityonline.org/)来扩大其影响？
如果选择了错误的人和/或没有为他们提供足够的能力，就有可能浪费精力，最终导致新的内源倡议的失败。
### 故事
考虑一下下面的故事。一家公司想启动一个内源计划，以促进跨越组织边界的合作。他们已经决定从一个范围有限的实验阶段开始。管理层已经为第一个内源社区选择了一个合适的试点主题，并期望来自整个组织的许多业务部门的贡献。公司已经提名了一位新员工来用他工作时间占50%领导社群，因为他还没有打算100%投入其中。6个月后，社群只收到了一些贡献，其中大部分是来自一个业务部门。公司用一个在公司有较长历史的人替换了社群负责人，这次只用了他30%的时间。又过了6个月，贡献的数量仅有小幅回升。该公司不再相信内源能帮助他们实现增加跨部门合作的目标，于是放弃了内源。
### 背景
* 该公司是一家大型的老公司。它以前没有开源或其他基于社群的工作经验。公司文化的典型特点是自上而下的经典管理风格--它通常与社群文化相抵触。
* 虽然在高层管理中有支持者和赞助者，但公司的中层管理人员还没有接受内源。
* 管理层没有被说服，只能提供有限的预算来资助一个兼职的社群领导。
* 最初选定的社区领袖在开源工作模式方面几乎没有经验。
* 最初选定的开发者社区领袖在公司内部没有广泛的社交网络。
### 约束
如果一个公司没有在预算和能力方面对最初的内源社群进行大量投资，那么它对内源的承诺的可信度可能会被认为是有问题的。一个具有传统管理文化的公司，如果项目或倡议的表现不尽如人意，其常见的冲动就是更换领导人。在没有社区参与和遵循任人唯贤原则的情况下这样做，将进一步破坏公司对内源的承诺，因为它突出了当前公司文化和目标文化--社区文化之间的摩擦。
内源项目的价值贡献对于许多沉浸在传统项目管理方法中的管理者来说并不明显。这些经理人不太可能把他们的高级人员（通常非内源项目对他们的工作时间优先级要求很高）分配到内源项目中去，来占用他们相当大的工作时间。
沟通在社群领导的日常工作中占了很大比例。同时，他或她很可能也要带头进行初步开发。在能力有限的情况下，没有经验的领导人会倾向于专注于发展，而忽略了沟通。如果社群领导人很难联系上，或者因为没有时间而对反馈和问题反应迟钝，那么潜在的贡献者做出第一次贡献和对社群做出承诺的障碍就会大增。此外，技术上没有经验的领导者很可能比在公司内有很高知名度的顶尖人才更难吸引和保留经验丰富的贡献者。
如果一个社群不能快速成长，不能加速发展，很可能他们就不能令人信服地展示内源的潜力。
如果公司选择一位经验丰富的项目或部门经理来担任社区领导人，他或她很可能会关注传统的管理主题，如资源分配、提供结构和报告渠道，而不是通过任人唯贤的原则以身作则。这将破坏内源项目在开发者眼中的可信度。
### 解决方案
选择一个社群领导，他：
* 对开源工作模式或类似的社群工作模式有经验。
* 具备必要的软技能，可以作为一个自然的领导者。
* 以身作则，从而证明他在社群中的地位是合理的。
* 是一个优秀的社会网络工作者。
* 激励社群成员。
* 能够有效地与执行管理层和开发人员沟通，并且
* 能够处理社群工作的管理问题。
授权社群领导将其100%的时间用于社群工作，包括沟通和开发。告知管理层，在对社群管理进行改革时，需要对社群的意见保持敏感。理想情况下，授权社群自己提名社群领导。
### 结果
一个具有上述属性的社群领导将为公司带来面子，体现出公司对内源的承诺。这将使他社交网络中的其他同事更有可能跟随他的步伐，为内源做出贡献。随着时间的推移，他或她将能够建立一个稳定的核心开发人员团队，从而增加内源项目的成功机会。通过说服公司内部足够多的人相信内源的潜力，他或她将为公司文化向社区文化的转变做出重要贡献。
拥有优秀而敬业的社群领导是内源项目成功的先决条件。然而，这并不是银弹。内源有许多挑战，超出了社群领导可以解决的范围，如预算、法律、财政或其他组织挑战。
### 已知实例
*BIOS at Robert Bosch GmbH*. 请注意，博世的内源在大多数情况下是为了增加创新，并在很大程度上处理面向内部的产品。由于缺乏资金，这种模式目前在博世没有使用。
### 别名
专职社群经理
### 状态
* 结构化
### 作者
* Georg Grütter (Robert Bosch GmbH)
* Diogo Fregonese (Robert Bosch GmbH)
### 致谢
* Tim Yao
* Padma Sudarsan
* Nigel Green
* Nick Yeates
* Erin Bank
* Daniel Izquierdo
### 修改记录
* **2016-11-06** - 第一次评审
* **2017-04-06** - 第二次评审
### 翻译校对
* **2022-12-06** 翻译[姜宁](https://github.com/willemjiang)
* **2022-12-11** 校对[龙文选](https://github.com/hncslwx)
* **2023-06-18** 最后更新日期
# 交流工具
### Title
交流工具
### Patlet
一个内源项目正在原始开发团队之外使用，但用户在寻求帮助和与项目团队联系时遇到困难。 我们的想法是建立和记录标准的通信工具，使讨论变得可见、存档和可搜索。
### 上下文
一个团队依赖于另一个团队的组件。它希望对该组件做出贡献。 即使是书面形式的沟通，也是1对1的方式进行的。
### 问题
一个团队愿意接受来来自于下游的他们的组件用户的贡献。 由于协调和沟通是以一种点对点的方式进行的，导致了信息共享的不连贯性，收到答复的延迟，贡献者于是在收到明确的答复前会呼叫多个东道主团队成员。
### 约束
* 东道主团队有兴趣接受贡献，并愿意指导贡献者。
* 团队有很强的口头沟通文化，在建立项目特定的异步沟通渠道方面缺乏经验。
* 沟通渠道可能与应该接触到的特定群体使用习惯相一致，但不是以沟通目标进行选择的。
### 解决方案
东道主团队需要明确提供公司公开的、存档的、可搜索的、可链接的沟通渠道的好处，公司内部的任何人都可以免费订阅信息。
在精简内源项目的沟通渠道时，目标应该是围绕主题进行沟通，而不是围绕某些人。
* 项目应该有自己的问题跟踪器，东道主团队成员采用公开透明的方式进行结构化的沟通、决策和进度跟踪需求，同时也鼓励下游的用户和贡献者遵循同样的原则进行沟通。
* 该项目应该有一个或多个结构不太严格的讨论渠道。通常情况下，这将是邮件列表、在线论坛甚至是存档的聊天频道。通常情况下，项目开始时只有一个频道就足够了，如果流量增加太多，把关于项目使用的讨论和关于项目开发的讨论分开是有帮助的。
* 此外，项目应该有一个私人频道，可以在 [Trusted Committer](/zh/p/trusted-committer) 之间进行敏感的交流--例如，将更多的 Trusted Committer 加入到东道主团队中。这个渠道的使用应该非常谨慎，因为沟通默认为公开的，只有在非常罕见的情况下才会保持私密。
虽然沟通可以发生在书面渠道之外，但尽可能多的信息应该被带回异步渠道。
所有的通信渠道都应该在项目的`README.md`中进行记录。东道主团队成员需要努力将他们个人收到的问题带回官方沟通渠道。
### 结果上下文
建立并持续使用官方的异步交流渠道，有助于建立一个基础的被动文档，当类似的问题再次出现时可以再次参考。
随着交流的公开化，其他人可以很容易地关注项目的进展，并积极做出贡献。其他人的聆听和阅读降低了参与的门槛，提高了获得贡献的可能性。
随着问题被公开回答，更多的人可以加入他们的观点，从而形成一个完整的画面--这不仅包括东道主团队成员，也包括项目的用户。
在异步渠道中保持交流，可以让不同时间段的参与者--无论是由于不同时区，还是由于不同的作息时间、会议时间、团队作息时间--对项目做出有意义的贡献。
在这些渠道中回答问题，不仅意味着其他团队成员可以倾听并提供额外的信息，也意味着有相同问题的其他用户可以看到（或后来找到）之前的答案，从而降低重复解释的需要。
### 已知实例
* Europace AG
* Paypal Inc.
* Mercado Libre
### 作者
Isabel Drost-Fromm
### 状态
* 结构化
* 于2019年12月起草。
### 翻译校对
* **2022-12-06** 翻译[姜宁](https://github.com/willemjiang)
* **2022-12-09** 校对[龙文选](https://github.com/hncslwx)
# 代码仓活跃度评分
### Title
代码仓活跃度评分
### Patlet
潜在的贡献者希望找到需要他们帮助的活跃的内源项目。通过计算每个项目的代码库活跃度评分，可以创建一个项目的排名列表（例如在[内源门户网站](/zh/p/innersource-portal)上），这样潜在的贡献者可以更容易地确定他们想要贡献的项目。
### 问题
内源项目应以**何种顺序**呈现？典型的排名指标，如*GitHub星数*、*复刻（fork）数*、*提交数*、*代码行*、*最后更新*，都不足以简明地表明项目的活动。
活跃的项目有很多吸引力，但也有相当新的和热情的项目，需要新的贡献者，应该比活动很少或处于维护模式的成熟项目排名更高。
为了给项目的活动水平定义一个可靠的、通用的分数，我们需要一个从几个KPI中得出的新指标。 它可以被用来根据项目的活动水平进行分类排序。
### 故事
当内源实践了很长时间，或者规模超过了一定数量的项目（比方说50个，给一个有意义的门槛），就很难找到目前最流行和最活跃的内源项目。存在了很长时间的项目是众所周知的，但可能不再是非常活跃的。另一方面，相当新的项目还没有声誉或活跃的社区。
内源项目列表不应该被认为是一个静态资源，而是一个发现和探索新的和活跃的项目的令人兴奋的地方，就像一个新闻页面首先列出当天最有趣的话题一样。因此，当项目的顺序定期更新，并根据项目的受欢迎程度和活动情况而改变时，这是很有好处的。
这些考虑导致了第一个计算代码库活跃度评分的原型，它的效果出乎意料地好，并根据项目的活动提供不断变化的排名顺序。
### 背景
发现内源项目可以通过[内源门户网站](/zh/p/innersource-portal)和[零工市场](/zh/p/gig-marketplace)模式，或者通过在其他交流渠道和平台上推广项目来实现。活跃度评分定义了项目被展示给社区的默认顺序。
### 约束
通过查询GitHub的API可以自动获取到和代码开发相关的关键绩效指标。那么如何评价，代码质量、良好文档的可用性，或者使项目成为一个有趣的贡献场所的活跃和互助的社区呢？
这些 "软"的关键绩效指标必须手动或半自动地添加到计算中，并得出分数。如果有工具可以为代码库提供更多的背景，如代码覆盖率报告，它们可以很容易地被加入。
### 素描
一个集中的方法来计算和应用代码仓活跃度评分。更多细节，见[结果](#jie-guo)
### 解决方案
代码仓活跃评分是一个数值，代表内源项目的（GitHub）活跃度。它是由GitHub星数、关注和复刻等代码仓库统计数据自动得出的，并可以用其他工具或人工评估的KPI来进行补充。
此外，它还考虑了活动参数，如 repo 的最后更新和创建日期，以便为具有大量吸引力的年轻项目提供助力。 拥有贡献指南、积极参与的统计数据和问题（公共backlog）的项目也会获得更高的排名。
所有这些都可以通过[GitHub搜索API](https://docs.github.com/en/rest/search#search-repositories)和[GitHub统计API](https://docs.github.com/en/rest/metrics/statistics)的结果集来自动获取和计算。如果有类似的API，其他代码版本系统如BitBucket、Gitlab、Gerrit也可以被整合。
下面的代码假设变量`repo`包含一个从GitHub`search`API获取的实体，`participation`对象包含一个来自GitHub`stats/participation`API的实体。
如果需要，可以根据软的关键绩效指标（见[约束](#yue-shu)）在上面进行手动调整。
```javascript
// 从标星、关注、提交和问题中计算出一个虚拟的内源分数
function calculateScore(repo) {
// 初始分值为50分，作为GitHub KPI（复刻、观察者、标星）较低的活跃仓库一个的起点
let iScore = 50;
// 权重：复刻和关注最多，然后是星标，对没有关闭的问题也加一些小分
iScore += repo.forks_count * 5;
iScore += (repo.subscribers_count ? repo.subscribers_count : 0);
iScore += repo.stargazers_count / 3;
iScore += repo.open_issues_count / 5;
// 在过去3个月内更新：给总分增加一个0...1的奖励乘数（1=今天更新，0=100天以前更新）
let iDaysSinceLastUpdate = (new Date().getTime() - new Date(repo.updated_at).getTime()) / 1000 / 86400;
iScore = iScore * ((1 + (100 - Math.min(iDaysSinceLastUpdate, 100))) / 100);
// 评估过去3个月的参与统计
repo._InnerSourceMetadata = repo._InnerSourceMetadata || {};
if (repo._InnerSourceMetadata.participation) {
// 平均提交量：为总分增加一个0...1的奖励乘数（1=每周提交量大于10，0=每周提交量小于3）
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);
}
// 加分计算
// 所有在前一年更新的资源库都将获得最大1000的加分，并按上次更新后的天数递减
let iBoost = (1000 - Math.min(iDaysSinceLastUpdate, 365) * 2.74);
// 根据资源库的创建日期，逐步缩小加分的规模，与 "真实 "的参与统计相混合
let iDaysSinceCreation = (new Date().getTime() - new Date(repo.created_at).getTime()) / 1000 / 86400;
iBoost *= (365 - Math.min(iDaysSinceCreation, 365)) / 365;
// 在总评分中加分
iScore += iBoost;
// 给予有意义的描述的项目以50的静态加分
iScore += (repo.description?.length > 30 || repo._InnerSourceMetadata.motivation?.length > 30 ? 50 : 0);
// 给予有贡献指南（CONTRIBUTING.md）文件的项目以100的静态加分
iScore += (repo._InnerSourceMetadata.guidelines ? 100 : 0);
// 为非常活跃的项目建立一个对数表（不限，但稳定在5000左右）
if (iScore > 3000) {
iScore = 3000 + Math.log(iScore) * 100;
}
// 最终得分是一个从0开始的四舍五入值（减去初始值）
iScore = Math.round(iScore - 50);
// 为元数据添加分数
repo._InnerSourceMetadata.score = iScore;
return iScore;
}
```
### 结果
贡献者可以自由地将他们的一部分时间投入到内源项目中。他们可以选择为一个他们在常规团队中依赖的项目做出贡献。然而，他们也可以根据自己的兴趣和个人发展目标，选择为一些完全不同的项目做贡献。
项目可以按照资源库活动得分进行分类和展示，在向潜在的新贡献者展示项目的门户中给出一个有意义的顺序。分数可以即时计算，也可以在后台工作中计算，定期评估所有项目并存储结果列表。
一个定期搜索所有内源仓库的爬虫（例如在GitHub中被标记为某个[主题](https://github.com/topics)）也可以是一个有用的补充。它提供了一个经过排序的项目列表，可以作为[内源门户](/zh/p/innersource-portal)、搜索引擎或互动聊天机器人等工具的输入。
### 原理
仓库活跃评分是一个基于GitHub API的简单计算。它可以完全自动化，并容易适应新的需求。
### 已知实例
* 在SAP的内源项目门户中使用，用于定义内源项目的默认展示顺序。它首次创建于2020年7月，此后经常进行微调和更新。在2020年7月向 InnerSource Commons 提出时，出现了这种模式。另见[Michael Graf & Harish B (SAP) at ISC.S11 - 不知不觉实现了一个内源模式](https://www.youtube.com/watch?v=6r9QOw9dcQo\&list=PLCH-i0B0otNQZQt_QzGR9Il_kE4C6cQRy\&index=6)。
### 状态
* 结构化
### 作者
[Michael Graf (SAP)](mailto:mi.graf@sap.com)
### 致谢
感谢 InnerSource Commons社区光速提供的建议，以及大量有益的意见，不断完善这个模式。特别感谢：
* Johannes Tigges
* Sebastian Spier
* Maximilian Capraro
* Tim Yao
### 翻译校对
* **2022-12-08** 翻译[姜宁](https://github.com/willemjiang)
* **2022-12-16** 校对[龙文选](https://github.com/hncslwx)
* **2023-06-18** 最后更新日期
# 以实验的方式开始
### Title
以实验的方式开始
### Patlet
将内源实践倡议作为一个有时间限制的实验开始，使不熟悉内源的管理人员更容易认可和支持该倡议。
### 问题
一项内源倡议被考虑但没有开始实施，因为管理层对其结果没有把握，因此不愿意承诺投资。
### 背景
该公司正在考虑采用内源来提高软件项目开发的协作效率。然而，大多数管理人员并不熟悉开放源码的工作模式，而是习惯于等级制度、自上而下的控制式管理。内源的想法在该公司的软件开发人员中非常流行，这主要是因为许多开发人员使用或正在积极开发开源软件。
### 约束
* 在进行长期投资之前，管理人员希望验证通过内源改善协作的说法。这通常涉及到对协作改进的测量。
* 如果内源计划在开发者中可能有巨大的接受度，如果许多项目可能依赖它，那么关闭它的决定将非常不受欢迎，因此也很难做出。由此产生的控制权的丧失可能会使一些管理人员甚至不敢开始推行内源。
* 实施内源风格的工作模式往往与以前的工作模式截然不同。因此，现有的、强制性的流程很可能不再适用，并且缺少适当的管理流程。其结果可能是，人们不得不在有时是法律上的无主之地监管运作。例如，在多个国家拥有多个法律实体的大公司的税收和出口控制相关法规。
### 解决方案
宣布内源计划是一个有时间限制的实验。界定并宣传加入内源实验的项目标准。选择能够最大限度地提高建立一个健康社群的实施标准。如果一套标准在实验中积累的洞察指标能够直观地应用于涉及其他潜在内源项目的环境中，那么这就是一个好的标准。
这种标准的例子有：
* 开发者有足够的地理分布
* 足够的开发人员的部门参与
* 社群内交流的开放性
* 社群内基于功绩的职业道路
* 社群内的民主决策
考虑将实验结束时指定为\_支点\_、\_变化\_或\_暂停\_点，以重新评估。还可以考虑建立一个[评审委员会](/zh/p/review-committee)，通过参与增加管理层认同的机会。根据公司文化，在实验中加入适当的指标，[设置指标的第一步](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/introducing-metrics-in-innersource.md)可能会有帮助。如果实验中的项目没有对公司的收入产生直接影响，可以考虑引入[跨团队的项目评估](/zh/p/crossteam-project-valuation)来强调其价值贡献。
### 结果
管理人员能够启动内源的原因如下：
* 实验性的设置减轻了管理人员对内源项目数字的审查需要，就像他们对典型项目的审查一样。
* 实验失败的可能性被理解和接受。管理人员支持内源的个人风险被降至最低。
* 即使在失败的情况下，这种设置也能确保公司将从实验中学习。
* 在成功的情况下，实验期间收集的数据将使管理人员能够对内源做出更长期的承诺。
内源实验的参与者现在意识到，他们必须向管理层证明内源产生了承诺的效益。因此，这将有助于将工作重点放在那些能提供最明显价值的活动上，从而增加成功的机会。
最后，作为一个实验开始，它更容易避开可能会减少成功机会的法规和约束，如工具和流程政策。
### 相关模式
* *Trial Run*(摘自\[无畏的改变]一书)()
### 已知实例
* Robert Bosch GmbH (全球分布式软件开发)
### 状态
* 结构化
### 作者
* Georg Grütter (Robert Bosch GmbH)
### 致谢
* Jason Zink (Robert Bosch GmbH)
* Diogo Fregonese (Robert Bosch GmbH)
* Robert Hansel (Robert Bosch GmbH)
* Hans Malte Kern (Robert Bosch GmbH)
* Russ Rutledge (Nike)
* Tim Yao (Nokia)
* Clint Cain (Optum)
### 翻译校对
* **2022-12-06** 翻译[姜宁](https://github.com/willemjiang)
* **2022-12-21** 校对[龙文选](https://github.com/hncslwx)
* **2023-06-18** 最后更新日期
# 共同的需求
### Title
共同的需求
### Patlet
共享代码库中的通用代码不能满足所有想要使用它的项目团队的需要；这一点可以通过需求调整和重构来解决。
### 问题
共享代码库中的通用代码并不能满足所有想要使用它的项目的需求。
### 上下文
* 许多项目都在尝试使用共同的代码。 有一个所有项目都能访问的共享代码仓库。
* 有人（或某些项目）首先写了代码，并把它提交到了共享代码仓库。
* 通用代码在任何一个项目的总体交付物中只占很小的比例。
* 每个项目都有自己的交付时间表，一组交付物和客户。
* 这种模式适用于以下任何一种情况：
* 有一个**强的代码所有者**，即所有对共享库的修改都必须得到共享库所有者的批准。
* 有**弱的代码所有权**，即没有人真正拥有这些代码。
* **没有仁慈的赞助者**，即没有组织或行政人员提供资源，以InnerSource的方式组织公共代码。
### 约束
项目的开发团队为了满足一组需求实现了代码。这些需求与一些代码的使用组织的需求相似，但不完全相同。 对代码的要求应该是可以从真实的客户需求中推导出来的。
不同客户的需求通常是非常相似的；然而，他们可能表达的方式不同，或者客户之间表达的轻重缓急不同。一个例子是，有些客户希望某些结果以一种方式呈现，而其他客户则希望以相反的顺序呈现。在他们之间进行转换很简单，但需要对其中一种情况进行额外的编码，结果是计算结果的模块不能被两个客户重复使用。
许多客户希望供应商能帮助他们了解自己的需求。公司有很多 "系统工程师 "为产品写需求。 这些需求应该是对客户需求的提炼，以指导产品的开发。 重用代码是一个重要的目标，就是节省公司的时间和金钱。
### 解决方案
解决这个问题有两个方面，应该同时进行。
1. 统一项目的要求，使满足一个项目要求的代码也满足其他项目的需要。
2. 将代码重构为更小的模块，使许多使用项目能在需求上达成一致。
此外，利用客户期望供应商帮助阐明需求的优势。在与客户的谈判中实现需求的一致性，影响客户的需求，而不是改变组件。
在上面的例子中，供应商帮助两个客户认识到他们想要同样的东西，如果他们同意接受相同格式的结果，这将节省每个人的努力（和金钱）。
### 结果上下文
这可能需要与客户协商需求的变化。 这些变化可能还需要销售团队和产品经理的参与，以获得需求上的一致性。 客户可能需要激励措施，如折扣，以同意这些变化。
一个相关的挑战（和可能的新模式）是在一家采用InnerSource的公司报告的循环故事写作练习。简而言之：
* 开发人员独立写一个故事来解决一个问题。
* 项目经理重写故事以更好地表达他们的需求--保持本质不变。当故事回到开发人员手中时，他们并不能认识到这是他们最初想做的事情，因此在实施时逡巡不前。
* 解决这种模式的方法是在计划表上有更多的参与者，这样故事的修改就会在整个项目中得到理解，而不仅仅是在开发人员或项目经理的阵营中的人。
### 已知实例
* 大型电信提供商
### 状态
* 结构化
### 作者
Robert Hanmer
### 致谢
* Manrique Lopez
* Daniel Izquierdo
* Tim Yao
* Sebastian Spier
### 翻译校对
* **2022-12-05** 翻译[姜宁](https://github.com/willemjiang)
* **2022-12-09** 校对[龙文选](https://github.com/hncslwx)
* **2023-06-18** 最后更新日期
# 内源许可证
### Title
内源许可证
### Patlet
属于同一组织的两个法律实体希望彼此共享软件源代码，但他们担心在法律责任或跨公司会计方面的影响。
“**内源许可证**”为组织内的源代码共享提供了一个可复用的法律框架。它提供了新的合作选择，并明确了参与的法律实体的权力和义务。
### 问题
当一个组织中的两个或更多的法律实体想要互相分享代码时，他们需要一个关于条款的协议，通常是一个法律合同。在每个项目的基础上创建此类协议需要付出努力并会对共享创造障碍。例如，一个法律实体内的团队可能决定不与组织内的另一个法律实体分享他们的源代码，因为这看起来很复杂。
共享的障碍会导致在组织内多个实体重建类似的解决方案时出现独自开发和重复劳动的现象。
在共享源代码时，可能无法可靠地预测共享的价值。如果共享活动需要付出巨大的努力（例如，对源代码使用的条款进行持续谈判），则法律实体不太可能这样做，因为他们关心投资的回报。
### 背景
* 大型组织内有许多想要共享代码的法律实体（子公司）。当组织变大时，共享模式的价值会增加。
* 按照定义，法律实体有自己的法律权利和义务。
* 这些法律实体中有多个实体正在开发软件，并正在使用其他法律实体的服务。他们有动力为彼此的源代码做出贡献。
* 该组织及其组织结构足够复杂
### 约束
* 撰写正式协议所需的**努力程度**，特别是如果他们需要考虑技术、法律和商业角度。
* 一个大型组织（由许多法律实体组成）有许多**内部规定**。任何新签订的协议都必须遵守这些规定，例如安全、隐私、采购流程等。规定的数量会导致难以评估两个法律实体之间共享软件是否符合这些规定，尤其是在没有标准程序的情况下。
* 如果组织中的任何一个法律实体有一个**商业模式**依赖专有代码和组织内许可费用的核算。
* **公司文化**不习惯于内源协作和共享代码。这导致了在使用共享代码时权利和义务的不确定性。
* 使用软件的自由导致了竞争以及所有权的分散。
* 有一些法律合同，涵盖了源代码的共享。这些合同并不是标准化的，所以它们为每个项目的谈判和理解带来了额外的负担。现有的合同也可能不允许在足够开放的意义上共享源代码，以支持真正的内源方法。
* 或者，没有法律合同，但源代码被非正式地共享。在需要明确所有权和权利义务的情况下，这可能会造成不确定性。
### 解决方案
创建一个根据有关组织（及其法律实体）的需要定制的**内源许可证**。这个许可证需要有足够的通用性，可以应用于最重要的公司间关系。
重要的是，撰写内源许可证，要真正允许类似开源的合作跨越相关法律实体的边界进行。因此，自由软件的4项自由应当被融入许可证中。
许可证按正式的法律文件撰写，并作为法律实体之间的合同的一部分来管理代码共享协议。
### 结果
有了内源许可证，我们就有了一个在组织内的法律实体之间分享代码的工具。
该许可证简化了我们组织内部关于共享源代码的对话，并推动第一批法律实体这样做。
**注意：** **已知实例**中描述的实验还处于早期阶段。因此，一个可靠的**结果**还没有形成。几个月后，内源许可证对这一问题空间的影响将更加清晰，本节也将更新。
### 已知实例
DB Systel创建了他们自己的内源许可协议，见[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)是因为它提供了一个类似于开源的起点，然后在他们特定的组织环境中制定了所需的约束和附加规则。
DB AG内部的第一批法律实体（公司）正在使用他们的内源许可证。
一个已经显示出来的积极效果是，它简化了对话，特别是当一些参与方还不太了解内源的概念时。许可证是一个众所周知的概念，因此拥有一个内源许可证是一个很好的讨论起点。
实验还发现，为了实现真正的内源贡献和合作模式，还有更多的合作挑战需要解决。
所提到的合作挑战包括：
* 让大家能够找到适用内源许可的项目
* 像在开源中一样建立项目合作的社群。
值得一提的是，到目前为止，在这个内源许可下分享的软件主要是工程工具、基础设施和底层的工具。
### 状态
* 结构化
* 在**已知实例**下所列的实验自2020年2月开始运行。初步的经验显示了第一个积极的效果，但需要更多的经验来全面评估该模式。
### 作者
* Cornelius Schumacher (DB Systel GmbH)
* Schlomo Schapiro (DB Systel GmbH)
* Sebastian Spier
### 参考
* FOSSBack 2020演讲。[Cornelius Schumacher - Blending Open Source and Corporate Values](https://youtu.be/hikC6U8X_Ec) - 请看27:30及以后的内容，了解有关内源许可的细节。
* [DB Inner Source License](https://github.com/dbsystel/open-source-policies/tree/master/inner-source-license)
### 词汇表
* **组织** - 多个法律实体的综合体。(同义词：集团、企业）（如汉莎航空）。
* **法律实体** - 拥有自身的法律权利和义务的实体（同义词：公司，子公司）（例如汉莎系统有限公司，汉莎工业解决方案TS有限公司，...）
### 翻译校对
* **2022-12-08** 翻译[姜宁](https://github.com/willemjiang)
* **2022-12-09** 校对[孙振华](https://github.com/sunzhh02)
* **2023-06-18** 最后更新日期
# 内源门户网站
### Title
内源门户网站
### Patlet
潜在的贡献者很难找到他们感兴趣的内源项目。你可以通过创建一个索引所有可用的内源项目信息的内部网站，可以让贡献者了解他们可能感兴趣的项目，也可以让内源项目的负责人发展外部受众。
### 问题
内源项目团队发现吸引外部贡献是件很难做的事情。
你的组织的内源项目逐渐增加，但潜在的贡献者却没有办法轻易找到这些项目。
### 故事
你正尝试在你的组织内建立一个内源实践。 你知道有些项目正在使用内源模式运行，但它们只是通过口耳相传、电子邮件或与其他员工的旁听对话来获知其存在。 因此，内源项目负责人发现吸引贡献者是件很难做到事情。
没有一个专注于分享内源项目信息的网站可以供整个组织的员工去方便地使用来了解所有正在进行的内源项目。 这严重制约了每个内源项目的发展。
做什么才能帮助所有内源项目尽可能高地提高其知名度，并吸引整个组织范围中的贡献者呢？
### 背景
* 你的组织有兴趣采用内源的工作方式。
* 内源项目的所有者正在寻求一种方法来吸引受众参与他们的项目。然而，他们受限于现有的沟通渠道，无法向潜在的贡献者进行宣传。
* 你的组织中的内源项目正在增加。
* 让问题变得更加复杂的是，正在使用的共享源码控制管理应用程序的搜索功能非常有限，即使是寻找内源项目的开发人员也很难找到相关的项目。
#### 前提
* 管理层已经默许他们的员工参与内源项目。
* 使用一个共享的源码控制管理系统，该系统提供了对其托管的代码资源库内容的程序化访问。
* 在你的组织中，有一个部门负责推进内源合作。
### 约束
* 相互独立的工程团队协作应对共同挑战的潜力没有得到充分发挥
* 个人很难发现内源项目的存在
* 内源项目的负责人很难吸引外部贡献者的关注
### 解决方案
创建一个内源门户的内部网站，内源项目的负责人可以很容易地宣传其项目的可用性。
该门户网站的关键属性是：
* 内源门户网站的访问者应该能够看到所有可用的项目，以及根据各种标准搜索特定的项目，如项目名称、使用的技术、贡献者姓名、赞助的业务部门等。
* 通过内源门户网站显示的信息应该在任何时候都在内源项目负责人的完全控制之下。 最好是通过直接从特定的数据文件或存储在项目库本身的元数据中获取这些信息。
* 项目负责人应在这些数据文件中包括所有与他们的项目有关的信息，包括项目名称、受信任的贡献者的名字、简要描述和链接到代码库或任何支持文件。
* （可选）虽然大多数组织会选择只在其内部网络上提供他们的门户，但有些组织也会选择在公共互联网上提供他们的门户。后者对于那些想在门户中显示有关其内源方法的额外信息的组织来说可能很有意思，例如出于品牌和招聘的目的。
在启动门户网站时，应该考虑开展宣传活动，推进大家将内源数据文件或元数据添加到代码库中，以增加门户网站中显示的项目数量。
在GitHub上有一个内源门户的[参考实现](https://github.com/SAP/project-portal-for-innersource)，并开放众人贡献。它以一种互动和易于使用的方式列出了一个组织的所有内源项目。项目可以通过一个专门的GitHub主题进行自我注册，并提供额外的元数据。
### 结果
* 内源门户网站使内源项目负责人能够向整个组织的受众宣传他们的项目。 由于曝光度的提高，他们吸引了比以往更大的贡献者群体。
* 对于那些希望参与内源项目的人来说，内源门户允许他们根据特定标准同时搜索所有可用的 内源项目，从而准确发现他们感兴趣的机会类型。
* 满足供给者和消费者的需求，有助于将内源确立为一个可行的、有吸引力的选择方案，使组织内的所有领域都能利用它来完成他们单独无法完成的事情。
### 已知实例
* **一家大型金融服务机构**利用创建的内源门户提供了一个宣传和发现不同业务部门的内源项目的机制。
* **SAP**在内源门户中推广内源项目--项目可以使用GitHub主题自行注册。[代码仓活跃度评分](/zh/p/repository-activity-score)定义了内源项目在门户中的默认顺序。也可参见[Michael Graf & Harish B (SAP) at ISC.S11 - 应用内源模式非常规路径](https://www.youtube.com/watch?v=6r9QOw9dcQo\&list=PLCH-i0B0otNQZQt_QzGR9Il_kE4C6cQRy\&index=6)。它的代码库以[参考实现](https://github.com/SAP/project-portal-for-innersource)的形式发布，并开放给众人贡献。
* **Elbit Systems**使用了这个模式，并在上面添加了游戏化内容。
* [游戏化作为文化变革的手段和内源参与的助推器](https://www.oreilly.com/library/view/oscon-2018-/9781492026075/video321579.html) | Shelly Nizri | OSCON 2018 - 波特兰，俄勒冈州
* 岛屿、怪兽和内源 [(幻灯片)](https://docs.google.com/presentation/d/1P1OCEK9B6eSrVRUclVWY6meSI-qHOBjM_UAPNvCZamU/edit#slide=id.p15), [(视频)](https://drive.google.com/file/d/1pM89uHMn0vhE3ayFJDGYcCO8R0tAXXZD/view?usp=drivesdk) | 2019年内源春季峰会（爱尔兰，高威）
* 实现这一平台的代码已经开源，可在[gitlab.com/gilda2](https://gitlab.com/gilda2)上查阅。
* **美国航空公司**通过[内部内源市场](https://web.archive.org/web/20240226230502/https://tech.aa.com/2020-10-30-innersource)推广内源项目。与SAP类似，项目通过添加`内源`作为GitHub主题进行自我注册。项目可按语言、主题、开放问题的数量等进行搜索和过滤。
* **Banco Santander**创建了一个名为 "Santander ONE Europe 内源社群" 的公共门户，以支持和增加内源的采用。除了项目目录外，该门户还包括相关内容，如文档、工作方式、新闻和活动。
* **空中客车公司**部署了[SAP门户](https://github.com/SAP/project-portal-for-innersource)，并进行了小的修改以符合空中客车公司的图形标识。此外，对[Python爬虫](https://github.com/zkoppert/innersource-crawler)进行了修补，以便与GitHub企业实例协同工作。
* **Mercado Libre** 使用了[SAP门户](https://github.com/SAP/project-portal-for-innersource)来展示组织内部的内源项目。
### 参考
* 在这种情况下，内源门户模式已经被证明与相关的内源[零工市场](/zh/p/gig-marketplace)模式配合使用效果非常好。
### 状态
* 结构化
### 作者
* Stephen McCall
### 致谢
* Shelly Nizri
* Melinda Malmgren
* Michael Graf
* Jesús Alonso Gutierrez
### 翻译校对
* **2022-12-08** 翻译[姜宁](https://github.com/willemjiang)
* **2022-12-11** 校对[安旭](https://github.com/anzipomelo)
* **2023-06-18** 最后更新日期
# 利用RFC进行透明的跨团队决策
### Title
利用RFC进行透明的跨团队决策
### Patlet
内源项目如果想实现高参与率，并为每个参与者做出最好的决定，就需要想办法在整个软件生命周期中建立易于参与式的环境。发布内部征求意见稿（RFC）文件，可以在设计过程的早期就进行讨论，并促进在参与各方在高参与度下建立解决方案的机会。
### 问题
为了使内源项目健康发展，它持续需要大量的贡献者。这些贡献者（或团队）可能对给定的项目有不同的要求。例如，他们可能想在项目中添加彼此不兼容的功能，或导致架构的不健康的膨胀。
在过程的后期发现这种分歧或误解，例如，一旦软件已经建成，就会付出很大的代价。这些分歧可能会导致所有参与方的挫败感，甚至会破坏项目中合作文化的健康。常见的分歧是，一个变更请求（pull request）被搁置了很久，因为变更请求的作者和项目的维护者基本上都不同意进行拟议的变更。
对于内源项目来说，当项目由公司内的多个团队一同维护时，这种情况更经常发生，即共享所有权。
### 故事
一个项目，或由多个项目组成的应用程序，由许多不同的团队维护，每个团队负责不同的项目或应用程序的不同领域。这些团队确实对彼此的领域做出了内源的贡献，但更大的、跨领域的变化只由团队的技术负责人共同推动，或者根本就没有发生。这导致大多数工程师无法实现大规模、跨领域的变革，减少了创新和合作的机会。
通过实施RFCs的流程和模板，团队和个人被授权通过一个透明的决策过程提出大型的、跨领域的变化，并在各团队之间进行异步磋商。这促进了更大的创新，更紧密的合作，以及更多的知识传播。这有赖于各层级的所有专家的认同，以及一个心理安全的环境，以便人们可以公开提出和辩论想法。
像任何过程一样，这必须被不断地改进。可能需要对RFC模板或流程进行修改，以确保其具有包容性、协作性和有效性。
### 背景
* 一个内源项目由许多团队共同拥有。
* 最重要的设计决策不可能一直由一个中央机构（例如一组架构师）做出，因为他们既没有足够的时间，也没有足够的特定领域的知识来在所有情况下做出好的决策。
* 各种类型的用户对某个项目的发展方向有意见。这样的用户可能是：开发人员、产品负责人、产品经理等。
* 决策需要以异步的方式做出，至少部分是这样，因为经常召集所有参与者的同步会议是不可行的
* 希望记录所做的决定，即确保这些决定是书面的，而不仅仅是口头的。
### 约束
* 大多数时候，相关各方都希望能很快做出决定（例如，前期的设计时间相当有限）
* 对许多参与的人来说，把事情写下来（在没有实施的情况下）往往是一种新的技能。
### 素描
### 解决方案
我们选择了一个类似于RFC的程序来增加我们跨团队决策过程的透明度（也见[请求评论](https://en.wikipedia.org/wiki/Request_for_Comments)）。
该方案的重要内容有：
* 关于何时发布RFC（以及何时不发布）的描述
* 一个RFC文件的模板
* 应该促使RFC作者从多个角度考虑他们的建议
* 既要提示高层视角的概述，又要提示详细的深入解释
* 一个众所周知的、围绕RFC的轻量级过程，例如
* 如何发布RFC并与所有利益相关者分享（如Slack、邮件列表）。
* 如何收集对RFC的反馈
* 如何在反馈中工作
* 如何将RFC推向一个结论或决定（例如，相关的指定维护者签字）。
* 选择适当的工具（例如，非开发人员可能无法使用源代码控制工具）。
* 承诺对RFC模板和流程进行迭代
#### 示例/模版
* [Rust](https://github.com/rust-lang/rfcs)是一个很好的RFC模板和流程的开源例子，也是许多其他RFC流程的基础。
* [通用化的BBC iPlayer & Sounds RFC模板](/zh/fu-lu/e-wai/rfc)，最初基于[Rust](https://github.com/rust-lang/rfcs)模板
### 结果
实施类似于RFC的流程被证明是有价值的，因为它使跨团队的决策过程对每个人来说都更加透明，使所有的声音都能被听到。
可观察到的积极效果。
* **决策过程的民主化**，影响到许多团队的决策（同时也减轻了团队负责人的负担）。
* **一个开放的异步沟通方法**，在多个团队和地区都能很好地运作。
* **赋予个人和团队**大规模变革的能力
* **记录所做的决定**供人们参考，以了解情况
* **扩大有经验的工程师的影响**，因为他们可以通过异步和远程方式为解决方案做出贡献，而不需要在会议上出现。
* **统一术语**，例如，通过阐明我们的测试术语，如 "什么是系统测试"，来实现术语的统一。
* **统一流程**，例如，明确说明下班后的支持流程。
* **更清晰的思路**，因为写RFC使作者比平时更多的挑战自己。
RFC方法也有我们想要指出的风险。
* 它并不总是有效的！例如，有些人可能仍然反对已经通过RFC做出的决定。然而，在这些情况下，将决策过程写成文字仍然是有益的，因为你可以指出人们是在什么时候和为什么做出某个决定的。
* 将设计方案（架构、协议等）写在前面，有一种瀑布式的设计元素，不适合许多开发团队喜欢的迭代式开发方法。记住："工作的软件胜过全面的文档"（[敏捷宣言](https://agilemanifesto.org/)）。RFC过程应该尽可能的轻巧。
* 一个RFC可能会变得很大，太不方便了。这往往表现在冗长的评论和围绕RFC的讨论。在这种情况下，我们可能会决定用同步交流的方式来补充RFC，比如工作小组和面对面的会议。但时间仍然可以节省，因为人们可以在会议之前阅读RFC，而不是在会议期间分享所有的信息。
### 原理
多年来，RFC在开源世界中证明了自己。对于互联网整体而言，RFC在制定标准方面发挥了重要作用（例如，见[30 Years of RFCs](https://www.rfc-editor.org/rfc/rfc2555.txt)），对于其他开源项目也是如此，它们采用这种方法来促进社区的透明决策（例如，[RUST](https://github.com/rust-lang/rfcs)，[ZeroMQ](https://rfc.zeromq.org)）。
在内源的背景下，其他公司也分享了他们在类似RFC方法方面的经验，例如[Uber](https://blog.pragmaticengineer.com/scaling-engineering-teams-via-writing-things-down-rfcs/)和[Europace](https://github.com/open-organization/open-org-distributed-work-guide/blob/master/drostfromm-remote-first-through-openess.md#setting-cross-team-standards-and-best-practices-in-the-open)。
对于纯粹的软件设计决策之外的决策，透明的决策模型也是有效的，例如在努力实现开放组织的时候。一个例子见Red Hat的[Open Decision Framework](https://www.redhat.com/en/about/press-releases/red-hat-releases-open-decision-framework-spur-transparent-and-inclusive-leadership)（2016年6月7日公开发布）。
### 已知实例
* **BBC iPlayer & Sounds** - 如2020年ISC秋季峰会[利用内部RFCs加强合作](https://www.youtube.com/watch?v=U6zlghE0HcE)所述。
* **Europace** - 如在开放组织中所述。[在开放中设置跨团队的标准和最佳实践](https://github.com/open-organization/open-org-distributed-work-guide/blob/master/drostfromm-remote-first-through-openess.md#setting-cross-team-standards-and-best-practices-in-the-open)。
* **Uber** - 根据Gergely Orosz的这篇博文：[通过RFCs扩展工程团队：将事情写下来](https://blog.pragmaticengineer.com/scaling-engineering-teams-via-writing-things-down-rfcs/)。
* **Google Design Docs** - 根据Malte Ubl的博文[Google的Design Docs](https://www.industrialempathy.com/posts/design-docs-at-google/)的描述。
* **DAZN** (10/2021) - DAZN做出技术决定的一种方式是通过RFCs。RFCs仅用于适用于工程范围内流程的决定！RFCs存在于GitHub中。RFCs存在于GitHub仓库中，然后技术标准逐渐被他们的工具和工程师所采用。一个RFC可以由任何工程师提出，并由所有工程师投票表决。如果支持率超过反对率，RFC就会被采纳。值得注意的是，RFC的投票过程至今没有因为任何争议的决定引发"压力测试"。- 正如Lou Bichard在这篇博文中所描述的：[建立一个DX团队：经验教训](https://medium.com/dazn-tech/building-a-dx-team-lessons-learned-4a66446088bc)
### 状态
结构化
### 作者
* Tom Sadler
* Sebastian Spier
### 别名
* [设计文档](https://www.industrialempathy.com/posts/design-docs-at-google/)
* 架构决策记录（ADR）--不一定是直接的别名，因为它们有时会有非常不同的使用方式，例如，RFC用于寻求意见和建立共识，ADR用于记录决策和实施细节。
### 翻译校对
* **2022-12-01** 翻译[姜宁](https://github.com/willemjiang)
* **2022-12-11** 校对[龙文选](https://github.com/hncslwx)
* **2023-06-18** 最后更新日期
# 基准级的文档
### Title
基准级的文档
### Patlet
内源项目的新贡献者很难搞清楚谁在维护这个项目，该做什么，以及如何贡献。在标准文件中提供文档，如`README.md`/`CONTRIBUTING.md`，可以为新的贡献者提供一个自助服务流程，这样他们就可以自己找到最常见问题的答案。
### 问题
一个团队希望与更广泛的组织分享一个新开始的或已经存在的项目，并接受对它的贡献。潜在的贡献者常常迷失。他们无法确定团队的首选沟通渠道。他们难以快速判断添加一个新功能是否有意义。他们很难了解到底哪些同事目前正在积极维护该项目。
### 上下文
一个项目要作为一个内源项目与他人分享。为了让其他人能够理解项目的内容以及如何做出贡献，项目需要提供一些基本的文件。到目前为止，该项目要么缺乏所有的文档，要么缺乏用户以自助服务的方式进行尝试以及贡献者快速上手所需的某些方面的内容。
### 约束
* 该项目最近才转为内源项目。以前，用户要么是内部的，要么是在个人面对面的会议上加入进来的。同样，从事项目的人员经历了入职培训，而这种入职培训并不能随着贡献者或远程贡献者人数的增加而扩大。因此，自助服务文档是缺乏的。
* 该项目是作为一个内源项目新创建的。然而，东道主团队缺乏内源的经验。因此，他们需要指导建议在文档中包括哪些信息，把文档放在哪里，以便其他人可以找到它，以及在文档中面向的是哪些类型的读者。
* 该项目是最近才转为内源项目的，东道主团队对内源的经验有限。因此，现有的文档解决了很多技术方面的问题。它不包括促进透明规划所需的沟通、协调和信息。
* 该项目是最近才转化为内源项目的。因此，很多存在于团队中的隐性知识既没有被写下来，也没有对贡献者可见。
* 文档的缺乏导致潜在的贡献者需要很长时间来设置环境和入门学习。制作文档（并保持更新）需要时间投资。即使东道主团队依靠贡献者的帮助来解决缺乏文档的问题，这些贡献仍然需要时间来评审。
* 项目成员要花大量的时间来回答入门问题。维护一个可以被认为是支持问题的综合数据库需要大量的时间和精力。
* 组织内的不同团队对于如何格式化源代码和使用何种软件模式有不同的标准。因此，贡献通常最后会被大幅修改甚至全部重写。将所有这些操作标准化并执行这些标准，需要大量的时间和工作。
* 重复解释和重写的额外工作削弱了内源方法的效用。
* 由于额外的工作和重写造成的延迟而频繁问题升级，导致了一个大奶酪的局面。
### 解决方案
解决为新的贡献者提供更清晰的文档的需求。创建此文档的目标应该是使入门尽可能成为一个自助服务的过程，用标准的文档格式来解答常见问问题。
#### README.md
如果它还不存在，为你的项目创建一个`README.md`。它应该包含。
* [项目的使命](https://producingoss.com/en/producingoss.html#mission-statement)，格式要尽可能简洁。它应该回答发起项目的目的是什么，并使贡献者能够很好地初步猜测一个建议的功能是否可能在项目的范围内。
* 为项目的下游用户提供一个 "入门 指导"部分。它应该解释如何设置/整合项目的工程文件，以及为第一次使用的用户解释一些最初的典型操作步骤。
* 为项目用户提供更深层次的指导文档--或者是文档链接。
* 对项目进行修改所需的文档--或者是文档链接。
* 关于如何为项目做出贡献的文档--或者是文档链接。
* 一个 "参与 "部分，解释项目使用哪些公开的、存档的、可链接的交流渠道。这应该包括一个指向项目问题跟踪器的链接，但也包括任何进一步使用的讨论渠道。
* 一个 "我们是谁 "的部分，解释谁是项目背后的[Trusted Committer](/zh/p/trusted-committer)--并解释应使用上述公共交流渠道而不是私下联系这些人进行交流。
* 解释项目将贡献者变成Trusted Committer的标准是什么--如果存在这种途径的话。
! [README.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/assets/img/standard-base-documentation/README-for-users.png)
#### CONTRIBUTING.md
如果对做出贡献的步骤的解释过于复杂，可以创建一个单独的`CONTRIBUTING.md`文档。这个文件应该回答贡献者过去经常问到的问题。没有必要预先提供全面的书籍。相反，分享已证实为贡献者所需要的信息。它可能会涉及到以下一个或多个主题。
* 如何从版本控制中签出项目的源代码。
* 如何对项目进行修改（可能包括编码指南方面的信息）。
* 如何构建项目。
* 如何运行测试以确保上述修改没有引入新的错误。
* 如何将你的修改提交给项目。
* 关于所作修改的预期周转时间的一些信息。
在各种开源项目中，有许多关于如何写 "README.md "和在 "CONTRIBUTING.md "文件中包含何种信息的好例子， 诸如[如何写好readme](https://m.dotdev.co/how-to-write-a-readme-that-rocks-bc29f279611a)的页面。 [来自GitHub的开源指南](https://opensource.guide/)以及[生产开源](https://producingoss.com/en/producingoss.html) 都有关于提供什么样的信息的宝贵信息。虽然《生产开源》一书中没有关于写好README本身的章节，但[入门章节](https://producingoss.com/en/producingoss.html#starting-from-what-you-have)确实提供了一份相当广泛的清单，列出了东道主团队成员、用户和贡献者需要的东西。InnerSource项目很可能不会从一开始就涵盖所有这些方面，该清单本身对于启发我们可以涵盖何种内容是有帮助的。
除此之外，这个模式还附带了两个非常基本的模板，可以让你马上开始。[README-template.md](/zh/fu-lu/e-wai/readme-template)和[CONTRIBUTING-template.md](/zh/fu-lu/e-wai/contributing-template)
### 结果
* 贡献者上手的时间大大减少。
* 为[Trusted Committer](/zh/p/trusted-committer)回答初始问题的时间大大减少，使他们有更多时间从事其他工作。
* 由于误解和错位导致的问题升级明显减少。
### 已知实例
* Europace AG - 见博文[InnerSource: Adding base documentation](https://tech.europace.de/post/innersource-base-documentation/)
* Paypal Inc.
### 作者
* Isabel Drost-Fromm
### 别名
通过README提供标准的基础文档
### 状态
* 结构化
* 于2019年12月起草。
### 参考
* [README-template.md](/zh/fu-lu/e-wai/readme-template) and
* [CONTRIBUTING-template.md](/zh/fu-lu/e-wai/contributing-template)
### 致谢
[网络](https://storyset.com/web)和[人物](https://storyset.com/people)的插图由Storyset制作。
### 翻译校对
* **2022-12-21** 翻译[姜宁](https://github.com/willemjiang)
* **2022-12-31** 校对[孙振华](https://github.com/sunzhh02)
# 小组支持
### Title
小组支持
### Patlet
如果某个团队或个人不再支持 InnerSource 项目怎么办？ 由一群感兴趣的个人组成小组来保持项目活跃。
### 问题
* 即便是一个广受欢迎的 InnerSource 项目也可能陷入孤立的困境。
* 当前没有明确的出路。
### 故事
一个 UI 组件类库，在全公司有 50 多个项目使用。 该类库的开发团队在资源耗尽后，宣布解散。 起初，没有人注意到，但过了一段时间，每当有人问“谁负责它”时，得不到答案。 接下来会怎么样？ 新的团队会避免使用它吗？ 该项目是否会停滞不前，直到其用户最终被迫转向其他项目？ 如果一个完美且有价值的项目出现这种情况，那将是多么令人遗憾！
### 上下文
* 广受欢迎的 InnerSource 项目。
* 作为一个构件时的依赖项使用（比如 代码模块）。
* 没有活跃的开发者提供支持。
* 公司无法指派团队提供支持。
### 约束
* 没有人在日常工作中被指派负责这项工作。
* 每个人都很忙。
* 项目迁移的成本很高。
### 解决方案
面向全公司征集感兴趣的志愿者，组成一个 [可信任提交者](/zh/p/trusted-committer) 小组来支持该项目。 可能需要根据提交或使用的历史记录联系特定的个人。 重要的一点是要有足够的数量，这样每个人的负担可以相对较小。
该小组成立后，应确定或创建[标准基础文档](/zh/p/base-documentation)和[沟通工具](/zh/p/communication-tooling)。
团队应尽全力从以下方面管理项目：
* **维护**. 如果项目在标准用例中完全失效，那就修复它。 随着项目使用的依赖关系和框架的不断发展，及时更新项目。
* **新人上手**. 如果有人对如何使用项目有疑问，确保他们能得到合理的答复。
* **更新**. 如果有人想在项目中添加新功能，请为他们提供必要的设计和技术支持，以便他们实现该新功能，使其既能为自己所用，又能为项目增光添彩。 及时评审收到的 PR。
由于该小组由志愿者组成，因此重要的是要传达提供“尽力而为”的支持。 因此，这种支持模式不太适合像实时 API 这类运行时关键的生产项目。 它更适合在构建时使用的项目，例如类库/包/模块。 该小组预计不会为其他人实现任何新功能。
### 结果背景
* 对 InnerSource 项目有些微弱的支持。
* 从长远来看，小组支持可能会在某个时候再次解散。如果该项目长期持续下去，那么就利用这段稳定的小组支持期，找到一种长期支持的方式（比如 [核心小组](/zh/p/core-team)）。
### 理由
人们通常都愿意提供帮助。 如果有人邀请某个人是否愿意加入成为[可信任提交者](/zh/p/trusted-committer)，通常会有很多人回答“是的”。 感受到自己是集体的一员，并在组织结构上体现和被赋予一定的责任，通常会激励人们尽最大努力，很多时候这就已经足够了。
### 已知实例
* WellSky
### 状态
结构化
### 作者
[Russell R. Rutledge](https://github.com/rrrutledge)
### 翻译校对
* **2024-10-10** 翻译[Chris Yang](https://github.com/node)
* **2024-10-12** 校对[姜宁](https://github.com/willemjiang)
# 成熟度模型
### Title
成熟度模型
### Patlet
各个团队已经开始采用内源。这种做法正在向多个部门蔓延。然而，人们对什么是内源项目的理解各不相同。解决方案是提供一个成熟度模型，让团队通过自我检查，发现他们还没有意识到的模式和做法。
### 问题
当内源在企业中的应用开始增加时，通过一个布道者对每个项目进行单独指导就变得不可行了。此外，越来越多的人至少对在内源项目中工作的意义有了基本的了解。纵观所有的内源项目，对这一概念的理解深度会有差异。团队可能没有意识到那些可以帮助他们进入下一阶段并解决他们所处理的问题和痛点的成熟模式。
### 背景
一些团队已经开始采用内源实践。各个团队对该实践的确切理解程度不尽相同。团队遇到的具体问题也因每个团队的背景和工作环境而不同。因此，在内源项目中，对什么是重要的最佳实践的定义因每个团队而异。
### 约束
分享内源经验的团队遇到了误解，因为他们没有意识到各自采用内源的水平。
团队认为，"这都是迁移到一个共享的软件开发[锻造](https://en.wikipedia.org/wiki/Forge_%28software%29)"（GitLab、GitHub或Bitbucket是这种锻造的众所周知的例子）。
团队没有意识到可以帮助他们解决日常工作中遇到的问题的最佳实践。
### 解决方案
要求团队根据建议的成熟度模型进行自我评估。
#### 透明
**产品和规划**
内源项目路标规划在组织内公开透明，不仅可以使利益相关者能够更好地理解相关决策，也可以让组织内的其他人能够参与或影响决策。
* PP-0：组织内没有正式的路标规划。由个人和团队不定期向多个利益相关方披露他们的计划或产品。
* PP-1: 有公开路标规划。个人和团队在启动之前，向多个利益相关者展示他们的计划或产品。
* PP-2：有公开的路标规划，并且有清晰的指引和贡献规则帮助和指导利益相关方进行反馈。但是，这些过程没有在组织内规范化和标准化，不是所有内源都能提供这些信息。
* PP-3: 项目的路标规划默认是公开共享的，并且在组织内的每个内源项目有统一的标准流程和方法。对路标规划的贡献和变化也有明确的规范。
**开发流程及工具**
贡献者主动参与到内源项目可以让项目获得更好的发展。因此，需要在使贡献更容易和追求完美的技术目标之间达到平衡。。
* DP-0: 互相区隔的开发团队。各团队有自己的开发流程和工具。没有和其他团队共享知识和作品。
* DP-1: 公司内开发团队之间共享代码库。部分团队有自己的CI流程，没有使用公司统一或标准的CI工具。部分团队内部有自己的代码评审流程。但是公司没有统一的代码评审流程。
* DP-2: 建设公司级的知识共享库。部分团队使用公司CI工具来开发自己的CI流程。公司存在统一的CI环境和代码检视流程。部分项目已经应用。代码审查会邀请外部团队成员协助完成。
* DP-3: 大多数团队使用公司CI工具来完成自己的CI流程。有统一的CI环境和代码检视流程。代码检视由团队内部和外部成员共同完成。
**决策**
为了激励员工在他们所属的核心团队之外的工作中做出贡献，他们需要了解项目的决策过程，同时也要感觉到他们的声音是被倾听和重视的。
* DC-0：决策者往往有意或无意的隐瞒与项目决策相关的数据和资源。
* DC-1：决策结论定稿后，决策过程中的部分材料可共享可评审。
* DC-2：人们感觉自己了解并帮助决策大多数（但不是所有）重要决定。决策过程公开，可在所参与的项目里程碑中获得决策的相关材料。
* DC-3：人们感觉自己是集体决策的重要一环，决策过程公开规范，并且被组织所支持。可以持续地获取到决策过程中的相关材料。
**提供有用的资源**
为了吸引贡献者，需要让贡献者很容易获得有用的信息。
* RS-0：个人和团队既不贡献，也不利用共享的知识库。
* RS-1：个人和团队的交付件在内部评审。个人和团队有共享资源，但是知识是碎片化、不连贯的，存储在不同的系统和仓库内。个人和团队有共享资源，但无法确定信息是否敏感，对哪些信息需要共享没有达成共识，也没有标准和规范。没有“和他人分享想法”。
* RS-2：个人和团队可参考已明确定义的信息共享格式或协议，可以让团队成员方便地获取相关资料。团队对于必须保留的敏感信息，仅提供了有限的细节、背景信息和共享范围。
* RS-3：个人和团队可参考明确定义的信息共享格式和协议，可以让组织内部、外部相关人员方便地获取相关资料。对于必须保留的敏感信息，明确定义了共享范围，其他人也能够了解哪些信息不能共享。
**总结经验**
当在东道主团队中工作时，错误会自动被广泛看见。为了保持贡献水平，企业文化需要庆祝失败，作为大家共同成长和学习的机会。
* ST-0：个人和团队不分享成功或失败的经验，其他人无法学习。
* ST-1：个人和团队愿意分享成功经验，但不愿意分享失败经验。
* ST-2：个人和团队在回顾和评审时，愿意分享成功和失败的经验。。
* ST-3：个人和团队很方便的分享成功和失败的经验，并例行开展总结和学习活动。
#### 协同
**提供反馈渠道**
为了减少工作间壁垒（silos），同事们需要坦诚地分享反馈意见。一个简单的支持方式是跨层级使用相同的通信原则。 理想情况下，您最终会建立起适当的沟通渠道，并被整个组织广泛使用。这些渠道将聚焦于不同的目标（公告、用户支持、开发渠道、非正式讨论、等）。你将逐渐形成一套最佳实践，例如采用网络礼仪准则，为每一个新的内源项目开辟一套成熟的标准化沟通渠道（消息即时存档、可公开访问、提供搜索功能）。
* CF-0: 没有流程也没有建立渠道。组织成员通过私人渠道或讨论分享资料。
* CF-1：组织开始建立内部规范和渠道，以便组织的任何成员都可以使用，通过这样的渠道来鼓励对公司/部门决策提出不同观点。组织的一些成员利用非官方平台非正式地分享决策材料。领导者至少有一个明确、直接的渠道，让组织成员就一些与工作相关的事项分享有建设性的意见。
* CF-2：组织已经确立了内部规范和渠道，并提供特定的资源（培训项目、获取内容等），来鼓励和征求对于团队或决策的多方意见。
* CF-3：组织成员在官方认可的平台上分享决策材料，组织成员通过多种渠道和方法公开分享材料，征求反馈意见。领导者自己使用这些渠道，并公开鼓励其他成员使用这些渠道。对于收到的反馈以及针对反馈的处理意见，有专门面向团队的公开记录。
**领导力**
内源项目鼓励员工在不受其部门主管直接影响的情况下为部门外项目做出贡献。这需要信任的文化。
* LS-0：在一个高度层级化的组织中，大家奉行的是指挥与控制文化。
* LS-1：一些领导人愿意接受反馈，并创造一个让人们感到能够安全反馈的环境。
* LS-2：多数领导人愿意接受反馈，并创造一个让人们感到能够安全反馈的环境。领导者在理解所有成员是否都感到有权力和能够分享时表现出消极的态度。组织鼓励领导者积极寻找对话中没有出现的声音，以求包容。
* LS-3：成员们感到有力量，能够就任何与其工作有关的事项或他们有激情的事项建设性地分享意见。
**组织和功能结构**
当内源的理念离开单纯的编码层面，而是进入社区和工作团队的层面时，即使无法直接进行代码协作，也可以有效减少壁垒。
* OF-0：工作团队中的成员构成和技能组合往往是长期不变的。
* OF-1：跨职能部门团队存在，但团队的定位往往不明确，治理结构也很模糊。
* OF-2：跨职能部门团队较常见，团队会公开指出他们的定位和目标。
* OF-3：跨职能部门团队很常见，并在组织中广泛宣传他们的活动；反过来，组织也会推广这种合作的最佳实践。
**贡献**
为了减少壁垒，需要牢记改进组织内贡献模式的目标是为了增加职能部门间的合作。
* CB-0：完全区隔的状态，团队和团队间没有协作。只是由于一些跨职能部门团队的需要，会有一些协作。
* CB-1：组织成员会在团队间达成协作，但经常反映 "太难"。团队不经常注重审视合作的结果。
* CB-2：团队中的成员会积极寻找合作机会。团队经常就他们的合作成果进行讨论、审视并辩论，并默认这些合作成果是公开可用的。
* CB-3：组织成员通过内部和外部合作的方式，使所有参与者受益。团队经常就他们的合作成果进行讨论、重新审视和辩论，并在组织外分享他们的学习成果，并默认将这些成果对外公布。
#### 社群
**共享策略**
共同的共享价值观可以让大家跨越组织边界更好地协作起来。如果拥有一套标准、通用的共享规则及准则，那么跨团队协作将变得更加的容易。
* SP-0：没有共享文化，也没有书面的共享政策。
* SP-1: 组织中的一些成员联合起来协定价值观和原则，但他们这样行为并没有得到明确的支持。
* SP-2：组织成员集体撰写共同的愿景和协议，如使命宣言和行为准则等，使其易于获取，并可以经常参考。入职材料和迎新仪式提供充分的背景材料和信息，以帮助新成员了解组织如何得益于他们的贡献。
* SP-3：共同的价值观和原则为组织成员之间的决策、冲突解决和评估过程提供信息，组织成员以口头和书面的形式不断地引用这些价值观和原则。
**组织的归属感**
将内源引入组织的可能动因之一是员工参与度的增加。这一条目追踪了组织内推行内源时参与度的变化情况。
* PA-0：参与度低，没有合作，人们不喜欢与他人分享。
* PA-1：组织成员对于分享他们的想法和意见感到安全，但只在熟悉的领域发表意见。不必担心因此被攻击。人们明白，只有最好的想法会最终会被采纳，而领导权将会根据贡献和付出的多少来分派。
* PA-2：组织成员在分享他们的想法和意见时，不必担心因此被攻击。领导者对组织的共同价值观表示认可并投入精力建设。
* PA-3：组织积极主动地告诉成员，组织从他们的贡献中受益；因此，成员表现出强烈的集体意识和强大的执行力，并感到对组织的责任感。领导者明白，他们是通过帮助他人成长而获得自身成长的，因而他们会为组织的初级成员提供指导。
#### 治理
**奖励**
为了吸引更多的人参与到内源项目中，可以使用一些外在的激励手段来增加跨团队的协作。
* RW-0：没有奖励。
* RW-1：内源项目的管理者鼓励协作，想要奖励那些对项目作出卓越贡献的个人或组织，但是没有制定政策和流程来作为支撑。
* RW-2 制定了标准的流程和制度来鼓励内源项目开发团队之外的组织和个人参与协作，并进行奖励，奖励谁是由项目管理者或者项目管理委员会来决定的。
* RW-3：奖励不仅由组织提出，社区也会提出他们认为的更有价值的奖励。内源社区有责任决定谁应该得到奖励。
**监管原则**
内源项目需要一种自我评估的方法。度量指标可以作为促进自我评估的一个方面。此外，在一个成熟的内源项目中，我们期望采用一种基于清晰、一致指标的跟踪方法来监控内源项目。
* MP-0：组织中不存在任何级别的监控策略。
* MP-1：指标对某些团队很重要，但他们仅以一种孤立的方式在使用它们。
* MP-2：在组织层面有一个关于度量指标的策略，有助于在整个组织内验证特定的政策。在某些内源项目的层面也存在监控政策。
* MP-3：在组织提供的相应基础设施上，有明确的指导方针、建议和培训，来应用具体的度量指标。这在两个层面都起作用：在组织层面，以及内源项目层面。
**支持和维护**
内源团队不仅要负责特性开发，支持和维护也是内源团队核心任务的一部分。
* SM-0: 由核心开发或支持团队给予支持和维护，通过商业合同来保证产品的支持和维护。团队之外对产品一无所知。
* SM-1: 有由专门的支持团队提供的规则和制度，来使对产品的支持和维护正式确立。
* SM-2: 通过内源模式来使内源贡献的支持得以正式确立，如：[30天保修](/zh/p/30-day-warranty)或[服务与库](/zh/p/service-vs-library)。
* SM-3: 有成熟社区的规则和制度正式支持产品。
**文化**
在多种层次上向合作文化迈进。
* CL-0：筒仓型 - 团队独立的工作，相互封闭隔离，缺少交流和信息共享，甚至缺少协作。
* CL-1: 被动型 - 团队独立的工作，但知道如何对依赖性中的缺陷做出反应。
* CL-2: 贡献型 - 团队通过贡献积极帮助改善他们的依赖性。
* CL-3: 积极型 - 团队积极寻求帮助、指导和招募新的贡献者。
**内源角色**
内源带有明确的角色。虽然在早期阶段，某些模式可能不需要采用这些角色，但是在项目内部使用明确的角色称号进行沟通会变得更加容易。
* RO-0: 没有具体角色帮助内源夯实。只有常见的开发角色：开发人员、分析师、测试人员等。
* RO-1: 偶尔有个人和团队参与其他项目。这些是技术贡献，即用户/贡献者角色。对于某些团队，可以指定至少一个成员作为技术指导，该成员向其他开发团队成员解释开发过程。他/她可以作为 Trusted Committer 角色的候选人。
* RO-2: 内源管理者角色负责治理和支持，包括流程等。识别教育需求，并确保向组织提供所需的教育和培训。内源领导和教练负责组织参与内源项目。第一个正式步骤是：定义内源愿景和路标。组织定义了 Trusted Committer 角色，不仅为开发团队成员，而且为外部贡献者提供联系/参考。有一个标准的流程描述如何为社区做出贡献，贡献者角色是存在的。数据安全员角色负责管理内源活动留下的操作日志，这是需要衡量内源演变所必需的。Trusted Committer 角色将演变为更具技术性的形象，社区管理员将负责“激励”社区，他的主要职责是吸引和留住新的开发者/用户（贡献者/社区成员）。
* RO-3: 布道师在组织内部活动，让其他人了解当前的工作，内源做什么以及如何做，并帮助其他人理解并成为内源动议的一部分。非技术贡献者出现。
### 结果
所有团队都了解现有的最佳实践。
团队了解他们对内源的采用程度。
在采用内源作为工作模式之前，团队了解对他们的期望的做法--无论是短期的还是长期的。
### 已知实例
* Entelgy
* Zylk
* Bitergia
### 作者
* Daniel Izquierdo Cortazar
* Isabel Drost-Fromm
* Jorge
* Nerea
### 致谢
* Alexander Andrade （特别感谢拼写修正）
### 别名
成熟度模型： 了解内源的最佳实践
### 状态
* 结构化
* 于2019年9月起草
## 翻译校对
* **2022-12-09** 翻译[姜宁](https://github.com/willemjiang)
* **2022-12-27** 校对[龙文选](https://github.com/hncslwx)
* **2023-06-18** 最后更新日期
# 服务 vs. 库
### Title
服务 vs. 库
### Patlet
由于对服务宕机责任的模糊不清，DevOps团队都不太愿意基于公共代码进行跨团队工作。 解决办法是让大家认识到通常情况下：要么在独立的环境中部署相同的服务，在服务宕机时有独立的问题处理兜底机制；要么将大量的共享代码纳入一个库，大家在此基础上进行协作。
### 问题
当团队在DevOps环境中工作时，开发人员负责一个功能的端到端：从服务客户到软件部署、从维护和支持。 这也给跨团队工作带来了挑战：对于发生在任何一个团队的错误，问题处理流程可能是不一样的。 源代码和部署的耦合给团队留下了这样的问题，在发生错误时，谁负责及时解决问题。 因此，即使在需求上有很大的重叠，团队也不愿意联合起来进行协作。
### 上下文
* 团队在一个微服务环境中工作。
* 大家是按照功能齐全的DevOps团队进行组织。每个团队负责他们端到端的贡献，包括维护服务、及时处理问题和客户支持。
* 一个团队的任务是向下游客户提供一个由其他团队构建的和现有服务类似的服务。
### 约束
* 组织上的问题升级支持路径对每个团队来说可能是不同的。
* 每个团队的成员对于不影响自己下游客户的错误的线上问题并不愿意提供支持。
* 由于每个团队/客户关系的SLA定义不同，同一类型的错误的严重程度在团队之间可能不同。
* 团队可能有不同的安全或监管约束来管理他们的部署。
### 解决方案
将源代码的责任与部署脱钩：两个团队都致力于准确识别重叠内容并进行协同。
只有共享的源代码被保留成为内源项目的一部分，大家分担责任。共享源代码应该是连贯的，它包括所有的测试代码（如果有的话，包括集成测试）和尽可能多的持续集成管道，以使得贡献验证更容易。
将配置和部署管道与实际业务逻辑解耦。为新的团队建立新的服务部署。
将团队间共用的内容以库（不是直接使用代码）的方式进行使用，并共享代码所有权（通过协商的方式进行修改）。
部署配置的内容可以作为单独的项目列入内源项目中，以允许团队讨论/协作或新团队复制这些配置代码。
### 实施结果
团队开始愿意合作，并从分享实现业务逻辑的工作中获益。
一个原本专门为单一环境工作的服务，被转换成一个基于特定业务需求的更为通用的解决方案。
两个团队都了解他们各自的升级政策和部署设置，有可能为他们自己的设置找出改进。
需要对共享源代码进行修改的可能性增加，导致更频繁的机会来完善、改进和优化实施。
鼓励在发布包装、遥测、健康/准备就绪端点等方面逐步实现操作标准化，因为团队意识到，如果他们同意贯彻这些标准，就能更有效地在共享代码中维护这一点。
### 参见
与这种模式相关的是[30天保证](/zh/p/30-day-warranty)模式，它采取了不同的方法来解决上述的约束问题。
### 已知实例
* Europace AG
* Flutter 娱乐公司。一个[Flutter 内源应用程序](https://innersource.flutter.com/sdlc/)有一个共享的代码 "服务 "库，有跨团队的贡献和持续集成到流水线来构建和发布一个共享的发布工件。 每个采用的团队有一个 "部署配置 "库，定义他们自己的部署。这样方案满足了不同的监管要求、服务和事件管理实践以及不同业务领域的基础设施技能的需求。
### 状态
* Structured
### 作者
* Isabel Drost-Fromm
* Rob Tuley
### 致谢
感谢Tobias Gesellchen在Europace AG 的内部评审。
### 别名
服务 vs. 库: 这是内源，不是内部部署
### 翻译校对
* **2022-12-02** 翻译[姜宁](https://github.com/willemjiang)
* **2022-12-06** 校对[曾江云](https://github.com/skw0rm)
* **2023-06-18** 最后更新日期
# 标准发布流程
### Title
标准发布流程
### Patlet
如果团队不确定 InnerSource 项目的成熟度，他们可能会犹豫是否采用该项目。为了解决该问题，一致的发布说明和已发布制品至关重要。这些做法展示了对项目的坚定承诺，为用户提振了信心，并向他们保证了对可持续和管理良好的软件的持续承诺。
### 问题
当一个团队决定是否使用 InnerSource 项目时，他们的考虑因素之一是他们是否可以长期依赖于该项目。更换他们正在使用的工具/项目是有成本的，因此他们只希望在必要时进行这些投资，并获得切实的收益。
开源项目的通常做法是按版本发步，并在发行说明中记录破坏性变更和新功能，同时发布二进制文件或 Docker 镜像链接。对于 InnerSource 项目、模块等来说，这种做法可能不那么透明，或没有很好的文档化/可见性。
缺乏明确的发布制品或规范的发布流程的 InnerSource 项目往往会削弱团队间的信任。在这种情况下，其他团队难以预知下一个版本的发布时间，也无法准确把握可能出现的破坏性变更。
### 上下文
大型组织会生产大量的内部软件，其中很多软件都可以被整个公司的团队重复使用。运维工具、软件库和基础设施即代码（IaC）模块就是这类软件的常见例子。然而，大多数大型企业不会发布内部软件供公司其他团队使用。出现这种情况的原因可能是他们太忙，没有时间提供文档，或者没有意识到项目对其他人的价值。
应该有一个内部或公共代码库来存储源代码，但团队缺乏一个让外部团队使用软件的流程。
随着组织的发展和更多内部软件的编写，这种模式的价值也在增加。
### 约束
#### 对于没有集中式 CI/CD 系统的组织来说很困难
对于没有为工程师提供集中式 CI/CD 系统的组织而言，自动化构建和发布流程可能具有挑战性。团队可能需要建立自己的工具（Jenkins、Drone 等）。在没有 CI/CD 系统的情况下，仍然可以制作制品和发行说明，但可能需要在本地构建软件，并手动上传到托管制品的工具。
#### 增加了发布发行说明的负担
除了构建源代码之外，如果无法自动生成 git 提交列表，编写发行说明可能会很枯燥。除了编写更多发布细节之外，还需要其他人手动完成。
#### 没有地方来托管制品增加了难度
如果公司没有提供一个集中位置来存储制品（jar、npm 模块等）和 docker 镜像，工程师可能需要自己决定在哪里适合存储各版本软件。 GitHub 等工具可以提供此功能，但是，如果公司不使用这些流行工具之一，这可能会造成负担。
### 解决方案
通过提供清晰的**发行说明**和已发布的制品，可以增强人们的信心，让他们相信你发布的是值得信赖的优质产品。。
以下是实现这一目标的关键要素：
* 代码库中包含一个 CI/CD 流水线配置，可[自动化执行发布流程](https://opensource.guide/best-practices/#use-tools-to-automate-basic-maintenance-tasks)
* 由 CI/CD 系统来生成制品（二进制、docker 镜像、jar 等等）
* 发布的版本有清晰的标签，和[语义化的版本标记](https://github.com/semantic-release/semantic-release)
* 发布内容包括新功能说明、错误修复和所有的“破坏性变更”。
[这里](https://github.com/jaegertracing/jaeger/releases) 提供了一个高质量发行说明的范例。
### 结果背景
接触到您项目的团队会看到已发布的发行说明，并对您的工具充满信心。已发布的制品也会使您的产品使用起来更简单、更快捷。像这样定义明确、清晰可见的流程还有助于跨团队协作和新的贡献者。他们可以确信自己的贡献会在合理的时间内发布，并有明确的使用路径。
发行说明也是[表扬参与者](/zh/p/praise-participants)的绝佳机会！众所周知，对于希望参与项目的新人来说，[文档是极其重要的](/zh/p/base-documentation)。表扬外部队友的贡献，包括文档和发布说明，是培养社区和扩大用户群的好方法。
### 已知实例
* Comcast （多个项目）
* GitHub （多个项目）
### 作者
David Grizzanti
### 状态
结构化
### 翻译校对
* **2024-10-08** 翻译[Chris Yang](https:github.com/node)
* **2024-10-12** 校对[姜宁](https://github.com/willemjiang)
# 核心团队
### Title
核心团队
### Patlet
即使一个内源项目被广泛应用，但也可能因为项目难以协作而阻碍项目的贡献和使用。 建立一个核心团队，专门负责处理项目的基本事务。 他们的工作可以确保贡献者能够增加和使用满足他们自己使用场景需要的特性。
### 问题
* 很难为项目做出贡献。 这可能是由于以下情况：
* 不能在本地运行该项目。
* 糟糕的文档。
* 复杂的代码。
* 测试不充分。
* 难以使用该项目。 一些可能的原因：
* 糟糕的文档（再次）。
* 频繁的bug。
* 不直观的设置。
### 故事
有一个人人都依赖的中心项目。 这是一个多么好的内源候选项目啊！ 不幸的是，这个项目是自然发展起来的，各种贡献和补充功能都是胡乱地加进去的。 现在，它是一个恶心的、厚厚的代码泥潭，没有人理解，每个人都不敢去碰。 很明显，它应该进行一次大修（例如，重构、测试、文档等），但尽管每个人都需要并希望这项工作发生，却没有人投入时间和精力来完成这些事。
### 上下文
许多团队需要这个项目。
* 该项目有大量的技术债务。
* 与团队项目到适配和项目自身的迭代速度比较缓慢。
* 没有一个负责者或维护者对项目和项目贡献生态负责。
### 约束
* 每个作出贡献的团队都很忙，因此优先考虑那些能给自己带来直接回报的工作。
* 随着项目发展，项目变得越来越难使用和修改是一个普遍的趋势。
### 解决方案
组建一个核心团队，他们的工作是进行项目的维护，以便其他人可以很容易地加入到项目中并为其做出贡献。 这个核心团队做的工作对于建立一个健康的使用和贡献的项目生态系统是非常必要的。 这种关键的工作往往不会被常规到贡献所关注。 这类工作的类别包括项目沟通、本地环境适配和DevOps基础设施搭建。
下面是一些具体的例子。
* 产品Bug
* 文档
* 入门教程和示例
* 自动化测试
* CI/CD
* 本地环境适配
* 模块化
* 版本管理
* 监测
* 开拓新的类别/功能类别
上面的每一个条目对一个健康的产品生态都是非常重要的，但是却不太可能被优先考虑。
核心团可以由少数的全职或者兼职的人组成。 这种选择取决于所需的工作量、资源的可用性和组织的文化。 最重要的是，和其他团队一样，赋予他们权利，让他们承担责任，通过这样的方式形成一个核心团队。
由于他们的核心作用，核心团队成员几乎都应该充当 **Trusted Committer** 的角色（关于这个概念的更多信息，请参见[学习路径](https://innersourcecommons.org/learn/learning-path/trusted-committer/)和[模式](/zh/p/trusted-committer)）。 虽然受 Trusted Committer 的角色主要侧重于帮助他人对项目的贡献和使用，但核心团队成员也会定期对项目做出贡献。 核心团队并没有自己的商业目标来驱动其贡献。 他们根据什么最能帮助他人使用和贡献项目来决定工作内容。
不断提醒核心团队这一目标的一个好方法是让他们定期报告。
* 使用本项目的活跃团队的数量
* 对项目做出贡献的非团队人数。
持续关注这些指标会自然驱使核心团队优先考虑正确的工作，从而围绕项目创建一个繁荣的InnerSource生态系统。
### 结果上下文
* 它提升了项目的使用性并降低了项目贡献难度。
* 许多团队使用该项目并为其做出贡献。
* 他人对项目的交互和反馈是衡量核心团队做得好与坏的标准。
### 理论依据
项目贡献者都只关注自己业务，而不太关心项目的后续的发展，组建一个核心团队，并给他们分配维护项目任务，可以弥补这样的缺陷。 核心团队弥补了这种缺陷，扮演了团队润滑剂的角色，促使项目贡献生态保持健康发展。
### 已知实例
* 围绕其可重用的CI/CD流水线，\*Nike\*\*实施了这种模式来管理其InnerSource工作。\*实施了这种模式，
* **WellSky**为一个关键项目建立了一个核心团队。这使他们能够显著扩大对该项目的InnerSource贡献--见[具有核心团队的广泛应用规模的InnerSource](https://www.youtube.com/watch?v=kgxexjYdhIc)。
### 状态
结构化
### 作者
[Russell R. Rutledge](https://github.com/rrrutledge)
### 翻译校对
* **2022-12-08** 翻译[姜宁](https://github.com/willemjiang)
* **2022-12-08** 校对[曾江云](https://github.com/skw0rm)
* **2023-06-18** 最后更新日期
# 签约贡献者
### Title
签约贡献者
### Patlet
想为内源做贡献的同事被他们的直线管理层劝阻。正式的合同和协议为这种困境提供援助。
### 问题
如果没有中层管理人员的支持，贡献者的总数以及由此产生的贡献量和内源计划产生的价值可能会低于高层管理人员的预期。 如果没有足够的资金和授权给[专职社群领袖](/zh/p/dedicated-community-leader)，这种情况可能会被放大。 这有可能导致高层管理人员放弃内源的想法。
### 背景
一家大型企业开始了一项内源计划。该计划的主要目标是提高分布式软件开发的效率，并通过允许每个员工自愿为内源项目做出贡献来促进创新，而不论其从事的领域和所在的业务部门。
最高管理层已经加入并支持内源计划。对他们来说内源计划只是促进创新和效率的众多计划中的一个。他们正在为内源提供资金和社群领导人的能力，并在很大程度上给予预算如何使用的自主权。 他们还限制了该计划的范围和持续时间，并参与定期评审，直到证明它产生了预期的结果（见[评审委员会](/zh/p/review-committee)）。 最高管理层已经在各种公司内部会议上宣布他们对 内源 的支持。
然而，高层管理人员还没有授权或激励中层管理人员允许或甚至激励他们的员工参与跨部门的内源活动。 除此之外，每个员工的工作时间通常都被分配给非 内源 项目，占到了100%。 跨组织合作尚未成为常态，部门经理通常没有自己组织以外的目标。 对内源项目的贡献应该是在工作时间内做出的，而不是在空闲时间。
### 约束
* 管理人员要对其业务部门的结果负责。让他们的员工参与内源活动，可能会花时间在他们的业务部门之外做出贡献，减少了他或她的为业务部门工作的时间。这将可能使管理人员更难达到或超过他们的目标。
* 部门经理和人力资源部门会默认其下属的表现是根据其业务部门的目标来判断的，而这些目标可能与内源社区的目标不一致。
* 部门经理认为自己的行政管理权限越小，他或她就越不可能让自己的员工参与内源活动，从而为另一个业务部门作出贡献。
* 部门经理对下属所做工作的透明度和控制力越低，就越不可能让她对外做出贡献。
* 内源工作的管理和组织越不正式，习惯于正式程序的部门经理就越不可能同意其员工对内源做出贡献。
* 一个员工花在非自己本职工作的内源项目上的时间越多，他的业务部门的队友的工作量就会增加。
* 个人贡献者可能会认为参与内源是一个机会，可以增强他们在公司内的专业网络，并获得她所贡献的技术领域的知识和经验。
### 解决方案
在贡献者、他们的部门经理、企业内统一资助和指导的内源治理办公室（ISGO）之间，建立一个正式的协议，让ISGO为履行协议落实贡献时间的业务部门提供补贴。
* 协议规定了员工在内源中工作时间的最大百分比。
* 协议中明确规定，贡献者所在业务单位的工作优先于内源的工作。
* 协议规定，不要求在内源中的工作时间达到合同中规定的最大百分比。
* 该协议由贡献者、贡献者的直接经理、治理办公室和贡献者将要贡献的社区的[专职的社群领导](/zh/p/dedicated-community-leader)签署。
* 治理办公室在贡献者和她的直接经理在贡献时间上发生冲突时提供调解。
* [专职的社群领导](/zh/p/dedicated-community-leader)对内源工作占比协议超过20%的贡献者，直接参与其绩效评估或为提供参考意见。
### 结果
一个正式的协议和统一资助的补贴，令人信服地传达了组织对内源倡议的支持，从而授权中层管理人员签署协议：
* 将公司资金配置到业务部门的开发能力补贴上，向直线经理们传递了这个信号：内源被组织认为是有价值的，已获得管理层的支持，直线经理们应该支持内源。
* 正式的签约贡献者协议表明，内源的工作得到了专业的管理并鼓励相互信任
* 一个正式的合同增加了透明度，并为业务部门和内源项目提供了一个更好的可用人力资源概述，从而减少 "超额预订/预算资源"的风险。
正式的合同对贡献者和社群也有好处。
* 有了一个稳定的贡献者群体，他们中的一些人更有可能最终获得 [Trusted Committer](/zh/p/trusted-committer) 地位。
* 正式的协议为解决内源活动相关的冲突提供了一个基础。请注意，协议调解可能只适用在少数具有文化匹配的公司。
### 已知实例
* BIOS at Robert Bosch GmbH
### 状态
* 结构化
### 作者
* Georg Grütter (Robert Bosch GmbH)
### 致谢
* Diogo Fregonese (Robert Bosch GmbH)
* Robert Hansel (Robert Bosch GmbH)
* Jim Jagielski
* Tim Yao
* Cedric Williams
* Klaas-Jan Stol
* Padma Sudarsan
* Nick Stahl
* Ofer Hermoni
* Robert C. Hanmer
### 修改记录
* **2016-10-25** - 第一次评审
* **2017-05-09** - 返工
* **2017-09-08** - 第二次评审，最后修改和合并
* **2021-02-27** - 修复书中图案显示的问题
### 翻译校对
* **2022-12-06** 翻译[姜宁](https://github.com/willemjiang)
* **2022-12-31**校对 [陈泳](https://github.com/gzchenyong)
* **2023-06-18** 最后更新日期
# 记录你的指导原则
### Title
记录你的指导原则
### Patlet
通常内源对 "在组织内部应用开源最佳实践 "的解释对缺乏开源背景的人来说效果并不好。 作为一种补救措施，内源最重要的原则被记录下来并广泛宣传。
### 问题
该组织正试图在更大范围内推广内源。 该倡议是从开源爱好者发起。现在的目标是获得缺乏开源经验的人的支持。 对于这些人来说，典型的"应用开源最佳实践"的口号已经不足以传递内源是什么、它解决了哪些问题以及它使用哪些工具来解决这些问题的信息。 因此，内源在组织中的采用速度减慢了。 当贡献者开始跨越团队边界时进行协作是， 团队对内源的目标是什么以及如何实施最佳实践产生了疑惑。
### 故事
在一个组织中的早期实验表明，开源合作的最佳实践可以带来好处。 现在的下一步是将该倡议影响到缺乏开放源码深厚背景的团队和个人。
现在的目标是要清楚地传达内源计划的目标以及实现这些目标的明确路径。
### 上下文
* 内源作为一个术语在员工中流传。
* 该倡议由开源爱好者发起。
### 约束
* 团队难以准确地沟通实施内源在哪些方面比较重要。
* 缺乏开源经验的人无法理解将开源最佳实践引入组织的意义。
* 在日常工作中，试图遵循内源最佳实践的团队很难决定他们所做的是否符合内源的一般价值观。
### 解决方案
那些在组织中推动内源计划的人需要帮助那些缺乏深厚开源背景并对内源的缺乏直观理解的团队和个人。
应该通过记录这两个方面来向团队和个人传递清晰的信息。
1. **目的** - 组织为什么要采用内源？
2. **原则** - 哪些内源原则将有助于解决这些挑战？
下面的章节提供了关于这两个方面的更多细节，意味着可以作为你的组织记录这些原则的起点。
#### 为什么该组织要采用内源？
在过去，内源已被证明可以成功地解决组织中常见的几个问题。
然而，您的组织希望使用内源来改善哪些组织挑战？
与其一概而论，不如尝试准确地找出与你的组织的挑战相匹配的解决方案 - 最好是和哪些你想影响的人一起。
其他人通过遵循内源最佳实践解决的一些挑战：
* 减少由过度地盘意识造成的开发孤岛。
* 通过促进健康的代码重用，减少解决类似问题的时间，从而提高创新速度。
* 通过更好的跨团队合作来提升开发速度。
* 解决项目/团队的依赖性，超越 "等待解决方案 "和 "建立变通办法"，从而减少工程瓶颈。
* 提高质量。
* 增加员工的幸福感。
* 提高新员工的入职成功率。
* 建立可操作的文档。
#### 哪些内源原则将有助于应对这些挑战？
一旦团队了解内源将帮助他们解决哪些问题，下一步就是解释哪些原则有助于解决这些挑战。
基于基本的开源开发原则，以下准则已被证明是成功的。
(1) 代码必须透明地托管在组织内
源代码、文档、与项目开发相关的数据必须对组织内的任何人都是可用的，并且容易找到。
(2) 贡献大于提交功能要求
一个项目的所有利益相关者都是潜在的贡献者，并被作为贡献者对待和予以支持。 贡献仍然是建议而不是要求。 贡献前的协调有助于避免精力浪费。 项目提供贡献指南以避免摩擦。
(3) 错误是学习的机会
由于工作在整个组织中都是可见的，任何错误都会被所有人看到。 因此，必须建立一种文化，使错误成为学习的机会，而不是应该不惜一切代价避免的失败。
(4) 书面沟通大于口头沟通
对于跨越多个团队的项目，可能会有不同的会议时间表，需要有可能进行异步协作。 内源项目的目标是招募新的贡献者。 为此，未来的潜在贡献者需要能够在以低门槛，自我服务的基础上关注项目的进展。 如果项目的相关交流是通过同步交流进行的，那么所讨论的论点需要在书面渠道中透明化--最终决定应该只在书面渠道确定。 作为一个副作用，这会产生被动记录的基础文档，对任何项目的新人来说都是非常有价值的。
(5) 允许书面建议积累在一个持久的、可搜索的档案中
所有的项目交流，特别是所做的决定和导致这些决定的讨论，都需要被归档。 必须有可能通过稳定的URL来提供参考链接交流。 以往的交流需要以一种容易搜索的方式来储存。
但有两点需要注意:
1. 这并不能取代结构化文档。但它可以作为收集结构化文档的一个起点。
2. 所有的东西都要写出来，而且要让整个组织都能看到，这个规则也有例外。与个人有关的讨论以及与安全有关的讨论是敏感的，不应公开进行。
(6) 奖励 Trusted Committer 人员
所有的贡献（如源代码、文档、错误报告、对讨论的投入、用户支持、营销）都是受欢迎的，并应该得到奖励。 那些对项目表示支持的人将被邀请成为[Truested Committer](/zh/p/trusted-committer)。 一个项目的所有 Truested Committer 都会被公布。
### 结果
* 组织成员了解他们可以通过应用内源最佳实践来解决哪些挑战。
* 缺乏开源经验的组织成员了解内源项目的基本价值和原则。
* 缺乏开源经验的组织成员能够根据一套共同的既定价值观来检查他们的日常活动。
* 组织的开发实践变得与开源项目更加相似，从而使组织成员更容易参与到开源项目中。
### 已知实例
#### Europace AG
上述解决方案中列出的内源原则大部分是基于Europace公司的经验。 详情见 [Europace InnerSource Prinzipien](https://tech.europace.de/post/europace-inner-source-prinzipien/)（德语）。
#### GitHub
**目的**
在GitHub，我们的工作模式是团队为其职责范围以外的领域贡献功能。常见的例子包括：销售工程部贡献功能以促进销售，特别项目部贡献急需的、对整个产品有高度影响的功能，以及一个团队在多个领域工作以交付一个功能。
**原则**
总的来说，这份文件中概述的原则是为了避免增加技术债务和项目东道主团队的支持负担。很多时候，为东道主团队提供帮助是因为他们在自己的责任范围内由于支持和维护成本导致忙不过来，而且他们没有相关资源来实现这个功能。任何由其他团队完成的新功能，如果增加了支持负担或技术债务，就意味着东道主团队在新功能上的时间更少了，所以我们要确保他们（贡献团队）做得正确。
同时，我们努力成为一个工程师可以自由地跨边界工作的公司，业务优先事项经常要求我们在我们的核心领域之外的领域作出贡献。
对这些原则的一个很好的总结是，离开这个领域时要和你发现它时一样好，甚至更好。
考虑到这一点，以下是我们同意的原则。
* 避开累积功能债务的最小可用产品（MVP）。为了获得客户的反馈，发送一个MVP是可以的，但是贡献团队必须致力于完成功能集。这方面的例子包括。
* 承诺超越MVP，形成一个能满足大多数客户的解决方案。
* 完全支持对新功能的管理（例如，在设置的用户界面中支持，而不是只做命令行）。
* 在UI和API中展示功能，而不是只提供API（或反之）。
* 确保功能在云和本地服务器环境中工作。
* 对功能提供不局限在部署到生产环境中支持。
* 协调渐进式的推广
* 处理支持任务单
* 计划好时间来处理客户的反馈（功能和bug）
* 以正确的方式构建功能（不要积累技术债务）
* 与产品和工程团队就需求和解决方案达成共识
* 合理的架构和设计
* 确保数据被正确存储，以避免以后的数据迁移。
* 具有适当的遥测技术
* 具有适当的测试覆盖率
* 在云和本地生产环境中得到支持（包括设置、配置、备份/恢复、迁移等）
* 修复错误
* 更新文档
**参与**
我们之所以使用参与模式，是因为我们喜欢让团队在为其职责范围以外的领域贡献功能时，可以采取哪些具体步骤。
在GitHub，一个典型的参与模式是这样的。
* 获得产品负责人对功能集和推广计划的批准。
* 获得工程负责人（通常是工程经理和总监）对工程设计的批准，包括解决非功能需求（遥测、测试覆盖、多环境测试和支持）。
* 沿途进行代码审查，同时审查任何新的或改变的需求。
#### Robert Bosch GmbH
**目的**
促进合作、学习和创新是 Bosch 内源计划（BIOS）的主要重点。
**原则**
为此，Bosch 采用了以下原则。
* **开放性**：我们尽可能地降低进入BIOS社区的门槛。
* **透明度**：我们是完全透明的，与公司所有员工分享我们的工作成果、我们的沟通和我们的决策。
* **自愿**：加入BIOS社区并为之做出贡献的决定是由每个员工自己决定的。员工应该在 BIOS 工作，因为他们有内在的动力，而不是因为他们的经理告诉他们这样做。
* **自我决定**：BIOS社区可以自由选择工作内容、工作时间以及工作工具和流程。
* **任人唯贤**：BIOS项目成员的权力是基于他们的功绩，也就是基于他们贡献的质量和数量。
*开放*、*透明* 和 *自愿* 的原则有助于发展由内在动机的同事组成的多样化社区。 事实证明，*任人唯贤* 是做出巨大贡献的有效激励。 *自我决定* 使社区能够以最有效的方式利用他们有限的时间来做出贡献。
### 状态
结构化
### 作者
* Isabel Drost-Fromm
* Georg Grütter
### 致谢
* Zack Koppert - for sharing GitHub's approach in the Known Instances
### 别名
明确的内源原则
### 翻译校对
* **2022-12-08** 翻译[姜宁](https://github.com/willemjiang)
* **2022-12-27** 校对[龙文选](https://github.com/hncslwx)
* **2023-06-18** 最后更新日期
# 评审委员会
### Title
评审委员会
### Patlet
对于开发人员和管理人员来说，内源的工作模式与更多的传统方法截然不同。通过建立一个评审委员会，作为内源计划和所有参与该计划的业务部门高级管理人员之间的接口，后者更有可能更加熟悉并支持该计划，因为评审委员会为他们提供了一定程度的监督和控制，而不会助长微管理。
### 问题
管理人员会认为内源的工作模式与他们习惯的和有经验的工作模式有很大的不同。因此，他们很可能会拒绝内源计划，或对其进行微观管理，以尽量减少这种变化所带来的风险。在这两种情况下，内源的好处都无法实现。结果是，大家都不相信内源能够成功实施。
### 背景
A公司想引进它的第一个内源计划。A公司的大多数经理都不熟悉开放源码的工作模式，而是习惯于等级制度、自上而下的控制式管理。
### 约束
* 管理者对内源计划中的工作的控制感越强，就越有可能在没有经验的情况下支持该计划。
* 管理者对开源工作模式的经验越少，就越有可能希望控制内源 计划的风险。
* 对内源计划的管理越严厉、越微观，开源工作模式就越不可能被广泛采纳。因此，内源的好处将无法实现。
### 解决方案
* 建立一个评审委员会，由参与内源计划的所有业务单位的高级管理人员组成。
* 评审委员会成员有权以集体评议的方式决定哪些内源项目将获得通用资源的支持，特别是资金。
* 申请人可以在会议前被评审委员会成员推选，在评审委员会会议期间提出其拟议的内源项目供评审。
* 目前由评审委员会资助的 内源 项目的负责人有义务在每次评审委员会会议上汇报其项目的情况。
* 评审委员会成员有义务在评审委员会会议期间向新申请人和现有项目负责人提供建设性的反馈意见。
* 每个内源项目都要有对评审委员会会议上收到的反馈做出反应的机会，直到下一次会议，以避免过早地关闭项目。
* 内源项目负责人也可以在评审委员会上主动提出要关闭的项目的动议。然后，评审委员会要决定是否需要给使用该软件的业务部门时间来制定措施，以确保代码库的开发和/或维护继续进行，直到找到内源社区开发的替代解决方案（如果与业务相关或任务关键）。
* 评审委员会应定期举行会议。事实证明，每年召开两次会议是成功的。
### 结果
* 管理者将他们熟悉的工具应用于内源，以获得所需的关于内源计划内部运作的足量信息和控制权。这种熟悉程度将使他们更有可能签署内源计划，并给予内源项目所需的自由度。
* 开发人员在一定程度上仍然有自组织的空间。微观管理不会发生，因为评审委员会召开的频率相当低。
### 已知实例
* BIOS at Robert Bosch GmbH
### 状态
* 结构化
* 截至17年8月31日，*已定稿和评审完毕*。
### 作者
* Georg Grütter, Robert Bosch GmbH
* Diogo Fregonese, Robert Bosch GmbH
### 别名
奶酪接口(Cheese Interface)
### 翻译校对
* **2022-12-07** 翻译[姜宁](https://github.com/willemjiang)
* **2022-12-19** 校对[龙文选](https://github.com/hncslwx)
* **2023-06-18** 最后更新日期
# 跨团队的项目评估
### Title
跨团队的项目评估
### Patlet
要推销跨团队的内源项目的价值是很难的，因为这些项目并没有对公司的收入产生直接影响。 这里有一个数据驱动的方法来展示和凸显你的项目价值。
### 背景
* 你负责一个跨团队项目，为公司其他团队提供平台服务。
* 这种跨团队的项目并没有为公司的收入带来任何直接的价值。
### 问题
跨团队的项目有可能对公司产生非常大的影响，但很难用数据驱动的方式来表示。 因此，在不提供真正价值的项目中耗费很多精力或对本来会产生巨大价值的项目投资不足是一种非常容易产生和普遍的现象。
### 约束
* 项目需要向公司领导展示价值（客观或主观）以获得资金支持。
* 跨团队的项目价值分散在多个终端业务部门。
* 由于这种分散性，跨团队项目的价值很难直接衡量。
### 解决方案
定义一个如何评估跨团队项目价值的模式和模型。 这种模式给我们提供一个需要关注和放大公司的高价值合作的工具。
所有跨团队项目价值的核心是，我们可以一起完成比分头行动更多的工作。 衡量一个跨团队的工作价值是一个量化大家一起完成的工作 *怎么就更多* 的练习。 不同的领域和项目的生产效率存在差距。 有一个常见的流程，你可以用它来创建一个模型，用来计算这个协同带来的价值。
#### 解释
组建一个由你的领域内的相关专家组成的小团队。 利用这个专家团队，对使用你项目的每个消费者进行4个方面的估计：
* 他们需要多长时间来消费你的项目产出？
* 如果一切都靠他们自己来实现，他们需要多长时间才能实现和你项目一样的功能？
* 你的项目产出中有多大比例对他们来说是有用的？
* 如果不这样做，他们会花多少时间（每个用户）来维护他们自己的解决方案？
在进行这些估计时，不可能高度准确地知道任何活动需要多长时间。 这不是你的目标。 与其说是准确，不如说你应该努力为这些估算 ***设定一个最坏情况下的界限***。 我们的想法是让专家组能够达成一致："我们不知道到底要花多长时间，但我们都同意至少要花这么多时间"。 具体来说，你应该估计出使用你的项目的 *最大* 合理时间，以及消费者如果自制、使用和维护他们自己的解决方案的 *最小* 合理时间。
关于 "实现你自己的解决方案"（home-roll）的成本的一个说明。 自研解决方案的成本不一定（事实上不太可能）与制作一个共享解决方案的成本相同。 通常情况下，对于相同的功能，建立一个跨团队的共享解决方案所涉及的模块化和质量的投入明显高于只使用一次的快速、硬编码的实现。
#### 公式
一旦你有了最坏情况的界定，你就可以通过简单的公式来评估你在给定时间内的跨团队项目产出。
```
[节省的时间] - [投入的时间]
([新用户数] * [自研成本] * [有用功能百分比] + [使用次数] * [每次使用的维护成本]) - ([新用户数] * [用户入门成本])
[新用户数] * ([自研成本] * [有用功能百分比] - [用户入门成本]) + [使用次数] * [每次使用的维护成本]
```
#### 评论
尽管有严谨的外表，这个过程并没有给出衡量跨团队项目产出的确切方法。 然而，在实践中，它确实提供了一个计算框架，你可以据此对如何资助这个项目做出合理的决定。 根据上面的解释，在有了好的、合理的数据之后，你应该运作项目投入专门的开发时间，投入 ***至少*** 要达到以下三个层面中的较小者。
1. 通过上述公式节省的原始时间。 既然我们都确信这个公式会产生一个低于真实节省的小时数的数字，你就可以有信心，就项目投入到节省的时间，对你来说是稳赚的。
2. 支持内源性贡献给跨团队项目所需的时间。 由于贡献者很可能会以一次性的方式完成工作，所以资助他们的工作以达到协同工作所需的时间是值得的。
3. 只要你觉得好就行。拥有一个估值公式的一个有益的副作用是，它自然会迫使大家对项目消费者提供价值的关键使用点进行测量。
通过理解这些测量结果，并以其原始形式进行使用，那你就可以得到一个关于项目有多大价值的直觉想法。
有些人可能会担心这种评估方法缺乏准确性。 虽然这个过程不能给出一个非常准确的测量结果，但它只需要在两个方面提供足够准确评估：
1. 为那些组织和资助跨团队工作的人提供一种展示正在发生的价值的手段。
2. 帮助那些参与者根据价值的优先级明确跨团队工作的哪些领域是值得追求的。
在实践中，只要这些价值是在现实和彼此之间的一个数量级内，它们就足够准确，并满足这些目的。与本文开头的**问题**部分所描述的临时评估（以及由此产生的影响）相比，它们将在实际结果中提供一个从源头入手的改进。
### 结果
* 用数据驱动的方式与领导层讨论跨团队项目的价值和资金。
* 围绕跨团队项目的关键指标，以原始形式进行检测。
* 定义跨团队项目所提供的价值，可能导致它实际上为公司产生更大的价值。
* 推动更多项目成功，并且不断宣传这些成功项目。
### 已知实例
* Nike
### 状态
* 结构化
* 在多个领域得到证实。
### 作者
* Russ Rutledge
### 致谢
* Jeremiah Wright教我把跨团队项目看作是以开发者时间为货币的内部业务。
### 翻译校对
* **2022-12-07** 翻译[姜宁](https://github.com/willemjiang)
* **2022-12-19** 校对[龙文选](https://github.com/hncslwx)
* **2023-06-18** 最后更新日期
# 通过扩展实现可持续增长
### Title
通过扩展实现可持续增长
### Patlet
InnerSource 项目收到了太多的贡献，这会导致维护变得困难。通过在核心项目之外提供扩展机制，维护者可以用最小的成本和维护开销扩展项目功能。
### 问题
随着对成熟 InnerSource 代码库的贡献数量迅速增加，代码评审和维护的负担也随之加重。这将导致大量代码评审任务积压或过早拒绝新功能贡献。
项目团队如何才能更快地发布新功能、鼓励创新和实验，同时又能很好地维护代码库呢？
### 故事
有一个战略性项目，旨在将某一领域内的最佳创新集合到一个通用栈中，从而实现通用基础架构的重复使用，并提供标准的用户体验。通过 InnerSource，组织内从事该领域工作的各个团队都有机会开展合作，并将自己的创新成果贡献给通用代码库。
然而，当多位开发者同时进行大量并行贡献时，代码库的维护变得愈发复杂。这种情况给项目维护者带来了巨大的挑战。他们不仅要肩负确保代码质量的重任，还需要通过多种沟通渠道积极促进社区的健康发展。
项目维护人员面临职业倦怠的风险，原因如下：
* 待评审的贡献者 PR 不断积压。
* 工作不满意： 维护者的大部分时间都花在社区支持上，没有创新的空间。
* 缺乏成就感： 并非所有贡献的功能都有足够的用户需求，并因此被采用。
* 发布耗时： 代码库中的功能越多，测试时间就越长。
* 维护活动增加： 随着新功能的增加，会出现更多错误。
我们常常在新功能正式发布前，投入大量时间对其进行完善和优化。然而，这种做法存在一定风险：如果这些精心打造的功能最终无法满足潜在用户的实际需求，那么我们为追求卓越代码质量所付出的努力可能就会付诸东流。
### 上下文
* 一个具有战略意义的 InnerSource 代码库正随着多名员工对新功能的贡献而迅速扩展。
* 评审人员与贡献者的比例悬殊导致 PR 积压越来越多，这拖慢了向社区发布新功能的速度。
* 代码库质量下降，用户体验受到负面影响。
* 代码库维护人员不堪重负，无法及时应对大量贡献和社区支持的增加。
* 一些贡献的功能没有得到用户的采用，甚至可能完全处于休眠状态。然而，即使这些功能未被使用，它们仍然会增加维护开销。
* 组织正在投入巨资强化新功能的贡献，以便在社区探索这些想法之前保持质量标准。
* 这种模式适用于任何一种情况：
* 维护者发现自己经常拒绝新功能提议，以控制项目规模。然而，这可能会抑制社区创新，限制项目的发展潜力。
* 为了减少项目积压，新功能在没有完整文档、加固或测试的情况下就被发布，造成了糟糕的用户体验。这也在扩大代码库的规模，增大依赖关系图，使其难以维护。
### 约束
* 维护者和产品所有者希望允许扩展、鼓励创新和试验，但又不过于限制贡献，同时还要保持良好的代码和质量标准，以保证用户体验。
* 为达到产品标准，需要花费大量时间对功能进行加固和全面测试，但产品所有者可能希望在投入时间使功能成熟之前，允许更快地发布新的创新，供采用产品的用户探索。
* 维护者希望鼓励社区分享将产品功能与其他用例相结合的创新，而不给主代码库增加更多的依赖性。
### 解决方案
允许[扩展/插件](https://en.wikipedia.org/wiki/Extensibility)进入大规模的 InnerSource 代码库，可以减轻代码库维护者的维护负担，并允许更快地发布新功能供采用产品及探索。这就将功能的维护工作转移给了扩展所有者，并允许主代码库支持已被更广泛采用且更具战略性的功能。
扩展机制为潜在的核心功能提供了一个有效的筛选渠道。它不仅充当了新功能的孵化器，还为社区创造了一个自然的强化环境。这种方式使得大量功能完善和优化工作能够在一个更加开放和灵活的环境中自然进行，避免了在耗时耗力的正式评审过程中进行这些工作。
为了使扩展模式取得成功，在架构上有一些注意事项需要牢记：
1. **易于创建：** 为了获得社区参与，扩展需要易于创建。
* 创建一个初始扩展的代码库模板，作为新扩展的起点。这允许扩展在新代码库中添加新功能，与核心项目分开。该模板应提供与主代码库相同的模块化结构，并包含打包和发布扩展的框架。
* 确保随着主代码库的变更，模板得到良好维护。主代码库维护人员负责更新模板以确保其与主项目兼容。遵循良好的版本控制约定，例如 [semver](https://semver.org/)，可以使这更容易遵循。
* 建议主代码库的维护团队提供详细的指南，阐明如何在新版本发布时，基于旧版本的模板对扩展进行更新。
* 添加从模板开发的示例扩展，项目开发人员可以参考这些扩展来了解如何编写模式良好的扩展。
* 放宽对贡献者创建扩展的要求，绕过评审，以实现更快的发布或试验。
2. **低耦合：** 拥有包含功能的模块化组件可以允许松散耦合，其中扩展的更改不会影响主代码库或其他扩展的质量。
3. **依赖管理：** 每个扩展都应谨慎地指定其所依赖的主代码库版本范围，就如同处理其他依赖项一样。在选择其他依赖项时，也要特别注意与主代码库的依赖关系，确保所选版本与指定的主代码库版本相兼容。这种做法不仅能够保证扩展的稳定性，还能通过扩展的测试框架有效地捕获与主代码库之间可能存在的任何冲突。
4. **测试策略：** 如何单独和组合测试扩展？
* **单独测试扩展：** 扩展模板将提供一个测试框架，供扩展开发人员用来测试添加的功能。这可以包括单元测试、运行时性能和质量测试的框架。
* **与主代码库结合测试扩展：** 扩展开发人员有一种模式良好的方法，可以针对主代码库的特定版本测试其扩展，而无需主代码库维护人员的参与。
* **与其他扩展结合测试扩展：** 为每个扩展提供全面的测试框架可能会显得过于繁重。如果扩展之间保持适度的松散耦合，冲突的可能性本来就较低。然而，若用户在组合使用扩展时遇到冲突，他们可以直接向相关扩展的维护者报告问题，由这些专业人士来解决兼容性问题。值得注意的是，当扩展发展到生命周期的后期阶段，并有机会被合并到主代码库时，它将与库的其他部分一起进行全面测试。在这个关键阶段，所有潜在的依赖冲突必须得到彻底解决，以确保整个系统的稳定性和一致性。
5. **可发现性和可用性：**
* 通过显示用户已创建并希望共享以供产品使用的扩展的发布页面，使扩展易于被发现。
* 允许在主项目中注册扩展，以便用户可以在原始项目中利用扩展，从而保持相同的用户体验。
6. **扩展的生命周期和可维护性：** 建立扩展从创建到移植到主代码库的生命周期，以及明确的所有权准则。
* 扩展创建者继续维护扩展，提供任何支持并修复缺陷。任何未维护的扩展都不会从发布页面列出。
* 创建何时可以将扩展移植到主代码库的标准，例如内部产品对扩展的采用以及对该功能的需求。
* 扩展到主代码库的移植过程将遵循库维护人员制定的更严格的代码评审指南。
遵循这些原则可确保：
* 开发人员无需编写大量[样板](https://en.wikipedia.org/wiki/Boilerplate_code)代码，即可为项目生态系统添加新功能。
* 主项目的所有用户都能以可重复的方式发现扩展功能；代码还没有合并入主库并不意味着它没有价值。
* 维护者的负担会减轻，直到扩展证明它填补了主项目中的重要空白。
* 核心项目的通用代码（如基类和实用功能）可以作为扩展项目领域的新开发的起点。这就避免了事后移植创新工作的需要，从而减轻了为项目开发新功能的总体负担。
* 开发人员更有可能为他们的代码库做出贡献，并继续参与维护和社区建设，这也有利于整个项目生态系统的健康发展。
### 结果背景
* 项目能够通过增加新功能来扩展，同时不会增加主项目代码库的维护成本。
* 更快地发布新功能供社区探索，鼓励创新和试验。
* 将耗时且成本高昂的代码审查和功能完善过程推迟到功能已经证明其实用价值之后， 以有效降低企业的投入。
* 可能引入的一个后置问题——如果扩展无法完成一个完整的生命周期，会怎么样？
* 如果一个扩展在一段时间内没有被采用，也无法围绕它建立一个支持维护的社区，那么就需要扩展所有者在他们希望的任何时间内继续维护它。如果扩展没有得到维护，就会被取消发布。
* 如果扩展开发者无法继续维护其项目，而社区中的其他开发者希望继续支持该扩展，他们可以继续维护该扩展。
### 已知实例
* **IBM 公司**采用了这一解决方案来扩展[InnerSource 人工智能类库](https://youtu.be/Lz-tIc2cyRM)。扩展库为开发人员提供了一个灵活的平台，使他们能够通过添加新算法来丰富人工智能类库的功能。这不仅促进了技术创新，还为公司内部社区创造了分享和交流的机会。与此同时，核心库保持精简，仅包含经过充分验证和广泛采用的关键算法。这种结构设计确保了在项目规模不断扩大、贡献者增多的情况下，核心库仍然易于维护和管理。
### 别名
管理大规模贡献的扩展
### 状态
结构化
### 作者
* Sukriti Sharma, IBM
* Alexander Brooks, IBM
* Gabe Goodhart, IBM
### 翻译校对
* **2024-10-10** 翻译[Chris Yang](https://github.com/node)
* **2024-10-12** 校对[姜宁](https://github.com/willemjiang)
# 问题追踪器使用案例
### Title
问题追踪器使用案例
### Patlet
内源东道主团队不仅没有使计划和进展，而且也没有将变化背景信息变透明。这可以通过增加项目问题跟踪器的使用案例来解决，它也可以为头脑风暴、实施讨论和功能设计服务。
### 问题
一个团队开发了组织中许多团队都依赖的组件。 它使用一个标准的问题跟踪器来跟踪开放的错误报告和功能请求。 然而，每个条目的上下文是非常有限的。因此，潜在的贡献者没有办法知道每个问题到底是在谈论什么变化。
### 上下文
内源项目的工具都已经设置好了。然而，一般的项目问题跟踪器主要用于分享项目进度。 在内源项目中，问题跟踪器则可以用于更多的用例追踪，使远程、异步的沟通更容易。
### 约束
* 贡献者希望了解他们所需的功能是否已经安排在路线图上。但由于问题中缺少大量的上下文，因此不可能决定现有问题是否符合贡献者的需求。
* 因此，很多重复的问题被打开，核心维护团队不得不处理。
* 由于开放问题中的上下文是如此有限，贡献者无法通过实施一些已经开放的更容易的问题来帮助核心维护团队。因此，大量的工作仍然在东道主团队的手中。
* 由于强烈关注口头交流，在几个月或几年后，不可能辨别出为什么某个功能会被选中实施。因此，重构，特别是简化组件的工作，就成了项目考古学和寻找谁还记得讨论过什么的脑力练习。
### 解决方案
拥抱 "书面胜于口头 "的理念，不仅是在纯粹的软件开发中，而且在新功能的规划阶段也是如此。
* 对于bug，计划中的功能以及功能想法都会产生单独的问题描述。在每一个问题中包括尽可能多的信息，以便潜在的外部贡献者能够理解其背景。理想情况下，特别是对于比较容易的变化，包括足够的信息，以便外部贡献者通过实现相关的功能来支持东道主团队。
* 尽可能使用问题跟踪器作为提问的渠道。如果你缺乏其他的沟通渠道来解决用户的问题，这尤其有帮助。
* 利用标签和类别，以区分用于不同目的的问题。
* 对于异步开始的头脑风暴会议，打开一个问题来收集想法。当讨论开始平静下来时，在一个单独的文件中总结这个问题中已经确定的要点。在相关的拉动请求（代码实现）发布出来，以深入研究仍然需要澄清的个别要点，以供代码评审使用。由此产生的文件可以用来在其他适当的渠道发布结果，并供未来参考。
* 大多数问题跟踪器的实现都提供了问题模板。利用这些模板，不仅可以收集bug报告的常用信息，还可以包括其他使用类型所需的信息提示。
### 结果
* 更多地利用项目的问题跟踪器进行交流，使外部贡献者能够跟上，并对贡献什么内容做出更好的。
* 注重结构化的书面交流使东道主团队成员能够远程参与。
* 始终以书面形式进行沟通意味着关于项目决策的被动文件会作为副产品积累起来，而不是需要增加关注。
* 始终如一地使用公共交流渠道，导致更多的人关注讨论。这意味着有更多知识渊博的人可以回答问题，在开放的问题上插话，或者指出计划中的功能的缺陷，否则这些缺陷会在很久以后才被发现。
* 将讨论转移到公共讨论媒介上，为未来的潜在贡献者创造了一个机会，让他们在第一次需要参与之前就能聆听、跟随、适应和了解项目的运作方式。
### 已知实例
* Europace AG - 请看博文 [Issue Use Cases](https://tech.europace.de/post/using-issues-for-asking-questions-and-tracking-work/)
### 作者
Isabel Drost-Fromm
### 状态
结构化
### 翻译校对
* **2022-12-06** 翻译[姜宁](https://github.com/willemjiang)
* **2022-12-09** 校对[龙文选](https://github.com/hncslwx)
# 零工市场
### Title
零工市场
### Patlet
建立一个市场，创建一个内部网站，将特定的内源项目需求列为 "任务"，并提出明确的时间和技能要求。 这将使管理人员能够更好地了解员工的时间承诺和专业利益，从而增加获得批准做出内源贡献的可能性。
### 问题
经理和员工都不明白他们如何能从参与内源项目中获益。
员工很难向管理层传达他们需要为内源项目投入多少时间。
管理人员没有统一的方法来跟踪或奖励员工对内源项目的参与。
### 故事
你已经成功地在公司创建了一个内源项目，并得到了高级管理层、中级管理层和开发人员的支持。 然而，在将近一年之后，除了最初创建内源项目的团队之外，很少有人对这些项目做出实际贡献。 在采访了所有相关方后，主要的症结似乎是很难知道如果开发者选择参与内源项目，他们将被要求做出多少时间承诺，以及他们个人将如何受益。没有统一的方式来告知能够为贡献者提供什么样的机会，他们会被要求做什么，以及大概需要多长时间。 经理们都很支持，并希望他们的员工参与进来，但到目前为止，还缺乏一种方法来记录或奖励他们的员工在内源项目中的活动。 对于所有相关方（内源项目所有者、潜在贡献者和开发经理）来说，可以做些什么来改善这种状况？
### 背景
员工希望他们能够在不离开他们目前的职位就能接触到公司其他领域的活动。内源项目的存在，可以提供这些经验，但有两个主要因素阻碍了员工的参与。首先，他们无法轻易发现正在进行的内源项目中存在哪些贡献机会，也无法将这些机会传达给他们的经理。 其次，是经理们无法计划和说明他们的员工对这些内源项目任务的时间承诺。 因此，内源项目所有者发现很难建立足够规模的社区来实现他们的既定目标。
### 约束
* 员工没有简单的方法来发现内源存在的机会。
* 员工不了解如何做出对他们职业发展有利的贡献。
* 管理人员不了解与内源项目相关的时间/精力要求。
#### 前提
* 经理为员工提供时间，让他们参与到内源项目中。
* 管理人员需要一种方法来量化、跟踪和记录内源的贡献，以便对其进行核算和奖励。
### 解决方案
创建一个基于 "零工"的内部网站，个人可以在这里宣传他们的技能和兴趣领域，内源项目负责人可以宣传合作机会。
员工应该能够在应用程序中创建一个档案，在其中列出他们的技能和兴趣领域。 该系统应利用这些信息，在有符合一个或多个标准的零工发布时，主动通知个人（通过电子邮件或其他方式）。
内源项目负责人发布的每项任务都应包括估计的技能和时间要求，这样就可以很容易地与可用的员工匹配，并清楚地传达给他们的直接管理人员。说明中还应包括一个理由，说明该任务对承担该任务的人有什么好处，以使其尽可能具有吸引力。
可以建立一个基于积分的系统，以奖励和跟踪员工参与零工的情况。 例如，一旦任务完成，任务拥有者可获得10分，完成任务的开发人员可获得100分。完成任务所积累的积分可以作为一种游戏化机制和绩效管理标准，以展示其在组织内专业领域表现。
那些希望接受零工的人应该首先由零工的所有者进行审查，以确定该员工是否具备必要的技能，以及他的经理分配给他完成零工的时间。
通过工作任务所做贡献的透明度可以帮助贡献者建立（或减损）她的声誉，从而创造更多的可能性，使贡献的质量高。 完成 "任务 "也可以作为一个特定领域的专业知识的证明。
发布在市场上的工作性质可以包括硬技能和软技能，如组织团体活动、撰写报告或请求提供指导等。
创建零工市场的工作最好由组织内的一个团队承担，这个团队负责提供全公司的基础设施和能力。
### 结果
内源零工市场极大地增加了内源项目的数量以及参与这些项目的员工人数。零工市场的自我导向性提高了员工的工作满意度，因为他们可以对自己的工作和公司内部的合作伙伴有一定程度的选择。 员工们清楚地了解他们所签署的是什么，以及他们能从这种经历中得到什么。经理们能够更好地估计和跟踪员工在内源项目上的时间承诺，认可他们的个人努力，并将完成零工作为验证他们具体技能的一种方式。 经理们还能够利用其员工可能遇到的任何现有的休整时间，让他们转而从事零工市场中的工作。 零工市场内的互动所产生的数据也有助于推动所有部门的招聘和培训决策。
当与内源门户模式结合使用时，零工市场除了提供与零工相关的项目的代码库和文档的链接外，还提供了更精细的背景和细节。
### 已知实例
* 一家大型金融服务机构利用创建内源零工市场网站来推进其内源计划。
* SAP实施了零工市场网站模式-在内部工作平台上增加了一个新的内源项目，在这里可以发布职位和类似的任务。
* 在这种情况下，零工市场模式与相关的[内源门户](/zh/p/innersource-portal)模式已被证明效果非常好。 内源门户网站提高了人们对目前正在进行的具体项目的认识，而零工市场则公布了在这些项目中可以进行的某种类型的任务。
### 状态
* 结构化
### 作者
* Stephen McCall
* Shreyans Dugar
### 翻译校对
* **2022-12-07** 翻译[姜宁](https://github.com/willemjiang)
* **2022-12-26** 校对[龙文选](https://github.com/hncslwx)
# 模式模板
### Title
Short Title Here
### Patlet
Concise 2 sentence description of the problem and solution. The 1st sentence describes the problem. The 2nd sentence describes the solution. Readers may quickly review dozens of these patlets (aka summaries) to discover and browse the larger library of patterns. From .
### Problem
What is the problem - crisp definition of the problem. Short description, usually not more than a couple sentences, that describes what the issues and challenges are. Be careful not to morph into information found in other sections below.
### Story (optional)
Sometimes there is a story that helps people understand the pattern better.
### Context
Where does the problem exist? What are the pre-conditions? **Unchangeable** before the solution goes into place. The content here is often tied to the applicability of the pattern for other readers: "Do I have this same particular situation?"
### Forces
What makes the problem difficult? What are the trade-offs? These are constraints that **can be changed** at a cost. The solution might change one or more of these forces in order to solve the problem, while also in-turn changing the context.
### Sketch (optional)
visual illustration
### Solutions
Verified resolutions and possible resolutions to the problem.
### Resulting Context
What is the situation after the problem has been solved? The original context is changed indirectly by way of the solution. Often this section can include discussion of the next possible Patterns/problems introduced. This section can be short in content - the solution may not introduce new problems or change much context.
### Rationale (optional)
Explains why this is the right solution; using totally different words WHY this solution balances these forces and this context to solve this problem. Can expand on what-if's or theories.
### Known Instances (optional)
Where has this been seen before? Helps to reinforce that this is a REAL pattern and that you match the context.
May mention:
* A particular business
* Anonymized instances ex: "3 companies have proven that this is a good solution" or "A large financial services org...".
### Status (optional until merging)
General pattern status is stored in GitHub's Label tagging - see any pull request. Note that this GitHub label tagging becomes less visible once the pattern is finalized and merged, so having some information in this field is helpful.
You might store other related info here, such as review history: "Three of us reviewed this on 2/5/17 and it needs John's expertise before it can go further."
### Author(s) (optional)
Often, this is yourself. If you need to, find someone in the InnerSource Commons to be the nominal author (As Told To). Could also be no-one if you do not want to take on authorship (common with a donut looking for a solution).
### Acknowledgments (optional)
Include those who assisted in helping with this pattern - both for attribution and for possible future follow up. Though optional, most patterns should list who helped in their creation.
### Alias (optional)
If this pattern is also known under a different name than what is listed under **Title**, please list those alternative titles here. e.g. if the pattern is named after the problem it solves, a helpful alias might be one that describes the solution that is applied.
# 额外
# README 模板
## 项目使命
这里应该包含一个关于你的项目使命的简短描述（3-5句话）。其目的是说明项目打算做什么，并帮助外部的贡献者大致了解项目的哪些类型的功能可能会受到欢迎。
参见《生产开源软件》中的[使命宣言篇](https://producingoss.com/en/producingoss.html#mission-statement)。
## 快速入门
这一部分应该包含为第一次使用的用户编写的关于如何开始使用这个项目的简短文档。其它的详细信息文档可以通过链接的方式加入这个小节。
## 更多信息
这一部分可以列出以下任何或全部内容。
* 软件所涉及的功能、用例的清单。
* 用于解决权衡问题的设计原则的信息
* 用户级文档的链接
* 常见问题（FAQ）的答案，最好是可以链接到具体问题及其答案的格式，以方便参考。
## 获取帮助
这一部分应该包含一个简短的文档，让用户了解如何获得项目的帮助。 文档可以很简单，如果你的项目想要回答问题的话，可以把用户指向问题追踪链接。 它也可以指向一个存档和可搜索的聊天频道，或者存档的可搜索邮件列表，或者在线用户论坛。
## 参与项目
这一部分应该包括如何与该项目取得联系的信息。通常，这将包含存档的、可搜索的和可链接的沟通渠道的链接。
## 关于我们
这是一个给项目的 Trusted Committer 以荣誉的好地方。
这里可以包括作为一个 Trusted Committer 人对这个项目意味着什么的信息--尽管理想情况下， 一个组织中的所有项目都使用相同的定义，而这里提供的只是指向这个定义的链接。在这里保留链接的原因是为了让那些没有或很少 在内源项目中工作和贡献经验的同事能够直接从他们日常工作中需要的技术项目链接中获取到公司范围内的信息。
## 贡献指南
这一部分应该记录（或链接到文档）所有第一次贡献者需要知道的事情，以便更好开展工作。通常情况下，文档中不会包含下面的所有主题。 文档描述的重点是你的项目中与标准设置不同的地方，以及以前的贡献者认为难以理解的地方。
* 如何获取源代码。
* 如何找到你的项目需要帮助的问题清单--这些问题既可以是技术性的，也可以是非技术性的。一般来说，你会把这些问题放在问题跟踪器中，供贡献者访问。
* 链接到更多的文件，例如关于项目的结构、一般的编码风格、测试惯例......。
* 对于技术贡献。进行代码修改，构建项目并测试你的修改。
* 将你的修改提交给项目。
理想情况下，你还应该包括关于项目的首选开发流程的信息。贡献者应该先打开一个issue并提交修改提案，还是欢迎他们立即提交修改？ 在检视贡献时，什么对你来说是重要的？
此外，你应该概述你希望在项目中遵循的任何设计原则。将这些原则明确化往往有助于更快、更容易地解决权衡问题解决方案。 此外，它还有助于使原本隐含的假设变得透明。
随着时间的推移，你会注意到这一节会有很大的增长。在这种情况下，可以考虑将这些信息转移到不同的文件中，例如，`CONTRIBUTING.md`和`TESTING.md`。
# CONTRIBUTING 模板
## 贡献的类型
在这里提供你的项目需要什么样的贡献的信息。例如，这些可以是错误报告，帮助回答用户问题，改进文档，修复错误，以及新功能的实现。
## 错误报告
在这里添加关于如何提交错误报告的信息。这应该包括提示项目需要哪种类型的信息，以便重现和修复问题。它还可以包括常见的看起来像bug的错误配置的信息。
也可以包括关于贡献者在首次回应和之后的处理方面可以期待的信息。
## 功能请求
在这里添加关于如何提交功能请求的信息。也包括关于贡献者在首次回应和之后的处理方面可以期待的信息。
## 贡献文档
包括关于你的项目所遵循的任何文档最佳实践的信息，以及如何构建文档、运行检查和如何将所做的修改提交给项目。
## 贡献源代码
本节应包含以下信息
* 如何访问项目的源代码。
* 一般的项目布局。
* 对开发环境的任何要求。
* 代码格式和风格指南。
* 如何运行测试套件。
## 如何成为Trusted Committers
如果成为Trusted Committers的途径对贡献者是开放的，那么这一节应该明确解释成为Trusted Committers的过程。
## 如何提名Trusted Committers
这一节是对现有Trusted Committers的提醒，也是向新的Trusted Committers提供详细解释，如何增补其他人到项目拥有者团队中。理想情况下，本信息也应该适用在组织中的所有项目，因此本信息可以作为统一的定义已链接的形式引用。
# RFC 模板
* 功能名称。(请填写一个独特的身份，`my_awesome_feature`)
* 开始日期: (填写今天的日期，YYY-MM-DD)
* 被提名的负责人：（受RFC影响的技术领域专家代表。这通常是技术负责人，但他们可以委托。在所有被提名的所有者签字之前，RFC不能被接受。）
## 概述
一段对该功能的解释。
## 回顾
这一部分对于让我们从正在实施的事情中学习是至关重要的。
*什么时候进行回顾？*
\[] 复盘完成？
(将在哪里/如何举行，人们如何参与，结果在哪里？)
## 动机
我们为什么要这样做？它支持什么用例？预期的结果是什么？
## 指南级的介绍
就像在向另一个工程师介绍一个已经存在的提案一样介绍该提案。这通常意味着：
* 引入新的命名概念。
* 用示例来解释主要特点。
* 解释工程师是如何思考这个功能的。应该尽可能具体地解释其带来的影响。
* 如果适用的话（例如代码/架构建议），提供错误信息样本、弃用警告信息或迁移指导文档。
* 如果适用的话，描述向现有的工程师和新的工程师传授这些知识的区别。
对于面向实现的RFC来说，这一部分应该关注贡献者应该如何思考这个变化，并举例说明其具体影响。对于政策/流程型RFC，本节应提供一个以实例为导向的政策/流程介绍，并具体解释其影响。
## 参考实现级别的介绍
这是RFC的技术部分。对设计进行足够详细的介绍，以便
* 它与其他功能的交互是清晰的。
* 合理地清楚介绍该功能将如何实现。
* 通过实例剖析如何处理极端情况。
该部分应该回到上一节给出的例子，并更充分地详细地解释如何实现这些例子的。
## 缺点
为什么我们不应该这样做？
## 理由和替代方案
* 为什么这个设计是可能的设计空间中最好的？
* 还有哪些设计被考虑过，不选择这些设计的理由是什么？
* 不这样做的影响是什么？
## 现有技术
讨论与本提案有关的现有技术，包括好的和坏的。 这可以包括几个例子。
* 对于语言、库、工具等。这个功能在其他地方是否存在，他们的社区有什么经验？
* 对于社区建议。这个功能是否由在其他社区已经实现了，他们在这方面有什么经验？
* 对于其他团队。我们可以从其他社区所做的事情中吸取什么教训？
* 论文。是否有任何已发表的论文或有相关的帖子来讨论这个问题？如果你有一些相关的论文可以参考，这可以作为一个更详细的理论背景。
这一部分的目的是鼓励你作为作者思考其他地方的经验教训，为你的RFC的读者提供更全面的信息。 如果没有现有技术，那也没关系--你的想法无论是否是全新的，还是从其他地方改编而来，我们都很感兴趣。
## 未解决的问题
* 在提案被接受之前，你希望通过RFC过程来解决哪些部分的设计问题？
* 在提案酝酿成熟之前，你希望通过实现这个功能来解决哪些部分的设计问题？
* 你认为哪些相关问题超出了本RFC的范围，可以在未来独立于本RFC的解决方案而得到解决？
## 未来的可能性
思考你的提案的自然延伸和演变是什么，以及它将如何全面地影响团队和项目。 试着把这一节作为一个工具，更全面地考虑你的提案中与项目和团队的所有可能的相互作用。 还要考虑这一切如何与项目和相关子团队的路线图相适应。 这也是一个 "倾倒想法 "的好地方，如果它们超出了你正在写的RFC的范围，但又与之相关。 如果这些想法超出了你正在写的RFC的范围，但又与之相关，那么这里也是 "抛弃想法 "的好地方。 如果你已经试过了，却想不出任何未来的可能性。你可以简单地说，你想不出任何东西。 请注意，在未来可能性部分写下一些东西并不是接受当前或未来RFC的理由；这样的说明应该放在动机或理由部分。 在这个或以后的RFC中的动机或理由部分。该部分只是提供额外的信息。
---
[Next Page](/llms-full.txt/1)