InnerSource Summit 2026

Welcome to InnerSource Summit 26! In this opening session, Shane Coughlan, InnerSource Commons Board Member, will set the stage for 20 hours of continuous programming spanning every timezone, bringing together the global InnerSource community to share experiences, insights, and practical approaches to open collaboration.

Under this year’s theme, “InnerSource in Motion: Navigating the Shifting Tides,” Shane will explore the evolving landscape of InnerSource and the importance of adaptability, resilience, and sustainable open cultures in a changing world. As organisations navigate shifting technologies, distributed teams, and evolving ways of working, InnerSource offers opportunities to strengthen collaboration, foster shared ownership, and connect people across organisational and geographical boundaries.

The opening will invite participants to reflect on how we can move with change rather than resist it, embracing the human and cultural dimensions of InnerSource alongside its technical practices. Shane will welcome attendees from around the world and set the tone for a day of learning, connection, and shared discovery.

Join us as we bridge borders, balance change, and explore how we can sustain open cultures together across 20 hours of global programming.

In 2025, Mitsubishi Electric introduced the InnerSource Value Co-Creation Model (IVCM) at InnerSource Summit. Our message was that InnerSource should go beyond code sharing. By sharing not only implementations, but also approaches and challenges across business domains, organizations can create value even when direct software reuse is difficult.

We also introduced an InnerSource platform model based on Discovery, Connection, and Collaboration, supported by technologies such as GitHub Enterprise, Backstage, and generative AI.

As we continued to expand InnerSource across a conglomerate, however, we encountered a more fundamental issue: valuable information is not always disclosed in the first place.

Even when engineers are willing to share and the technical platform is available, information may remain inside organizational boundaries. In a conglomerate, different business domains have different customers, regulations, business practices, decision processes, and priorities. These differences can create barriers that make organization-wide disclosure and reuse difficult.

Rather than assuming why information was not being disclosed, we turned to our InnerSource community itself. We raised the issue openly and collected feedback through surveys and interviews. This helped us identify recurring barriers behind seemingly unrelated concerns from different business domains.

We then connected these findings to Mitsubishi Electric’s company-wide Data Utilization Statement, which calls for data to be interconnected and circulated across businesses and organizational boundaries. Instead of treating these barriers as isolated InnerSource problems, we reframed them as structural issues that could prevent the company from realizing its stated direction and brought them to management.

Today, we are beginning to work with legal and other corporate functions to explore how these barriers should be addressed. We do not yet have complete solutions, and the barriers themselves continue to evolve as we deepen our analysis.

In this session, we will briefly revisit the IVCM vision introduced in 2025 and share what we learned from moving that vision into practice: what kinds of barriers emerge when InnerSource is expanded across a conglomerate, how we used the InnerSource community itself to identify those barriers, and how connecting them to corporate strategy helped us bring the issue to management and relevant corporate functions.

To scale InnerSource value co-creation, organizations need to understand what prevents information from crossing organizational boundaries and elevate those barriers from local concerns to enterprise-wide issues.

As AI makes code cheaper to produce, software teams need better ways to share context, judgment, and trust.

This talk starts with a long-serving maintainer who had become the person everyone relied on to explain why the system worked the way it did. When he prepared to retire, the team faced a familiar problem. Years of architectural reasoning, past decisions, exceptions, and unwritten knowledge lived largely in one person’s head.

We captured his conversations, guidance, and technical documentation so AI could use them. The AI became a first place for developers to ask questions about the system. It could point people to past decisions, explain architectural choices, and help contributors understand the code before they asked a maintainer for help.

This experience changed how I think about InnerSource in an AI-heavy development environment.

InnerSource already creates much of the context that AI needs. Shared architecture, documentation, contribution rules, ownership, decision records, and working practices help people understand how a system should evolve. They also give AI enough context to reason about intent and constraints instead of working from source code alone.

AI also changes the volume of work flowing through these systems. Developers can create changes much faster, while trusted committers still need to understand the consequences of those changes. Review, judgment, and trust become harder to scale.

This talk looks at how InnerSource can help teams make shared context available to both people and AI, preserve knowledge when experienced engineers leave, reduce avoidable mistakes, and adapt the trusted committer role as AI becomes part of the team.

Tune in to see glimpses of how NatWest uses a design first approach to bring in inner source practices to their processes and products.

