Adopting InnerSource at Scale in an Agentic World

This post is based on talks I recently gave at Agentic 101 workshops in DC and Boston.

There's a saying I like to repeat every chance I get:

"What's good for the agent is good for the human."

I've seen a certain pattern repeated many times over:

• Somebody makes a suggestion for behaviors that will improve everyone's experience
• Somebody rebuts that saying "it's too hard" or "that will take too much time"

Yes, these are usually mundane things like writing documentation, submitting release notes, or any other "non-sexy" work that developers think of as "janitorial" in nature. Before I go any further, let me just go ahead and raise my hand and say "It's me. I'm the problem, it's me" lest I be a hypocrite. I'm not a hypocrite, I'm just lazy.

Now fast forward a couple of years, and we start hearing the following exchange:

• We need to write better, structured documentation, and it has to be comprehensive, easily accessible, and well-structured with clearly defined categories
• But that's too hard!
• But we need it for our agents!
• Oh... Ok! Yes, right away

I'm going to walk through the steps for implementing an InnerSource program at scale in an enterprise that is deep into its adoption of agentic engineering. If you're unfamiliar with the term InnerSource, I would start with the InnerSource Commons site. In short, InnerSource is the application of open source collaboration principles internally at a company, behind the firewall. It's meant as a way to accelerate collaboration between teams, and consequently, the pace of innovation. I find that InnerSource can often complement and improve other company initiatives for digital transformation, such as Agile methodologies.

For the remainder of this article, I will talk about process changes to implement through your InnerSource program that you should probably already have been doing, but now we have to think of the agents. This is why I say it's a chance to get things right. With great change comes opportunity, and the agentic shift is just such an opportunity. That said, there are real changes you can make in your InnerSource implementation that will aid your agentic rollout(s), so it's not completely a cynical ploy at deferred change management.

It's also not a good idea to wave this in front of your manager and say "I told you so! Seven years ago!" Well, ok, I'll leave that one as an exercise in judgment for the reader.

Why InnerSource is so Damned Hard

Those of us who have actually tried to implement InnerSource programs within the bowels of corporate technology departments - and lived to tell about it.. sort of - can tell you one thing: it's extremely difficult to do at any kind of scale or impact. There are a number of reasons for this.

• InnerSource is scary. If you work in the type of environment where heirarchy means a lot and people get worked up over things like promotions and salary increases, then InnerSource is going to be a tough sell. InnerSource, like open source, doesn't respect corporate boundaries or heirarchies. InnerSource is 100% about how much you can contribute to a given project, not your job title. I'll go over some ways to improve this when I talk about incentive structure.
• InnerSource doesn't respect departmental boundaries. Similar to the above, successful InnerSource programs thrive on inter-team and inter-department communication and collaboration. If those are foreign concepts at your company, boy are you in for a rough ride. Ideally, an InnerSource program can help improve those things, but in reality, InnerSource rollouts are often hampered by these phenomena.
• Team members aren't incentivized to collaborate. Most people tend to believe that because open source-style collaboration leads to better outcomes, then teams and leaders will gravitate towards the InnerSource model because they want to make better work product. Oh my sweet summer child... you thought managers and workers were incentivized by the quality of their work. I mean, they are but it's within the context of winning a promotion, and that is determined by their VP. This is why in order for any InnerSource porgram to have a scalable impact, it has to be inculcated in employees and reinforced by the HR policies. Nothing happens in corporate tech unless you can show a path to promotion. If VPs and team leaders all work in silos and frown on their teams assisting others outside their silo, then the incentive structure prevents a strong InnerSource program. This is where team and organizational leaders absolutley must step up and determine which behaviors are to be rewarded and how.
• InnerSource has its own rules of governance. They're just different and often orthogonal to corporate governance. InnerSource governance takes the form of, if you've taken the time and effort to become an expert in this project, then you will win a leadership role, regardless of your corporate level or title. And there are rules that govern who has access, who can make changes, and who reviews changes. They're very clearly spelled out in the governing documents of the program and each individual project. But because these governance rules function independently of corporate governance, they can get lost in the shuffle when you consider the other points above.

The changes that InnerSource style governance recommends does have analogs in the form of Agile implementations, but for whatever reason, Agile was adopted at a mass scale and InnerSource was not. I suspect that Agile implementations followed the patterns of SAFE, which was "safe" by corporate standards because it didn't require much to change - it was basically an iteration on previous themes, whereas InnerSource adoption required more wholesale change to adopt.

What's Agentic AI Got to do With It?

Everything! But also... nothing. Everything I wrote above is not magically solved by agentic AI. However, the introduction of agentic AI does introduce some new problems that enterprises now need to address.

