yukihattori.com

What It Means to Define InnerSource

hello@yukihattori.com (Yuki Hattori) — Mon, 25 Aug 2025 00:00:00 +0000

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.

InnerSource is a Lie - A Response to Common Misconceptions

hello@yukihattori.com (Yuki Hattori) — Mon, 18 Aug 2025 00:00:00 +0000

When you search for “InnerSource” on YouTube, one of the first results you’ll likely encounter is a video claiming that “InnerSource is a lie.”

(link: https://youtube.com/shorts/53jEP3mPP3E)

This viewpoint represents a typical pitfall that many people fall into when they first learn about InnerSource.

I want to use this video as a case study to explain what kind of misleading conclusions it promotes. This is a mistake I’ve made in the past as well, and it’s a trap that many people who haven’t deeply explored this field can easily fall into. That’s why I want to examine this with self-reflection and help others find the right path by unraveling these pitfalls.

Contents

The First Misconception: “Use React So Others Can Contribute”

Let me first unpack the argument in this case. The video suggests using React for internal applications “Use React because other people can contribute to it.” This kind of reasoning is rarely heard in actual InnerSource discussions.

should you use react HTMX or solid or something for your company’s internal application now a lot of people what you’re going to hear is use react so other people can contribute to this

This argument can be dissected into three key issues:

Fundamental misunderstanding of what InnerSource actually means
Choosing the wrong domain for InnerSource application
Confusing individual versus team perspectives

What InnerSource Actually Means

InnerSource is about practicing open source principles within a company. It’s not just about “contributing” or “receiving contributions.”

Most people who interact with open source are simply “users.” Some are just consumers, others file bug reports, and only a small fraction actually submit pull requests. InnerSource applies open source learnings internally to create organizations that are open, broadly accessible, with transparent decision-making, and team relationships built on trust through ownership and mentorship. This creates a culture of transparency and collaboration.

This is what “practicing open source internally” means - it’s not just about “receiving pull requests.” Pull requests are merely one result of this culture, not the primary goal.

A Less Optimal Domain for InnerSource Application

The second issue is that this argument unfolds in a domain where InnerSource and open source face particular challenges.

If you want to “receive pull requests” or “have many people use your code to improve quality,” that might be limited by the nature of your product. It’s clear that sharing “high-dependency components” or platform-level tools would create more value than end-user applications. While stream-aligned teams should still adopt open source practices when beneficial, the collaboration dynamics differ significantly.

In my experience working with enterprise companies, using InnerSource for project-level initiatives where the end users are “non-engineers” presents unique challenges. Why? Because ultimately, these products need to serve the needs of “end users” or “business users” who may lack development skills and direct communication channels with development teams. This creates complex, individualized requirements and longer communication lead times.

InnerSource implementations tend to work relatively well when applied to shared libraries, platform components, development tools, and infrastructure code—areas where the “users” are primarily other developers who can meaningfully contribute to and benefit from collaborative development practices.

While applying InnerSource practices to user-facing applications can bring valuable benefits like transparency and improved issue tracking (which alone makes it worthwhile).

Individual vs. Team Perspective

The third issue concerns whether “you” refers to an individual or a team.

It’s important to note that InnerSource isn’t necessarily about waiting for someone to contribute to “your personal project” within a company. When InnerSource is applied, there might be cases where people contribute to projects developed during 20% time, like big tech firms, but that’s not necessarily the mainstream approach.

InnerSource is primarily introduced and maintained because it generates ROI through cost reduction, avoiding reinventing the wheel, creating synergies, quality assurance, and removing communication overhead from hierarchical decision-making. This typically involves shared internal libraries, proprietary competitive advantage components, or things with high dependencies that are niche within the enterprise. And these “business benefits” typically flow back to “team operations” in most cases. Ultimately, it’s all about ROI for teams and organizations. If we don’t think about teams, someone will stop you from contributing to projects. You need to justify your ROI whether it’s short-term or long-term.

What’s unique about InnerSource is that it’s fundamentally about team-to-team collaboration. This is where most implementations ultimately end up. It’s not necessarily individuals randomly contributing to convenient personal projects. It’s typically implemented through host team and guest team relationships, where guest teams ride along with parts maintained by host teams. Most enterprises have employees with defined roles and responsibilities, and collaboration tends to happen within these structures.

Therefore, InnerSource is particularly effective when relationships between platform teams and stream-aligned teams (guest teams and host teams) are established. Active co-creation between stream-aligned teams or individuals are more uncertain to succeed naturally.

Criticizing all of InnerSource based on scenarios that are unlikely to work makes no logical sense.

The Second Misconception: “It Never Happens in Real Companies”

because we want people doing that the reality is that’s not what’s going to happen ever at any company ever inner source

Actually, this is happening. Case studies prove it. Period.

The Third Misconception: “99.69% of InnerSource Projects Will Fail”

99.69% a lie you’re going to build the entire project by yourself when it goes down people are going to look to you

This might be correct depending on how you define “InnerSource.” As mentioned earlier, InnerSource is not about “receiving PR contributions.”

However, there are three important points to consider:

InnerSource especially applies to strategic components - it’s not required for all components
Benefits extend beyond active contributions
Open source has the same “failure rate” issue

InnerSource is a Corporate Strategy

When people think about InnerSource, they sometimes imagine radical ideas like “sharing all code within the enterprise” or “everyone contributing to everything.” They might envision hundreds of shared repositories within a company with everyone actively exchanging contributions. Like open source being a strategy for companies, InnerSource is also a corporate strategy with priorities. Companies share “what’s worth sharing” first.

Therefore, the actual number of codebases where code actively flows between teams and vibrant cross-team collaboration occurs is relatively small. This might indeed be single-digit percentages. However, even without active cross-team collaboration, many projects can benefit from being open and transparent. In this sense of InnerSource, enterprises can often share value across many more cases.

While InnerSource includes individual contributions, it is primarily focused on team-to-team collaboration. Therefore, what gets shared through InnerSource tends to be relatively niche within enterprises, or purpose-specific items like forked Linux distributions for particular needs. Or it might simply be open source-like development culture, as when GitHub shares Ruby on Rails code across all employees.

When we condition this percentage discussion on InnerSource that actively collaborates and gets maintained as common requirements, the percentage may indeed be relatively low. However, small collaborations like documentation pull requests or minor configuration changes (sending small patches) between guest teams and platform/host teams happen relatively frequently. When you include these micro-collaborations and transparency benefits that prevent duplicate efforts, these numbers increase significantly.

Open Source Has the Same “Problem”

On the other hand, if we define it that way, open source would also be a “lie.” Because “99.69% of open source projects will fail.” Most code published as open source doesn’t receive contributions. But nobody says “open source is a lie” because of that. People pursue open source because there are benefits beyond receiving contributions.

Again, “being contributed to” isn’t the only value of InnerSource. And the same holds true for open source value as well

The Real Benefits of Transparency

Keeping internal code open rather than hidden - at GitHub, architects or solution engineers on the revenue team might be able to examine source code to find relevant information, potentially finding details very close to customer requests, facilitating smoother support conversations, and extracting more accurate information from issues. I live in Tokyo, and sometimes it’s faster to just look at Ruby code to check the implementation, or go to issues to check the background of the changes, rather than waiting for the SF-based product team to wake up to ask implementation questions about the changes and their background. Using the git blame command, you can identify the “real” stakeholders of the code and ask questions about the background of decisions. Needless to say, the same applies to other development teams. Having information readily available about components that might create dependencies clearly reduces communication overhead.

InnerSource is about practicing open source principles internally. InnerSource isn’t just about sending pull requests back and forth - it’s about ensuring transparency and gaining benefits through open source-style collaboration. These benefits extend far beyond the few percent of actively maintained repositories to broader cultural implementation benefits.

The Fourth Misconception: “You’ll Get Called Back When You Leave”

“when you leave the company they’re going to send you a message 6 months later asking you questions or seeing if you would like to contract with them to upgrade your application there is no such thing as innersourcing”

Resources sometimes go unmaintained, but this isn’t an appropriate criticism of InnerSource itself - it’s criticism of failing to implement InnerSource properly. This isn’t criticism of InnerSource, but criticism of lacking maintenance culture where nobody maintains the code. This results from failing to implement InnerSource properly or not considering it at all - the result of lacking ownership.

The DevOps Analogy

This is criticism of failing to do InnerSource, not criticism of InnerSource itself. Sometimes this confuses the logic. To put this in DevOps terms: it’s like saying “companies end up adopting slow review cycles of several months or audits, or adding processes for release decisions, so releases become quarterly or only twice a year. Therefore DevOps, which claims to enable fast releases, is no good.” That’s not because the DevOps methodology is bad, but simply because “there were cases where DevOps couldn’t be implemented.”

Breaking business processes is extremely difficult, and many companies said DevOps was impossible. But even when people thought it was impossible, there were courageous pioneers who worked hard to change the culture and achieved DevOps. The same can happen with InnerSource.

The Fifth Misconception: “You Must Own Everything 100%”

you own it 100% (which implies: InnerSource where you don’t own 100% is impossible)

“InnerSource means abandoning code ownership” is wrong. InnerSource actually requires teams to own code. This is a common mistake. This is like people who want to abandon maintenance responsibility and say “let’s make it open source.” That doesn’t work.

Individual vs. Team Ownership - Is InnerSource Strong Code Ownership?

First, is this “You” individual or plural? Though individuals might be listed as CODEOWNERS file in organizations, teams ultimately hold responsibility for code. Contextually, it’s likely talking about Strong Code Ownership. But this isn’t good when considering organizational maintenance. Because employees might quit.

InnerSource is not Strong Code Ownership. At minimum, multiple people need to share responsibility. Having said that, I acknowledge that Strong Code Ownership may emerge in the short term, and in the early stages of a project, strong individual will might naturally lead to such arrangements, but if you want to achieve long-term success, it’s necessary to delegate authority so that the organization can handle maintenance collectively.

Types of Team Ownership - Is InnerSource Collective Code Ownership?

This kind of argument might sometimes refer to Collective Ownership. In this case, the argument also seems to suggest that InnerSource means collective ownership, but that’s actually different. InnerSource is not Collective Code Ownership InnerSource involves host teams ultimately handling maintenance. InnerSource is Weak Code Ownership. So while maintenance responsibility is 100% correct, saying “you must own 100% and InnerSource is different” is completely illogical. This is actually an incorrect opinion.

As Martin Fowler famously argued about code ownership, having everyone own code 100% (collective ownership) sometimes creates situations where nobody takes responsibility. That’s very problematic - responsibility becomes unclear and projects ultimately fail.

Weak Code Ownership Model

In Weak Code Ownership, maintainers exist, host teams maintain projects, and specific parts might bring in trusted committers/maintainers from other teams. Someone might contribute, someone might maintain, but not 100% by “you” or “your team” - it might be quite different. For example, 98% of code might be owned by your team, while 2% might be owned by other teams.

In this case, remember that even if individuals are assigned as code owners in organizations, teams ultimately hold responsibility for code. Teams should own it, and don’t forget this important point.

The Sixth Misconception: “Someone Will Drop 7000 Lines on You”

Every now and then there will be a sufficiently motivated coworker who’s really great and do like a 7,000 line update no explanation but don’t ever fall into this idea that choosing anything for an internal app that you are going to be working on

Having 7000-line pull requests suddenly appear is itself a failure to introduce InnerSource culture - it’s not something that happens by doing InnerSource. This case might worry that introducing InnerSource makes such collaboration happen, but that’s completely wrong.

The Real Problem

This argument represents failing to implement InnerSource culture and collaborative practices, not InnerSource itself. 7000-line implementations are very limited cases. This represents failure of collaboration culture where 7000 lines get submitted as pull requests suddenly without any notification - the organization should fix this fundamental culture problem, which is pre-InnerSource.

If you want to prevent this, there’s a solution. Foster InnerSource culture within your organization:)

