Intuit tech evangelist Aliza Carpio and staff engineer Rocio Montes know that, in many engineering organizations, open source-style collaboration is already standard practice.
At their 30-year-old, globally distributed company, it’s been a different story.
“People go, ‘Wait a minute, isn’t this how everyone works?’ and I’m like, ‘Actually, they don’t,’ Carpio said. “When you’re at a company like Intuit that has grown by acquiring many, many different companies, we’re bringing in all different types of tech stacks and all different types of mindsets.”
Often, it was easier to just duplicate projects than hunt down solutions in another team’s repository.
In early 2018, Intuit’s global teams were using different structures for their repositories, different best practices for documentation and different workflows for code reviews. Often, it was easier to just duplicate projects than hunt down solutions in another team’s repository.
Carpio and Montes, along with Intuit’s chief architect and a few other people, joined a task force that traveled the world on what the company called a “Beautiful Code Tour.” They met with engineering leaders and teams from Bangalore to Mountain View, encouraging them to make Intuit’s code “composable, discoverable and contributable,” and training them on “innersource,” or the use of open-source development practices for internal projects.
Now, Intuit is well on its way to company-wide adoption of innersource. Engineers across products and teams can contribute to codebases outside their own, making it easier to add features, manage dependencies and build new skills. While less than half the company’s repositories are currently open for contribution, the goal is to open them all.
For large companies, overhauling legacy engineering practices can be an uphill climb. Here are some strategies to borrow from Intuit’s push for innersource.
How to make a successful switch to innersource
- Clearly lay out the benefits. Innersource practices cut lag time on new features and help developers expand their knowledge by interacting with different tech stacks.
- Make it easy to contribute code across teams. Without accessible repositories, clear-cut code review processes and high code coverage, engineers will likely be slow to adopt.
- To earn buy-in, leverage team-level influencers. Whether they’re experienced mainstays or fresh-from-college contributors, you’ll need advocates on the ground.
- Be ready for objections. When engineers feel ownership over their codebases, it’s hard to accept suggestions from newcomers.
- Celebrate incremental success. You can transition to innersource without overextending your engineers or company leaders.
Clearly Lay Out the Benefits
Even if innersource makes engineers more efficient in the end, the changeover will slow them down. Lead with the benefits for rank-and-file developers, so team members know exactly why processes are evolving.
“Many times when we speak to business leaders about innersource, they think about the external customer and benefits like ‘delivering with speed,’” Carpio said. “Obviously, the business reaps those benefits, but a lot of times I think we forget that it’s really beneficial for the individual engineers and development managers.”
Carpio and Montes mentioned four main benefits for developers and team leaders. The first is that dependencies get a lot less annoying. Take TurboTax, a product composed of many small codebases owned by different teams. When one team needs to deliver a feature that cuts across multiple codebases, it no longer has to wait for help and approval from all other teams involved — it can just create pull requests and make those changes itself.
“Because innersource has defined contribution guidelines, quality guidelines and release guidelines, it’s going to be easy to go make the code changes in all those repos,” Montes said.
The second benefit is streamlined processes. When engineers on different teams can collaborate directly in their repositories, they can cut a lot of meetings from their calendars. When the code review workflow is automated in GitHub, people spend less time waiting for their pull requests to get reviewed. When repositories are well documented, developers spend less time hunting for information.
“Developers aren’t happy to create clones that do almost exactly what another solution is already doing, but many times it’s faster than waiting for someone else to act on a pull request.”
The third benefit is less duplicated work. Before the innersource initiative, duplicate projects were a big problem for Intuit’s engineering teams.
“We called it the Clone Wars,” Carpio said. “Developers aren’t happy to create clones that do almost exactly what another solution is already doing, but many times it’s faster than waiting for someone else to act on a pull request.”
Here’s when duplicates usually happen, Montes said: Engineers are tasked with creating a new capability, they know a similar capability exists in another codebase, but the guidelines for extending or modifying that capability aren’t clear. With innersource, teams create internal service-level agreements for the codebases they own, so requirements for contributing are clear and pull requests don’t languish in no man’s land.
The last benefit, Carpio said, is more opportunities for skill-building. When engineers can contribute to unfamiliar projects, they get chances to work with brand new tech stacks — instead of the ones they see every day — and make broader impacts at their companies.
Make It Easy to Contribute Code Across Teams
Setting unified, organization-wide contribution, quality and release guidelines is the first step for any innersource initiative. But guidelines alone won’t turn developers into enthusiastic innersource contributors. Some will have an immediate need to make changes in other teams’ repositories, but others will be unsure where to begin.
For that second group, try a master list of projects actively looking for contributors. Intuit’s “first-time contributors” site features repositories across the company with issues labeled “good first issue” or “help wanted.”
“That tells engineers that these issues are up for grabs, and if they want to diversify their knowledge and the languages in which they code every day, here are some opportunities,” Montes said.
As mentioned, Intuit teams created service-level agreements ahead of time to dictate how they’d deal with pull requests from external engineers. In other words, how long after an external pull request should the codebase owners make an acknowledgment of activity and respond with a code review or commit?
Once that’s decided, teams should lock in their code review workflows. Intuit works in two-week sprints, so team members cycle through code review responsibilities. But that doesn’t mean one person has to review every external pull request during that period — if the code reviewer receives a request related to a chunk of code they’re not familiar with, GitHub can use the team’s “code owners” file to automatically funnel that request to the engineer who’s most knowledgeable. Over time, some external contributors earn “trusted committer” status, so they can merge pull requests on their own and save time for project owners.
Last, keep in mind that not all codebases are equally user-friendly.
“If there were no unit tests in a code repository or the code coverage was low, engineers felt scared to contribute.”
“If there were no unit tests in a code repository or the code coverage was low, engineers felt scared to contribute,” Montes said. “I even heard some engineers saying, ‘Can you sit down with me and pair program, because I’m scared of these codebases.”
To address that, Intuit is developing a dashboard that will show the so-called maturity of each repository. Repositories that are innersource-friendly will be marked as such. That way, when engineering managers are planning their capacities for the next quarter or quarters, they can see which repositories are ready for external contributions and better estimate their project timelines.
To Earn Buy-In, Leverage Team-Level Influencers
Carpio and Montes’ team has seven people on it. They’re tasked with promoting innersource at 16 software development sites worldwide, which together employ about 4,000 technologists. They knew they couldn’t scale new engineering practices without plenty of team-level advocates.
Some of Intuit’s “innersource influencers” are senior employees who have amassed some influence on their teams. Others, Carpio said, are right out of college. But experience matters less than gameness. Often, young engineers are better versed in open source and the benefits of its collaborative model, which makes them excellent innersource champions.
“The younger engineers who come from college are always surprised that we don’t work this way already.”
“The younger engineers who come from college are always surprised that we don’t work this way already.” Carpio said. “We have a lot of people who are like, ‘Let’s make this happen,’ but for the early career engineers, it’s a no-brainer.”
No matter who steps up, it’s the advocate’s job to model innersource practices and help their team navigate any bumps in the road. Technical leaders also have a role to play. By demonstrating respect for external contributions, they help team members adjust to new suggestions and extra layers of feedback.
Be Ready for Objections
“Some of our dev managers were concerned that adopting innersource processes would make them go slower,” Carpio said. “They were concerned about the partnerships they have with product managers or marketing managers. But in reality, it’s sped them up.”
With new requirements come objections. Leaders should anticipate developers’ pain points — and be ready to stand by good ideas and toss out bad ones.
During Intuit’s transition, evangelists knew the biggest sticking point would be entrenched ideas about code ownership.
“That’s a mindset that has to change. This is not your code. This is Intuit’s code, and we all need to contribute to it.”
“There was a lot of: ‘This is my code. Why would you ever try to give notes on it?’” Montes said. “But that’s a mindset that has to change. This is not your code. This is Intuit’s code, and we all need to contribute to it.”
That paradigm shift meant managers and individual contributors alike needed revamped training on code reviews. When project owners see new contributions pouring in, sometimes, the knee-jerk reaction is to list everything that looks wrong or out of place. Instead, Montes said, code reviewers should focus on the top three things they’d like to clarify or adjust, and they should do so from a place of empathy. Why did the external contributor write their code the way they did? Did they draw on best practices from their external team? How does this contribution align with their distinct goals?
Some new frameworks will catch on — others won’t. It’s important that companies are willing to both talk and listen during big transitions, Carpio said.
“What we discovered is that what works for the engineers at the headquarters in Mountain View does not work for the engineers that are in smaller offices like Paris and London,” she added.
It’s OK to Progress Step by Step
Sometimes, success is incremental. When breaking out of longstanding processes, don’t bite off more than you can chew.
Sometimes, this happens at the individual level. Particularly eager engineers may see innersource as an opportunity to weigh in on every codebase they can get their hands on. Unsurprisingly, this won’t build goodwill for the innersource program. With the right reward structures, however, companies can avoid incentivizing that kind of behavior, Carpio said.
“Heroes will never get you where you need to be in terms of this change management process.”
“We wanted to establish a system of rewards and recognition that’s about recognizing good behavior, versus heroic behavior,” she said. “Heroes will never get you where you need to be in terms of this change management process.”
Overreaching can come at the company level as well. A hurried switch from siloed codebases to innersource collaboration could create chaos. Instead, identify which codebases are accessible or essential enough to merit innersource collaboration, and build from there.
“Ask yourself: ‘Which things should I open? Which things should we ensure that we document and make composable and extendable?’” Carpio said. “Use your data to figure out which of your engineering capabilities you should focus on, which ones are going to make the biggest impact if you open them up for innersource.”