Wiky Li will explore how AI coding is rapidly evolving from a personal productivity tool into an organisational capability that can reshape the entire software development lifecycle. In a large financial technology environment, scaling AI adoption requires more than technology; it also depends on reusable engineering practices, trusted governance, effective tool integration, and a strong community that enables teams to learn from one another.

In this session, Wiky will share how HSBC Technology leverages InnerSource principles and community collaboration to accelerate AI adoption and build a scalable AI Coding practice.

The session will cover six key areas:

From AI Coding to AI-enabled Engineering: Exploring the evolution from code generation to end-to-end software engineering productivity, including enterprise challenges around context, quality, security, compliance, and measurement.

InnerSource and Community Co-creation: How teams share AI Coding practices through InnerSource, transforming individual experiments and fragmented prompts into reusable tools, engineering practices, and Agent Skills.

Agent Skills across the SDLC: Practical examples of applying AI to requirements analysis, solution design, coding, code review, testing, defect analysis, and engineering verification.

Connecting Agents to Enterprise Workflows: How MCP and integrations with tools such as Jira, Confluence, VS Code, and GitHub Copilot help agents access relevant engineering context and enable cross-tool workflows.

Governance, Security and Responsible Adoption: Approaches to managing data boundaries, permissions, auditability, reusable Agent Skills, quality controls, and AI-related engineering risks while maintaining existing quality gates.

From Pilot to Scale: Lessons learned from growing small InnerSource initiatives into a broader AI Coding ecosystem, including use-case selection, developer adoption, training, feedback loops, contribution models, and community operations.

Through real-world experiences and practical insights, Wiky will highlight how InnerSource and community-driven collaboration can help organisations scale AI-enabled engineering responsibly and effectively.

Yoshitake Kobayashi from Toshiba will explore how InnerSource extends beyond source code to become a foundation for organisational knowledge, collaboration, and AI-enabled engineering. As AI transforms the way organisations develop software, the ““source”” in InnerSource takes on a second meaning: the knowledge an organisation builds about its own systems and the foundation AI needs to be useful within the enterprise.

In this session, Yoshitake will examine the reciprocal relationship between InnerSource and AI. InnerSource creates discoverable and reliable sources of organisational knowledge through shared repositories, transparent review histories, documentation, and trusted contribution practices. AI, in turn, can make that knowledge more accessible, reducing the barriers to cross-team collaboration, reuse, contribution, and onboarding.

Drawing on Toshiba’s experience building a shared industrial Linux platform, where long-term support, safety, and security require a high level of trust, Yoshitake will explore how shared knowledge can support AI-enabled engineering. He will discuss the importance of capturing reusable thinking and decision-making, rather than focusing solely on software artefacts, and how organisations can prevent siloed and undocumented knowledge from limiting AI’s potential.

The session will examine where the InnerSource and AI feedback loop delivers value, where it can break down, and what it takes to maintain a healthy source of organisational knowledge as AI becomes an increasingly important part of how we work.

While InnerSource traditionally thrives within enterprise tech silos, a powerful new paradigm is emerging: Government-led InnerSource. Today, global digital leaders are championing internal collaboration to break down bureaucratic silos, secure digital sovereignty, and accelerate public sector innovation—but their execution strategies vary significantly.

This session explores how the United States uses policy-driven reuse mandates, how Singapore fosters a unified engineering culture through central digital agencies, and how Saudi Arabia leverages national transformation blueprints to build digital public infrastructure via shared sovereign code.

Why Great InnerSource Portals Fail (and How to Avoid It): Lessons from ZF

Launching an InnerSource Portal is only the beginning. The real challenge is driving adoption, building an active community, and creating lasting value for engineers and the business.

This session explores the practical challenges organizations face after launching an InnerSource platform, using ZF’s experience as a real-world case study. Topics include project discoverability, documentation, onboarding, communication, training, and the role of community in turning a portal into an active ecosystem.

The session will also look at how InnerSource success can be measured beyond the number of projects, repositories, or contributions — focusing instead on meaningful engagement, software reuse, collaboration, and value for engineering teams.

Rather than a product showcase, this is an honest look at lessons learned, approaches that had to evolve, and practical recommendations for organizations looking to build or scale a sustainable InnerSource initiative.

Welcome to the EMEA leg of InnerSource Summit 2026 and hear about our exciting year of InnerSource

I’ve spent two decades watching open source run on a currency our dashboards never capture: trust. InnerSource inherited that currency. The Trusted Committer, the host-team handshake, the willingness to review a patch from three orgs over, these are trust instruments. We accrue them slowly, and right now we are spending them down on two fronts at once.

