Companies of varying sizes across many industries are implementing innersource programs to drive greater levels of development collaboration and reuse. They ultimately seek to increase innovation; reduce time to market; grow, retain, and attract talent; and of course, delight their customers.
In this article, I'll introduce innersource and some of its key facets and examine some of the problems that it can help solve. I'll also discuss some components of an innersource program, including metrics.
What is innersource?
Innersource is the practice of applying the lessons learned from developing open source software to the way a company develops software internally. Because it's done within a corporate environment, innersource happens behind the company firewall.
With innersource, developers have the opportunity to both get and give.
Get:
- Others' code to reuse or leverage (instead of rewriting the same thing differently)
- Testing, enhancements, and fixes from a larger crowd
Give:
- Code for others to reuse or leverage
- Enhancements, testing, or fixes by collaborating on others' projects
So, you may be asking, isn't this just collaborative development? Yes. But, for large, siloed companies, it's significantly magnified. This is where the lessons of open source come into play.
With innersource, developers aren't just collaborating with their own team members within their specific domains. They have the opportunity to collaborate on code and projects well beyond their specific, assigned areas. Everything is open. This means developers can read all innersource code and documentation by default, without jumping through hoops to access it.
With innersource projects, all decisions surrounding the code are documented and open. This creates a comprehensive log that new contributors or teams can use to quickly get up to speed and understand the history of the project.
What problems can innersource solve?
Many of the reasons companies pursue innersource are tied to the problems associated with closed or siloed development models.
Duplicative development
Building the same thing, many times, in many ways is costly. It's much more cost effective for code to be written once and reused, or at least leveraged and built upon. It can lead to products within the same portfolio that look and feel different. Customers expect (and deserve) products in the same portfolio to deliver a seamless and consistent experience. Duplicative development can also mean that your products don't work together—seamlessly or at all. If your goal is to provide fully integrated solutions, this is bad news. And you probably could have gone to market faster if you weren't spending time reinventing the wheel.
Slower time to market
Slower time to market can be a result of duplicative development, but it can also be due to dependencies that come with closed and siloed environments. If your product integrates with another one into which you have no input, you have to wait for someone to agree to add your feature or fix that bug. This means that it takes you longer to go to market with that feature or fix. Will you miss your market opportunity because you were slowed down? Will others beat you there?
Limitations
If your environment is siloed or closed, you're limited to testers within your specific group. You could also be limited in terms of resources for vulnerability response and issue resolution. How many issues could be found and resolved with a wider crowd that has diverse experiences and perspectives? What impact could that have on product quality?
Many developers get to work with smart, dedicated people, and they build and support features for amazing products. That's fantastic. But in a closed or siloed environment, you might get a chance to work with, build relationships and trust with, and learn from only three or five or 10 other people.
Wouldn't it be better if you could build relationships and work with 20 or 30 or more brilliant developers? What could you achieve? What could you learn? What skills could you acquire if you could learn from other projects and domains? Don't you want to work at a place like that?
How does it all come together?
Let's take a look at some of the critical components of an innersource program. I talked to more than 50 developers to ask them what they'd need. They replied:
Give us:
- A low barrier to entry
- The right environment (e.g., don't make us change our toolkit if it's not necessary)
- Guidelines, not mandates
Let us:
- Control our own destiny
- Manage and govern our own projects
- Communicate effectively
And:
- Keep it simple; don't make it process or procedure heavy
Here are key considerations:
Culture
There is consensus within the community that innersource is much more about change management and cultural transformation than it is about being able to share code and having the right tools. To get innersource right, companies need to cultivate that culture and environment of openness and transparency internally. For many companies, this means transformation.
Trust is a big component of the culture required. With intra-team development models, developers have the chance to build trust with their own team members, and they have confidence in the integrity of their team's code. Innersource opens these teams up for contributions from outside of their team, so it's natural for them to have concerns related to quality and risk. Trust must be built, and this requires an environment that allows the collaboration and open communication that are critical to healthy innersource endeavors.
Mentoring is another key aspect of a healthy culture. To put it simply, in an innersource environment, the mindset is: "Let's discuss how you can get this code to the level at which it can be merged," as opposed to: "We don't really know you; therefore, we don't trust this code; therefore, we're rejecting it."
Legal aspects
Depending on the company's nature, one of the biggest pieces of building an innersource program can be revision of policies and processes to enable developers to have internal access to the majority of code. Working closely with your legal department to reach an agreement without compromising the protocol for system application and security for protecting the internal code is important.
Education
Look to strike a balance between offering too little information for developers vs. providing mandates or overly rigid requirements. Deliver clear and accessible information on how to get started, general guidelines for engagement, and basic how-to information. Depending on collaborative development maturity levels, some teams may require more in-depth or hands-on training. In these cases, it helps to identify early adopters who can mentor and informally train their colleagues.
Tools
Innersource requires an environment that enables high levels of secure access, collaboration, communication, and findability. If developers are already using a robust and secure collaboration tool for intra-domain development, consider sticking with that if possible. Regardless of the tool you settle on, offer clear processes for code transfer or migration from other tools.
Opportunity
Especially when getting started, innersource can require a high investment of effort related to general engagement, code review, revision, and even finding the right collaboration opportunities. The allocation of time and resources for these activities is critical to success.
Metrics
Innersource programs generate a lot of activity. Members will join, they will collaborate, and some will contribute. From all this activity, you will produce many things. Projects will be created, and you will see releases, code commits, builds, and pull requests.
These are the easy data points to measure during the early stages of a program, and it can be encouraging to see them trend up. But it's important to remember that they are just data points; they don't paint a full picture of value.
Staying focused on your ultimate goals is critical. With innersource, you are likely seeking to achieve one or more of the following:
- Increased quality, employee and customer satisfaction, innovation, and/or integration
- Reduced time to market, cost, and/or defects
Are you capturing data that reflects your achievements? The data you collect can help expose problems to fix, as well as help tell the story of the value that you gain. Share your successes and your learnings along the way to encourage others to collaborate.
Learn more
Interested in learning more? Check out:
- How to create an internal innersource community by Jono Bacon
- 10 steps to innersource in your organization in 2017 by Jono Bacon
- Innersource Commons Summit
- Innersource Patterns
- Innersource 101 by Jim Jagielski
For a deeper dive into this topic, attend Erin Bank and Jim Jagielski's talk, Inner Source Case Studies: Companies Leveraging the Wisdom of Open Source, at All Things Open, Oct. 23-24, in Raleigh, N.C.
Comments are closed.