Many of us are old enough to remember the kinds of projects that were freely and openly licensed and yet all you ever got was www.foo.org, foo-user and foo-deve

Many of us are old enough to remember the kinds of projects that were freely and openly licensed and yet all you ever got was www.foo.org, foo-user and foo-devel mailman lists, a foo-1.2.3.tar.gz of source code, and a foo package or port in your free OS of choice. Within each of these projects was an elite cabal of committers — those with access to the source tree, it’s history, and the ability to commit to it. Mere mortals couldn’t just become committers! You had to be proposed and seconded off the back of a prior history of helpful patches you’ve emailed to the lists over the past months. Nowadays anyone can commit to any project because a git commit is always in a fork of the repo. Every single git working copy is a fork, even if most of them are just a means to be able to push commits back to your own master on someone else’s machine, usually GitHub’s. I wonder why the author of this post can’t enforce the old social model with the new tools? Is it a sense of social pressure to accept patches they don’t want? (Edit: in fact they do say this out loud — it really is about the emotional burden of having to reject contributors and interact with strangers — fair enough, I feel that too sometimes!) One other extremely understandable problem with having a public repo to which it is easy to submit patches: the project owner’s level of plausible deniability for having seen copyrighted code drops to dangerously low levels. If the Yaak author was also worried that someone was going to put up a commit implementing something that was already on the project’s private roadmap, and that the external contributor would then claim some kind of IP ownership of the feature once it shipped, then I would be sympathetic to that stance as well.