> For contrast, to drive or be responsible for a project is to sweat the details, to keep on top of communicating status, to go the extra mile with testing and get the work done on time. If you ask someone to own a project, aren’t they within their rights to simply not do anything and forget about it? After all, they do own it, so why shouldn’t they do what they want with it?!

People don't tend to invest themselves in or take responsibility for projects in which they don't have an ownership stake, including the ability to make decisions independently. This is why we have property rights in real-life. Consensus and cooperation don't scale without bright line boundaries around who has ultimate responsibility for various components.

But having an ownership stake is merely necessary, not sufficient. People don't fully invest in some property unless they're deriving immediate benefit or there's the threat of it being taken away.

The concept of adverse possession in the Common Law is instructive on this point. If someone begins to improve a piece of property while the nominal "owner" sits on his hands, guess who the law recognizes as the owner? I'm simplifying a bit, but my point is that if an owner is neglecting a project people should feel free to take ownership and the rules should reflect this. Ownership really only matters when there's substantive conflict, and such conflict is precisely when you want and need clear boundaries.

Employees proactively supporting each other and proactively picking up the slack isn't disincentivized by ownership. Ownership is perfectly reconcilable with a culture where people feel free to innovate and invest, you just need to make sure the rules are clear and goal oriented.[1]

Avoiding nominal ownership because of fears of conflict and tension doesn't actually resolve the fear and tension. People are social creatures--the fear and tension reflect expectations and anxiety about how others will directly react to their contributions. Lack of ownership makes this worse by removing a clear cut conflict resolution mechanism. If project owners aren't accepting contributions it's either because they're fearful of losing ownership, in which case the solution is to validate their ownership, or they're neglecting their responsibility as owners to improve the project, in which case ownership should transfer to someone willing to take on that responsibility.

> So why not start using "author" instead - which captures exactly the intended meaning - "I authored this doc, come to me if you want to know more or have questions".

Who cares about authorship? Authors are only useful for clarifying history--answering retrospective questions that aren't self-evident from the code. The questions that matter the most are prospective--in which direction is the project going? If I implement feature A in such-and-such manner, will it conflict with feature B? Only someone with meaningful control over future authorship can answer those questions, and that person--if they exist at all--is by definition the owner, regardless of whether they were, are, or will be an author.

[1] I like the Hacker Ethos, which is he who writes the code gets deference. A corollary is that if a nominal owner is dilitory, then the contributor should be free to take ownership--this often ends up the de facto state of things, anyhow, especially in the open source world. At work I try to apply the rule this way: if someone makes a contribution that provides substantive benefit and it doesn't imminently conflict with existing work ("planned" work doesn't count!) and isn't patently incorrect, then I'll accept it. Case closed. I may think it's the wrong approach, but the fact this person solved a problem while I was working on something else is strong empirical evidence about the best course of action for realizing substantive benefit globally; it can't be dismissed without equally strong manifest reasons.