
I started avoiding the word 'own' - rosshemsley
https://rosshemsley.co.uk/posts/no-own/
======
wahern
> 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.

