In the end, someone has power over the things in the real world, like releasing a version of the software or purchasing stuff. So everyone involved has to trust that someone at the least.
If the developer introduces a major change, it'll fork the chain. Everyone on the old version of the software will see one chain, everyone on the new version will see the new chain. If not many people switch, the old chain will be the valuable one. So it's kind of a voting system where the community as a whole votes. If the vote isn't decisive, both chains have value.
As far as purchasing stuff, there's no central purchaser that I can think of.
> If the developer introduces a major change, it'll fork the chain. Everyone on the old version of the software will see one chain, everyone on the new version will see the new chain.
Why? Can't the system keep using the same chain, or is this just convention? If any software change required a fork, you couldn't do even the most trivial of bug fixes (say, fix a typo in the UI, or whatever). But I notice you said "major change"; so who decides what's "major" and what isn't? On which grounds?
It's not convention. If it's possible to create a transaction that one version thinks is valid, and the other doesn't, someone will create such a transaction, it will be included in the chain that accepts it if that side has the majority of the hash power, and the other one will reject it. Thus you will have 2 chains (not to be confused with 2 Chainz).
The definition of "major change" in this case is a change that changes the definition of a valid block or transaction.
> Auditable in the sense that the code is there to read
Which code? Just your client code, or the code that miners and brokers and exchanges run on their servers, too? If the claim is the latter, how do you know that the published source code actually corresponds to the executables they're running?
