What It Means to Define InnerSource
The Question #
People frequently ask me what the definition of InnerSource is. Now, what is InnerSource? I want to share some thoughts about InnerSource and what it means to me.
Let me be clear from the start: these are my personal opinions, not an official position. While I currently serve as President of the InnerSource Commons Foundation, InnerSource has been shaped by many pioneers whom I deeply respect. Their contributions have built what InnerSource is today.
The foundation of InnerSource comes from the interweaving of corporate practices, academic research, and of course, the evolution of open source itself. Given this rich tapestry, it would be presumptuous for me to claim to define InnerSource personally. Just because I currently serve as President doesn’t mean I have the authority or wisdom to create that definition alone.
Rather than providing a single definitive answer, I’d like to share different perspectives on this question, offering viewpoints that might help you discover your own definition and understanding of what InnerSource means for your context.
The Two Paths to InnerSource #
We’re at an interesting inflection point. Let me be more explicit about what I mean. There are essentially two types of people coming to InnerSource today:
The first group consists of those who have been practicing open source, found its collaborative methods powerful, and naturally applied these principles internally. For them, InnerSource was simply a name given to something they were already doing—bringing the excellence of open source collaboration into their organizations.
The second group discovered InnerSource as a named methodology. They may not have extensive open source backgrounds, but they recognize that InnerSource as an organizational methodology offers tremendous value for transformation. They’re adopting InnerSource not because they were open source practitioners, but because InnerSource itself promises organizational benefits.
This duality creates fascinating opportunities in our community. The first group intuitively understands what it means to implement InnerSource within an organization, as well as the value and culture of InnerSource and open source. Therefore, they may contemplate how InnerSource should be defined and think about it within the framework of open source. On the other hand, the second group doesn’t necessarily have involvement with open source, so they tend to seek clearer ideas about what it actually is.
Learning from DevOps: The Power of Naming #
To understand InnerSource’s definitional challenge, let’s look at DevOps. Here’s how I understand its evolution: practitioners at companies like Flickr were doing something innovative—breaking down silos between development and operations. When they shared their experiences and someone gave it a name—“DevOps”—something magical happened. Suddenly, companies everywhere realized they were doing similar things, and they all started sharing their stories.
The key insight is this: the practice existed before the name, but naming it created community. With that community came tools, shared concepts, conferences, and explosive growth. DevOps wasn’t invented; it was discovered and named. The naming catalyzed everything else.
InnerSource follows a remarkably similar pattern. Tim O’Reilly mentioned it in a blog post in 2000. In 2015, Danese Cooper and colleagues, then at PayPal, formalized the InnerSource Commons, later spinning it out as a foundation. But they didn’t invent the practice—they named something people were already doing.
This naming was magical. Suddenly, isolated practitioners realized they weren’t alone. “Oh, that thing we’re doing with our internal libraries? That’s InnerSource!” The community exploded with pattern sharing, leading to resources like InnerSource Patterns that capture collective wisdom.
What is DevOps Today? One Perspective Among Many #
People define DevOps in countless ways, and I can’t possibly cover them all. Here’s one example of how it might be understood:
- A culture of collaboration between traditionally separate teams
- A set of practices and automation tools
- A philosophy that opposes traditional waterfall development
- A collection of methodologies and frameworks
- Extensions into specialized areas: BizDevOps, DevSecOps, and beyond
This is just one interpretation. Ask ten practitioners, and you’ll get ten different emphases. This diversity isn’t weakness—it’s evolutionary strength.
The Multiple Meanings of “Internal Open Source” #
The phrase “internal open source” seems paradoxical, and this paradox reveals why InnerSource means different things to different organizations. Let me share some representative examples that emerged from our community discussions:
InnerSource as a Path to Open Source Maturity #
For some, InnerSource opens an organic path toward open source participation and digital transformation. It’s not just about preparing for eventual open source contribution—it’s about creating an environment where the organization can grow into a true software company. Companies like Microsoft and Google exemplify this journey, where internal practices naturally evolve to mirror external ones, creating seamless collaboration both inside and outside the company.
But what about manufacturing companies, retailers, or financial institutions? While they may use massive amounts of open source, their journey is different. For them, InnerSource might be the first step in a longer transformation—building software capabilities, fostering innovation culture, and perhaps eventually finding their own unique way to engage with open source that aligns with their business model.
InnerSource as Organizational Transparency #
Many are drawn to InnerSource for cultural transformation. It’s not just about sending pull requests—though that’s part of it. It’s about creating organic transparency where you can:
- Submit feature requests to other teams
- See what neighboring teams are building
- Understand the broader organizational technology landscape
- Break down silos that prevent collaboration
- Create a more open, breathable organizational culture where information flows naturally
This transparency transforms organizations from rigid hierarchies into living networks of collaboration.
Ultimately, these contribute to the happiness and well-being of engineers, product teams, and everyone involved within the organization. Feeling trusted in a supportive work environment—feeling trusted by default—is incredibly important. This relates to developer experience, and consequently leads to improved talent retention while also delivering positive results for recruitment.
InnerSource as Resource Optimization #
Traditional hierarchical project management adds margins at every level. Requirements flow down, each layer adding buffer time for uncertainty. By the time work reaches implementation, timelines are bloated and engineers are squeezed.
InnerSource inverts this. The people closest to problems understand them best. They can prioritize, discuss, and solve issues without cascading meetings and approvals. This isn’t always right—field teams only know their field—but when balanced with strategic oversight, it’s powerful.
But resource optimization goes beyond human and team resources. It’s also about leveraging the organization’s code assets, intellectual property, and competitive advantages. When teams can share and build upon each other’s tools, libraries, and knowledge, they create synergies that wouldn’t exist in siloed structures. That internal machine learning library your team built? Another team might extend it in ways you never imagined. The testing framework that gave you competitive advantage? Sharing it internally multiplies its value across the organization. InnerSource helps organizations realize that their code and knowledge assets are resources that grow more valuable when shared, not hoarded.
The Definition Dilemma: Context is Everything #
This challenge of multiple meanings isn’t unique to InnerSource. Consider how Open Source Program Office (OSPO) advocates promote open source internally. They absolutely use different messaging for different audiences because each activity needs buy-in from different stakeholders, and each layer of the organization has different interests and concerns.
For InnerSource advocacy, the messaging might look something like this:
To engineers: “Collaborate with brilliant colleagues, learn from the best code, contribute to exciting projects beyond your immediate team”
To middle management: “Reduce duplication, increase efficiency, accelerate delivery through reuse and collaboration”
To executives: “Reduce costs, increase innovation velocity and retain top talent”
The same InnerSource initiative serves all these goals simultaneously, but you emphasize different aspects to different audiences. This isn’t deception—it’s recognition that InnerSource, like any transformative methodology, delivers value at multiple levels.
Your InnerSource definition isn’t just audience-dependent—it’s phase-dependent. And that’s perfectly fine.
Your InnerSource Journey: An Evolving Definition #
So what is InnerSource? It’s what you define it to be.
Perhaps in the future, the InnerSource Commons Foundation will develop a clearer, more communicable definition that makes it immediately obvious what InnerSource is. Personally, I look forward to that day, though I recognize that creating such a definition amidst such diversity is an incredibly difficult task.
Moreover, your definition can and should evolve. The InnerSource that helps you start your journey might be different from the InnerSource you practice three years later. Your definition might shift as your organization matures, as your challenges change, as your understanding deepens.
You can bring your definition to the community, share your perspective, and help us all think through these questions together. This collective exploration is how we’ll eventually arrive at shared understanding—not through top-down decree, but through collaborative discovery.
A Call to Action #
Rather than seeking the perfect definition, I encourage you to experience InnerSource:
- Submit an issue describing a problem you see
- Send a pull request fixing documentation
- Request a feature from another team
- Share your code with colleagues
- Explore what other teams are building
- Collaborate across organizational boundaries
Through practice, you’ll discover what InnerSource means for your organization. You might even invent new patterns that the rest of us can learn from.
Join the Conversation #
In 2025, as AI transforms how we write and collaborate on code, InnerSource principles become even more relevant. How do we maintain quality when AI can generate thousands of lines instantly? How do we preserve knowledge sharing when code creation is automated? How do we ensure human judgment remains central to software development?
For this issue, please refer to the article that covers collaboration methodology in the AI era.
Well, these questions don’t have answers yet, but I believe the InnerSource —with its emphasis on openness, transparency, prioritized mentorship, and voluntary code contribution—is uniquely positioned to explore them.
InnerSource has many flavors. You can add your own. You can name patterns that exist but haven’t been articulated. This is why InnerSource is exciting: it’s a banner under which a community grows, evolves, and spreads innovation.
The InnerSource Commons Foundation welcomes these discussions. Our community members are exploring these questions daily, sharing experiences, and building the future of internal collaboration.
So I ask you: What’s your InnerSource? How will you define it for your organization? What patterns will you discover and share?
Let’s explore these questions together. The journey is just beginning. I look forward to welcoming you to the conversation at innersourcecommons.org.