The first front is provenance. A pull request used to imply a person. Someone who reasoned about the change, who can be asked why, who will still be here to answer for it. When an agent authors the diff, that chain quietly severs. No one vouches, and no one carries the cost of a bad vouch. The code merges anyway: plausible, well-formatted, and unowned. The bill arrives later, all at once, as maintenance debt no human in the room can explain. This is free like a puppy, deferred a year. The code is free today; the care comes due exactly when you can least afford it.

The second front is the pipeline, and it is the one your finance team is actively mispricing. The starter issues and low-risk pull requests that juniors once cut their teeth on are precisely the work we now hand to agents. That work was never only output. It was how a contributor became someone the community could trust to say yes. Automate the apprenticeship away and you don’t only lose junior throughput; you lose the mechanism that produces next year’s Trusted Committers. The trust network you have on Thursday is the review bandwidth you have when Friday’s flood of machine-authored contributions lands. Starve the pipeline, and that bandwidth simply isn’t there. You won’t notice until you reach for it.

So this is not a talk about slowing AI down. It is a talk about who honors the 30-Day Warranty when the author is a model, and where the humans who can answer that come from. Open source learned this the expensive way: software is people. The answer to trust has always been people, specifically the ones we deliberately grow into the roles that hold it.

I’ll offer a working frame built on provenance, vouching, and trust as bandwidth built before you need it, plus three concrete moves: treat AI provenance as a first-class review signal; make no sudden moves with the norms your contributors rely on; and fund early-career pathways as apprenticeship, not probation, because that pipeline is trust infrastructure, not headcount you can defer.

Trust is the ultimate currency. In the AI era, InnerSource is where enterprises mint it, or quietly go insolvent.

Last year we shared our full assessment of Inner Source at Mercedes-Benz and all the frictions holding adoption back — from scattered resources to a missing recognition model and more. We promised to fix them and report back. This is that talk.

We briefly recap the 2025 findings, then show what we did against each — with real progress on most. We go deeper on our Inner Source Discovery Portal, newly built on GitHub Pages with full AI capabilities, and share a standout success: our internal time-tracking tool, now widely adopted and actively contributed to.

We’re also honest about what’s open. Recognition for Inner Source contributions remains unsolved: our Contributor Award Program baseline is done, but one hard problem isn’t — how do you reliably track contributions from people outside the owning project team? We’ll put that question to the room and look forward to the discussion!

AI coding agents can discover internal code, generate fixes, update documentation, and open pull requests faster than maintainers can review them. That changes the InnerSource bottleneck: contribution scarcity can quickly become review debt and governance overload. In this talk, I’ll show how to adapt familiar InnerSource practices for machine-speed collaboration without losing trust, ownership, or community. We’ll treat AI agents as contributors—not privileged automation—and build a practical control model around five things: machine-readable contribution context, clear ownership and review boundaries, short-lived identity and least privilege, provenance and evidence for generated changes, and platform guardrails that preserve maintainer control. Drawing on production AI, platform engineering, automation, and open-source practices, I’ll explain where agents genuinely reduce friction, where human judgment must remain, and which metrics reveal whether AI is improving flow or simply producing more work for reviewers. Attendees will leave with a five-part checklist they can apply to internal repositories immediately.

Platforms and InnerSource are the same thing. When everything is discoverable - services, ownership, architecture, patterns, dependencies - engineers can collaborate seamlessly across boundaries. No permission bottlenecks. No weeks learning someone else’s codebase. Discoverability is what InnerSource actually is.

Now add agents to that equation. Agents need the exact same thing engineers do: complete discoverability and clear governance. They need to see what’s available, understand the rules, and operate within visible boundaries. That’s not constraint - that’s true autonomy.

This presentation will explore how a platform that enables InnerSource for engineers is the perfect foundation for autonomous agents. The same governance that lets engineers collaborate safely lets agents operate independently at scale. You don’t lose control. You gain visibility. Agents have full context, operate under explicit rules, and every action is auditable. True autonomy without surrendering the keys.

This talk explores how InnerSource platforms become the vehicle for the agentic organisation.

InnerSource has helped organizations around the world improve collaboration, reduce duplicated work, and share knowledge at scale. Yet many fast-growing organizations continue to face these same challenges without recognizing InnerSource as a practical solution.

