Inner Source Challenges

Inner source sounds simple in theory. In practice, it runs headfirst into organizational politics, incentive structures, and deeply ingrained cultural habits. The technical barriers are trivial compared to the human ones. Most inner source programs that fail do not fail because of tooling. They fail because teams resist using code from other teams, managers do not reward cross-team work, and the organizational culture treats code ownership as territory.

The "Not Invented Here" Syndrome

"Not invented here" (NIH) is the tendency to reject solutions from outside your team, even when they are better than what you could build yourself. It is one of the oldest problems in software engineering, and it is the single biggest obstacle to inner source.

Why NIH Happens

NIH is not irrational. It comes from legitimate concerns that get amplified by organizational dynamics:

Legitimate concerns:
- "Their code does not meet our standards."
- "We do not understand their architecture well enough to depend on it."
- "If they change it, our service breaks and we cannot fix it."
- "Their team's priorities are not our priorities."

Amplified by:
- Team identity ("we are better than them")
- Risk aversion ("building our own is safer")
- Control ("we need to own our dependencies")
- Past bad experiences ("last time we used their library, it broke")

Overcoming NIH

NIH cannot be eliminated by mandate. It has to be addressed through trust, demonstrated value, and gradual exposure.

Strategies for overcoming NIH:
1. Start with low-risk adoption
   - Use another team's utility library, not their core service
   - Low stakes reduce perceived risk

2. Demonstrate quality
   - Show test coverage, documentation, and reliability metrics
   - Make the inner source project visibly well-maintained

3. Provide escape hatches
   - If a team adopts an inner source library and it breaks,
     they can submit a fix themselves (that is the point)
   - The ability to fix it yourself reduces dependence anxiety

4. Share success stories
   - When Team A uses Team B's library and ships faster,
     tell that story in engineering all-hands
   - Social proof is powerful

5. Joint ownership
   - When multiple teams contribute to a project,
     no single team feels like they are depending on "someone else's code"
   - It becomes "our code" across teams

NIH on the Contribution Side

NIH also works in reverse: teams resist accepting contributions from other teams. "Why would I merge code from someone who does not understand our system?" This resistance is addressed by the trusted committer pattern and clear contribution standards, but it requires the owning team to believe that external contributions are a net positive, not a burden.

Manager Buy-In

The most common killer of inner source programs is middle management. Not because managers oppose collaboration, but because incentive structures do not support it.

The Manager's Problem

A manager is evaluated on their team's output. When an engineer on their team spends a week contributing to another team's codebase, that is a week not spent on the manager's team's roadmap. From the manager's perspective, they are lending an engineer to another team for free.

Manager's calculus:
- Engineer contributes to another team: -1 week on my roadmap
- Benefit to other team: their bug is fixed
- Benefit to my team: unclear, delayed, indirect
- My performance review: based on my team's roadmap delivery
- Conclusion: I cannot afford to let my engineers work on other teams' code

This calculus is rational given the incentive structure. The problem is not the manager. The problem is that the organization rewards local optimization (team output) over global optimization (company velocity).

Getting Buy-In

Approaches to manager buy-in:

1. Quantify the cost of waiting
   - "Our team waited 6 weeks for Team A to make this change.
     Inner source would have taken 3 days."
   - Make the current cost visible

2. Executive sponsorship
   - Inner source needs a VP or Director champion
   - Top-down support signals that cross-team work is valued
   - The champion must protect teams that invest in inner source

3. Make it part of the roadmap
   - Cross-team contributions should appear in sprint planning
   - "Contribute OAuth fix to auth-service" is a legitimate work item
   - If it is not on the roadmap, it is not real work

4. Show manager-level metrics
   - Track time saved by cross-team contributions
   - Show reduced dependency on other teams' backlogs
   - Frame inner source as "my team is less blocked"

The VP Problem

Sometimes the resistance comes from above middle management. A VP who views inner source as "my engineers working on someone else's code" will kill the program. Executive sponsorship must come from someone with enough authority to protect the program from this resistance.

Incentive Alignment

If performance reviews do not reward cross-team contributions, inner source will not succeed. Engineers are rational. They optimize for what gets them promoted.

The Promotion Problem

Typical promotion criteria:
- Impact on team goals
- Technical complexity of work delivered
- Leadership within the team
- Code quality and reliability