The Reality: What InnerSource Actually Is

InnerSource is cultural implementation - using open source collaboration practices to enjoy various benefits that open source receives through collaboration. InnerSource’s ultimate purpose isn’t just receiving contributions (pull requests), but includes feature requests through issues, support coordination, and various other benefits, plus transparency in decision-making and practical cultural promotion.

Therefore, I definitively reject the claim that “implementing InnerSource best practices to get pull requests is a lie.”

Understanding Contribution Reality

“Nobody ever is going to contribute”

In open source collaboration, contributors are indeed a tiny fraction. Out of 1000 users, maybe vast majority are just users, 20 might submit issues or feature requests, 5 might send pull requests, and maybe only one becomes a maintainer.

Again, InnerSource best practices won’t make all 1000 people contribute. InnerSource helps induce such collaboration, but ultimately aims to break down enterprise silos, improve collaboration that’s hindered by traditional organizational constraints, reduce lead times from information silos, and optimize organizational resource allocation using open source practices.

Conclusion

While the arguments in this case touch on some real challenges, they’re based on common misunderstandings that many people encounter when first learning about InnerSource. These are well-known pitfalls in the community, and it’s understandable how someone might reach these conclusions without deeper exploration of the field.

The key insight is that InnerSource isn’t about forcing open source practices into a rigid framework. Instead, it’s about returning to the fundamental question: what can we learn from open source? By examining open source through a broader lens, we can better adapt these principles internally.

