The world is in a state of constant and profound change. Companies now need to take new paths to overcome the challenges of the future. What role can open source play in this?
The developments of recent years clearly show: stability is no longer a constant – adaptability is becoming the decisive factor for success. In today’s VUCA world – an acronym standing for volatility, uncertainty, complexity and ambiguity – companies need new planning and management approaches. The past is no longer a reliable benchmark. We must find new ways of doing things. Technology can support us in this. The following applies: collaboration beats isolation. No one can do it alone anymore. Open source principles and practices offer a solution here, because they are based on openness, collaboration, and shared learning – concepts that are crucial in the VUCA world to remain flexible and innovative.
The term InnerSource emerged in the early 2000s. What does it mean?
InnerSource is the use of open source principles and practices to create proprietary code within a company. The term was coined by open source advocate Tim O’Reilly. However, at that time, corporate organisations were still highly sceptical of open source, as it was not yet considered a professional development approach. Over the years, it has become apparent that open source software is the bedrock of modern software stacks and that well-managed open source practices are incredibly effective for enabling large-scale distributed development projects. As a result, more and more organisations are exploring how they can leverage best practices from the open source community to also deliver better code internally.
So how did InnerSource develop?
A crucial turning point for InnerSource came around 2015. In that year, Danese Cooper was brought on board by the online payment service PayPal to prepare the company for the open source world. Ms Cooper is a pioneer of the open source movement and has played a key role at the US computer and software manufacturer Sun Microsystems in making proprietary software such as Java and Open Office available as open source. At PayPal, she found that the corporate culture there was not geared towards open collaboration and decided to employ the concept of InnerSource as a way to get all the PayPal development staff familiar with open source practices. She simultaneously founded InnerSource Commons as an open community for InnerSource practitioners. Since 2015, over 4000 individuals and 800 organisations have participated in the InnerSource Commons community to share learnings about how to employ open source practices within their organisation.
Why do organisations practice InnerSource?
Early InnerSource Commons members were often open source advocates and used Inner-Source as a way to build open source capacity within their organisations. However, in more recent years, InnerSource has grown in popularity simply as a way to encourage internal code reuse and efficiency and a better developer experience. You can think of InnerSource as bringing the benefits of working in the open source way to an even wider set of developers.
So InnerSource is not mandatory for companies that want to operate open source, but rather a bonus?
Yes, of course, many organisations successfully engage with open source without first investing in InnerSource. Communities like the Open Logistics Foundation actively support companies in developing open source software – technically, legally, and organisationally. However, where an organisation wishes to increase open source engagement within their organisation and is faced with cultural blockers, InnerSource can help developers practice open source methods on internal code before engaging with open source communities directly. I would describe InnerSource more as a strategically smart addition to fully exploit the benefits of open collaboration internally – or as a logical step to systematically embed open source practices within the company.
One of the biggest structural challenges for companies is still silo thinking …
… and overcoming organisational silos is in fact one of the main reasons for introducing InnerSource today. In many companies, development departments work in isolation – even when they are developing similar or even identical technologies in parallel. In large corporations, it is often the case that several dozen different versions of the same software arise side by side – each developed, funded, and maintained in a separate department. Successful InnerSource initiatives, therefore, start with small pilot projects between a core team and a few contributor teams. Objectives and processes are coordinated – similar to an open source project in the Open Logistics Foundation.
Can open source principles and practices really be implemented so easily within the complexity of a company?
There are certainly challenges at many levels: in management, among executives, and among employees. Some employees view it as a hurdle to engage with others, to understand or use a project, rather than seeing it as an opportunity for collaboration and learning. Some managers, in turn, feel attacked when it is suggested to use existing software. They interpret it as a criticism of their team’s competence – in what is sometimes referred to as “not invented here” syndrome. In some companies, the existing cost-centre logic even leads to efficiency not being rewarded at all.
What is needed to improve the situation or even change structures?
You have to create transparency – through clear agreements and an open culture. Reliable expectations and consistent practices prevent frustration on all sides. Using existing software within the company should be rewarded, not punished. Reuse is not a loss of competence, but a sign of maturity, efficiency, and strategic thinking. External training and internal events can help to anchor this perspective. Project marketing is also very important: the benefits of a project must be actively demonstrated through internal presentations or by sharing success stories. It also helps to build a small community around the project, i.e. to create spaces and opportunities for participants to exchange ideas.
Open Source vs. InnerSource
Open source stands for open, collaborative software development across organisational boundaries; InnerSource stands for the application of open source principles and practices to create proprietary code. The info box shows how the two approaches differ, what connects them, and what kind of cultural change they can initiate.
| Open Source | InnerSource | |
|---|---|---|
| Who? | Teams in a community | Teams within the company |
| How? | External cross-team collaboration | Internal cross-team collaboration |
| What? | Publicly accessible for everyone on the internet | Open and accessible within the company, or a subset of teams within the company |
| Why? | Shared development, promotion of standardisation and interoperability, new perspectives | Breaking down silos, reuse, knowledge sharing, efficiency, learning culture, open source readiness |
| What changes? | Visible externally, has internal impact – strengthens external image, employer brand, and trust | Has internal impact, radiates outward – promotes openness, responsibility, and collaboration |
Clare Dillon
is Vice President of InnerSource Commons, an international non-profit organisation that supports open collaboration in corporate software development, as well as Community Lead with CURIOSS, a network for employees in Open Source Program Offices (OSPOs) at universities and research institutions. She is also a member of the OSPO at Lero, a Science Foundation Ireland-funded software research centre, and conducts research on InnerSource topics at the University of Galway. As a member of the leadership team at Microsoft Ireland, she led the “Developer Experience and Evangelism” division for over eight years; prior to that, she spent over five years at Microsoft as a Developer Program Manager.
