How Philips used InnerSource to maintain its edge in innovation

Author: David Terol, SW CoE Program Director at Philips

In its 131-year history, Philips has been a hub of innovation in improving people’s lives. And as technology changes, Philips has had to reinvent itself and maintain its edge. In the past decades, Philips has gone from a manufacturer of healthcare devices to a full-fledged software and hardware organization. In this regard, maintaining its growing and diverse fleet of source code repositories has been one of Philips’ greatest challenges.

To overcome this barrier, Philips has embraced Open Source and InnerSource.

InnerSource, the use of open source best practices for software development inside organizations, is a well established industry trend. Since 2015, more than 500 organizations have already joined the InnerSource Commons community of practitioners to create and share knowledge.

Philips’ path to adopting InnerSource was rocky accompanied with initial failures and adjustmens. But the journey was exciting and filled with experience and learning. Achievements like GitHub endorsing Philips Open Source Terraform module for scalable self-hosted runners could not have happened without creating a strong and connected software community.

This is the story of the exciting process of failing fast, learning, and building based on experience. You can also watch the audiovisual version of this story presented at the Innersource Commons Summit 2021.

Addressing a fragmented environment

Before we started on InnerSource, our source code was scattered across different systems and technologies. Our first structured attempt at InnerSource was to build a tool that would bring existing fragmented source code repository systems together into a consolidated catalog that software employees at Philips could search, consume, and engage in their projects.

We spent time and effort creating processes and practices to enable our existing teams and businesses to share and contribute to their code through that catalog interface. We listened to the concerns of all the businesses and incorporated their feedback into these processes. We concluded that it didn’t scale up as expected. We had limited engagement and the culture change we hoped for was nowhere in sight.

We took a step back and realized that we were trying to add InnerSource to existing processes without changing the culture and the way people collaborate. Another problem was that we were trying to keep our existing tool stacks and tailor them to make InnerSource work, which also caused complications.

Example — Intrinsic friction

Here’s an example of how the initial InnerSource framework caused friction: Two teams working under different, siloed Git-based version control instances could not collaborate on their source code unless it was approved by the region manager and project admin. Even then, the what and how of the collab were unclear as guidelines like a standard CONTRIBUTING.md was missing.

In most cases, the developers gave up, and the best case, limited themselves to adhoc collaboration. We realized that our tools would play a key part in creating the culture change we were looking for.

InnerSource 2.0

Based on what we learned from the first rollout of our framework, we designed a second version of InnerSource based on four key principles:
• Modern infrastructure where self-service, automation, and cloud will play protagonist roles.
• Ways of working based on InnerSource principles such us transparency and low-friction interactions.
• Migration with dedicated resources and tools to support teams in their transition to the platform of choice for InnerSource in a way that avoids the frictions of the first version of InnerSource.
• A community vision where we want to evolve from the more rigid existing structures and dependencies, allowing teams to support the creation and growth of communities across the company to ensure knowledge sharing, reuse, zerowait culture…

Examples
Infrastructure — Automation and self-registration

We moved from a transaction-based system required to create a source code
repository — including review and approval by IT and department manager — to selfservice automated workflows. Repositories created in Philips InnerSource include the option to request terraform based auto-scaling cloud build runners which create ephemeral infrastructure that grows with demand. Tools like the following dashboard detect repeating peaks of
demand to increase number of available runners.

Ways of work — InnerSource as default

We declared InnerSource as new default collaboration model. That has helped to break up the inertia and move from open-as-exception to open-as-default. When developers create a new repository, they get actionable guidelines, such us the following questions, to identify required exceptions either to consider open source or restrict access.

Migration — Unified Source Code Inventory

We created a unified system that brings together code from different sources,
including InnerSource and legacy repositories. We added a dynamic system thatconstantly runs sanity checks on all assets in the inventory based on programmable rules such as existence of README.md and CONTRIBUTING.md files or Philips custom meta-data to improve findability of resources (for example domain or business info). It automatically scans the whole repository family and creates a list of non compliance issues.

Community — Connected network beyond organization

The Philips Software Center of Excellence hosts company-wide conferences. The last one, held in June 2021, had open collaboration as one of the main themes. We arranged keynotes, panel discussions and hands-on workshops such as:
1. My First InnerSource repo: we guided people to get their account, join the
InnerSource community, and create a repository including a basic build and test pipeline.

2. For those who were more advanced practitioners, we arranged a second
workshop focused on Advanced CI/CD techniques such as infra/build as code,
modularity, advanced quality gates, and auto-scaling.

The large awareness-building events and more focused workshop sessions helped create momentum for the InnerSource initiative and attracted hundreds of new developers to the community.

Results — Enterprise mindset

We started with the goal of improving code reuse and reducing friction and repetition. But we ended up with something bigger, which is open knowledge over a large community. InnerSource has resulted in a true culture change across Philips; helping to break silos and spark innovation beyond the more static traditional reporting structures. At Philips we call this the Enterprise mindset.

Curious about working in tech at Philips? Find out more here