InnerSource checklist
- 1. Readiness
- 2. Repository
- 3. Tools
- 4. Logistics
- 5. Product owners
Ensure each participant is aware of their motivations, biases, and the skills required to support an InnerSource product.
- Motivations: Do you believe this is a viable strategy for your company, or are you just doing it out of ideological commitment and idealism?
- Comprehension: Do you understand the changes required to be successful at InnerSource?
- Empathy: Are you skillful at presenting ideas to others, listening to their concerns, and finding common ground without bias?
How to select (or reject) a product for InnerSource sponsorship.
- Value: Does this product matter to the company?
- Longevity: Is it likely to survive strategy changes?
Is the product appropriate for InnerSource?
- Appeal: Is this product likely to be interesting to developers outside the original development team?
- Usefulness: Is it currently or could it be used widely by other teams in the company who depend on it?
- Extendibility: Will it benefit from being extended by outsiders in ways that the original team could not anticipate?
- Stability: Could the product benefit from having other teams contribute bug fixes and refactoring work?
- Beneficence: Could outside developers contribute useful code or suggestions?
- Audience: Would outside developers respond to appeals to contribute?
Be sure your product's architecture and design is easy to understand and change.
- Modularity: Is the product modular enough to make changes easy and safe to make?
- Documentation: Is the code well documented?
InnerSource can only be sustained with solid DevSecOps.
- Deliverable: Can releases be made frequently?
- Continuous Integration: Is continuous testing and integration in place?
- Version Control: Is all of the code stored in a version control repository such as GitHub that makes branches, pull requests, and integration easy?
InnerSource teams must be open to outside criticism and able to provide constructive, polite criticism themselves.
Are team members ready for the challenges of InnerSource?
- Reception: Accepting code and changes to their code from outsiders
- Responsibility: Being responsible for less-than-perfect code contributed by outsiders
- Humility: Having outsiders see their less-than-perfect code
- Congeniality: Having to conduct conversations that are sometimes difficult with outsiders about accepting and rejecting their contributions
- Mentorship: Mentoring and/or learning to mentor contributors
Do team members understand the requirements of running an InnerSource product? (It helps if members have participated on open source products.)
- Documentation-as-a-Service: Creating and maintaining documentation for guest contributors
- Accessibility: Willingness to participate in forums and answer questions patiently
- Publicity: Using forums, which provide a historical record everyone can see, instead of hallway conversations (optionally, using a scribe to make notes during live meetings, just as long as all of the decisions and explanations for those decisions are documented)
- Engagement: Willingness to do code reviews of outside submissions
- Diligence: Maintaining the bug tracker
- Availability: Taking a turn in the role of TC
Have you chosen TCs who understand and have agreed to their responsibilities?
- Instructions: Write and maintain the
CONTRIBUTING.mdfile in GitHub - Pull Requests: Review incoming code (pull requests)
- Mentorship: Mentor guest contributors
- Merges: Merge pull requests
- Refactoring: Take the lead on refactoring and modularization
- Participation: Participate and answer questions on discussion lists
- Communications: Send announcements
- Collaboration: Watch for and suggest opportunities for collaboration
Do they understand the potential rewards (intrinsic and job-related) of this position?
- Education: Develop deeper understanding of the codebase
- Quality Assurance: Improve the quality of your team’s code
- Integration: Improve the quality of code within the organization as a whole with better integrations
- Growth: Learn and grow as a developer by seeing many incoming code examples
- Refactoring and Modularity: Understand how to better refactor and modularize code to encourage external contributions
- Leadership and Empathy: Develop interpersonal and leadership skills through mentoring and negotiation with guest contributors
Have team members been given leeway to do things not previously in their job descriptions?
- Time: Is time set aside in team members’ work schedules for these new responsibilities?
- Training: Are team members trained to handle these responsibilities?
- Communications: Is there a mechanism for making announcements that anyone in the organization can follow and search? (Examples: Slack, email)
- Knowledge Share: Is there a recorded mechanism for discussion so that all Guest Contributor questions and internal team decisions are searchable by incoming Guest Contributors? (Examples: Slack, online forum)
InnerSource initiatives can wither and die without leadership's support.
Ensure that executives understand the purpose and value of InnerSource.
InnerSource encourages basic good practice and helps develop and spread better coding and development practices.
Our executives understand and promote the value of:
- Spreading tribal knowledge across the organization
- Having teams remove their own external blockers and bottlenecks
- A more interconnected organization
- Having advanced team members with a deeper understanding of many arms of the codebase
InnerSource increases the learning and development of individual developers.
- Are they willing to support flexible work requirements and time spent on cross-departmental contributions?
- Can they accept experimentation, failure, and repositioning?
- Are they willing to support a path for career advancement that does not require management?
- Does the executive team support the initiative?
- Are company goals and KPIs clearly stated and shared?
- Are the company’s vision and mission relevant, up-to-date, clear, respected, and followed?
Effective HR partnerships help formalize and measure InnerSource competencies throughout the Enterprise.
Are there rewards and criteria for promotions based on InnerSource values?
- Rewards for people who contribute to products in other departments
- Rewards for developers who handle contributions from other departments (TCs)
- Need path for advancement that respects community role and does not require moving into management
The Central Coordinating Team evaluates products
- Is the team set up?
- Is it ready to communicate with products interested in going InnerSource?
- Can it apply the criteria in this checklist to ensure that the product and team are ready?
- How do products register as InnerSource?
- Do staff members have time to contribute to outside products?
- Do staff members have resources to measure and demonstrate gains and losses of teams?
- Can staff members choose what products to work on based on their expertise and motivations?
- Is there a meritocratic philosophy that can appreciate good contributions from all corners?
- Do developers around the company understand that they can contribute to the InnerSource product?
- Do they understand the value of contributing to other products?
- Removing external blockers
- Building integrations with other tools themselves
- Seeing how other teams structure code and learn from examples
- Do they understand the process for making contributions to other products?
- Reading the contribution requirements
- Exploring and/or contributing to the Help Wanted file
- Signing up for announcements
- Version control
- Programming language
- Test development
- Do they know how to support their team’s role in InnerSource?
- Can they participate productively on forums?
- Answer contributor questions
- Describe the reasons for choices that have been made in a way that is clear
- Respond constructively to feedback
- Can they participate in dialogs around reviews of their code?
- Are they permitted to contribute to products outside their departments?
- Do they understand how to get support from their product owners and managers?
- Documentation
- Discussion forum(s)
- Defect tracker
- Wiki
- ChatOps
Good documentation invites people to interact with your product.
InnerSource product delivery teams depend on asynchronous, geographically dispersed contributions. GitHub’s 2017 Open Source Survey showed incomplete or confusing documentation is the biggest problem for open source users. Succinct "instruction manuals" are therefore essential for InnerSource consumption, collaboration, and discovery via search engines.
The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
Eghbal, et. al. (n.d.). How to Contribute to Open Source. Retrieved August 30, 2017.
- Product name
- Any earlier names and codenames for this product
- Product description
- Team lead and PM/PMO contact information
Keywords for search purposes
- So that people can find this particular product by name
- So that people can find this product by what it does
- How to sign up for the announcement list
- Location of discussion forum
- Location of other repositories (Examples: JIRA, Rally, Confluence)
Whereas READMEs help people use the project, contributing docs help people contribute to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to.
Eghbal, et. al. (n.d.). How to Contribute to Open Source. Retrieved August 30, 2017
- Table of contents
- Names and contact information for TCs
- TC availability schedule
- Community guidelines
- Code conventions
- Testing conventions
- Branching conventions
- Commit-message conventions
- Steps for creating good pull requests
- How to submit feature requests
- How to submit bug reports
- How to submit security issue reports
- How to write documentation
- Dependencies
- Build process schedule
- Sprint schedule
- Road map
- Helpful links, information, and documentation
- When the repositories will be closed to contributions
- Can be initially empty
- Can link to a forum where requests and offers are posted
- Can contain a list of requests and offers
- Whatever a contributor might need to get the app up and running to begin coding
- Can be filled in by an intern, or after some contributors get started, based on feedback about what would have been helpful to them to get started
- Who reviews the documents in the repository?
- Version control
- Continuous integration
- Testing
- Sprints
- Codeathons, especially for tools
- Education
- Testing
- Gamification
- Reporting
- Pull requests during recent period
- Number
- Size (in lines of code)
- Type
- Name of pull request submitter
- Baseline metrics
- Ongoing tracking
- Resources
- Costs
- Time
- Who sees measurements? Display to the community?
- Bug fixing
Graph art by icons8.
Wiki Home-
CODE_OF_CONDUCT
Facilitate healthy community behavior. -
CONTRIBUTING
Detailed participation guidelines. -
LICENSE
Select an open source license. -
README
Your repo's home page.
- InnerSource Commons
paypal/InnerSourcePatterns- Submit a PR that adds community-standard docs
- Release cheatsheet