This session explores a question that extends beyond any single company or region: How do we introduce InnerSource in places where awareness is still emerging?

Using Africa’s growing technology landscape as the context, this talk examines why collaboration challenges such as duplicated engineering effort, knowledge silos, and slow onboarding persist, and why InnerSource is often absent from conversations about solving them. Rather than focusing solely on implementation, the session looks at what comes before adoption: helping organizations recognize the problems InnerSource addresses, communicating its value in terms that resonate with engineering and business leaders, and creating the conditions for meaningful adoption.

The talk combines insights from conversations with developers and engineering leaders, lessons from established InnerSource programs, and a composite case study inspired by recurring organizational patterns. Together, these perspectives illustrate how organizations can move from recognizing collaboration challenges to exploring InnerSource as a practical approach for addressing them.

Although grounded in Africa’s technology landscape, the discussion is relevant to any advocate, engineering leader, or community working to introduce InnerSource in a new organization, industry, or region. Attendees will leave with practical insights for communicating the value of InnerSource, fostering organizational interest, and helping collaborative engineering practices take root in environments where the conversation is only just beginning.

As AI assistants and autonomous agents become part of everyday software development, organisations face a new challenge: how can teams collaborate effectively while maintaining control over their code, data, workflows, and intellectual property? Many enterprises are rapidly adopting AI tools, but often through disconnected SaaS services that create new concerns around governance, security, compliance, and vendor lock-in. For highly regulated industries, critical infrastructure providers, or organisations handling sensitive intellectual property, these concerns are becoming strategic. This session explores how InnerSource principles can help organisations build trusted AI platforms instead of merely consuming AI services. Drawing on experiences from open source developer tooling ecosystems and large-scale platform adoption initiatives, we will examine how organisations can: Establish shared AI infrastructure that can be adopted across teams and business units. Support cloud, hybrid, and fully air-gapped deployment models. Maintain transparency over prompts, agents, data flows, and model selection. Enable internal collaboration around AI capabilities through reusable components and shared governance. Reduce dependence on individual AI vendors while preserving flexibility and innovation. The discussion will focus on a fundamental shift: treating AI as enterprise infrastructure rather than as a standalone product feature. Attendees will leave with practical ideas for applying InnerSource practices to the design, governance, and adoption of secure AI Open Source platforms that balance innovation, compliance, and organisational control.

Showcasing the Unite UN-Tapped programme and its outcomes

At the heart of inner source is collaboration and community. We know that to ““break down silos”” we need to get better at communicating more openly, sharing knowledge, and working together. If you’ve ever tried to actually shift from a closed culture to an open collaborative culture, you know it’s not easy to change how we work, talk to each other, and share information. Usually you’ll run into one of two issues: either teams stay isolated in their own silos, or everyone shares so much information that it becomes impossible to keep up. So, how do you build a culture where people actually know what other teams are working on, without overwhelming everyone?

This session covers how to make internal communication work. We will look at how to:

• Get information moving freely across the whole company (transparency).
• Keep communication manageable so people don’t get tired of reading updates and dealing with constant pings of new messages.
• Sustain and scale this way of communicating as the company grows.

I’ll share real-life examples of good and bad internal communication from companies of different sizes and in different industries, including balena, where I currently work.

You’ll leave with simple, practical ways to help your teams share information, communicate with intent, and know what’s going on.

What happens to InnerSource when producing a contribution is no longer the hard part?

AI can create code, tests, documentation and pull requests in minutes. That shifts the constraint. Review time, ownership, trust and shared context become even more precious. Adding agents to today’s operating model will not automatically create better collaboration. It may simply create a much larger queue.

In this talk I will ask what comes next for InnerSource and offer a socio-technical answer. Drawing on more than 30 years helping large and regulated organisations improve how their engineering systems work, I will follow an AI-assisted contribution from idea to production. Along the way, I will look at the relationships between contributors, trusted committers, platforms and product owners, and show where the familiar model may need to evolve.

I will introduce five practical ideas for agent-ready InnerSource:

1. Publish intent and contribution boundaries before code.
2. Make ownership and contribution paths easy for people and agents to discover.
3. Put repeatable governance into paved-road workflows.
4. Protect maintainer attention through progressive trust and clear evidence.
5. Measure reuse, learning and flow rather than pull-request volume.

This is not a talk about AI replacing communities. It is about why community becomes more important when implementation is cheap. The people who decide what should exist, who can change it and how the organisation learns together are still at the heart of the system.