• Agentic AI needs access to data. In order for agents to perform well, they need curated data sources, often from teams not under the VP of the engineers writing the apps. Turns out, silos are really bad for agentic AI.
• Agents need limits on access, but not too limited. You want your agents to be able to automate what it can, and to ignore what it isn't authorized to touch. This requires a thoughtful approach to identity and access management (IAM) in the context of agents and InnerSource. An agent will need access to source code to evaluate appication testing capabilities, but an agent should never have access to data sources that are not available to its operator.
• Agents need relevant, timely data. To fully understand a company's SDLC and the applications that are built and deployed on it, agents need good, accurate documentation to act on. Stale documentation will throw them off. So all that effort you spent telling your developers to write better documentation? This is where it pays off. Originally, you said this because it helps external InnerSource contributors understand a given code base. But now you say it because who will think of the agents.
• Agents operate at a speed and scale unheard of for human developers. This means the rules for governance have to be crystal clear and your universal governance documents for code respositories are spelled out in detail: who is authorized to make changes; who can contribute; who can review; etc. If you don't have explicit rules for interactions on projects, the agents will take the path of least resistance. Agents will also bombard your projects with an abundance of merge requests that go beyond human capacity for review if you don't have sufficient rules for engagement. This is where limits on the size and frequency of merges becomes important, not to mention using review agents with permissions to conduct reviews and write review notes without damaging the existing repositories. This is very similar to challenges open source maintainers experience when agents submit large merge requests, unsolicited.

Everything above points to needed changes that were probably pointed out years ago but unheeded because... "developers were bored". Welcome to the future! Everything old is new again.

Structural Governance for InnerSource

There are a few things that will be a higher priority once you let agents loose on internal infrastructure. A big part of your InnerSource implementation will depend on how your structure your IAM integration. It was always important to define strict rules for access for humans. But it's never been more important than now, because we have autonomous agents making decisions in SDLC workflows. Agents now have access to tooling, and tools have access to data. If you're going to design a program for InnerSource collaboration at scale, it's no longer good enough to simply start with "default to open", require that developers put a license in their repo, and stick in a CODEOWNERS file. They need to define who has access, how much, and who owns what. Oh, and you can never let an agent fully inherit the permissions of its operator. Let's start with the basics. I'm going to walk through setting up InnerSource governance for agentic engineering using commonly found tools in many enterprises: GitLab, GitHub Enterprise, or some other git-based source code management system (SCM); ServiceNow for approval workflows; and Active Directory for access control, specifically AD security groups. If you use different systems, there are probably equivalent steps you can take - let me hear about what is different in your setup.

How do you define access?

Let's start with the code repositories. Sure, InnerSource patterns can be used for any type of multi-team, inter-organizational project, but it's usually for code, and that's the first place that organizations start. Some organizations have flat access rules, where engineers have at least read access to most source code repositories, except in cases where repositories require tighter access control, whether due to the sensitivity to the data it accesses, or the trade secrets contained in the code itself. In less-regulated industries, the number of tightly controlled repos is smaller, and in highly regulated companies, that number is much higher. Let's assume that you're in the latter category and you work for a government agency, a bank, an insurance provider, a health care company, or some other entity that has to answer to regulators who can make your life difficult if you don't satisfactorily meet their compliance requirements.

For most of these companies, access to source code is limited to team members directly involved in a project they own. Access to source code is on a "need to know" basis, and the higher the risk tier of the project or product, the less that anyone outside of the immediate team needs to know. This makes open source purists blanch, but there are good reasons for these restrictions. In these cases, each product will have it's own AD security group, and membership in the right AD groups will grant read, contribution, or write access to the accompanying source code repo, depending on the role of a team member. This means that a typical enterprise setup will have multiple AD groups per source code repo, and in a large enterprise with thousands of products, multiply that number by at least 3-5, and you'll get the minimum number of AD groups required to administer source code access. In most cases, enterprises set standards for AD group names and they will have a nomenclature based on product name, SDLC stage, platform, degree of access, and many other types of metadata. An example would be the following:

In the above example, the AD group name starts with the product name ("MYPROD"), then the platform that contains the data needed by the developer ("SCMREPO" - this group grants access to resources in the source code management system), and the degree of access ("READ" - membership in this AD group only grants read access to data in the defined resources, but not write access). There are many variations on this theme, but you get the basic idea. In this setup, individual team members can request access to this group, and the components defined as part of the named product - everything from compute infrastructure to source code - are linked to a corresponding set of AD groups, including the one above. Enterprises can get as granular as they want to be, such as limiting access to databases to only members of a defined database AD group or even limiting access to only databases in a defined release stage. To make matters even more confusing, sometimes different parts of an organization will have different rules for AD group nomenclatures, meaning that it can be very difficult to standardize how AD groups are created and managed.

Luckily, there are ways to create cross-product AD groups to define access roles for those who are not directly involved in a specific product. There are numerous reasons for this - admins of a particular service that serves multiple products require access to all product resources if they are expected to fulfill their duties. For example, if you're the admin of your git source code management service, you have to be able to access multiple source code repos if you want to help developers that are stuck - maybe they don't know how to back out their last commit and require assistance. This cross-product AD group is exactly what we will use to define access roles for InnerSource contributors.

3 Basic Access Tiers

In order for this to work, you will need to define how a project can request InnerSource-ready status and what the request workflow looks like. The number of InnerSource projects will always be relatively small compared to the total number of projects, so it's ok if the approval process is manual. In contract, many engineers will want at least read access to InnerSource projects, and you will need an approval process that is mostly automated to meet demand without stifling interest. The speed of approval has to be commensurate with the level of risk involved. To start, let's identify the goals of what we want to accomplish with access tiers:

