Feel free to run an alternative implementation, you are absolutely right on bitcoin being permissionless and FOSS.
However, as you mentioned, a chainsplit is a risk and the outcome can be messy. When things get messy, it is safer to be on the side of the majority. So Bitcoin Core may not be your implementation, but a bug in Bitcoin Core could very well be your problem.
Chain split is not a problem. Where does this FUD even comes from.

Implementation follows specification.

That's how computer science always works, that's how the Bitcoin protocol works. Not the other way round, why should the Bitcoin-core implementation be the authority.
I can truly only shake my head about this. Why do Bitcoiners suddenly forget that decentralization was the whole point from the beginning. Why are we forgetting this and becoming defensive when it's about the Bitcoin implementation? Is it cognitive dissonance? I truly truly don't get it.
reply
Implementation is not the same as specification. Bugs happen, and they are never specified. Chain splits are a risk and have happened in the past. When it happens either there is a hardfork into two coins, or one of the two chains is abandoned. Neither is a positive outcome, and bitcoin will be (seen as) damaged either way.
Bitcoin is open source, and open source is decentralized. If you are not happy with Bitcoin Core feel free to fork the code or start your own implementation.
reply
The thing is: you can run your own implementation. No one stops you.
It just doesn't make sense since bitcoin is also based on consensus. So your implementation (or should we say, fork if you don't abide by the rules of core?) doesn't matter if it has no consensus and you just risk forking yourself away from the chain (assuming there are also miners who run your implementation).
Shaking your head about only one implementation being out there is the same as shaking your head that bitcoin woris only one chain with the most consensus behind it.
There is no cognitive dissonance at play here. Just pure game theory of bitcoin at work.
If you want to change the protocol, you have to contribute to core since that's the best way to make sure enough people will in the end actually run your code.
Just my 2 sats
reply
The question I was trying to get at is whether we should spend time and effort trying to increase the percent of nodes/miners who use implementations other than Core (even though it increases the severity of a chain split).
Bitcoin is permission less, but it's also political.
reply
I think we should prevent the risks of having a single implementation (censorship, centralization) with repository mirrors, more transparent release process (don't know how transparent it already is), node signalling for features instead of only miners etc. for example.
But I think the solution is not to create multiple implementations which will be very hard to be 100% compatible with each other for ever while also making it harder to upgrade the network since now you need to maintain/care about multiple implementations.
You initiated a very good discussion, thank you. Here, have some more sats, the original post is "undervalued".
reply
Just saw my typo:
same as shaking your head that bitcoin woris only one chain with the most consensus behind it.
Wanted to say "that bitcoin works by having only one (valid) chain ..."
reply
I don't come from the computer science world, but the main impression I get from Bitcoiners is that 90%+ nodes and miners running Bitcoin Core is no big deal. It is surprising that there isn't a larger push to develop different implementations and the communities that support them.
reply
It's not so much a defense against bugs, as it is a defense against the centralization of protocol development (that carries with it the risk of increasing the damage done by bugs).
It may be safer to be on the side of the majority, but the question is should we try to make the majority less major, or is that too risky (something that many people seem to believe)?
reply
reply
Bitcoin is based on consensus. And consensus by definition needs a majority. So it makes sense that the majority runs the same code.
Since they agree on the rules already anyway. So why use another implementation?
reply