Your Tools Don’t Have a Reputation
This began as a talk and fireside chat at the InnerSource Commons Summit on 12 November 2026 (slides). The recording will be linked here once it is posted.
Mike Bursell opens Trust in Computer Systems and the Cloud with a sentence I now read aloud whenever I get the chance, because it is even more fun with inflection.
As we consider how businesses deploy software A from software provider B using libraries from open source community C and proprietary software provider D for consumption by organization E and its user group F on hardware supported by a manufacturer G running on a BIOS from H from an operating system from I and a virtualization stack from J using storage from K over a network from L owned by a cloud service provider M, we realize that we are already halfway through the alphabet and have yet to consider any of the humans in the mix.
Halfway through the alphabet, and not one person in it. We have not reached the people who wrote the software, let alone the new tools which now write it for them.
That gap is where I want to spend this essay.
Anyone who has worked in security for any length of time has met Alice and Bob.
Alice and Bob do things together, and in doing them they form a bond. But the trust Bursell is describing, and the trust that matters for what we are building now, is transitive trust. If Alice trusts Bob and Bob trusts Carol, then when Bob passes along something Carol made, Alice extends some of her trust in Bob to Carol’s work.
This is not an abstraction. It is the actual mechanism by which communities function. When I see a familiar name in a conference program, I trust the talks will be worth my morning. When someone introduces a new contributor, that contributor starts a little ahead of the person who just walked up to the group unannounced. Vouching is how you borrow reputation you have not yet earned, and it has worked for human communities for a very long time.
So how do you vouch for someone? You put your name next to their work. You offer your reputation to bootstrap theirs. That is the whole protocol.
Which is exactly where this breaks.
When you use a tool, whether it is your IDE, a compiler, or a chat prompt, you are using it for you. Then you put your name in front of what comes out, and in doing so you extend transitive trust to that work. You are the one vouching. The tool is not a party to the transaction, because the tool has no reputation to stake and nothing to lose.
I am watching this damage communities right now. One of the communities I work in is receiving an enormous volume of contributions of very low value, because someone trying to move quickly, hands the problem to a tool, does not synthesize what comes back, and passes it straight into the community. Someone else then bears the weight of refusing it, rewriting it, or reworking it. That is not a neutral act. It spends down trust with the very community the contributor presumably wants to join. (This presumption is another whole essay about using open source communities for social proof, but that’s for another day.)
We trust tools, constantly. I am trusting a long chain of them to deliver these words roughly as I intended. But new tools have to be vetted for what they are good for. I don’t trust a crowbar to wash a window. That is not a criticism of crowbars.
The promise of AI code generation is that reproduction costs are going to zero.
There is an asterisk to that statement. As long as tokens are subsidized. The more dependent we become, the more captured that market becomes, and the less control we retain over our ability to move away from it. This is one of the arguments around technological sovereignty/digital sovereignty.
Free like sunshine has never been true of software. It was not true of open source, it is not true of inner source, and it is not true of generated code. Sunshine arrives whether or not you did anything to deserve it. Software arrives because people wrote it, reviewed it, patched it, and answered the security report.
Reproduction costs are not the interesting number anyway. Maintenance costs never go to zero. Anyone who has been in this industry for more than a few years knows that every band-aid they ever applied with a sincere promise to come back to it later is likely still in production somewhere. Maintenance has always been the larger cost of software development. It was never the writing.
And maintenance costs are deferred costs, because complexity keeps growing. Whether that complexity was generated, written by hand, or interpolated and then maintained by a model, it is a bill. Someone pays it later in tokens, or straining gray matter. If tokens get more expensive, that deferred bill fed by decreasing understanding and increasing complexity is unknown and potentially unbounded.
Open source is free like a puppy. I would now argue that all software is moving toward free-er like a puppy, and that inner source is one of the better ways to keep building the community and the context you need in order to use these tools well.
So my pitch, always and forever, is grow your people.
Here is the thing I am most worried about. The easy entry point, the good first issue, the get-to-know-us problems are being taken by a tool, because it is faster to prompt than it is to mentor. The on-ramp is being bypassed. And if the only thing an organization rewards is the rate at which pull requests appear, then yes, we are hollowing out a generation of engineers.
Even if you are moving fast with these tools, bring a buddy along. Find someone early in career and spend the time you have on the skills they are going to need.
That trade runs in both directions, and I will use myself as the example. One of the communities I work in now is the Coalition for Secure AI. I arrived saying plainly that I did not know much about cybersecurity, which was true. What I did have was two decades of community organizing. So I offered that: I will help you build this collaboration, and in exchange I get to sit in the room and listen to every security conversation that happens in it. My security knowledge has grown enormously over two years. Nobody was doing me a favor. That is just what it looks like when skills are shared or exchanged instead of hoarded.
Then there are incentives, which we keep getting wrong in ways that are entirely predictable.
Everyone saw how the summer of token maxxing went. If you ask people to spend more tokens and move faster, and you attach no framing to what you actually wanted, you will get exactly what we got. A great deal of spend that did not turn into value. Nobody running those programs actually wanted more tokens spent. They wanted their developers to spend time learning how to use these tools well. Those are different asks, and the easy to measure one was measured.
Align the incentive to the outcome you want, or the metric becomes the goal.
Accountability is the part that cannot be delegated, and the norms are where communities have to do the work.
Someone drops in a pull request with a very clever regular expression that nobody took the time to parse. It has a boundary condition nobody thought through. That bug is now yours. A million pull requests in thirty days is not stature. It is a house of cards, and if there is no human accountable for it, what we have built is robots talking to robots very quickly.
In one community I work in, a set of conformance tests arrived that several of us could not make heads or tails of. I spent thirty minutes with a model trying to work out what we were even testing for and why it mattered, and I came away unsatisfied. I was possibly spending more time asking a tool what somebody else’s tool had been trying to do than the change was worth. So I asked the person who submitted it to come explain it to the working group. We said, in as many words, ELI5.
Communities are reaching for harder boundaries too. File an issue before you may open a pull request. Get vouched for before you participate. I understand the impulse, and I don’t like where it leads. Those gates are hardest on people who were already underrepresented, because a first-time contributor without a sponsor is the person a vouch system turns away. The same asymmetry shows up in AI detection: a contributor who runs their prose through a model so their English reads more properly can get flagged as a machine for their trouble.
On using AI to govern AI contributions, I suspect it is turtles all the way down. These are tools like any others and they will have to be proved out. The useful precedent is industrial: you do not inspect every part coming off the production line, but you do sample, you do keep tolerances, and you do keep an exception path to a human. We will get there. We are not there yet.
And for those who object to these tools on moral grounds please keep making these arguments, inside the conversation. When a moderator in Reddit’s r/opensource community declared no AI ever, a fellow moderator objected that they had not been consulted, and commenters asked whether that meant they could no longer discuss Linux. Self-selecting out does not set the boundary. It just removes you from the room where the boundary gets set, and converts a question about norms into an us-vs-them.
If code generation really does become commodity, look at what is left.
The work that remains human is the connective work. Making sure people understand how the pieces fit, that the organization moves, that the thing being built is the thing anyone actually needed. Tanya Reilly’s term for it is glue work, and we have undervalued it for as long as we have had release dates to tie compensation to. The person shipping the feature is measured and rewarded. The person making sure every meeting happens and every handoff lands is not.
We had a structural answer to making glue work legible in Kubernetes, if an imperfect one. The Special Interest Group for Contributor Experience ran the mentorship programs, the onboarding, the want-to-be-a-leader track. Leading it came to be seen as a path to the steering committee, roughly as much as maintaining a critical subsystem was.
Claire Dillon gave me a phrase for this during the talk that prompted this essay, and I am going to keep it: legitimate peripheral participation. It is a real mode of belonging, not a waiting room. Isabel Drost-Fromm put the same point from another angle: a committer at the ASF is someone committed to the project, not someone whose code is committed to version control. And Ross Gardler said the thing years ago that remains the most useful sentence about culture I know: Communities grow to resemble the people who show up.
So participate in InnerSource (and open source) as an act of operational resilience.
The fantasy currently being sold is the one-person company worth a great deal of money, where you never have to talk to anybody. It sounds restful. It is also a short view. What happens when you get sick? What happens when a customer takes a dependency on your work and you would like to take a holiday?
I read that fantasy as a logical extension of a particular strain of individualism, and it has forgotten the thing that made us complex in the first place. Humans are not unusually strong or fast. We are unusually good at collaborating. Every durable piece of infrastructure we have is evidence of that and nothing else.
To move fast, grow trust. It is our responsibility, as leaders in a community or a company or a project, to make sure there is somebody to follow us, and that they understand not just the code but the lore. Invest in the context, invest in the judgment, invest in the humans. Everything else is a deferred cost waiting to be repriced.
Postscript: I’m studying at Trinity College Dublin, investigating questions about trust, privacy, security and technological sovereignty, and the phrase Claire handed me has a serious literature behind it. Legitimate peripheral participation comes from Jean Lave and Etienne Wenger’s Situated Learning (1991), the work that gave us communities of practice: the argument is that newcomers learn by doing real but peripheral work at the edge of a practice, and that the apprenticeship pathway is itself part of the practice’s structure, not an overhead on top of it. Read that way, automating away the good first issue is not an efficiency. It is the removal of the mechanism by which a community reproduces itself.
The boundary question has a literature too. Elinor Ostrom’s design principles for long-enduring commons institutions (Governing the Commons, 1990) put clearly defined boundaries first, and graduated sanctions well down the list, which is more or less the argument I am making against reaching straight for a vouch requirement. And Robert Putnam’s distinction between bonding and bridging social capital is a good lens on what transitive trust actually buys you: the vouch is a bridge, and a community that stops building bridges is not stable, it is just closed.
We in open source keep rediscovering this territory from scratch. There is a body of scholarship that would save us some of the more expensive experiments.
Sarah Novotny has worked in open source community governance for two decades, including Kubernetes, OpenTelemetry, NGINX, and MySQL. She currently lives in Dublin and is studying political science at Trinity College.