You can join this conversation and bring fresh perspectives. Whether you want to build on this discussion, explore more specific implementation details, or even challenge these arguments entirely - all approaches are welcome. What matters most is maintaining that broad perspective on open source learnings and how they translate to internal organizational contexts.

For comprehensive information about InnerSource, I recommend checking out the InnerSource Commons Foundation. They welcome diverse viewpoints and ongoing dialogue about how open source principles can create value within organizations.

Platform Engineering and InnerSource: Building Developer Communities at Scale

hello@yukihattori.com (Yuki Hattori) — Mon, 11 Aug 2025 00:00:00 +0000

The Backstage Moment: When the Real Work Begins

Your organization has done it. You’ve successfully implemented Backstage. You’ve given conference talks about your platform engineering transformation. You’ve shown how your developer portal provides visibility into everything across your engineering organization. You’ve ticked all the boxes.

But here’s the uncomfortable truth: implementing Backstage doesn’t mean you’ve “done” platform engineering—it means you’ve finally reached the starting line.

Platform engineering isn’t equal to Backstage, just as it isn’t equal to any specific tool or solution. Everyone knows this intellectually, yet organizations consistently fall into the same trap: they focus on the technology and forget the culture.

Contents

The Recurring Failure Pattern of Shared Platforms

Before we dive into what platform engineering actually requires, let’s acknowledge the elephant in the room: most shared platforms and common libraries have historically failed. This isn’t a secret—it’s a well-documented pattern that platform engineering is supposed to solve.

But why do they fail? The answer always follows one of two predictable patterns:

Pattern 1: The Service Desk Trap Your platform team becomes a service desk, drowning in feature requests, common requirements, and dependency management from every team in the organization. Conflicting requirements pour in, forcing you to either become a custom development shop for every use case or watch your platform fork into unmaintainable branches. Long-term maintenance cycles compound the problem—you’re not just building features, you’re maintaining a zoo of custom implementations that grow more complex over time.

Pattern 2: The Ivory Tower When the flood of requests becomes overwhelming, platform teams start saying “no.” They reject user requirements, refuse to accommodate edge cases, and insist that teams use the platform as-is. The result? Teams build their own solutions. The shared platform becomes irrelevant. Game over.

These failures aren’t structural—they’re cultural. Having fancy portals and sophisticated tooling doesn’t solve the fundamental problem: how do you create collaborative, sustainable relationships between platform providers and platform consumers?

The Missing Cultural Implementation

Think about your current GitHub setup. It probably serves as your organization’s default “portal”—a single place where you can discover repositories, collaborate through issues, and access documentation. When you had 100 repositories, you didn’t need Backstage. GitHub was enough. But as you scaled to thousands of repositories, you needed that additional layer of organization and discovery.

The same principle applies to platform engineering. The infrastructure and tooling are just the foundation. What you’re really building is a developer community—and communities require intentional cultural practices, not just better tools.

This is where platform engineering intersects powerfully with Infrastructure as Code principles. Platform engineering involves template generation, standardized deployments, and automated provisioning—all concepts that align with treating infrastructure as software. But unlike traditional IaC, platform engineering must also address the human elements: how do developers discover what’s available? How do they request changes? How do they contribute improvements?

Learning from Cloud Vendors: The Developer Community Playbook

Here’s a perspective shift that changes everything: as a platform team, you’re essentially running an internal cloud vendor. You’re taking the complexity of AWS, Azure, and GCP—with their hundreds or thousands of services—and distilling them into a simplified, enterprise-grade platform that your developers can easily deploy.

