On Thu, Jun 18, 2015 at 5:00 AM, Mike Hearn <mike@plan99.net> wrote:
Dude, calm down.

Well hold on, his concerns are real and he seems perfectly calm to me and others apparently.
 
and Gavin already said long ago he wouldn't just commit something, even though he has the ability to do so.

Nobody is worried about Gavin or anyone else making commits to git repositories. You'll notice that this wasn't even mentioned in the original email you were replying to. Instead, the email was talking about commit access, which is a property of GitHub's repositories.

So why did I say it? Because it's consistent with what I've always said:

(That's not a good reason.)

you cannot run a codebase like Wikipedia

Wikipedia is a top-down centralized authority-based hierarchy. That's pretty close to what you're proposing. That's what everyone else is disagreeing with. You seem to have switched your position mid-flight...?

This is not a radical position. That's how nearly all coding projects work. I have been involved with open source for 15 years and the 'single maintainer who makes decisions' model is normal, even if in some large codebases  subsystems have delegated submaintainers.

There are a number of reasons why that perspective is broken; throughout our conversations others have repeatedly reminded you (such as in -wizards) that forking an open-source repository is not at all like a hard-fork of the blockchain. Anyone can be glorious leader of any repository they want, that's how open-source works. However, it's critical that bitcoin users are never convinced to trust BDFLs or anything else that can be compromised. Should all bitcoin users suddenly start using software with BDFLs, even multiple implementations with separate BDFLs, then those users can be trivially compromised through their trust in those individuals and projects.

The alternative is that every developer and every user is personally responsible for self-validation of the rules, checking for correctness and validity. Happy coincidence that this seems to match the strategy of operating the bitcoin network itself, which is to run a node that sees everything and validates all the transactions. Anyone is able to find an error in logic or flaw in the system rules, and they should make it known as widely as possible so that others may evaluate the evidence and consider which solutions preserve the important properties of the system. This is not a matter of majorities or minorities; these arguments should be true for anyone independent of who or what they are, or what level of unpopularity they may have.

Anything other than this is somewhat radical, and I am confused as to why others have been talking about "developer consensus". I suspect that the reason why they have been saying developer consensus is because they are talking about the Bitcoin Core project on GitHub at the moment. But the topic switched to contentious hard-forks already, which is not a topic of repositories but a topic of the blockchain and network; and in the context of contentious hard-forks it is clear why everyone individually must evaluate the rules and decide whether they the software is correct, or whether changes can trivially cause catastrophic broken hard-forks. These lines of reasoning should be true for everyone, and not merely true for one person but not another. Users, companies and developers must be aware of this, even though it's different from their usual expectations of how systems operate and are maintained. And it is important to be careful to not misconstrue this to others because it is entirely possible to unintentionally convince others that traditional and centralized models are safely applicable here.

I realise some people think this anti-process leads to better decision making. I disagree. It leads to no decision making, which is not the same thing at all.

Well, if you're talking about the recent disputes regarding a certain patch to hard-fork the blockchain, a decision to not include such a patch seems like the very definition of a decision.

Gavin and I say - there is a process, and that process is a hard fork of the block chain.

I doubt that other bitcoin software maintainers would agree with that sort of toxic reasoning; contentious hard-forks are basically a weapon of war that you can use against any other collaborator on any bitcoin project. Why would anyone want to collaborate on such a hostile project? How would they even trust each other?

- Bryan
http://heybryan.org/
1 512 203 0507