Attendees will leave with a simple diagnostic they can use on a repository, a platform or an enterprise InnerSource programme the next day.

Most of the conversation about AI and InnerSource right now is about efficiency. Faster contributions, less duplication, tokens saved. All good things! But if that’s the whole story, it undersells what InnerSource actually produces.

Here’s the thing: some of the most durable outputs of InnerSource aren’t just shared code. They’re the shared organizational knowledge and the social capital that come from working across boundaries. The pull request discussions, the design rationale, the ““let me introduce you to the person who actually knows this”” relationships. That’s not a nice-to-have. Those relationships and that trust are the connective tissue of an organization, the thing that lets it move, adapt, and hold together.

And here’s the twist: it’s also exactly what AI runs on. That messy human context is what makes an AI assistant useful rather than generic. AI consumes organizational knowledge. It doesn’t produce it. Worse, it can quietly degrade the tissue itself: when the questions that used to go to a colleague go to a chatbot instead, the collaboration and the relationships that generated the answers stop forming. Stack Overflow’s collapse in new questions is the public preview. The wave of AI-generated pull requests hitting open source maintainers is another.

InnerSource practices do the opposite. They are one of the few deliberate ways organizations build shared knowledge and cross-team relationships. So this talk makes the case for InnerSource communities as stewards of the connective tissue AI depends on and erodes: what to hand over, what to hold onto as distinctly human, and how to answer the inevitable ““can’t AI just do that?””

Working in a government is tough. Lots of red tape. People not ready for change. In this session we’ll see how things have progressed after 2 years of trying (yes, trying) to set up an ISPO in the Geneva Canton IT Organization. It’s going to be fun!

Everyone is hitting their token limits. As AI-assisted development becomes part of our daily workflow, engineers are discovering that the real bottleneck is no longer coding speed, but context efficiency. Teams keep reinventing prompts, repeating experiments, and spending tokens solving problems that have already been solved elsewhere. What if we approached AI usage the InnerSource way? In this talk, we’ll explore how open collaboration practices can dramatically reduce token consumption while improving engineering outcomes. We’ll share practical techniques to reuse prompts, standardize context, build shared knowledge assets, and create community-maintained AI workflows that help teams avoid duplicated effort. By treating prompts, instructions, and AI practices as reusable InnerSource assets, organizations can save up to 90% of their token budget while enabling developers to learn from each other, scale best practices, and become more effective together. Join us to discover how InnerSource principles can turn token optimization from an individual hack into a community-driven advantage.

Surely we want to increase the number of PRs, to show that InnerSource is successful, or not? How about minimising the time it takes to review PRs? What about increasing the number of projects that are InnerSource-ready?

In this talk we will look at ways to measure InnerSource initiatives. We’ll investigate trivial to implement but often misleading metrics. We’ll show the importance of understanding the purpose of establishing InnerSource best practices to drive metric definitions. We’ll also look at what surveys can uncover - and where communicating with people in 1-on-1 settings can help reveal issues before they grow into mountains blocking collaboration.

Welcome to the Americas portion of InnerSource Summit 2026 and hear about our exciting year of InnerSource

TBD

This session will cover a set of practices that I’ve seen, and that should not be repeated(!), after participating in and championing InnerSource within my company. By sharing our mistakes, attendees can hopefully achieve success more quickly in their own InnerSource programs. Let our pain be to your benefit!

InnerSource has proven to be a success when working with highly reusable frameworks, templates and extensible services. Artifacts that are usually packaged or containerized, from an infrastructure perspective. However, everything is changing rapidly and every company in the world wants to keep its pace, evolving their infrastructure governance from DevOps to Platform Engineering. And then towards Agentic Platforms!

But, when you work in a holding-group, you see that companies are struggling to keep up and repeating the same mistakes over and over again. Which made us wonder, what if infrastructure itself could also become a reusable framework? But not only as single components, but a whole suite that is extensible and customizable to every company’s needs.

In this talk, we’ll explore how GitOps can turn shared infrastructure repos into genuine InnerSource projects. Using pull requests as the unit of contribution, Trusted Committers encoded in CODEOWNERS, policy-as-code guardrails instead of approval boards, and a control plane where ““merged”” means ““deployed.””