And how do cloud vendors communicate with developers? Through GitHub. Through documentation repositories. Through GitHub Discussions. Through open source components and transparent issue tracking. Through threaded conversations that are preserved and searchable. Through voting mechanisms where community feedback drives product decisions.

I’ve seen this firsthand during my time as a cloud architect at Microsoft. Ultimately, customer voice drives everything. Product teams desperately want to understand user pain points, validate whether issues affect many users, and measure business impact. Sometimes this involves manual information gathering and customer nomination processes, but increasingly, it resembles the open forum model where large numbers of users vote on features and product teams engage directly in public discussions.

This isn’t coincidental—it’s the proven model for developer-focused products at scale.

InnerSource: The Cultural Bridge

InnerSource provides the missing cultural framework for platform engineering success. It’s not about opening up all your internal code or expecting magical contributions from your organization. It’s about gradually transforming toward a more open, transparent, collaborative environment.

InnerSource enables the collaborative culture that platform engineering requires. It makes pull requests and transparent discussions the norm rather than the exception. Most importantly, it creates an environment where engineers can flourish as both contributors and consumers.

Here’s why this matters for platform teams: your customers are internal developers—engineers who speak the language of code, understand GitHub workflows, and can contribute meaningfully to platform development. The methodologies for communicating with internal developer communities are fundamentally different from Agile approaches designed for end-user products.

Your platform users communicate through source code management systems. They’re technical. They can contribute code, documentation, and meaningful improvements. InnerSource provides the proven patterns for harnessing this capability.

Team Topologies and Collaboration Patterns

Team Topologies, the bestselling book that everyone references when discussing platform engineering, outlines various collaboration patterns between teams. But here’s a crucial insight: not all team types benefit equally from InnerSource approaches.

Platform Teams and InnerSource: A Perfect Match Platform teams have the highest dependency relationships in most organizations. When one library is used by 100 people, collaborative development benefits all 100 users. It prevents reinvention, reduces review burden, and creates economies of scale. This high-dependency, high-reuse pattern makes InnerSource incredibly valuable for platform teams.

Stream-Aligned Teams: Less Natural Fit Stream-aligned teams, by design, have completely separate domain knowledge and minimal cross-team dependencies. Collaboration between stream-aligned teams is naturally limited because they’re optimized for independence. When dependencies exist, they’re more likely to be consumer-provider relationships rather than collaborative development relationships.

This distinction matters. Platform teams naturally benefit from InnerSource because they mirror the dynamics of successful open source projects: high reuse, diverse contributors, and shared maintenance benefits.

The AI Era: Amplifying Platform Engineering Through Better Information Architecture

As we enter the AI era, platform engineering becomes even more critical—and InnerSource principles become even more valuable. Here’s why:

AI-Assisted Platform Development Instead of having humans immediately respond to user issues, platforms can assign initial triage and solution attempts to AI systems. But this requires information architecture that AI can understand: consolidated information in GitHub repositories, clear documentation, comprehensive issue histories, and standardized templates.

The ideal user journey becomes: discover platform capabilities through your portal → encounter an issue → create a GitHub issue → platform team assigns the issue to AI for initial analysis → human review and implementation. This flow only works when all relevant information—documentation, conversation history, related tickets—lives in AI-accessible formats.

The Information Consolidation Challenge I understand the constraints. Not everyone has GitHub Enterprise licenses. Source code might be hosted on internal blogs or AWS CodeCommit. Related documentation might live in Google Docs. Various communication channels might be scattered across Slack, Discord, and other platforms.

But here’s the critical insight: every workaround you implement to accommodate these constraints increases your platform team’s operational burden. Multiple communication channels create fragmented conversations. Distributed information reduces traceability. Inconsistent workflows lead to duplication and confusion.

While AI doesn’t fundamentally change what platform teams need to do, it makes the quality of your information architecture more critical than ever. AI can significantly reduce the effort required to solve common platform issues—but only if you’ve structured your information for AI consumption.

Practical Implementation: The Four Principles of InnerSource for Platform Teams

1. Openness: Making Projects Discoverable and Contributable

Your platform components need to be more than just available—they need to be accessible for contribution. Simply registering repositories in Backstage isn’t enough. Each repository needs clear documentation about who maintains it, how to contribute, where to report bugs, and how to request features.

Without this transparency, teams can’t engage meaningfully with your platform components. They become consumers rather than collaborators, recreating the unsustainable service desk dynamic.

2. Transparency: Visible Decision-Making

Transparency means documenting not just what your platform provides, but why design decisions were made. When you provide a GitHub Actions template or a deployment pipeline, users need to understand the reasoning behind its design, whether it’s appropriate for their use case, and whether they should contribute improvements or create customized versions.

Closed decision-making leads to uninformed forking, duplicate solutions, and chaos in your platform ecosystem.

3. Prioritized Mentorship: Developer Onboarding at Scale

Platform teams serve developer communities. Your “customers” need onboarding processes, contribution guidelines, and clear paths for engagement. This isn’t about managing external contributors—it’s about creating sustainable ways for internal teams to engage with and improve your platform.

4. Voluntary Code Contribution: Community-Driven Platform Evolution

The goal isn’t for platform teams to handle every request. It’s to create conditions where users can contribute improvements back to the platform. This requires cultural change: platform components need to be designed for external contribution, not just consumption.

These four principles form the foundation of successful InnerSource implementations.

Beyond Tools: Creating Sustainable Developer Communities

Using GitHub doesn’t automatically create InnerSource. Sharing code doesn’t automatically create community. What matters is bidirectional contribution and collaborative culture.

Platform engineering without community becomes just another way of providing solutions to developers rather than building with them. The most successful platform teams create ecosystems where:

