Strong Code Ownership Yields the Fewest Bugs, but Also the Most Fragile Teams

The article maps the debate over code ownership in software engineering: according to empirical data from Microsoft, Google, and academic research, strong individual ownership leads to the lowest defect rates and fewer vulnerabilities, but at the same time creates fragile teams with a low bus factor and knowledge silos. Drawing on Fowler's taxonomy (strong/weak/collective ownership) as well as newer models (CODEOWNERS, stewardship, InnerSource, AREA), the author concludes that hybrid approaches combining clear accountability with openness come out on top. The closing recommendations tailor the model to team size, regulation, and architecture (microservices vs. monolith).

The strongest code ownership leads to the fewest bugs — and at the same time creates the most fragile teams. That is the core of one of the oldest disputes in software engineering: quality versus resilience. Microsoft's empirical research repeatedly shows that files without a clear owner contain an order of magnitude more bugs than files with a strong owner. Yet it is precisely this concentration of knowledge that makes a project hostage to a small handful of people. The answer of today's practice is not the extreme positions, but hybrid models that combine clear responsibility with openness to contributions across teams. The key is not the choice between extremes, but a model that fits the context.

In 2006, Martin Fowler described a taxonomy that still serves as a reference framework today. Strong code ownership assigns each module to a single developer; others may not change their code, at most they can submit a patch. Weak code ownership works similarly, but anyone can reach into someone else's module — the owner monitors the change and oversees consistency. Collective code ownership, which comes from Kent Beck's Extreme Programming of 1999 (hereinafter XP), abandons individual ownership entirely: the code belongs to the whole team and anyone can change anything.

Fowler himself rejects strong ownership as too rigid; he openly writes that of the three models it is the one he dislikes, because developers too often need to reach into someone else's code. Strong ownership moreover turns all internal interfaces into "published interfaces" with high costs for any modification — if you cannot touch the calling code, you cannot perform a number of desirable refactorings either. Fowler regards the choice between the weak and collective models as a question of the team's social dynamics, while he himself prefers collective ownership in the context of XP.

Beyond the boundaries of Fowler's taxonomy, several other approaches have emerged. The stewardship model, which Brad Appleton (then at Motorola) formulated in the mid-2000s and which Nicole Tietz-Sokolská reworked again in 2025, reframes ownership as care: the steward is not a gatekeeper, but a mentor and a protector of the code's integrity. The CODEOWNERS model (GitHub, GitLab) automates weak ownership — a file in the repository maps path patterns to specific persons or teams who must approve the relevant pull requests. The Linux kernel's maintainer model introduces hierarchical ownership of subsystems with a chain of trust from the developer through the subsystem maintainer up to Linus Torvalds. And InnerSource brings open-source principles inside the organization: the host team owns the project, and Trusted Committers accept contributions from guest teams.

Empirical data consistently show that concentrated ownership is associated with lower defect rates. The study by Bird and colleagues from Microsoft Research (ESEC/FSE 2011), which analyzed Windows Vista and Windows 7, found that the number of so-called minor contributors — developers with a share below 5% of changes to a given component — correlated with the number of defects more strongly than any other metric Microsoft tracks. After subtracting known quality factors, files with a larger number of these marginal contributors had more bugs both before and after release, in both versions of Windows.

The replication study by Greiler, Herzig and Czerwonka (MSR 2015) extended the research to four major Microsoft products — Office, Office 365, Exchange and Windows — and confirmed the original finding: weakly owned files have on average six times more bugs than strongly owned files. Classifying defective files based on ownership metrics achieved a precision of 0.74 and a recall of 0.38 at the file level and 0.76 / 0.60 at the directory level. Among the most important predictors were the number of contributors and the share of changes of the smallest contributor; the count of minor contributors alone, however, was for some products conversely the least informative, so the picture is not entirely uniform.

But the advantages of strong ownership do not end with defect metrics. Deep knowledge of the code enables faster and more accurate decision-making. The study by Borg, Tornhill and Mones (EASE 2023) showed that in low-quality source code, peripheral owners need 45% more time for small changes and 93% more time for large changes than dominant owners — it is precisely in burdened code that those who know it least are most disadvantaged. Clear responsibility at the same time removes the diffusion of responsibility; Amazon took this logic to the extreme with the concept of single-threaded ownership, where a two-pizza team (a team of up to 8 members) owns the entire life cycle of a service. Architectural coherence is then a natural consequence: the owner of the code, for example within Google's OWNERS system, assesses the technical debt of every proposed change.

The security implications are even more pronounced. Meneely and Williams (CCS 2009) found that Linux kernel files into which nine or more developers reached had roughly a sixteen times higher probability of a security vulnerability. In a follow-up replication on the Linux, PHP and Wireshark projects, files with six or more developers showed roughly a fourfold probability of a vulnerability, and changes by less experienced contributors were, according to later work, by an order of magnitude (1.8× to 24×) more prone to vulnerability than changes by experienced developers.

