@cryptonaut great points here
@maxentropy
Adam says:
How has he shown this? Can you link to anything? - Why is development any less centralized with two voting developers compared to five? are they both really centralized by any standard? Why does "Andresen being a poster child for XT but control lies in London" matter?
--
Software developers who can not lead the development activity are quickly moved aside - in development projects. Competent developers are unlikely to follow the designated lead developer, if the lead can not demonstrate leadership skills both technically and design.
So... if Andresen has thrown the towel in with Bitcoin Core team and hence any possibility of achieving the bump to Block Size, then he is not seen as the lead developer.
I don't believe Gavin is the lead developer of Bitcoin Core, and I don't believe he leads the team - They're all equals right? That's what's led us to this problem - If Gavin was the boss he wouldn't need to get every single person to agree and in practice this is them saying they don't believe they can
--
Code changes incrementally... design features are slipped into the code base without distribution channels; 3rd party developers and customers... knowing. New software releases are always required, else the software becomes stale. This requirement introduces the need to keeping evolving the code base at different levels. There will be 'features' added that do not affect the backwards compatibility that advance someone's interests.
It is the features that are slipped in that are subject to regional interests. Example, if Microsoft funded Bitcoin Core you would see Addon's and extensions and eventionally multiple implementations of Bitcoin Core... unique to Microsoft's interests.
I do not sense that Reddit follows the code changes in Github closely... so who would know?
Years ago I proposed a "Bitcoin Watchdog" that would have bitcoin media embed bitcoin-core "correspondents" within the developer haunts to pro-actively report and alert on anything important that might warrant educating the broader community about. The idea was for it to be somewhat cooperative and somewhat competitive and to limit the amount of developer time it required so they could focus just on developing. Might be time to revisit that idea if there is interest.
--
California should not outsource Bitcoin software development to the UK, London group.
I don't understand why this matters? I live in California, it's not a good environment here either
@maxentropy
Adam says:
Do you also have this curiousity for who is funding developers supporitve of the no-block-increase school of thought? Seems like everybody is obviously operating in what they perceive to be their own best interest in both camps.
--
I would have thought that if Hearn wanted to affect positive change, then he would have made a 'single code change' to the Bitcoin Core software for the Block Size fix. Anyone could have done this.
He did not do that, he forked the project and has introduced a great many code changes.
Why?
If as Hearn and Andresen argue, that the Block Size change is so urgent... simply advocate for changing the Bitcoin Core.
They are not doing that.
Why?
Because it's been made clear that it won't be allowed in core? It's not like they just proposed this in a vacuum, the discussion has been ongoing for months and lacking any sudden shifts of long-standing positions this won't be allowed in core. Are you just looking for the symbolism of having made the attempt even if it's obvious it cannot succeed in the current environment?**
@maxentropy
Adam says:
Do you also have this curiousity for who is funding developers supporitve of the no-block-increase school of thought?
--
No... I expect that the developers simply need a source of funding. MIT stepped up after the fiasco at the Foundation became apparent.
I still advocate for California to take the project back.
The project lives on Github, I don't get the importance here