What problems does InnerSource solve?

## When an InnerSource project can be useful? 1. [ ] Your team lacks the resources to create its core software > InnerSource allows other teams to upgrade your software to meet their needs. You can’t depend on other teams to take on your own priorities, nor can you assign a project to another team. InnerSource relies on voluntary contributions, and works where the interests of the guest and the host team align. 1. [x] You are badgering a high-level manager to get another team to implement a software change > Large organizations that assign different teams to different parts of a code base routinely suffer battles over priorities. What’s critical to your team’s business plan may be seen as an extraneous annoyance to the host team that owns the code. With InnerSource, you add the code you need directly to the other team’s project, although you are responsible for following their guidelines and the host team vets it before it goes in. 1. [ ] Most of your software is bought rather than built > If a third party delivers a proprietary solution, you can’t participate in its development. However, free and open source software from third parties offers excellent opportunities for collaboration. The skills you learn doing InnerSource can be applied to open source projects outside your company, and vice versa. 1. [ ] Not enough software changes are being submitted to your team > InnerSource exploits the desires of other teams to enhance your software. If your software is mature and doesn’t need many changes, there is no reason for you or other teams to enhance it. Your skills can be directed to new projects.

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.

  1. 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.

  2. 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.

    1. Any work done by the consuming team remains unavailable to any other consumers with the same feature request.

    2. 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.

    3. The company as-a-whole acquires duplicate projects and code in the same problem space.

  3. 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.

Contributors