It's worth emphasising that there is no one particluar developer the community should follow. People will naturally run whichever client is most representative of the rules they think the network should be governed by. No developer has any inalienable right to be the ones we "follow". Since it is ultimately up to users, it shouldn't really be described as "taking over". No one ever takes over the power users have.
In effect, we only follow them while they provide the best code.
it would have be easy to follow any client. IF it was not for cores REKT, "fork off" bilateral split campaigns that literally treat core opponents as "network attackers".
There are clearly some incredibly vocal supporters of Core. Some of them do take things to extremes. While it generally pervades the forum narrative that it's the supporters of alternative clients who supposedly act with "bad intentions", it's worth pointing out that some of the more militant, tribalist Core supporters have exhibited behaviour in the past that could be considered an attack on consensus. Things like encouraging client spoofing to manipulate statistics of current support levels, impersonating Satoshi to discredit fork proposals and even DDoS attacks on alternative clients. We've seen all of that and more. And I'll continue to argue against that kind of behaviour when I see it. I'm under no illusion here that it's an incredibly hostile environment for alternative clients to make any ingress.
But chances are, at the very least, some people will continue to describe any alternative client proposing consensus changes an "attack" or a "power grab" and have yet another "REKT" social engineering campaign whenever the opportunity arises. Even for those of us who don't believe that's a rational argument (and I certainly don't, because there isn't a central entity in Bitcoin to take power from), there's nothing you can do to prevent them saying that, as they're free to express their opinions. All anyone can do is state why you might disagree and argue a compelling case to the contrary. Granted, I don't seem to be having much success with that here, but still. I'll say it again just in case: alternative clients that propose changes in consensus rules are
not attacks, power grabs, coups, hostile takeovers, etc and should not be relegated to the altcoins subforum until a fork has occurred and that chain is the minority fork.
However, while I'm sympathetic to your stance, I have to make it clear that while
supporters are acting in this way, that should be no reflection on what any dev team themselves are doing. All the developers are doing is producing the code they think is best. If they want to do that via strictly moderated channels and procedures to produce what they believe is the strongest and most resilient code, that's entirely their prerogative.
but dare anyone to start their own version with their own OPEN and UNMODERATED bips proposal. that tried to defy cores closed and modered BIPS.. you would soon see that consensus would be avoided by core and new REKT, "fork off" and bilateral split campaigns occur again. even if core only had 35% vote in its favour before their fake election trigger day
It once again sounds like you're blaming one particular dev team for the way in which it's difficult to change consensus in Bitcoin. Any dev team can have prerequisites and processes that need to be adhered to in order to submit new code. Just because Core are quite strict and regimented about what can go into their repo, it doesn't mean they have any influence about what code goes into other clients. Ultimately it's still the users who are effectively forcing it work in this way, because it's the users who are choosing to run the code that has gone through such a rigorous process and rejecting other clients which may arguably be less stringent. But again, if they could do it without the social engineering REKT silliness, that would be an improvement. People should make more of an effort to be neutral and impartial about these things and not just jump on a bandwagon because it's popular. Ultimately, though, if the current methods are what the majority of users approve of, that's how it'll continue to be done. So blame the users, not that one dev team.
