@cellard:
Indeed, Bitcoin Unlimited has fewer full-time developers than Core. However, there is less work to do, as first-and-foremost Bitcoin Unlimited was intended as a patch-set on top of Core to permit node operators and miners to more easily adjust their node's block size limits and signal their preferences to the network.
Should we get larger blocks, then clearly all of the good developers presently contributing to Core aren't going to simply disappear. Some will patch Core to be compatible while others will move to BU, Btcd, etc. So the idea that larger blocks would lead to fewer developers doesn't make much sense. In fact, since larger blocks would permit Bitcoin to continue to grow how it did during it's first 7 years, larger blocks would likely result in more developers. Hopefully we end up with both more developers and more implementations, helping to decentralize development.
Regarding your comment about BU making improvements beyond the block-size limit patch set, BU was the first client to successfully implement thin blocks, significantly reducing the amount of time and the number of bytes required to communicate a block.
Indeed, Bitcoin Unlimited has fewer full-time developers than Core. However, there is less work to do, as first-and-foremost Bitcoin Unlimited was intended as a patch-set on top of Core to permit node operators and miners to more easily adjust their node's block size limits and signal their preferences to the network.
Should we get larger blocks, then clearly all of the good developers presently contributing to Core aren't going to simply disappear. Some will patch Core to be compatible while others will move to BU, Btcd, etc. So the idea that larger blocks would lead to fewer developers doesn't make much sense. In fact, since larger blocks would permit Bitcoin to continue to grow how it did during it's first 7 years, larger blocks would likely result in more developers. Hopefully we end up with both more developers and more implementations, helping to decentralize development.
Regarding your comment about BU making improvements beyond the block-size limit patch set, BU was the first client to successfully implement thin blocks, significantly reducing the amount of time and the number of bytes required to communicate a block.
There will never be "massive onchain scaling" without massive node centralization. Why is it so hard to understand?
Also, such flexibility on the setup may seem like a nice thing at first, but upon deeper inspection, it opens a nasty can of worms and all sorts of attack vectors. Same blocksize for all is actually a strenght. We need a strong set of rules. Im sure someone like gmaxwell can give a deeper technical answer and also explain the game theory and possible attack vectors that such such flexibility to change the blocksize on such level would mean. (yeah, im sure franky1 the resident coding genius that never coded anything relevant hates gmaxwell and knows better so he will ignore anything he says)
Unfortunately, I don't see ANY possible way to scale onchain anywhere near what we would need to conquer the world as a viable payment transactor that can replace the existing centralized options.
Want to compete with VISA? then get it throught your skull: we need a second layer solution, there's no way out, unless a time traveller or an alien from outter space with super advanced technology comes up with the actual next bitcoin that will make us overnight billionaires by buying in the first day. Until then I hope you understand the mistake of not supporting Core devs and LN. So far they haven't fucked up bigly enough to risk a god damned hard fork. We don't want a Buterin event... that is what could kill the network effect forever (and im sure everyone that has an anti-bitcoin agenda is aware on this, hence why they push with BU so hard)
Ps: I've heard the Roger crew pushing for way less than 94% so the hardfork would be nasty. They know they would never get anywhere near 94% no matter how many millions they invest in their propaganda.