Many organizations recognize the value of InnerSource in breaking down silos, promoting code reuse, and fostering collaboration. Yet, adopting InnerSource at scale remains challenging. Engineers struggle to discover reusable projects, understand unfamiliar codebases, navigate contribution processes, and build confidence when contributing outside their teams. At the same time, InnerSource Champions, Trusted Committers, and Maintainers face the ongoing challenge of onboarding contributors, maintaining documentation, mentoring communities, and measuring the health and impact of their InnerSource programs. These organizational and technical barriers often slow adoption long before engineering challenges arise.

This talk explores how Artificial Intelligence can accelerate the adoption of InnerSource by reducing friction at every stage of the organizational adoption journey. Beyond AI-assisted coding, it examines how AI can increase awareness of InnerSource, help engineers discover reusable projects, simplify onboarding, identify contribution opportunities, and provide repository-specific guidance for first-time contributors. It also explores how AI empowers InnerSource Champions, Trusted Committers, and Maintainers by automating repetitive tasks, improving documentation, supporting mentoring, surfacing community insights, and measuring program health. By lowering the barriers to participation while strengthening the capabilities of those who lead and sustain InnerSource communities, AI becomes more than a developer productivity tool—it becomes an enabler of organization-wide collaboration and a catalyst for sustainable InnerSource adoption.

The session also examines the organizational capabilities needed to make AI effective, including trusted repository-specific context, transparent governance, and well-defined InnerSource patterns. Through practical examples and an incremental adoption roadmap, attendees will learn how AI can increase contributor engagement, improve collaboration across teams, and help organizations scale their InnerSource programs sustainably.

The future of InnerSource is not simply AI-assisted development—it is AI-powered collaboration that enables every engineer to become a confident contributor and every repository to become a shared organizational asset.

AI adoption in software development is nearly universal, but the results are anything but. While the industry has moved beyond simple code completion, the promised productivity gains often get lost in downstream chaos. So, what separates the high-performers from the rest?

Drawing on insights from DORA’s research and industry observations, this session will reveal a critical truth: AI’s primary role is that of an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones.

In this talk, we will go beyond the hype and dive deep into:

• Identifying and reducing the contributor friction • Making your repository AI-ready • Guidelines for contributors

You will leave this session with a clear, data-backed framework for understanding and improving your team’s AI adoption strategy. Instead of focusing on just the tools, you’ll learn how to identify and address the systemic issues that are holding you back, and how to create an environment where AI can truly amplify your team’s success.

Open source and InnerSource are often treated as two distinct operating models: one facing the outside world and the other focused within the enterprise. In reality, the most interesting challenges (and opportunities) exist at the border between them.

This panel brings together industry practitioners working across open source, InnerSource, OSPOs, engineering governance, and enterprise technology to explore what each model can learn from the other. We will discuss how open source practices such as transparent decision-making, contributor pathways, maintainership, and community building can strengthen internal collaboration, and how enterprise InnerSource experience can help organizations become better open source participants.

The discussion will also tackle the difficult questions: When should an organization contribute upstream, maintain an internal extension, or fork? What processes, controls, incentives, and organizational structures unintentionally prevent effective InnerSource? And how can companies build a continuum where code and ideas can move more naturally between internal and external communities?

In the past two years the tech industry was taken by storm, the AI storm.

Everyone can “vibe-code/create” their own solutions now, does this mean reuse is dead? And how about InnerSource?

The bar for contributing to other projects has been lowered, but what does this mean for maintainers?

In this talk a seasoned InnerSource Officer will bring food for thought on how AI can impact the collaboration style prescribed by InnerSource, for the best of for the worst, and share ideas on how to navigate this ever-changing terrain. We will also look into intrinsic benefits we expect to have with AI, but also, where a human push is still needed.

What if scaling AI isn’t really about adoption, but about what a community creates once people start using it together? Within a large U.S.-based financial services firm, 94% GitHub Copilot adoption and 78% agent-written code were only part of the story. The bigger outcome was turning individual experimentation into repeatable, discoverable patterns through shared skills, prompt, and harness libraries.

By applying InnerSource principles alongside grassroots engagement, storytelling, and community building, teams could contribute what worked, learn from one another, and build on proven approaches instead of continually starting from scratch. This session explores how AI adoption became a catalyst for a shared collective of knowledge—and how measuring reuse, contribution, and impact can tell a much more meaningful story than adoption alone.

While Generative AI is all the rage today, it is easy to burn all the tokens without much to show. Moreover, without guidance, LLM assistances can easily create unmaintainable rats nests of code that has no chance of supportability in production. This talk will show how we can exponentially improve our results with just a bit of work crafting Skills and MCP Servers.

