A few initial thoughts:
The statement that SAFE is built to provide simply and only [Privacy; Security; and Freedom], will go a long way to suggest what is a good change.
Trying to force consistency and a single instance or version of code, is the root of Bitcoin’s problem atm. Managing dynamic change requires art and flexibility.
It is perhaps worth noting that most technology that goes mainstream, does get normalised; so, there is a real threat that other interests will try to force change that they can exploit in whatever way motivates them.
A network that can fragment, is not a network that can be destroyed by stress. If SAFE is capable of splitting and fractioning into different communities where that is required, then there is no issue. The weak link here maybe Safecoins. If safecoins can move between SAFE networks, that would allow for variety. Still I see no reason there needs to be too much variety.
We need to know how flexible the network is - must there be only one protocol:
- What happens now when part of the network is split off from the rest?
- What happens now when separate SAFE networks then find each other again?
- Are safecoins fluid enough that they can move from one instance of SAFE to another SAFE network and back, without risk of being compromised? If it is possible to create safecoins in an evil network and then introduce them to the real network, then there’s an immediate problem right there!
Expecting a simple creation attack on safecoins is not possible, then my first thought is to wonder the answer to the OP follows from allowing difference and evolution. In the event a new code is not backward compatible, perhaps it will not be adopted? The worse type of evolution would be a cancer, something bad that corrupts the network. If the network is well built and draws strength from survival of the fittest, then perhaps we can be less worried about controlling evolution?
However, it is important to recognise that the community will need to know that they can trust any changes… and that requires authority, if it doesn’t require that each user understands the code.
I wonder then that informed consensus is best. That is have authority gifted to those who are widely trusted but in a way that doesn’t have them individually liable to risk and coercion. Most people are lazy; we need to encourage good developments not bad. Gifting capability to upgrade to Joe Bloggs would be foolish, where there might be options to retain authority but distribute it.
I would suggest that those who retain authority, are those devs who have made commits and changes that have been adopted. Perhaps then the route to becoming a new dev, would be only through having a consensus from old devs accepting new code. So, if 19 of 32 devs agree on a change, then that is signed off… with some multisig. That will help satisfy the wider community’s interest in knowing they can trust changes. If anyone can make a change to what is widely understood to be the real SAFE network, that would risk other interests corrupting it too easily.
In the event that some other rotten group of devs want to make a unlockedSAFE, then I don’t know what limits on use of code there are that maidsafe.inc would have to allow. Wider community will likely prefer the original and best - first mover advantage and heritage count a long way towards who people trust.
In the event that the physics of this new world are so stable that changes are not made in ways that enough new devs are being brought in, perhaps there can be a secondary option to have simple consensus among devs nominate others to join them, without those devs having contributed code. The risk of political pressure compromising many devs in order to secure corrupting code, would be mitigated by the code remaining open source and available for whistleblowing and public sight of debate.