What is missing:
- Impact on other teams
- Cross-team contributions
- Improving shared infrastructure
- Mentoring contributors from other teams (trusted committer work)

If an engineer spends 20% of their time as a trusted committer, reviewing and mentoring cross-team contributors, that work must appear in their performance review. If it does not, they will stop doing it.

Fixing Incentives

Ways to align incentives:

1. Explicit recognition in reviews
   - Add "cross-team impact" as a review dimension
   - Trusted committer work counts as leadership

2. Inner source contribution badges or awards
   - Quarterly recognition for top contributors
   - Visible in internal profiles

3. Career ladder alignment
   - Senior engineer level: "demonstrates cross-team collaboration"
   - Staff engineer level: "enables productivity across multiple teams"
   - Principal engineer level: "shapes engineering culture through inner source"

4. Team-level metrics
   - Track cross-team contributions as a team metric
   - Include in team retrospectives

Compensation Considerations

Some companies have experimented with explicit bonus structures for inner source contributions. While this can jumpstart adoption, it risks gamification: engineers submitting trivial contributions to earn bonuses. The better approach is usually integrating inner source into existing performance evaluation rather than creating separate incentives.

The Cultural Shift

Inner source requires shifting from ownership to stewardship. This is a deep cultural change that affects how engineers think about their code, their team, and their role in the organization.

From Territory to Commons

In many organizations, code repositories feel like territory. The team that owns a service defends it. They resist changes from outsiders. They take pride in their independence. This is natural: humans are territorial. But it is counterproductive in a large organization where teams need to move fast and share infrastructure.

Territory mindset:
- "Our code, our rules, our decisions"
- "File a ticket and wait"
- "We will get to it when we get to it"
- Code ownership = team identity

Commons mindset:
- "Code we maintain, contributions welcome"
- "Here is how to contribute, let us help you"
- "Let us review your PR this week"
- Code stewardship = organizational responsibility

The Trust Gap

Cross-team contributions require trust in both directions:

Owning team must trust:
- The contributor's code quality
- The contributor's understanding of the system
- That the contributor will fix bugs in their contribution

Contributing team must trust:
- The owning team will review promptly
- The owning team will give fair, constructive feedback
- The contribution will actually be merged, not ignored

Trust is built through repeated positive interactions. The first cross-team PR is the hardest. The tenth is routine. The organizational challenge is getting through those first few interactions without either side giving up.

Psychological Safety

Contributors need to feel safe submitting imperfect work. If the first cross-team PR is met with harsh criticism or public shaming, no one else will try. Trusted committers must be trained in constructive code review that helps contributors improve rather than discouraging them.

Constructive review example:
  Instead of: "This is wrong. You clearly do not understand our architecture."
  Try:        "This approach will cause issues with our caching layer.
               Here is a link to our architecture doc that explains the pattern
               we use. Want to pair on this for 30 minutes?"

Ignoring incentive misalignment. If the performance review system does not reward cross-team work, engineers will not do it regardless of how much leadership talks about inner source.
Blaming engineers for NIH. "Not invented here" is usually a rational response to real concerns about quality, reliability, and control. Address the concerns instead of dismissing them.
Skipping the manager conversation. Managers control engineers' time. If managers do not support inner source, engineers cannot participate, no matter how enthusiastic they are.
Expecting culture change without investment. Culture changes when incentives change, success stories circulate, and leaders model the desired behavior. None of this happens by accident.
Measuring inputs instead of outcomes. Counting PRs is easy. Measuring time saved, silos broken, and developer satisfaction improved is harder but more meaningful.
Giving up after the first failure. The first cross-team contribution will be awkward. The process will have gaps. This is expected. Learn, adjust, and try again.

Key Takeaways

"Not invented here" syndrome is the biggest cultural obstacle to inner source, rooted in legitimate concerns about quality and control that must be addressed, not dismissed.
Manager buy-in is critical because managers control engineers' time and optimize for their team's roadmap delivery, which may conflict with cross-team contribution.
Performance reviews must explicitly reward cross-team contributions, trusted committer work, and cross-team impact, or inner source will not sustain.
The shift from code ownership to code stewardship is a deep cultural change that requires trust built through repeated positive interactions.
Executive sponsorship from a VP or Director level is necessary to protect inner source programs from organizational resistance.
Inner source adoption is a multi-year journey that starts with building trust through small wins, not a one-time announcement.