Innersource for Your Enterprise by Jessi Moths

Jessi Moths, a solutions engineer at GitHub, shares how we can bring innersource into your company.

What Is Innersource?

First, let's define innersource: it is the application of open source principles to enterprise development.

The open-source community and enterprise teams face common challenges. By looking at how open-source successfully tackles these challenges, we can apply them to our enterprise.

Here are some of those challenges:

• Collaboration among teams, especially distributed ones. The current climate has emphasized how challenging working remotely can be.
• Ownership and maintenance. Open source has to deal with challenges of multi-year ownership of applications, long after the bulk of features have been written.
• Rapid delivery. Open source reacts fast to the needs of its users and develops trust with its user base.

Goals of Innersource

Innersource has four goals:

• Reuse. We want to leverage the efforts of other people so we can save time and effort for our team.
• Collaboration. When working together, we want to play to our strengths and write better software as a result.
• Community. We should understand that we are part of a larger community—a community of both our coworkers and our users.
• Better, faster software. We can ship our software frequently without lowering quality. In fact, faster feedback can increase the quality of our software.

All of this leads to overall better quality software and happier team members.

Attributes of Innersource in Action

There are five attributes of innersource in action that are worth calling out:

• Openness. We should be open with our information and our work, and we should not hoard knowledge. This should be a default paradigm, but that doesn’t mean just anyone can commit to any codebase in your company.
  
  
• Transparent. We should make as much of our information as documented as possible. We should also iterate on it to ensure that it’s accurate. This documentation should be preserved and open, and it also should be searchable and discoverable. Collaboration does not need to wait for approvals—let it happen while in the stream of development.
  
  
• Participatory. We want people outside our team to be able to collaborate with us. This especially includes users. They can give us rich, early feedback if we include them in our process.
  
  
• Collaborative. We want to work with people, not compete against them. Incentives should be team-focused, not individual-focused. Use teams to facilitate communication, not only structure. You should feel free to pull in experts on differing subjects, like JavaScript or security.
  
  
• Governed. Though teams should have a high level of autonomy, this isn’t the Wild West. Our teams should be accountable for the things we own. There should be some level of governance that limits how we operate. This includes tools and best practices that help us follow the best paths to deliver software. Don’t assume everyone knows the best way to get things done. Make it clear what you believe are the best choices for your team. Also, use guardrails, not stop signs. Don’t necessarily have code reviews that stop code from being deployed, but raise signals that you can discuss as a team. Automate your governance where possible. Automated governance will not get in your way.

These attributes of innersource can tackle many of the challenges of communication in enterprise, which can be some of the most difficult ones to solve. You have to speak to people all across the organization to get your work done sometimes. Open source has to model communication in small places in order to succeed, and innersource will help us shore up our communication.

Manage Your Information

Doing all these things can result in a massive buildup of information. You must curate all of it. Consider these attributes as defaults, not rule of law. And be open with each other, free to suggest changes to improve your quality.

You’ll also want to have a single source of truth for your information in order to promote discovery. Information is useless overhead if no one can find it. This doesn’t mean you have to use one platform across your enterprise, but you should centralize as much as possible.

Remember to design for reuse. Find ways to ensure your information can be reused across many different scenarios. For example, you can link to your business glossary in your wiki from a user story and from a slide deck during a demo.

Next up, keep in mind that documentation is part of your software. It should be part of your day-to-day work, alongside your code. By continually working on it, you will keep the effort needed to maintain it as low as possible while keeping its accuracy high.

Finally, keep friction low for people to contribute to your documentation. For example, don’t require specific team membership for coworkers from other teams to edit your wiki.

Better, Collaborative Software

By innersourcing our team, we can have effective communication, documentation, and collaboration in our enterprise. Make your processes as open and documented as possible. Keep everything as centralized and friction-free as possible.

In the end, innersourcing will enable you to have a strong, creative team able to create effective software, even in large organizations.

This post was written by Mark Henke. Mark has spent over 10 years architecting systems that talk to other systems, doing DevOps before it was cool, and matching software to its business function. Every developer is a leader of something on their team, and he wants to help them see that.

Photo by Joshua Sortino