Despite these qualitative advantages, strong ownership has serious structural weaknesses. The most cited risk is the bus factor — the number of people whose departure would jeopardize the project. Avelino and colleagues, in a study of 133 popular GitHub projects, found that 65% of them had a bus factor of at most two; in other words, two thirds of the systems stood and fell with one or two key people. The departure of a single developer, voluntary or forced, can cripple a critical component.

The everyday manifestation of the same problem is the bottleneck. Fowler points out that convincing the owner of a needed change and waiting for its implementation often takes so long that it leads to delays and deeper troubles. Even Google, with its sophisticated OWNERS system, admits that the requirement of approval by more senior developers easily leads to overload; pull requests touching critical parts of a system without a clear owner then often lie idle for days on end.

The long-term strategic risk is the knowledge silo. Developers prefer to duplicate someone else's code into their own module rather than wait for the owner, and this gives rise to technical debt and divergence of implementations. Even Spotify, which otherwise practices internal open source, describes its experience with this model as one of a not insignificant amount of wasted time and unshared knowledge. Strong ownership also affects team morale: experienced developers who do not get access to interesting parts of the code may lose motivation. Tellingly, according to internal experience, Google's Android team attracted new people partly by the fact that, unlike other Google teams, the strict readability process did not apply to them.

Kent Beck proposed collective ownership as one of the twelve key practices of XP with a clear justification: on a project run according to XP, he claimed, you are never trapped in someone else's stupidity — you see an obstacle, you remove it. Ward Cunningham added that shared code paradoxically strengthens pride in the work done, because it is permanently in view of the whole team, instead of being hidden behind an opaque interface. Collective ownership moreover reduces the bus factor: teams practicing pair programming and shared ownership lose only around 20% of code knowledge when one to three members leave — a fraction of what happens with the individual model.

Google applies collective visibility in a monorepo of more than two billion lines of code, where every engineer can read and propose changes anywhere. Code reviews are mandatory and serve as a mechanism of knowledge sharing; the company puts it this way: code review strengthens team ownership — the code is not "theirs", it belongs to engineering as a whole. Meta goes even further and actively encourages developers to make changes to code maintained by other teams.

But the collective model works only with robust supporting practices. Without them, it degenerates into "non-ownership," a state in which no one feels responsible. Amazon, on its blog, names the problem with a proverb: when everyone is responsible, no one is responsible. Microsoft Research therefore distinguished, in the replication study, two forms of weak ownership — intentional collaborative ownership with clear roles, and unintentional non-ownership with minimal responsibility. Only the latter is problematic, but the boundary between them is easily crossed.

The tragedy of the commons then manifests itself in a measurable degradation of quality. Ribeiro and colleagues, in interviews with nineteen developers, identified six advantages and six disadvantages of shared code; among the disadvantages were more frequent conflicts in the team and longer development time. Meta provides a vivid example: developers use the internal interfaces of other systems, which are not intended for external use, which leads to outages when those interfaces are changed. And Jay Fields described how collective ownership in a team of senior developers slid into a "last in wins" pattern — the resulting form of the code was determined by whoever changed it last.

Another symptom is inconsistent code style. Google invested considerable resources into a system of readability certifications and company-wide style guides — a costly measure that most organizations cannot afford. Without a comparable mechanism, collective ownership suffers from stylistic chaos and gradual architectural erosion.

Academic and industrial research gives the decision about an ownership model a decent quantitative basis, but it must be read with caution. Among the strongest pieces of evidence is the study by Nagappan, Murphy and Basili (ICSE 2008): on data from Windows Vista, organizational metrics — the number of engineers who touched a given binary, the number of departed employees and the like — predicted defect rates with a precision of 86.2% and a recall of 84%, that is, at least eight percentage points better than traditional code metrics. Nagappan himself admitted they had not expected such precision.

A different angle is offered by the DORA (DevOps Research and Assessment) report of 2024. It does not study code ownership in the academic sense, but it examines closely related concepts: team autonomy, clearly delineated responsibilities and loose coupling of systems. Teams with well-defined responsibilities show stronger results across all four DORA metrics — deployment frequency, lead time from commit to deployment, change failure rate and service restoration time. Elite teams deploy on demand, with a deployment time under an hour.

Crucial, however, is context dependence. Foucault and colleagues (2014) replicated Bird's study on open-source projects and found that ownership metrics did not correlate with defects in all the systems examined; the effect of ownership is evidently stronger in corporate environments with stricter processes. And one more caveat applies that cannot be passed over: all the cited studies are correlational, not causal. They show that concentrated ownership and lower defect rates go hand in hand, but they do not prove that the former causes the latter.