1. Give every participant in the InnerSource program the means to access all products or projects that have been granted InnerSource-ready status. It's up to you to define who all is allowed in the InnerSource program and the governance of InnerSource projects. In other words, make InnerSource projects discoverable.
2. Allow InnerSource participants the ability to make contributions to their desired project if they have met the minimum requirements, as defined in your governance process.
3. Provide the means for agents to be used by operators to autonomously perform some operations: pull/merge requests, code reviews, writing test plans and scripts, and executing and reporting at least some tests - without providing too much access that exceeds the appropriate risk tolerance.
4. Communicate and execute a process for InnerSource participants to become core contributors if they meet pre-defined minimum requirements and have the approval of a project's core team members.

In our case, we're going to create a meta-project called "InnerSource" and attach different AD groups to it. These AD groups will be attached to both individuals as well as the projects that have been granted InnerSource-ready status. Membership in all AD groups should be for a limited time, depending on levels of risk.

InnerSource-Git-Read - this is the AD group that a developer requests access to if they want to be able to access any InnerSource project. This allows individuals to request 1-time access through which they will always be able to clone repos of every InnerSource project. Individual projects, when requesting approval for InnerSource-readiness, will automatically be tagged with this AD group. Appropriate term of membership would be 1 year or more.

InnerSource-Git-Contrib - This grants its members the ability to submit pull requests, test plan and script changes, and submit 1-time fixes that would be reviewed by a project's core team members before acceptance. This is the group that autonomous agents would be using. Or, you could create an entire subclass just for agents. Limiting membership to 6 months or some other time period less than the above is appropriate. Again, the idea is to provide the level of access needed without accruing too much risk. Approval for this group will require more review than read-only access, but you don't want to uphold approval with too much manual processing - that defeats the purpose of an InnerSource program.

InnerSource-Git-Agent-Contrib - Creating a separate AD group just for agent membership grants the ability to scope the actions of autonomous agents to a subset of actions versus those granted to their operators. For example, you may not want to grant permissions that allow agents to rotate keys and secrets or approve of code merges, although certain engineers will need to execute those functions. Putting the agents into a separate, limited tier prevents them from inheriting the full permissions of their operators and executing actions that increase potential risks. The time limits depend on how long you anticipate a given agent operating. In this case, shorter time periods are probably best, such as 1-3 months.

Core Team Membership - Each project team will have its own AD group membership for core members. These members have access to everything, reads and writes. Since each project will approve its core members, the approval process can have manual oversight, assuming membership is mostly static with few changes over time.

Tie-ins to Platform Engineering

With the AD group membership defined and approved, defining membership and participating projects, you now have the ability to integrate your InnerSource work into platform engineering. Because all participating projects have been tagged with the InnerSource-Git-Read AD group, they are now discoverable by your developer portal. This means that it should be trivial to construct a view of your InnerSource projects accessed by visitors to the developer portal. And through this developer portal integration, you will be able to construct workflows that can be accessed based on AD group membership of the individual - or agent - accessing the portal. Members of various AD groups will be presented with various options that non-members will not see. A core team member of an InnerSource project will see project management capabilities invisible to others. There are other governance integrations we well.

Platform Standards

It's not useful to define all of this governance if you don't have the means through platform engineering to define standards that apply to all projects, with their requisite controls. Having a centralized developer platform grants the ability to institute platform-level policies that are integrated into a project's scaffolding. For example, mandating and distributing a standardized policy, eg. AGENTS.md, means that every code repo will have the same policy-as-code format as well as rules and controls for what is allowed in these policies. These can then be enforced through checks in different release stages managed by the CI tools. This prevents individual projects from circumventing platform standards. This gives you, the InnerSource program administrator, the ability to write and enforce a global AI governance document with explicit guidance on AI-assisted contributions, for example.

The centralized standardization of policy-as-code, combined with the streamlined management of AD security group membership approval, gives enterprises the tools needed to implement an InnerSource program at scale for agents and humans. Sure, most of this, with the exception of the dedicated service account class for agents, is stuff you should have already been doing. But with your management's hair on fire over adopting agentic engineering more quickly, I say don't let a good crisis go to waste - use it as an excuse to finally do InnerSource right.

Some Closing Tips

MFA - You probably have tools for one-time-passwords and other MFA process for accessing sensitive information. It's probably a good idea to integrate access to repository changes with your MFA tools - another way to enforce scoping of access so that a rogue agent faces further guardrails for forbidden actions

Process Automation and Streamlining - You may read the above and think, "Wow! That's a whole lot of governance" and perhaps express the concern that it's too heavyweight and counter-productive. After all, the whole point of an InnerSource program is to accelerate innovation, not stifle it. I think each enterprise has to decide what the appropriate level of risk tolerance is, and that will vary greatly between organizations and sometimes between different teams in the same organization. Use whatever level of caution you feel is appropriate. Or perhaps more importantly, use the level of caution that will be met with approving looks from your risk management and audit organizations. The whole point of this exercise is to strike the right balance between efficiency, automation, and risk management.