InnerSource encourages and rewards collaboration and code reuse with anyone, regardless of their position in a company’s organizational structure. This approach differs from what is seen in traditional organizations where ideas and work product tend to stay trapped within the boundaries of the internal corporate hierarchy and its silos. Let’s explore one situation that gives an example of this idea.
Imagine two teams at the same company deliver separate pieces of software with one team’s software depending on that of the other. An example could be a user experience that depends on an API service to retrieve data for display. This situation is common in a large enterprise where a single team producing software may have dozens or hundreds of consumers.
When consuming teams need many features, producing teams normally have some sort of requirements and prioritization process to decide which features they will work on. For critical feature requests that are not prioritized for immediate work, the consuming team may commonly choose one of 3 options, each of which comes with their own drawbacks.
-
Wait it out. The consuming team may do nothing and limp along without the requested functionality. This option requires the least amount of work on their side. Depending on the benefit of the feature request, waiting might be just fine. However, it may come with real amounts of pain, especially if the requested functionality is never delivered.
-
Workaround. A consuming team that doesn’t want to wait may do extra work somewhere else to compensate for the absence of their requested feature. This extra work may come as change in the consuming project. Alternatively, they may create a new project that meets their needs and replaces their use of all or part of the producing team’s system (code/project duplication). This strategy allows the consuming team to get the requested feature via their own efforts only. It comes with several drawbacks, though.
-
Any work done by the consuming team remains unavailable to any other consumers with the same feature request.
-
The consuming team has inadvertently signed up for the long-term burden of maintaining the newly-written code, which is not in the domain of their core team competency.
-
The company as-a-whole acquires duplicate projects and code in the same problem space.
-
-
Escalate. The consuming team may not take "no" for an answer and, instead, advocate to someone in the producers' management hierarchy to influence (or force) the producing team to do the work. This option sounds attractive for the consuming team because they get the requested feature without doing the work to implement or maintain it. It is still a drag on the team, though, because it necessarily diverts some of their attention and work to the non-engineering task of escalation. Additionally, this option does not scale as there are only so many times that a consumer can escalate feature requests before damaging their credibility. Escalation is similarly disruptive (even more so) for the members of the producing team, who are taken out of their normal workflow and prioritization methods to deal with the escalated feature request.
This discussion sets the stage for InnerSource. InnerSource applies to the same type of situation where a consuming team is unable to get what it needs via feature request. InnerSource provides a way for the teams to gain the benefits of wait it out, workaround, and escalate without the associated drawbacks.
InnerSource also provides a general improvement to engineering culture as engineers have the chance to work with a wider variety of new technologies and people. Developers mentor and learn from one another as they share ideas and solutions across organizational silos. Engineers and teams can reuse internal solutions to commodity problems, allowing them to focus on higher value streams of work for the organization.
