InnerSource (IS) is the use of open source software development best practices and the establishment of an open source-like culture inside organisations, especially for the development of proprietary or non-open source software. Let’s explore some of the common challenges faced by organisations that are on their IS journey.

Like open source, IS has its set of benefits and challenges. Some benefits include faster time-to-market, higher code quality, innovative development, wider collaboration, reduced costs, increased reuse, and so on. But as more organisations embrace IS for its benefits, they should look out for the challenges and be prepared to sort them out.

In this article we will see some of the common challenges faced by organisations that are on the way to explore IS. We will also look at how a company’s policies, from a human resources (HR) perspective, can help mitigate these challenges and provide a conducive environment for IS adoption and success.

IS implementation involves a lot of cultural/behavioural changes like developing a collaborative mindset, decentralised decision making, etc. The HR business unit can especially be helpful in driving such changes by hiring the right staff, keeping them motivated for such changes, and creating awareness about the benefits of IS.

InnerSource challenges

Challenges faced by organisations when they adopt InnerSource can be broadly grouped into three categories.

1. Operational: Differences between conventional and IS software development practices can lead to challenges in adoption.

2. Organisational: Organisational policies and culture, like targets, incentives and code ownership, can create roadblocks if they don’t take IS into account.

3. Individual: Inertia, fear, lack of awareness, and other such factors can make individual employees reluctant to adapt to an IS way of working and culture.

Addressing operational challenges

Final product vs incremental quality code

