InnerSource as an Enterprise Accelerator to Build a Culture of Collaboration

Enterprise organizations often want to encourage more collaboration among internal teams and even consider the idea of open sourcing some of their in-house software (often referred to as InnerSource). However, many organizations aren’t sure what’s involved or where to start.

Here, I’ll talk about what InnerSource is, how it works, and why enterprise organizations should embrace it. I’ll also share tips about how organizations can get started.

What Is InnerSource?

At many large organizations, every department or line of business behaves like its own entity, each building its own proprietary applications and testing frameworks. A common barrier to collaboration we often experience is lockdown of internal source code repositories. Only members of a particular team have access to their team’s code.

InnerSource disrupts this traditional practice, helping organizations develop a new way of working. InnerSource is a term coined by Tim O'Riley to describe the use or adoption of the open source paradigm inside an organization. Innersource is a development methodology where engineers build proprietary software using best practices from the open source community. There is even an InnerSource community called InnerSource Commons, founded by PayPal’s Danese Cooper in 2015.

InnerSource encourages innovation and a greater degree of contribution from in-house development teams. Rather than starting from scratch with every development project, teams can modify existing code developed elsewhere at the organization, which helps teams reuse application code, reducing cost substantially. Organizations that are successful at Innersourcing also focus on project documentation, which increases transparency and builds a broader understanding of goals and decisions made along the way.

InnerSource Borrows from Successful Open Source Concepts

Many developers are accustomed to working on open source software, and InnerSource applies lessons learned from the open source community to the way organizations develop software internally. Typically, different business units each create their own development and testing frameworks. Open Source, however, essentially borrows open source concepts and encourages the use of those concepts (and reuse of existing code) inside the organizational firewall, enabling development teams throughout an organization to benefit from the efforts of each individual team. In particular, InnerSource breaks down silos and builds the organization’s collective knowledge base by encouraging developers to share their projects with other in-house development teams.

In open source fashion, a project can be forked and extended or adapted for a specific use case. Because Innersource encourages internal collaboration on one common framework, communication and documentation are critical parts of the project (arguably as important as the source code itself).

When code enhancements can benefit the greater good of the organization, those enhancements should be merged back into the original master branch via a pull request. As a result, teams can both reuse a solution and pay it forward by contributing beneficial developments back to the organization.

In addition, continuous integration and unit testing are essential programming tasks. In both Open Source and InnerSource projects, teams execute unit testing with every code commit to guard against software regression. For example, in order for a pull request to be accepted, the accompanying unit test must be included with the source code change.

InnerSource Benefits

If an enterprise development team has a business need for a specific software solution, they often end up recreating solutions or looking for vendor solutions outside the organization, especially if they lack a centralized shared hub or repository where they can make use of the software solutions available within the organization. Duplicated functionality is extremely costly and extremely common in large organizations. The result is multiple different solutions to a problem that has already been solved vs. one solution used and optimized by the entire enterprise development team. Some duplicated examples we have seen include CI/CD pipelines, automated testing frameworks, external email or communication services, authentication services, UI styles, and skins for applications.

Organizations embrace and adopt InnerSource concepts in order to:

• Encourage knowledge sharing and collaboration across different organizational units.
• Reduce duplicate development efforts and promote software reuse across the enterprise, thus increasing transparency, reducing waste, and saving money.
• Increase the speed and quality of software development. Developers learn to write unit tests for code coverage, static code analysis, and continuous integration (among other best practices) in order to detect and prevent defects early in the SDLC.
• Enable developers to contribute to a wider variety of projects, thus expanding their skill sets.
• Improve and accelerate new resource onboarding and assimilation.
• Serve as a gateway to open source projects by identifying opportunities for an organization to contribute software or portions of a project to the open source community.

How to Build an InnerSource Culture Within Your Organization

So how can organizations get started with InnerSourcing? As we describe here, an organization must have (or be willing to foster) a culture of openness. A culture is transformed in an organization when new ways of working replace the old. In a transformed organization, each team member strengthens individual competencies, and teams behave and work in a way that fosters open communication, rapid feedback loops, transparency, and continuous learning. All the while, teams continually improve processes and create more tangible value that drives organizational performance.

Understandably, some development teams may still not feel comfortable sharing their applications given the current state or quality of their code. As part of this culture of openness, it is imperative that the organization create and foster a development environment where incomplete code or failed code does not equate to blame. An environment where developers fear embarrassment or blame will erode the developers’ desire to experiment and innovate. In short, psychological safety (a shared cultural belief that interpersonal risk taking is safe) is paramount in order for developers from different teams to feel comfortable sharing code with each other.

How to Find and Utilize InnerSource Projects

Applications from each line of business can be stored in a comprehensive, well-known community location. Here are the key steps to follow in order to file your applications in an InnerSource hub for shared access and use by development teams throughout the organization:

1. Establish an “InnerSource Hub” or group for InnerSource applications (e.g., GitHub, GitLab, or Bitbucket).
2. Work with your SCM Admin to move your project to the InnerSource Hub.
3. Adopt a standardized project naming convention to make it easier to find projects.
4. Create and use well-documented ReadMe files.
5. Include a mechanism for contributing to an InnerSource project. (I’ll cover this topic in a future blog.)

InnerSource Project Best Practices

To use InnerSource effectively within an organization or move from InnerSource to Open Source, it’s important to first establish clear roles and responsibilities and clear rules of governance. A typical InnerSource project usually includes the following types of roles and responsibilities:

• Project Master: Individual who assumes ownership and accountability for ensuring teams follow best practices.
• Maintainers: Developers, project managers, and key decision makers who are responsible for managing the organizational aspects of the project.
• Contributors: Developers, testers, and others from across the organization who contribute code, bug fixes, etc.

Recommended continuous testing and development best practices for InnerSource projects include the following:

• Unit Tests: A unit test accompanies each commit. Developers are responsible for ensuring the quality of their own code. All unit tests are automatically triggered and must pass before any code commit is accepted.
• Documentation: Well-documented ReadMe files facilitate rapid usage and contribution to projects. An example of a well-documented ReadMe file can be found here. In addition, developers document their assumptions, decisions, and implementation details to provide historical context and the development best practices expected for a given repository.
• Packages and Namespaces: Groups, Namespace, Artifacts, and Imports do not reveal internal organizational names or departments.
• Continuous Integration Build and Quality Gating: Jenkins jobs are triggered with every code commit. Builds are gated, which means that they fail if the code does not compile, if unit tests do not pass, or if a code scan reveals new security or quality issues.

Is InnerSource Right for Your Organization?

Innersource helps teams build software faster and collaborate more efficiently, resulting in better code and better documentation. It leverages the brain share of all developers in the organization. When an organization adopts Innersourcing, anyone from high school interns to the CTO can submit pull requests.

The benefits are many, but understanding InnerSource principles and potential challenges in the implementation of those principles is critical to the success of any Technology Transformation.

Five key questions include the following:

1. Does the organization have an open, transparent culture without barriers to collaboration?
2. Do engineering teams use CI tools and develop software on a single, open platform?
3. Can teams work easily across organizational divisions to contribute to each other’s projects?
4. Do cross-functional communities currently work across teams at the organization?
5. Do leadership teams champion organizational engineering initiatives?

For the right organizations, InnerSource can increase efficiency and transparency, speeding up quality development and eliminating duplicate efforts across the organization. InnerSource also allows developers to contribute to other projects, thus expanding their skill sets and exposure.

I have a lot more to say on this subject, and a more technical blog will follow. Until then, if you want to learn more about how Innersource can work at your organization, reach out!