Why organizations should commit to innersource in 2020

Even if you’ve never heard the term “innersource” to describe how teams build their software, you’ll probably still recognize some of the principles behind it. They’re powering code at the world’s most influential companies, and they might even be important practices on your team.

Innersource isn’t a novel concept. Instead, it describes how the processes and principles developers have used for decades to build large-scale open source software (think Git, Linux, or Python) can apply to closed source projects at companies of all sizes.

As enterprises increase their investments in open source, they’re also looking behind the code at new ways for their engineering teams to work together quickly, globally, and at scale. At Ford Motor Company, code is increasingly open by default to bring more ideas to the table, says Software Processes and Tools Supervisor Timothy Carmean. “Make your repository public. Then let people use it, open pull requests, and have conversations about it.”

Here are five more reasons why every enterprise should make innersource a priority in 2020:

1. Collaborate with context across teams and time zones

The way people work is changing. And the shift toward globally distributed teams and remote work is more than a trend—it’s an inevitability. Making the most of a worldwide workforce means that no matter where work happens, from HQ or the living room couch, it happens in a collaborative, transparent, and open way.

Zendesk’s global offices are a great example. The company values transparency, especially on the engineering side, so that an engineer in Copenhagen can understand and leverage work happening in San Francisco. Jason Smale, Zendesk’s VP of Engineering, describes the team’s internal setup as similar to one you’d find in an open source project, with maintainers and contributors collaborating on the company’s ecosystem.

Clear and documented ownership of projects allows each team to manage the chaos of different workstreams without shutting them off from great ideas. They leverage the company’s collective brain power by allowing anyone on any team to contribute to, build on, or reuse existing work. As Smale explains, “Our engineering culture is open and centered around teams owning services and being responsible for running them in production.”

2. Get new ideas to customers faster

Opening up a project invites more ideas. But it can also help teams step up their code quality, remove friction from their processes, and get work to production, faster. Tom Erickson, Supervisor of Global Software Tools and Processes at Ford, sees the value in not only encouraging more ideas about code but also about process and work styles. “Developers can make suggestions and adopt a style of working that’s more open and fits their needs,” he says. “If you want to ship higher quality software faster, innersourcing just makes sense.”

To avoid slowing projects down as teams grow, thoughtful processes and documentation take on an important role. Teams at Stripe frequently work on each other’s code, but no matter where it comes from, it always goes through the same review process. Documentation on contributing to and reviewing code takes the burden of figuring out “what’s next“ off individual contributors, making it easier to get involved on a project’s terms. Stripe Developer Advocate Michael Glukhovsky finds the ability to contribute without friction empowering: “If you see something that needs to get fixed, you can submit a pull request, and start a conversation.”

3. Discover and reuse code across your company

Tell me if this sounds familiar: Your team plans, designs, and implements a new UI pattern for your product. It’s usable, effective, and iterated to perfection over a few months. But then you stumble upon a pull request with a similar feature, developed independently by another team. Not only could your code have spared its creators some work, but now there’s an inconsistency in your product’s user experience. Adapting and reusing field-tested features seems obvious. Making your code discoverable for other teams isn’t.

For ENGIE Digital’s Innersource Project Lead Florent Zara, “[The goal of innersource] is to break down silos and encourage people to work together.” He explains that innersource gets projects out in the open, making it easier to discover and reuse and build on code across the organization.

The practice holds up even in larger companies like Ford, where Chief Engineer Florian Frischmuth feels that keeping code in one place, like on GitHub, makes it easier to discover. “Our environment allows developers to find solutions that have already been developed. They can collaborate on those, and then reuse them.”

4. Step up code quality and security 

There’s a logical tension between “open” and “secure”. As people release software with a growing number of open source dependencies, it’s more important than ever that software teams make security a priority from the start and focus on releasing secure and high-quality code. In practice, enterprise teams have found that more collaborators create more opportunities to catch bugs and other issues. They also find that it invites security expertise into the process sooner.

At Nationwide, teams once kept projects close to the chest, but opening them up, at least internally, proved integral to higher quality code at scale. Cindy Payne, Associate Vice President of IT Application Services at Nationwide Insurance explained that the projects teams were most hesitant to share often benefited the most from outside perspectives. The practice also helped address security vulnerabilities, allowing the team to quickly assess impact, then triage the situation accordingly.

5. Save time and encourage innovation with self-service 

When it comes to starting new projects, many teams still follow a request-and-wait model. They put in a request, and a central administrator spins up a new repository. This model adds two layers of complexity to what could be a simpler process: administrative maintenance and barriers to trying something new. Innersource, on the other hand, grants everyone the autonomy to get started without friction.

Allowing teams to create their own projects may sound like more work. The upfront effort of documenting a new process and even creating governance models can seem daunting, but many teams have found that a self-service model ultimately saves time on maintenance and empowers them to just get started.

Payne tells us that self-service GitHub repositories not only remove blockers. They’ve also saved the company time and costs from an infrastructure perspective. She says of switching models, “We knew we were going to save money, but that savings immediately turned into more capacity for teams to do the most valuable work for our business.”

The team at automotive supplier Continental has also found that removing barriers has encouraged creativity, explains Innersource Project Manager Zsuzsanna Gnandt. “With innersource, we want to enable all developers with the freedom to be creative, to drive innovation without barriers, and to be appreciated for their contributions across the company.”

It’s undeniable that open source has changed the way we all build software. The best practices that have made many large-scale open source projects so successful are quickly becoming the new norms for enterprise software development. In 2020, innersource is no longer a methodology. It’s how people build proprietary software across industries, teams, and time zones.

This post originally appeared on LinkedIn on September 26, 2019.

Written by

Erica Anderson

@eanderson