In a traditional organisation, the focus is more on the end output or product, whereas IS encourages frequent incremental additions to the code. The implementation of an IS program requires a “mindset shift from delivering [a] final product to incremental quality code” and can lead to a “culture shock and dissonance” (https://www.blackducksoftware.com/resources/webinar/understanding-inner-source-fundamentals-transparency-collaboration-and-self-organization). If not addressed at the right time, this shift can lead to demotivated employees and subsequently a failed IS implementation.

One way to deal with this shift is to divide the project/product into measurable incremental chunks and tie a performance metric (define specific KPIs) to each chunk.

Status oriented vs meritocratic (hierarchical vs egalitarian) culture

In status oriented culture, there is a rigid decision-making hierarchy. For example, the decision to add a module or functionality is decided by those higher in the hierarchy. Meritocracy, on the other hand, involves decision making based on merit (of the decision) rather than a hierarchy.

Most corporate organisations have a status oriented culture. People strive to reach the next step on the hierarchical ladder. Meritocracies, on the other hand, are egalitarian. In a meritocracy, the importance of a thing depends only on the benefit to the overall project (its merit).

IS projects are egalitarian. Every contributor who is willing to help an IS project is welcome. Also, contributions to IS projects are judged based on the value they bring.

Such a transition from status oriented to a meritocratic culture with IS can result in conflicts. For instance, in IS all decision making happens in public and is based on consensus. This presents challenges for people who are accustomed to operating in a hierarchical environment where decisions come from above — from managers down to subordinates. This leads to hindrance in collaboration due to different priorities, and so on.

To mitigate this challenge, it is important to tie rewards and recognitions to the actions and contributions of the person rather than to ‘who’ or ‘what’ the person is. This will also help to remind teams about the egalitarian culture of IS and its decision-making process.

Users vs co-developers

Unlike open source, where users can be anywhere in the world, all the users of an IS software project are internal to the organisation it’s being developed in.

In a great IS implementation, users hold a very important position: they’re also the developers. Furthermore, they often don multiple hats like bug-fixer, tester, evangelist, and so on.

Attracting users to become active members of the community requires effort and can be a challenge because of reasons like:

• Users tend to use and not contribute back either due to laziness or they don’t see any incentive in doing so.
• People fix bugs only in their personal copy without contributing to the shared code.

To entice users to become contributors to the IS project, companies can organise a hackathon where the winner is the user with the best contribution. The core members of the IS project plus other relevant stakeholders can be the judges of the competition. The winners can be rewarded by elevating them to be contributors or a part of the core team for the project or program.

In addition, awards or recognitions for the one who fixes the most bugs can encourage users to take bug-fixing seriously.

Clear benefits vs vague advantages

Among the benefits of IS are rapid innovation, improved collaboration, increased code quality, faster time to market, more satisfied and motivated employees, and reduced attrition. We all know these are great advantages, but they’re also difficult to measure.

Peter Drucker famously said, “If you can’t measure it, you can’t manage it.” To effectively manage an IS program, organisations should set clear goals, define baseline metrics and KPIs, and engage in regular monitoring and course correction. These measures also help in assessing the efficacy of an IS program.

A few approaches to define the goals and measure them are:

• Employee satisfaction by surveys and personal connect with HR
• Attrition numbers and time-to-market through A/B testing
• Innovation through feedback from an expert jury

Such an approach to clearly define, measure, and track IS goals can go a long way in sustaining and thriving the IS efforts.

Assigned tasks vs self-organising

IS has a varied degree of assignment and self-organisation for tasks, which is very distinct from the strictly assigned nature of the work in conventional software development. This often leads to chaos, indifference, or both.

One must ensure work continues by gamifying tasks and development components. Points, badges, leaderboards, and performance graphs can be used to assess the contributions. In some teams, it may make sense for the final score to become a factor in the annual performance appraisal.

Addressing organisational challenges

Fear of resource loss

Middle management can be an impediment to IS adoption, fearing that IS may result in a disadvantage for their organisational unit, e.g., delay in non-IS project timelines due to resource diversion towards IS projects. There is also fear of not meeting goals dependent on completion of non-IS projects. Due to this, middle managers may either hinder IS adoption or be indifferent towards it. This can have an adverse impact on the IS program’s success.

To allay the middle managers’ fear of losing resources, companies can create a private market for IS, where organisational units can place software components ‘for sale’. They can design the public market to reimburse both for providing an IS component and for contributing to it. Take care that the private markets do not hinder reuse and collaboration.

For example, the IS program at Philips implemented something similar to a private-market where the organisational units were required to pay a fee for reusing a component (http://dx.doi.org/10.1109/MS.2008.79).

InnerSource brand dilution

“Success has many fathers.” When an IS project succeeds, it often leads other teams using the brand to suggest they were part of the success, without them actually practising the values of IS.

Worse, business units may simply claim they “do InnerSource” but not make the effort that is required (https://www.oreilly.com/library/view/adopting-innersource/9781492041863/).Gamification can come to the rescue.

Something like an InnerSource premier league can be organised, where the scoreboard is updated daily with teams or individuals getting scores for their contributions like development, mentorship, evangelization, testing, etc. Such real-time tracking of efforts can thwart any attempts at IS brand dilution or false claims of contribution.

Addressing individual challenges

Unwillingness to mentor

Mentoring in IS projects is intended to help new joiners (with respect to the IS project) learn the basics of IS along with the culture and process of collaborative development, realise its benefits, and overcome barriers to contribution. Mentoring is thus a crucial element for the success of an IS project. However, often due to intense time pressures such mentorship takes a hit. For example, it is observed that mentoring is the first to get affected in a situation of impending deadlines as people either fail to realise its importance or think of it as a thankless job.

Organisations should encourage mentorship through rewards, points, and leaderboards, and add it as a component of the InnerSource goals discussed earlier in the article.

Not invented here

‘Not invented here’ (NIH) is a suspicion many software developers have about the quality and maintainability of any software they didn’t personally write. Such suspicion often manifests as a misplaced perception that the IS software, which is usually developed by multiple teams, is of sub-standard quality.

Companies can avoid this challenge by developing a mechanism to standardise the software and its components. For example, code quality can be scored based on its size, reliability, maintainability, efficiency, and security. For IS contributions, the code should be above a minimum threshold score.

This can help address trust issues as well as ease the on-boarding process for developers new to the IS project. Also, it’s good to add a goal for documentation. Good documentation helps to reduce NIH suspicions.

Summing it up

InnerSource (IS) adoption brings numerous benefits for software organisations. However, as with any change program, IS has its share of challenges. Organisations planning to walk the IS path need to be aware of the challenges that might come their way.

Involve different organisational units—including HR—when working to understand the challenges, formulate policies to address them, and develop a culture suited for IS adoption. With collaborative brainstorming that includes all the stakeholders and business units, the recommendations in this article can form a basis for tackling the unique challenges you’re facing in your organisation.

This approach not only helps to manage the IS challenges, but also to build the inclusive and collaborative organisation that is one of the signs of IS success.