Skip to content

Latest commit

 

History

History
86 lines (51 loc) · 6.55 KB

innersource-hackathon.md

File metadata and controls

86 lines (51 loc) · 6.55 KB
Raw

Title

InnerSource Hackathon

Patlet

In a company, initially only InnerSource enthusiasts are interested and practicing InnerSource during the early stages of InnerSource adoption; not all engineering teams are willing or have enough time and resources to adopt InnerSource. In this scenario, it is good to provide a safe space to try and adopt InnerSource through an InnerSource Hackathon event within the company.

Problem

The company wants to adopt InnerSource as software development methodology but only those familiar with open source principles or those who understand the benefits of InnerSource, adopt it. It results in just a handful of InnerSource projects and is difficult to scale beyond that.

Context

Scenario 1: Challenges in scaling beyond the early adopters

The senior leadership believes in InnerSource and wants to drive it throughout the company. The engineers who are familiar with open source principles and/or understand the benefits of InnerSource are the early adopters. There is success with these initial pilot project and teams.

Now the next step is to drive it across the company. There might be reluctance from engineering teams due to various factors like:

  • not familiar with InnerSource or open source practices
  • not enough time to prioritize InnerSource, given the regular work deliverables
  • reluctance to changing ways of working when everything works well already
  • unclear return on investment for the upfront setup costs that an InnerSource project takes

Scenario 2: Challenges in getting contributions and building community around InnerSource projects

Teams slowly start adopting InnerSource and open up their repositories. Some new projects are started as InnerSource projects from the start (that is open for contributions). However, there are not many contributors. It is also challenging to build a community around those projects, in spite of publishing the projects in an InnerSource Portal. This could be due to various reasons like:

  • engineers do not have time to explore new InnerSource projects and contribute, outside regular work deliverables
  • no additional incentive to this effort apart from being acknowledged
  • lack of motivation by middle management

Forces

Apart from the reasons listed in the Context section, there are other factors from different entities that prevent teams from adopting InnerSource like:

  • From middle management: perception of no direct benefit to the team apart from team upskilling and individual growth; eventually resulting in no motivation by the middle management to the engineers in trying out InnerSource ways of working.
  • From engineers: investing time to try new ways of working when there is already time and resource constraint for regular work deliverables; it is also challenging to balance both and show outcomes in both; this curbs motivation from the engineers as there is little safe space to experiment.
  • From senior leadership: not prioritizing investment in InnerSource ways of working such as it being part of long term goals or OKRs.

For those new to InnerSource or any technology/methodology, there is a need for safe space to try and experiment without definite outcomes in the initial stages. These factors and forces hinder such an experiment ground.

Solution

Organize a company-wide hackathon focused on InnerSource. An InnerSource hackathon provides a safe space for engineers to try and contribute to InnerSource projects without any presumption and prejudice. It could be a 1 or 2 day event.

It can preferrable be organized by InnerSource Program Office (ISPO), if it exists in the organization or by the Open Source Program Office (OSPO), if OSPO also drives InnerSource within the company. It can also be organized by other common service organizations too, if need be. Basically a central team or a group of individuals, who believe in InnerSource, can organize the hackathon.

All engineers in the organization can participate in the hackathon. The participants can be new to InnerSource, or InnerSource practitioners already. They can participate individually or as a team. Participating as a team also provides a safe environment, for example, those are new to InnerSource can team up InnerSource practitioners.

There could be one or more categories to participate as follows:

  • Start a new InnerSource project: It could be either starting a new project from scratch as InnerSource or making a existing project InnerSource ready.
  • Contribute to the existing InnerSource project: InnerSource project owners can list down the features in GitHub issues as a pre-requisite before the hackathon and the participants can contribute to it during the hackathon.
  • Participate as an InnerSource mentor: Participants can also mentor new InnerSource practitioners and provide knowledge transfer or coaching during the event.

The event could be held virtually or physically in different locations in the organization based on the cost and budget involved. A virtual event will have best ROI but it could depend on each organization.

The winners and participants should be recognized and acknowledged in a company-wide forum at the end of the hackathon. This is important as it keeps motivating them and more engineers to adopt and practice InnerSource going forward.

Such an event provides a safe space for the engineers who want to adopt or contribute to InnerSource but didn't have the time and motivation to do it or for those who kept deprioritizing due to high priority work deliverables. From middle management point of view, 1 or 2 days for such an event is not much of an ask and hence they are more likely to accept.

Resulting Context

  • There is increased adoption of InnerSource by providing such a safe platform to try and experiment combined with recognition and support by the senior leadership and middle management.
  • More InnerSource projects are published within the company.
  • The InnerSource projects receive more contributions.
  • Communities start to form around these InnerSource projects.
  • This happens not only during the event but continues after the event too, with the hackathon participants acting as InnerSource ambassadors in their teams.
  • It also helps ISPO and OSPO spread awareness about InnerSource best practices quickly, across the whole engineering community in the organization.
  • Such an event also gives more exposure to projects that were developed to solve the needs of a specific team but turns out that many teams have similar requirements.

All these help scale InnerSource in the organization.

Known Instances

  • IKEA (Ingka Group)

Status

  • Initial

Author

  • Shanmugapriya Manoharan