Companies often kick off their InnerSource programs by starting small. Pilot projects can help teams experiment with more open processes, democratize access to code, and document best practices before applying InnerSource more widely.
Small successes can help show your internal community of developers how to make the most of their code and ship better software, faster.
Consider measuring:
- % of issues created from external contributors
- Responsiveness (e.g. how quickly does someone respond to an issue opened by an external contributor)
- % of PRs that come from external contributors
- % of PRs from external teams that are merged
- % of reviews that come from external contributors
- % of code reuse across projects
- % of repositories using InnerSource components (managed contributing guidelines, assigned TCs, )
What is your timeline?
What is your timeline? What is your next step?
Initial InnerSource rollout checklist
Here is a list of some recommended checklist items to review when adopting InnerSource that apply to most organizations:
- Define program goals, timeline and Exec sponsor team
- Identify pilot group(s) to validate and drive internal success
- Establish and schedule initial workshops to align purpose with practice among internal pilot group(s)
- Create internal portal for InnerSource
- Establish Search/Tagging conventions
- Establish template documentation and repository set up guidelines.
- Contributing guidelines, passive documentation, etc.
- Provide example workflows that teams can use to blueprint their desired workflow
- Provide a template repository with example README(s), issue and pull request templates, CONTRIBUTING files, license guidance, CODEOWNER templates, gitignore files, etc.
- Create an innersource team within the GitHub organization to provide guidance when at-mentioned
Expanding your checklist
Many companies have already adopted InnerSource or are currently in the process. There is a lot of great information from many resources including InnerSource Commons and PayPal’s journey just to name a few. Below is an expanded checklist compiled from many resources including PayPal, GNU Manifesto, and the Apache Way.
Team
- Are team members ready for the challenges of InnerSource?
- Accepting code changes to their code from outside teams
- Being responsible for less-than-perfect code contributed by outsiders
- Having outsiders see their less-than-perfect code
- Discussions around conducting difficult conversations with non team members about accepting and rejecting their contributions
- Establishing channels for mentoring and/or learning to mentor contributors
- Do team members understand the requirements of running an InnerSource project?
- Create and maintain documentation for contributors
- Willingness to participate in forums and answer questions patiently
- Willingness to perform code reviews for non team members
- Establish Trusted Committers (TCs)
- Does each TC understand their responsibility?
- Write and maintain CONTRIBUTING.md files in GitHub
- Approve pull requests
- Mentor contributors
- Merge pull requests (if applicable)
- Take lead on refactoring and modularization
- Watch for and suggest opportunities for collaboration
- Time set aside in 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)
- Do TCs understand the potential rewards (intrinsic and job-related) of this position?
- Develop deeper understanding of the codebase
- Improve quality of the team’s code
- Improve quality of code within the organization as a whole
- Develop interpersonal and leadership skills through mentoring
- Organizational benefits and rewards from this position
Company
- CxO-level executives
- Do the executives understand the purpose and value of InnerSource?
- The value of spreading tribal knowledge across teams
- The value of having teams remove their own external blockers and bottlenecks
- The value of a more interconnected organization
- The value of having advanced teams that have a deeper understanding of many arms of the codebase
- How InnerSource encourages basic good practice and helps develop and spread 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?
- Does the executive team support this initiative?
- Are company goals and OKRs (Objectives and key results) clearly stated and shared?
- Are the company’s vision and mission relevant, up-to-date, clear, respected, and followed?
- Human resources
- Are there rewards and criteria for promotions based on InnerSource values and contributions?
- Rewards for contributions to other teams
- Rewards for developers who review code contributed from developers on other teams
- Organizational setup
- How do projects register as InnerSource?
- Do team members have time to contribute to outside projects?
- Do team members have resources to measure and demonstrate gains and losses of teams?
- Can team members choose what projects to work on based on their expertise and motivations?
Developers
- Do developers around the company understand that they can contribute to the InnerSource project?
- Do they understand the value of contributing to other projects?
- 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 projects?
- Joining the discussion
- Reading the contribution requirements
- Exploring and/or contributing to the Help Wanted file
- Do they know how to use the tools?
- Version control
- Programming language
- GitHub features
- Test development
- Do they know how to support their team’s role in InnerSource?
- Can they participate productively on forums, comments, and issue discussions?
- Can they describe the reasons for InnerSource adoption?
- Can they respond constructively to feedback?
- Can they participate in dialogs around reviews of their code?
- Are they permitted to contribute to projects outside their own department?
- Do they understand how to get support from their product owners and managers?