Inner Source: Bringing the Benefits of Open Source Into the Enterprise

Most of us are familiar with Open Source Software (OSS) and the many benefits that sharing the effort of maintaining source code brings to our codebases, teams, and products. We all leverage dozens—and likely thousands to tens of thousands, in the case of transitive Node module dependencies—of Open Source projects for our daily work.

Thankfully, there are countless dedicated contributors out there who work hard to maintain the Open Source projects we’ve all come to rely on. Some are paid to work on OSS by their employers. Some are given the time to submit patches as they encounter issues during their normal sprint work. Most spend their own free time building, maintaining, and documenting tools for the rest of us.

Our familiarity with how OSS development works makes it inevitable that some of those processes and concepts will leak into our closed source work. Most companies adopt a branching strategy, testing strategy, and Pull Request (PR) workflow and call it a day; some go further and integrate Continuous Integration (CI) and Continuous Delivery (CD).

All of these are steps in the right direction, but we can push this idea much further (especially at the enterprise scale) by adopting an Inner Source development strategy.

What is Inner Source?

Inner Source is essentially the idea of bringing Open Source practices to the enterprise. It involves opening your code to collaboration from the entire organization and implementing policies and procedures that promote and facilitate developers sharing code—and knowledge—across the company.

Breaking down the silos that often form in large organizations is key to the Inner Source approach.

The “open” bit of Open Source is what most organizations, especially very large or heavily regulated companies, often forget (and sometimes refuse) to implement. Code is locked away behind access restrictions and repositories are hidden from view. Development teams end up competing with one another, rebuilding the same tools, and sometimes making each other’s jobs harder because the organization lacks open communication and the developers are refused open access to the codebase.

An Inner Source approach to your organization’s codebase enables your teams to collaborate more. It empowers your developers to create more reusable solutions. An Inner Source approach engages your organization in moving forward as a collective instead of as individual teams competing against one another for a chance at the next big digital transformation project.

The Challenges of Sharing Code in an Enterprise

The primary obstacles to sharing code in an Enterprise are:

discoverability,
developer autonomy,
and organizational buy-in.

Discoverability is the likelihood an artifact will be found in a particular system. These artifacts can take on many forms: repositories, modules, components, functions, constants, configuration, documentation, etc. Most organizations have multiple systems that house this information and each system comes with its own set of access restrictions or obtuse methods of retrieving artifacts.

Developer Autonomy is the ability of a developer to take ownership of part of a system. This ownership can range from the short-lived, such as submitting a PR to patch a bug in a shared artifact, to long-lived—owning the input validation rules and messaging for an organization, reviewing every PR for changes to it, and orchestrating the roll out of any validation updates, for example. Many companies divest power from individual contributors via layers of process and a constant focus on individual, or team, velocity instead of considering potential long-term costs and benefits to the enterprise as a whole.

Organizational Buy-In is the willingness of the entire organization (not just the developers) to accept a collaborative, shared-ownership model for the system. It has to come from leadership as well as the developers actually doing the work. Without buy-in from the front-line developers, no one will feel engaged enough to take the time to abstract, genericize, document, and share common solutions. Without buy-in from leadership, no one will feel empowered enough to act in the organization’s interests when there is pressure to just get something done.

Each of these challenges, when left unaddressed, can prevent the organization from successfully sharing code. It can prevent collaboration across team boundaries and promote operating as a loose collection of disconnected units, instead.

There are many ways to tackle these challenges, most of them specific to your organization, tools and processes, and codebase. Even so, there are a few broad ideas to consider, and questions you’ll definitely want to answer.

Standardized Tooling

How many different tools are you using for documentation? Do you have a Wiki system like Confluence? Do you have shared network drives? Do you use Sharepoint?

There is a good chance that every system that could house documentation currently has some subset of your documentation. Now, consider that each of those systems has its own viewing and editing restrictions.

If you could reduce this web of possibilities down to a single source of truth, it would immediately make your documentation more usable. If you can shift this documentation to the left—moving it closer to the code and those writing and reading it—you increase the likelihood it will be kept up to date, and of more documentation being created as things change and new features are introduced.