Users contribute templates and tools back to the platform
Feature requests become collaborative development opportunities
Knowledge sharing happens naturally through transparent processes
Platform evolution is driven by actual user needs, not platform team assumptions

Companies like Netflix and Spotify have demonstrated how platform teams can build thriving developer communities around their platforms.

The Path Forward: Starting Small, Building Community

You don’t need to transform your entire organization overnight. Start with one platform component. Make it truly open for contribution. Document not just how to use it, but how to improve it. Create clear paths for user feedback and contribution.

Build your core fan base—the developers who become genuine advocates for your platform approach. Enable them to contribute meaningfully to platform evolution.

Platform engineering at scale isn’t about building better tools—it’s about building better communities around those tools. InnerSource provides the proven patterns for creating these communities within enterprise constraints.

The most successful platform teams understand that they’re not just infrastructure providers—they’re community builders, facilitating collaboration between developers who share common needs and can contribute to common solutions.

Your platform engineering journey doesn’t end when you deploy Backstage. It begins when you start building the collaborative culture that will sustain and evolve your platform over time.

Do It in Open Source Way - The Role and Potential of InnerSource in the AI Era

hello@yukihattori.com (Yuki Hattori) — Mon, 04 Aug 2025 00:00:00 +0000

The Question That Haunts Modern Organizations

While countless developers debate the merits of prompt engineering and context engineering, while influencers demonstrate their latest AI coding tricks, and while startups pivot toward AI-first development, a glaring gap persists in the discourse. We’re drowning in discussions about individual productivity and small-team tactics, yet we’re starving for guidance on how large, established organizations should navigate the AI transformation.

This isn’t just a big enterprise problem. Even small startups with powerful 10-person AI teams will eventually handle massive codebases and scale into large systems overnight. The fundamental question becomes: how do organizations prepare their source code and collaboration practices to work seamlessly with AI at speed without breaking down?

This isn’t another article about how to write better prompts or optimize your copilot experience. This is about the organizational DNA that will determine whether your company thrives or merely survives in the AI era.

Contents

TL;DR: Five Critical Organizational Challenges

AI-powered development faces five critical organizational challenges that the Open Source Way can address:

The Standardization Dilemma: Organizations want AI to understand their proprietary methods, but AI excels at open standards rather than proprietary ones. The key is recognizing that AI has learned extensively from open, standardized practices.
Quality Assurance Bottleneck: AI generates massive amounts of duplicate code, and humans can’t review it all. Instead of letting AI reinvent the wheel repeatedly, organizations need to prevent duplication by sharing quality-assured code internally and avoiding endless review cycles.
Information Silo Problem: As AI becomes more autonomous, organizations want it to access broader organizational knowledge, but siloed information creates multi-layered access problems. Transparent, non-siloed organizations enable AI to access the information it needs without bureaucratic bottlenecks.
Document Format Chaos: AI struggles with PowerPoint, Excel, and proprietary formats. Open source collaboration naturally gravitates toward Markdown-based documentation and issue-based collaboration—formats that AI can easily parse and understand.
Missing Context Crisis: People give AI snapshot information without the crucial context of “why” decisions were made. Open source culture naturally documents decision-making processes, creating the contextual understanding AI needs to make appropriate suggestions.

Think of AI as a context-free genius engineer who suddenly joined your organization—like an open source contributor who arrived without any background knowledge of your systems, processes, or history. We need to provide organizational mentorship to AI, but this can’t be an individual effort—it requires systematic, organization-wide support that helps AI understand not just what we do, but how and why we do it.

Implementing this Open Source Way within organizations is what we call InnerSource. Open source practices encourage transparent collaboration, shared standards, and community-driven improvement. Open source methodology helps teams naturally gravitate toward practices that AI understands while preserving the institutional knowledge that makes your organization unique. Open source approaches develop strategies for gradually aligning organizations with “AI-known standard methods” while building the organizational resources and individual capabilities needed for this transition. It’s not about forcing change—it’s about creating conditions where change feels natural and beneficial.

1. “Our Way” vs “Standard Way”

Picture this: Your organization has spent years perfecting its code review process, documentation standards, and testing methodologies. They’re not just practices—they’re part of your organizational identity. Then AI arrives, and suddenly it doesn’t understand your carefully crafted conventions. It generates code that follows PEP8-ish style, not your custom Python style guide. It writes tests in Jest patterns, not your proprietary testing framework.

Of course, you could teach AI your specific ways, but it’s obviously easier to leverage the zero-shot knowledge it already possesses. That’s why most people end up gravitating toward Bootstrap, Tailwind, and other well-established patterns—because it’s simply more efficient.

The Uncomfortable Truth

AI doesn’t know your proprietary information. It wasn’t trained on your internal coding standards, your custom frameworks, or your unique architectural decisions. It speaks the language of open source—the common tongue of developers worldwide that has been extensively documented and shared.

This creates an immediate friction point. Organizations invested heavily in their “special way” of doing things, often for good reasons. Maybe your coding standards emerged from painful debugging sessions. Perhaps your documentation format evolved to meet specific compliance requirements. These aren’t arbitrary choices—they’re institutional wisdom crystallized into process.

The Short-Term Solution: Embrace Standards

The pragmatic answer, at least for now, is standardization. Adopt PEP8 for Python. Use conventional commit messages. Follow established testing patterns. Structure your documentation in formats that AI can parse and understand.

This isn’t capitulation—it’s pragmatism. When AI generates code that aligns with your standards, the friction disappears. As context windows expand dramatically, you’ll eventually be able to dump all your source code and proprietary information into the context anyway. Code reviews become smoother. Integration becomes seamless. Your developers spend less time fighting with AI-generated code and more time leveraging its capabilities.

