I was a member of the Software track committee for GHC, which meant that by attending the conference in person, I was also responsible for chairing a session. Session chairs arrive in the room prior to the start of the presentation and ensure that the presenters have arrived, there are no technical difficulties with A/V equipment, the timer is set up and ready to go, and the session starts and ends on time. The session that I chaired was titled “Better Together: The Inner Source Journey.” Presenters Aliza Carpio and Rocio Montes shared the findings of Intuit’s case study detailing its lessons from embarking on an inner source journey.
By now, you’re probably asking yourself, “What is inner source?” In brief, it is leveraging open source software development practices within your organization. Having been on teams that develop with and without these software practices, I can personally attest to the value of institutionalizing them. Not everyone will want to adopt new ways of working, some will have to be dragged kicking and screaming. Every journey starts with a champion(s), Aliza and Rocio are those brave individuals in this story.
If you work for a company with a large number of developers aligned with different business units, who have competing priorities, and are dispersed geographically, you are painfully familiar with the silos this can create. The challenges Aliza outlined for Intuit were:
- Code was owned (not stewarded) by teams and individuals, which led to bottlenecks and long wait times for code changes
- The waiting impacted work/life balance and created a culture of heroics to meet deadlines
- Repositories lacked documentation, or the documentation was only good enough to be used by the people who already owned the code
- Varying standards made it difficult to on board new members
So how do you ensure people can work together across the globe and still produce quality software? Rocio discussed three simple criteria to start. Make sure that repositories are:
- Discover-able – Can people find it?
- Contribute-able – Once they have found it, can they incorporate their changes?
- Compose-able – Are there processes in place to ensure that new changes are non breaking?
This means that people, process, and technology changes must be instituted.
Process:
- Make sure there is ONE set of unified guidelines, including
- A standard structure for repositories
- A minimum set of documents to detail contribution guidelines
- Rules of engagement — how do you engage the stewards of the repository?
- Templates for issues and pull requests that auto-populate with the expected information
- Use containers for local development — it minimizes the time to onboard new developers by fully encapsulating the working environment (packages, software versions, etc.)
- Continuous Integration/ Continuous Deployment (CICD) must be a part of the process
- Pull Request (PR) Builds give contributors and reviewers the opportunity to review tests and coverage to determine quality
People:
- See every PR as a mentorship opportunity!
- If it does not already exist, a “trusted committer” role, held by the group of developers who have the knowledge to do code reviews, and will be responsible for code mergers and reviewers , should be created
- Hold code review training to ensure that consistency and quality is maintained for each PR
- Make the trusted committer role a rotating on call so the burden is dispersed and not only one person is responsible — those who are frequent committers will eventually become trusted committers.
- Have service level agreements (SLAs) for PR reviews, merge and release; declare and define the timelines so external contributors know what to expect and can plan accordingly
- Scale efforts by identifying passionate advocates and leaders at each site (by location) to ensure there is someone physically present to champion the transition, and to assist with the technical implementation
- Identify repositories and teams that provide foundational capabilities to the organization, those that are a dependency for many other teams, and bring them to inner source first.
- Establish rewards and recognition — work with leaders to make the transition a part of each engineer’s goals
Technology:
While this was not explicitly mentioned during the session, I want to take the liberty of calling out the technology behind the inner source transition. These are observations based on the internal tools and processes in place at my company to support developers so that tooling does not become an encumbrance.
- Secure the necessary support and funding to internally or externally host the tools to enable the inner source journey
- Work with IT to identify the CICD pipeline, revision control, and ticketing systems you intend to use; make certain they are interoperable, and integrate them as an enterprise offering.
- If Agile is part of your Software Development Lifecycle, add additional integrated tools to support the work methodology
- Allow adoption of the tools to be independent — some teams may be more mature, so they can adopt the entire suite of tools, whereas others may need to start with just revision control.
- Maintain training collateral for the suite of tools, but have a means of requesting assistance with on boarding
- Regular office hours where people can dial in for live assistance
- A means of submitting tickets or requesting help
Tools that I have used in this space are:
- CI:
- CD (some also do CI as well)
- Communication/Collaboration
- Workflow
*Tool used by Intuit
Back to the session.
What steps do you have to take to start this journey at your company?
- Get support from leaders (Vice President, Director, Architect, etc.) and identify partnerships
- If possible make these connections in person
- Research and beautify the standards; the unified standards; guidelines, documentation, rules should be hosted in a repository as well so that they can be treated as code
- Identify teams who will be models for the transition to inner source and work with them to bring other teams along
- Conduct workshops to teach teams how to live in the culture
Preparing to be a champion
Moving to inner source is not just a technology adoption, it is a change management journey. To champion the transition, you will need to be able to articulate the return on investment and the business value. Aliza mentioned multiple resources to help prepare for making the case:
- Measuring and Analyzing Behavior in Organizations: Advances in Measurement and Data Analysis
- Measure What Matters – understanding your metrics and the results to measure
- Switch: How to change things when change is hard
- Herd: How to change mass behavior by harnessing our true nature
- whatmatters.com
- innersourcecommons.org
- codewithher
You must be a storyteller. Take the time to craft your message so you can be effective at being a catalyst for change!
Helping drive success
When people are new to inner source, it can be overwhelming. Intuit created a “good first issues” site that highlights filed issues from various repositories that are great introductory problems to solve for a newbie. Projects have their issues highlighted on the site by labeling their issues with the appropriate tags, and have well documented contribution guidelines. This also gives engineers an opportunity to gain new skills by working on new projects.
Creating a visible badge for taking the training, becoming a contributor, and championing inner source helps foster pride in the transition.
The final result.
Intuit is one year into their journey and are already seeing the benefits. It is not enough to have anecdotal stories, you want to measure the value added by the transition to inner source, through measurement, analysis and presentation of the results.
Now you’re ready to embark on your journey! Safe travels.