Most successful technology companies today do not use a pure model, but hybrid approaches combining clear responsibility with openness. Five patterns are widespread.

InnerSource (PayPal, Siemens, Airbus, BBC) brings open-source workflows inside the organization. The host team owns the project and determines its direction; Trusted Committers guide contributors from other teams and approve their pull requests. The key principle reads: contributions from outside must be the exception, not the rule — otherwise the experts spend all their time reviewing someone else's code.

The stewardship model reframes the relationship to ownership. Nicole Tietz-Sokolská sums it up by saying that owners care about the value of what they own, while a steward cares about how well it can serve the group. The steward consults on changes, handles production incidents and oversees architectural decisions, but does not function as a gate that blocks others.

CODEOWNERS with open pull requests (Google and the broader GitHub ecosystem) introduces automated weak ownership: anyone can propose a change, but the system automatically requests approval from the owners of the affected directories. On top of that, Google adds a third layer — a readability check by a reviewer certified in the given language.

Ownership rotation systematically shifts responsibility for various parts of the code among developers; pair programming during these transitions transfers knowledge smoothly. The InnerSource Commons community therefore recommends rotating even the role of Trusted Committer itself.

And finally, the AREA model (Mike Cvet, 2024) decomposes "ownership" into four dimensions: accountability (who must ensure correct and safe operation), responsibility (who does the actual work), expertise (who understands the system best) and authorization (who may approve changes). These roles need not be held by a single person; separating the dimensions makes it possible to design ownership structures much more precisely.

The choice of model depends on four factors whose weight each organization sets for itself: productivity (a permanent owner delivers faster), quality (an experienced owner makes fewer mistakes), risk (the bus factor upon the departure of key people) and developer satisfaction (some want stable territory, others variety).

Small teams of two to five people should lean toward collective ownership or stewardship. In such a small group everyone should know the entire codebase, and pair or mob programming is the most effective for the distribution of knowledge.

Medium-sized teams of six to fifteen people benefit from weak ownership complemented by a CODEOWNERS file: clearly delineated areas of expertise, but open contributions through pull requests with mandatory review by the owner. Dual review, in which one reviewer comes from the owning team and the other from outside, provides both architectural control and a fresh perspective.

Large organizations of over fifty developers need formalized team ownership of services and InnerSource for collaboration between teams. A proven framework is offered by Team Topologies: stream-aligned teams own entire business domains, platform teams shared infrastructure, and enabling teams temporarily help build the capabilities of others.

Regulated industries — healthcare, finance, defense — require stricter governance: CODEOWNERS with mandatory reviews, clear audit trails and authorization controls. Here CODEOWNERS functions as responsibility and compliance written directly into the repository.

Junior teams should start with stronger ownership, where seniors manage critical areas, and gradually move toward the collective model as experience grows. Fowler describes a case from practice in which a team switched from collective to weak ownership precisely because less experienced programmers were making mistakes in key code; the solution was to allow work across the entire codebase, but to make changes to the core in collaboration with someone who knows the given part well.

Microservices are naturally compatible with strong team ownership under the motto "You Build It, You Run It" (Netflix, Amazon): each team owns its service from design through development to operation. A monolith, by contrast, calls for collective ownership within the team and weak ownership between teams.

Research clearly shows that some form of clear ownership is essential for code quality — Microsoft, Google and Amazon arrived at this independently of one another. Pure individual ownership, however, creates unbearable risks for continuity and scaling. Practice has therefore settled on a spectrum between weak ownership and stewardship, underpinned by automation (CODEOWNERS, CI/CD, linting) as well as cultural habits (code review, pair programming, rotation).

Three findings stand out above the rest. The decisive thing is the difference between intentional shared stewardship and unintentional absence of responsibility; the problem was never in sharing, but in no one claiming responsibility. Furthermore, ownership should be assigned to teams, not individuals — this is the path taken by Amazon, Netflix and Google. And finally, the model should be situational: it should adapt to the maturity of the team, the complexity of the domain and the organizational context, much like situational leadership of people.

Brad Appleton, in the debate about balancing individual and collective ownership, summed it up simply — what decides the success of both extreme models is the presence of a steward. If there is someone who cares for the code, both strong and collective ownership can work. If one is missing, in the end neither will succeed. The question, then, is not "who owns the code," but "who cares for it."

Transparency of creation:

The conception, structure and editorial line of the article are the work of the author, who prepared the content sketch, established the key theses and directed the entire creation process. Generative AI (Claude, Anthropic) was used as a tool for research, searching for primary sources and the formulational elaboration of the author's content sketch.

The author edited the outputs continuously, verified the key findings and approved the final wording. No part of the text was published without human review. All factual data were verified against the publicly available sources cited in the text.

The procedure complies with the requirements of Art. 50 of EU Regulation 2024/1689 (AI Act) on the transparency of AI-generated content. #poweredByAI