The Long-Term Reality: AI Will Learn Your Way

But here’s the nuance that most discussions miss: this is likely a temporary problem. AI systems are rapidly improving at understanding context and proprietary information. Fine-tuning, improved in-context learning, and longer context windows will eventually allow AI to absorb your organizational quirks.

The question becomes: Is it worth the organizational upheaval to solve a problem that may resolve itself?

InnerSource as the Bridge

This is where InnerSource becomes invaluable. InnerSource doesn’t demand that you abandon your organizational identity overnight. Instead, it provides a framework for gradual transition—helping your Red Riding Hood find a path that’s both safe and efficient.

InnerSource isn’t about writing code for yourself—it’s about writing for your team, for the broader organization, for neighboring teams, and for teams one or two hops away. It means writing code that everyone can read easily, whether they’re new junior engineers or experienced, seasoned professionals. This philosophy extends beyond just code to in-code documentation and architectural decisions.

InnerSource encourages the adoption of open source practices within your organization: transparent collaboration, shared standards, and community-driven improvement. It helps teams naturally gravitate toward practices that AI understands while preserving the institutional knowledge that makes your organization unique.

The methodology develops strategies for gradually aligning organizations with “AI-known standard methods” while building the organizational resources and individual capabilities needed for this transition. It’s not about forcing change—it’s about creating conditions where change feels natural and beneficial.

2. The Quality Assurance Bottleneck: When AI Outpaces Human Review

This isn’t really a secret—everyone is struggling with this inconvenient truth. AI capabilities keep expanding exponentially, but human cognitive abilities remain relatively static. While AI can certainly assist with code comprehension and make reviews more efficient, there are fundamental limits to human processing capacity that we can’t engineer away.

AI can generate a thousand lines of code in seconds. A skilled developer might review a few hundreds lines in an hour. The math doesn’t work, and it’s getting worse as AI capabilities improve.

The Reviewing Problem Is Hard to Scale

Writing tests can certainly improve this situation significantly, and the consensus from many organizations is that tests have become more critical than ever—they serve as essential guardrails in an AI-assisted development world. Even if AI generates test code alongside implementation code, someone still needs to review those tests. Even if AI explains its reasoning, someone needs to verify that reasoning. The fundamental constraint remains: human cognitive bandwidth.

Traditional quality assurance assumes scarcity—that code is expensive to write and therefore worth careful review. But when code becomes cheap to generate, our quality models break down completely.

The key insight is preventing AI from reinventing the wheel repeatedly. Instead of letting every AI solve the same problems and generate similar code, create repositories of reviewed, tested, and approved code components that teams can reuse.

When you have many shareable parts like in open source and InnerSource environments, something interesting happens: various people end up using those tools and code components. Quality gets assured through collective usage—many eyes end up examining that code, finding issues, and improving it over time.

This approach requires a fundamental shift in mindset. Code becomes less about individual ownership and more about collective resource management. However, this means implementing weak code ownership rather than collective code ownership—because when everyone owns something, no one truly owns it. This implies we also need a culture of properly maintaining source code.

But here’s the good news: AI can now handle much of source code maintenance. The real question is how organizations will own and steward such shared code repositories.

Teams need to think beyond their immediate needs and consider how their solutions might benefit others across the organization.

InnerSource provides the cultural foundation for this transformation. It encourages developers to think like open source maintainers—not just writing code for their immediate needs, but creating solutions that others can understand, modify, and improve.

This isn’t just about code libraries. It’s about creating frameworks for identifying which code deserves quality assurance investment, processes for maintaining shared repositories, and cultural practices that encourage contribution and reuse.

The methodology addresses the balance between automation and human oversight, helping organizations develop sustainable practices for AI-generated code integration while maintaining quality standards.

3. The Information Silo Problem: AI’s Knowledge Hunger

Organizations dream of AI that knows everything—an artificial employee with access to all departmental knowledge, capable of exceptional cross-functional work. But this dream crashes against the reality of information silos.

The Multi-Layered Access Challenge

Consider your organization as a Venn diagram. Department X has access to certain information, Department Y to different information, Department Z to yet another set. The intersection—information accessible to all departments—is often surprisingly small.

When you try to create “organizational AI,” you hit this limitation immediately. Current RAG implementations optimize information per department, but they struggle with search accuracy and cross-departmental context. Each department gets its own AI assistant, but none of them can truly understand the organization as a whole.

You might think this isn’t a big deal because the projects you want AI to reference might fit within one circle of a Venn diagram. But this isn’t just about source code access—it’s a multi-layered, multi-stage problem that goes much deeper.

Your organization might use Notion for some projects, Office 365 for others. Some teams use GitHub, others use GitLab. There are differences between people who have licenses and those who don’t. When these different systems need to collaborate, problems multiply. Even when employees work on the same project, their access levels to information might differ dramatically based on their role, seniority, or department.

In the short term, AI will likely remain personal—individuals will handle their own AI interactions. In such cases, lack of access to organizational information, or the lead time required to get permissions to access organizational information, becomes a critical bottleneck that limits AI effectiveness.

The Power of Information Overlap

The solution isn’t giving AI access to more information—it’s increasing the overlap in the Venn diagram. The larger the intersection of shared information between departments, the more powerful your organizational AI becomes.

This requires cultural transformation. Organizational members might keep much information in their personal Google Drives or local storage. Without proper rules and cultural shifts, employees, engineers, and product owners will naturally default to keeping information in their personal possession rather than making it organizationally accessible.

Employees need to shift from hoarding information to sharing it. Departments need to move from protecting their knowledge to contributing to organizational intelligence.

Security and Access Considerations

This doesn’t mean removing all access controls or creating security vulnerabilities. It means thoughtfully expanding access to information that can safely be shared while maintaining appropriate boundaries for sensitive data.

