InnerSource checklist

Table of contents

• 1. Readiness
  • 1.1. Personal
  • 1.2. Product
    • 1.2.1. Appropriateness
    • 1.2.2. Code maturity
    • 1.2.3. Existing process
  • 1.3. Team
  • 1.4. Company
    • 1.4.1. CxO-level executives
    • 1.4.2. Human resources
    • 1.4.3. Organizational setup: central coordinating team
  • 1.5. Developers
    • 1.5.1. Joining the discussion
    • 1.5.2. Do developers know how to use the tools?
• 2. Repository
  • 2.1. Are ancillary resources set up, such as the following?
  • 2.2. Are the following files in place?
    • 2.2.1. README.md
    • 2.2.2. CONTRIBUTING.md
      • 2.2.2.1. Required
      • 2.2.2.2. Optional
    • 2.2.3. HELPWANTED.md
    • 2.2.4. GETTINGSTARTED.md
• 3. Tools
• 4. Logistics
• 5. Product owners

1. Readiness

1.1. Personal

• Do you believe this is a viable strategy for your company, or are you just doing it out of ideological commitment and idealism?
• Do you understand the changes required to be successful at InnerSource?
• Are you skillful at presenting ideas to others, listening to their concerns, and finding common ground without bias?

1.2. Product

• Does this product matter to the company?
• Is it likely to survive strategy changes?

1.2.1. Appropriateness

• Is this product likely to be interesting to developers outside the original development team?
• Is it currently or could it be used widely by other teams in the company who depend on it?
• Will it benefit from being extended by outsiders in ways that the original team could not anticipate?
• Could the product benefit from having other teams contribute bug fixes and refactoring work?
• Could outside developers contribute useful code or suggestions?
• Would outside developers respond to appeals to contribute?

1.2.2. Code maturity

• Is the product modular enough to make changes easy and safe to make?
• Is the code well documented?

1.2.3. Existing process

• Can releases be made frequently?
• Is continuous testing and integration in place?
• Is all of the code stored in a version control repository such as GitHub that makes branches, pull requests, and integration easy?

1.3. Team

Are team members ready for the challenges of InnerSource?

• Accepting code and changes to their code from outsiders
• Being responsible for less-than-perfect code contributed by outsiders
• Having outsiders see their less-than-perfect code
• Having to conduct conversations that are sometimes difficult with outsiders about accepting and rejecting their contributions
• 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.)

• Creating and maintaining documentation for guest contributors
• Willingness to participate in forums and answer questions patiently
• 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)
• Willingness to do code reviews of outside submissions
• Maintaining the bug tracker
• Taking a turn in the role of TC

Have you chosen TCs who understand and have agreed to their responsibilities?

• Write and maintain the CONTRIBUTING.md file in GitHub
• Review incoming code (pull requests)
• Mentor guest contributors
• Merge pull requests
• Take the lead on refactoring and modularization
• Participate and answer questions on discussion lists
• Send announcements
• Watch for and suggest opportunities for collaboration

Do they understand the potential rewards (intrinsic and job-related) of this position?

• Develop deeper understanding of the codebase
• Improve the quality of your team’s code
• Improve the quality of code within the organization as a whole with better integrations
• Learn and grow as a developer by seeing many incoming code examples
• Understand how to better refactor and modularize code to encourage external contributions
• Develop interpersonal and leadership skills through mentoring and negotiation with guest contributors
• Have they been given leeway to do things not previously in their job descriptions?
• Is time set aside in team members’ work schedules for these new responsibilities?
• Are team members trained to handle these responsibilities?
• Is there a mechanism for making announcements that anyone in the organization can follow and search? (Examples: Slack, email)
• 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)

1.4. Company

1.4.1. CxO-level executives

• Do the executives understand the purpose and value of running a product as InnerSource?
• The value of spreading tribal knowledge across the organization - [ ] The value of having teams remove their own external blockers and bottlenecks
• The value of a more interconnected organization
• The value of having advanced team members that have a deeper understanding of many arms of the codebase
• How InnerSource encourages basic good practice and helps develop and spread even better coding and development practices —How 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?

1.4.2. Human resources

• 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

1.4.3. Organizational setup: central coordinating team

• 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?

1.5. Developers

• 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?

1.5.1. Joining the discussion

• Reading the contribution requirements
• Exploring and/or contributing to the Help Wanted file
• Signing up for announcements

1.5.2. Do developers know how to use the tools?

• 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?

2. Repository

2.1. Are ancillary resources set up, such as the following?

• Documentation
• Discussion forum
• Bug tracker
• Wiki

2.2. Are the following files in place?

2.2.1. README.md

• 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)

2.2.2. CONTRIBUTING.md

2.2.2.1. Required

• Table of contents
• Names and contact information for TCs
• TC availability schedule

2.2.2.2. Optional

• 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

2.2.3. HELPWANTED.md

• Can be initially empty
• Can link to a forum where requests and offers are posted
• Can contain a list of requests and offers

2.2.4. GETTINGSTARTED.md

• 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?

3. Tools

• Version control
• Continuous integration
• Testing

4. Logistics

• 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

5. Product owners