Also, poor communication skills and "immaturity" have also been a "traditional" problems in FLOSS too. Being unwelcoming to new devs is especially a big problem for a project that _is already_ losing the old trusted devs.
https://github.com/bitcoin-dot-org/bitcoin.org/commits/maste...
As long as the core coders can associate and work well with good communicators, it's all good as far as I'm concerned.
A welcoming community doesn't need to coddle everyone who might send a patch, because that's a lot of people. If they want to succeed, they should document enough to get started, and review unfinished patches.
The comment I replied to does not challenge the assumptions, but the conclusions. Whether the assumptions are true or not, I do not know.
> It is worth noting that bitcoin core’s response to scaling has been to propose a solution called segregated witness. While it is a well done piece of technology, I believe it would be quite risky
SegWit is not a compression technique, it is a bandwidth redundancy reduction technique. It simply makes it so that some nodes doesn't need to fetch all of the transaction data.
Only compression or merging can increase the transaction count per block without becoming incompatible with old full nodes.
But sure, it is a backwards compatible way to reduce overhead for old nodes. But if they want to remain full nodes then they must upgrade and take on larger storage and bandwidth requirements anyway.
Can you clarify what you mean by the majority hash rate needs to enforce the new rules?
If someone blindly accepts non-standard zero confs they've got bigger problems.
It also addresses some of problems with validation costs that are quadratic in transaction size.
It's also, by far, not the only tool in the Increased-capacity-without-harming-decentralization tool belt, for example I recently described a new approach for signature aggregation which, if applied to the current transaction load would decrease transaction sizes around 30% while making verification somewhat faster.