The challenge is cultural as much as technical. AI can only handle formalized information—it cannot access tacit knowledge or information that individuals hoard. Therefore, enabling open, transparent collaboration becomes extremely important.

However, showing your thoughts, resources, unfinished work, and documents you’re not confident about to many people creates significant barriers, including psychological ones. That’s why training that makes such practices feel natural and safe is essential.

Information sharing requires trust, and trust requires time to build. Organizations need frameworks for gradually expanding information access while maintaining security and privacy requirements.

InnerSource Breaks Down Barriers

InnerSource excels at breaking down information silos because it’s fundamentally about creating open, collaborative environments within organizations. It provides proven practices for knowledge sharing, contribution management, and community building.

The methodology helps organizations develop trust and security models for broader information access while creating cultural transformation programs that encourage open information sharing. It addresses the reality that information access changes can’t be implemented overnight and requires sustained cultural adoption.

4. Document Format Chaos: The Markdown Revolution

Your organization has decades of institutional knowledge locked in PowerPoint presentations, Excel spreadsheets, complex Word documents, JIRA tickets, Confluence pages, and Notion databases. You want to feed all of this to AI, but here’s the problem: format diversity creates accuracy nightmares.

The AI Accessibility Challenge

To AI, a PowerPoint file is just XML and image files. It lacks semantic understanding of your carefully crafted slides. Excel spreadsheets become data soup without context. Complex documents lose their structure and meaning when processed by current AI systems.

Image processing accuracy still has significant room for improvement, and platform walls create additional barriers. Your knowledge is scattered across multiple systems with different APIs, search capabilities, and access controls.

The Radical Solution: Markdown and GitHub Centralization

The answer sounds almost absurdly simple: write everything in Markdown and centralize everything in GitHub (or similar version-controlled platforms).

This recommendation might trigger immediate resistance. What about rich formatting? What about complex visualizations? What about our existing workflows?

But consider the benefits: fewer locations for AI to access, semantic structure that AI can understand, built-in version control and collaboration features, linkable and searchable content, and maintainable documentation over time.

The Migration Challenge and Gradual Approach

Moving from rich documents to Markdown represents a significant migration effort and cultural shift that essentially asks organizations to update processes and long-cultivated information repositories in favor of simpler documentation formats. This challenge parallels the difficulty organizations face when trying to transition from traditional project management approaches (PowerPoint-based planning, Excel tracking) to issue-based and design document-driven development workflows.

However, this isn’t an all-or-nothing proposition. Rather than choosing between “all PowerPoint and Excel” versus “all Markdown,” organizations should focus on gradually increasing AI-readable information formats. The characteristics of management systems matter too—systems that can keep information relatively flat are more ideal than those requiring complex hierarchical permissions.

While platforms that support multi-layered permissions for enterprise governance are certainly important, increasing the portion of information that can be managed with high transparency within the organization benefits everyone. This is about finding the right balance and using appropriate tools for different purposes, not making binary choices.

Teams need to learn new tools and workflows. Complex documents need to be restructured. Permission systems need to be redesigned. Yet organizations that make this transition report surprising benefits beyond AI integration: improved collaboration, better version control, more accessible documentation, and reduced tool complexity.

InnerSource Provides the Framework

InnerSource provides proven strategies for this kind of organizational transformation. It offers migration strategies that maintain document fidelity while improving AI accessibility, unified information architecture principles, and open-source-inspired documentation practices.

The methodology acknowledges the trade-offs between rich documents and AI accessibility while providing pathways for gradual transition that minimize disruption.

5. The Missing Context Crisis: Understanding the “Why”

AI knows the “what” but not the “why.” It sees snapshots of completed work but lacks the context of how and why decisions were made. This limitation creates significant problems for AI-assisted development.

The Snapshot Problem

Many people give AI snapshot information and expect it to understand the full context, but this approach fails because it lacks the crucial “why” behind decisions. When organizations need to solve problems, there are typically massive amounts of information and numerous potential solutions available. Even when alternative solutions exist, there are usually extensive reasons why those solutions weren’t chosen previously—but this reasoning is rarely documented comprehensively.

Current AI systems see finished code but not the development process. They know that a function exists but not why it was written in a particular way. They can identify “inefficient” code but can’t distinguish between genuinely problematic code and code that’s deliberately structured for specific reasons.

This creates dangerous scenarios where AI suggests “improvements” that break carefully constructed solutions or removes “redundant” code that serves important but non-obvious purposes.

The Informal Knowledge Gap

Much of the valuable context exists in informal communications: GitHub issue discussions, Slack conversations, Microsoft Teams threads, hallway conversations, and design decisions made in meetings. This institutional knowledge is often inaccessible to AI systems or gets lost over time, yet it’s crucial for understanding why code exists in its current form.

New team members often can’t understand why certain implementations should be avoided, and AI faces the same limitation. This historical context—documenting not just what was decided but why alternatives were rejected—is valuable for both human contributors and AI systems.

Creating AI-Accessible Decision Trails

The solution requires creating systems to capture and make decision-making processes accessible to AI. This doesn’t mean recording every conversation, but it does mean formalizing important decisions and their reasoning.

In open source projects, when decisions are made in completely different contexts or platforms, new contributors find it extremely difficult to understand how implementations were realized or how current decisions were made. Such barriers end up hindering contributor participation and making contributions more difficult. AI faces identical challenges.

This involves both technological challenges (integrating with communication systems) and cultural challenges (encouraging documentation of decision-making processes).

InnerSource Culture Naturally Documents Decisions

Open source projects excel at documenting decisions because transparency is fundamental to their success. Contributors need to understand not just what code does, but why it exists and what problems it solves.