We’ll cover what Skills and MCP servers are. How to create them (with some simple examples) and lastly illustrate how they can work with a variety of common harnesses (including Antigravity, Copilot, Claude and more).

Attendees should walk away with a good handle on how to make a skill and MCP server, and when. More importantly, how we can reliably share with easy to maintain repositories in GIT.

The sharing aspect of skills truly leads to democratization of Gen AI improvements and drives at the core of Inner Sourcing.

Every company has a brain, but it is scattered across source-code repositories, documentation, chat channels, issue trackers, meeting notes, policies, and the experience of individual employees. The problem is not that organizational knowledge does not exist. The problem is that people often cannot find it, understand its context, or identify who can help.

A Company Brain is a shared, AI-powered knowledge layer that connects this fragmented information and makes it accessible through natural-language questions, structured exploration, and links back to trusted sources. Unlike a static intranet or general-purpose chatbot, a Company Brain understands the relationships among teams, projects, applications, decisions, contributors, and organizational processes. It can also improve over time by capturing new answers and connecting them to the people and evidence behind them. This session introduces the Company Brain concept through the lens of InnerSource. Attendees will learn how a Company Brain can help employees discover reusable internal projects, understand how and where to contribute, locate maintainers and subject-matter experts, preserve the reasoning behind technical decisions, accelerate onboarding, and reduce duplicated work across organizational silos. The session will also address the importance of permissions, provenance, human review, and clear ownership—ensuring that greater access to company knowledge does not come at the expense of trust, accuracy, or security.

Preliminary session outline:

1. What is a Company Brain? How it differs from enterprise search, knowledge bases, RAG chatbots, and traditional intranets.
2. How can a company use it? Practical applications including developer onboarding, internal project discovery, contribution guidance, expertise location, decision history, and cross-team knowledge sharing.
3. How do you get started? Choose one measurable use case, connect a small set of authoritative information sources, define access and ownership rules, launch a simple question-and-answer experience, and create a feedback loop that turns unanswered questions into durable organizational knowledge.
4. How do you measure success? Track faster answers, increased project reuse, greater contributor participation, fewer repeated questions, and less time spent locating information or experts.

InnerSource started with code. The future of InnerSource is not open code. It’s open capability.

As AI agents become part of everyday work, a new class of reusable assets is emerging: agent skills, prompts, tools, plugins, and workflows. Organizations are no longer just sharing software. They are sharing expertise.

This talk explores the next frontier of InnerSource: the shift from sharing code to sharing capabilities. As organizational knowledge becomes executable, the most valuable InnerSource assets may no longer be libraries and services, but reusable agent skills that capture how experts think, decide, and operate.

What happens when expertise can be discovered, reused, improved, and composed like software?

The next wave of InnerSource isn’t about code reuse. It’s about agent reuse.

InnerSource is often associated with opening source code internally so that teams can discover, reuse and contribute to each other’s work. But in enterprise software, source code is only one part of what teams need to build and operate a product. There is also a lot of knowledge around privacy, security, compliance, architecture and operational practices that can be difficult for other teams to discover and reuse.

I have seen this challenge firsthand in privacy engineering. A product may be considered compliant with a privacy requirement, but when a customer, auditor or internal stakeholder asks, “How?”, finding the answer can be much harder. The information may be spread across product documentation, architecture decisions, privacy assessments and the people who have worked on the product. This talk explores whether we can apply InnerSource principles such as transparency, discoverability, reuse and contribution to this problem. What if contributors were expected not only to contribute code, but also to make the privacy implications of their work and the “how” behind compliance understandable and discoverable? I will share some ideas for what an InnerSource approach to privacy compliance could look like and invite the community to think about where else InnerSource can go beyond code.

For most of computing history, building software meant negotiating with scarcity: limited memory, limited compute, limited time, and limited access to expertise. Today, those constraints are rapidly falling away. With AI, cloud platforms, open source, and powerful tools, more people can turn an idea into working software faster than ever before.

But when you can build almost anything, the hardest question is no longer how. It is what…and why.

In this keynote, Scott Hanselman explores what happens when creation becomes abundant. Through stories, code, and practical examples, he examines the new skills that matter: judgment, taste, curiosity, empathy, and the discipline to understand the problem before generating the solution. The future will not belong simply to those who can build the most. It will belong to those who choose carefully, build responsibly, and create things genuinely worth having together.