This same concept applies broadly to reusable code, as well. How many repository systems are you using? Is there a team using SVN, Perforce, or TFS while the newer projects are moving to git? How segregated is your code inside of your Version Control System (VCS)?

If you have multiple ticketing or issue reporting systems please stop reading this. Go choose the one that is easiest for everyone in the company to access, ensure everyone has access to it, and then come back. Seriously, we’ll wait.

Standardize on one or two tools and focus on choosing those with the best usability and not those with the lowest cost. Evaluate new tools in a pilot with a cross section of your organization and gather feedback from leadership all the way down to the front line. Not every tool will fit everyone’s needs, but choosing to heavily favor the top or the bottom will alienate the other and lead to multiple attempts to pursue other tooling and undermine the standardization effort.

Specialized Monorepos

Monorepos have gained a lot of popularity with companies like Facebook, Google, and Twitter promoting their benefits and even developing specialized tooling to help manage them.

First, let me emphasize that a monorepo is not a silver bullet that will solve all your code sharing woes. It is a tool that, when implemented with the right codebase and the right organizational emphasis, can improve productivity and developer satisfaction. Monorepos definitely come with their own set of challenges, especially when it comes to orchestration and deployment, and there are plenty of articles out there that dig into those issues. With those caveats out of the way, let’s talk about how a monorepo can help enhance discoverability in your organization.

A well-organized and documented monorepo allows developers to search the entire codebase, rather than hopping between repos trying to find the connections between packages while tracking down a bug.

One of our clients had so much code split across so many repositories that had been created by so many different developers over time that we would sometimes discover a repository that no one knew about while tracking down a bug. In some cases, no developer actually had access to update these newly discovered repositories because the creator had left the company and no one was configured as a maintainer who could approve and merge PRs.

This was an extreme example, but imagine what dealing with this kind of fragmentation every day does to developer productivity (and sanity).

In a true monorepo, your organization decides to host all of its code in a single VCS repository. While a multi-gigabyte repository that spans several languages works for these organizations that can afford to spend significant developer time on optimizing and patching their VCS system and developing internal tools specifically for their organizational needs, it isn’t all that practical for most of us. Luckily, we don’t have to go all-in.

Consider the impacts of implementing several specialized monorepos breaking things apart by language.

Could you bring all of your JavaScript development into a single repository where developers can more easily create and share new packages?

Would it make sense to collect common utilities into a single repository that developers can easily import?

Internal Marketing

Where do developers go for information in your company? Can you easily broadcast information about important updates to your internal consumers?

This issue is one of the hardest to solve in a large enterprise due to the lack of a proper communication channel and general email fatigue among employees.

Something like Slack can help solve the question of where to put the information, but you still need to market your new #innersource channel so that people join it. There are a number of other questions to tackle:

How often should updates be shared?
Are there developer-specific and leadership-specific updates?
Do all updates go through the same channel or are there specific channels for leadership and maintainers?
How can maintainers reach out for support on a project?

Organizational Change

It’s important to provide time for people to actually maintain and contribute to these shared projects. This works best if:

it can be worked into the existing Agile process and prioritized along with the rest of their sprint work,
if developers are given specific sprints that are dedicated to Inner Source work,
or if some amount of general capacity is reserved to contribute to Inner Source projects.

Reserving time can be tricky; there are plenty of stories from various companies about how things like 20% Time are easily consumed by normal work as priorities shift. Having Inner Source prioritized like normal work will likely require some degree of grooming and planning of the projects’ backlogs to ensure there are Issues that are ready to be consumed.

The time reserved to work on Inner Source might not just be for your developers, but your scrum masters, product owners, and project managers might also need to be involved. Remember, Inner Source is for the benefit of the whole enterprise, not just your developers. You may find that people with all sorts of job titles are interested in helping out, and that you desperately need their help for any of this to succeed.

There is a fair amount of research that shows that employees who feel empowered and have autonomy may perform better, are more satisfied with their jobs, and are less likely to experience burnout. This can mean different things to different employees and different organizations, but providing them with a chance to take ownership and provide value across the company can be very empowering.

Looking for ways to innovate more successfully, improve employee and customer experiences, and better define the operating model that suits your organization? Contact our team here at Method to see how we can help.