InnerSource brings this culture inside organizations. It encourages teams to document their reasoning, discuss decisions openly, and create audit trails that preserve institutional knowledge.

The methodology provides decision documentation frameworks, processes for formalizing informal communications, and practices for linking code changes to business decisions.

The Reality of Organizational Constraints

Many of these challenges will likely be solved by technology in the short to medium term. Improved AI capabilities, better integration tools, and enhanced context understanding will address some of these issues automatically.

But organizations can’t wait for perfect solutions. They face immediate pressures to leverage AI capabilities while managing real constraints: budget limitations, risk aversion, regulatory requirements, and the simple reality that changing large organizations takes time.

The Actionability Problem

When these discussions arise, sometimes drastic recommendations get proposed. I remember when I was at Microsoft, we had a customer struggling with advancing in-house development capabilities. When we brought a Microsoft executive to meet with the customer, her suggestion was straightforward: “Since you’re a large company, why don’t you just acquire companies with lots of cutting-edge engineers?”

That recommendation was probably correct, but…

It’s easy to make dramatic recommendations: “Buy innovative companies,” “Rebuild your systems,” “Replace resistant employees,” “Hire AI experts.” But most organizations can’t easily implement such suggestions.

Such opinions are probably considered correct on social media, and in reality, it would probably be ideal for visionary CEOs to execute such transformations rapidly. So that argument is definitely right.

But actual enterprise leaders and middle managers in real companies already know this. They know, they know. Yet there are massive reasons why they can’t execute these solutions. They can’t justify major acquisitions to shareholders. They lack the talent for successful post-merger integration. They need expensive consultants for major system overhauls. They’re constrained by existing contracts, compliance requirements, and operational dependencies.

The companies that can’t follow dramatic advice aren’t necessarily wrong—they’re operating within real constraints that “advisors” often ignore.

The Gradual Transformation Imperative

This is why methodologies matter. Organizations need frameworks for gradual transition, supported by passionate leaders, enthusiastic contributors, and sustained cultural evolution.

Changing yourself is relatively simple. Changing environments, other people, and entire departments is genuinely difficult. Yet organizations must move forward despite these constraints.

The John Problem

You, reading this, probably have a growth mindset and are actively seeking new AI topics. If you’re a highly paid engineer who considers such developments natural, you’re definitely going to leverage that growth mindset to continuously improve performance. You probably think naysayers don’t belong in organizations.

But think about John in the neighboring team. His voluntary cooperation in growth initiatives is questionable. He’s not incompetent—he’s reasonably capable but requires more effort to motivate, or he’s excellent elsewhere but seemingly unmotivated in YOUR area because it doesn’t directly benefit him.

This isn’t necessarily about individual performance—it’s an organizational problem. How do you create conditions where John wants to participate in AI transformation? How do you align incentives so that cooperation feels natural rather than forced?

The Expanding Definition of “Engineer”

InnerSource was originally designed as an engineering methodology for handling source code, information, and collaboration while encouraging new contributors to participate in development ecosystems. But the definition of “engineer” is clearly expanding.

When Ruby on Rails was developed, “framework users” became part of the engineering community. Rails provided their entry point into software development. Now, “Vibe Coding” and AI-assisted development represent new entry points for engineers.

As more people become involved in “engineering,” traditional boundaries blur. People previously considered “non-engineers” now participate in code creation, system design, and technical decision-making.

You might still think there’s a clear boundary between non-engineers and engineers. While I understand the skepticism about whether non-engineers can suddenly acquire engineer-equivalent capabilities without substantial learning, the undeniable fact is that entry barriers are continuously decreasing, and barriers to participation are getting lower.

The Democratization of Software Creation

This expansion mirrors previous technological shifts. Just as Ruby on Rails democratized web development by providing powerful abstractions, AI is democratizing software creation by reducing the technical barriers to code generation.

This democratization creates new challenges. How do you maintain quality when more people can create software? How do you ensure security when the barrier to system modification is lower? How do you preserve institutional knowledge when the technical workforce is more diverse?

InnerSource as Organizational Framework

InnerSource provides answers to these challenges because it’s fundamentally about managing diverse communities of contributors with varying skill levels and motivations. It offers proven practices for onboarding new contributors, maintaining quality standards, and preserving institutional knowledge.

The methodology becomes increasingly vital as “engineering” expands to include AI-assisted developers. It provides the cultural and methodological framework for managing this new reality.

Conclusion: The Open Source Way as AI Strategy

The future belongs to organizations that can successfully blend their unique knowledge and processes with AI capabilities. This isn’t about choosing between human expertise and artificial intelligence—it’s about creating synergistic relationships that amplify both.

The Open Source Way is the key to successful AI collaboration. Organizations that embrace transparency, encourage contribution, document decisions, share knowledge, and build communities will thrive in the AI era.

InnerSource, as the organizational embodiment of open source principles, provides the framework for this transformation. It addresses the fundamental challenges of information sharing, quality assurance, accessibility, and context preservation that organizations face when integrating AI into their development processes.

The Path Forward

This isn’t about implementing InnerSource overnight or forcing dramatic organizational changes. It’s about gradually adopting practices that make your organization more AI-friendly while preserving the knowledge and culture that make you unique.

Start small. Choose one team or one project. Begin sharing code more openly. Document decisions more thoroughly. Standardize where it makes sense. Build trust through transparency.

The organizations that master this balance—between openness and security, between standardization and uniqueness, between AI capabilities and human judgment—will define the next era of software development.

The question isn’t whether AI will transform how we build software. It’s whether your organization will be shaped by that transformation or will help shape it.

The choice, as always, is yours. But the Open Source Way provides a proven path forward.