InnerSource scaling and metrics - OSPOlogyLive Malmö Roundtable (Day 2)

[spriya-m]

Meeting notes for round table sessions on Day 2, Friday, 31st May 2024.

[spriya-m]

ROUNDTABLE - 2

InnerSource scaling and metrics - challenges and sharing learnings

Attendees coming from different companies, semi-public sector and academia, including Volvo, Ikea, BBC, Blekinge Institute of Technology, etc.

Challenges with InnerSource scaling

• InnerSource is successful when it is part of the company culture rather than envisioned by the leadership and then trickle down the hierarchy. It works well when it comes bottom up.
• Middle management is mostly a blocker for scaling InnerSource. InnerSource metrics are needed in more meaningful and measurable form (in terms of cost saved) in order to get the buy in from the middle management. In early stages of innersource, with not much successful projects, deriving innersource metrics is difficult which in turn hinders getting middle management buy-in and hence scaling.
• These challenges pose difficulty in getting funding to invest in community building and management of the innersource projects.
• It could be assumed as a mere file sharing approach than realizing the benefits such as collaborative development, breaking down silos, etc.
• Even though many companies have shared the success stories publicly (numerous companies have shared the success stories in the InnerSource Commons), convincing the middle managers is sometimes difficult as it is hard to measure direct cost saved.

Possible solutions for the challenges listed above:

• Forming communities around a project that is being reused and then innersourcing it, is fruitful than developing a project with an assumption that is a reusable component and then build a community around it.
• Middle management from an engineering background is more inclined to innersource.
• InnerSource can be scaled if middle management can see it as an aspect of career progression and define it as one of the KPIs for the senior engineers. (encourage team to spend 20% of time on innersource projects)
• Define contributing guidelines like consumers cannot add requirements to the innersource project unless they actively contribute back to it.
• Ownership of code in an innersource project is also one of the challenges during early stages of innersourcing. Proposed solution is that the ownership should be independent of the line management and the project be self managed by the community itself. However, shared ownership also has its own challenges like who is accountable in a distributed ownership.
• Defining right common requirements and making sure that the innersource project does not deviate from the functionality is more important. It avoids bloating the innersource projects with multiple variations by each consumer team.
• If talent retention by innersource is measurable, it can help scale innersource.
• InnerSource benefits should be seen as a long term transformation and should not be decided based on short term outcomes.
• Teams with middle management support and with some kind of recognition like badging, tend to be more inclined to contributing to innersource projects.
• Educating teams about innersource as a path to open source can also help scale innersourcing.

InnerSource metrics

• During early stages, start with basic metrics like number of innersource practitioners and number of projects innersourced. And then move to other metrics like quality metrics later.

• Metrics that are hard to measure are:
  Cost saved through reuse
  Knowledge sharing
  Reduced time to market

• InnerSource badging - the number of innersource badges can be used to measure the maturity of the organisation over time with respect to innersource.

• Metrics and tools like Grimoirelabs already available can be leveraged to measure innersource metrics.

Apart from these, we also discussed about the kind of projects that are most successful with innersource:

• Common tooling, common frameworks
• Tools that make the everyday life of a developer easier
• Reusable customer facing applications
  Niche or a differentiating project is not a common innersource project.