That’s part of it. But the community pool also never even had enough funds to consider funding core development until early this year, after the percentage was increased from 2 to 10. Of course just because it has the funds doesnt mean it has the structures, or as you say the policies. We need to build those up.
Yes this has been a major focus for the ICF, but there are naturally constraints on what it can do. There was also an initial separation of concerns between ICF and AiB, with AiB expected to lead organization of Hub development, as the ICF nurtured the Interchain. With AiB fallout, that all collapsed back on the ICF. A big part of what the ICF had to do the last 3 years was figure out how to re-organize a Hub team in the first place, after the original team and incentive structure broke apart.
The ICF is probably not the right body for ultimate accountability of the Hub’s core development teams - that would be better served by the Hub itself. Of course we need to build the policies and structures to enable that. But that’s not to say the ICF doesn’t have many other ways to support the Hub and the growing AEZ, and having the Hub take over responsibility for its own development will allow the ICF to focus on other means to support the Hub.
Of course, and they are. Historically this has been difficult to define in the absence of a Hub team. And there has been significant demand on the interchain stack from a diversity of projects across the interchain. We need to find ways for these projects to meaningful support core development of the stack they depend on and currently use for free, and to define the relationships between core stack development and the Hub. The interchain stack also does not have unified technical organization, which makes coordination across the layers more challenging. That said there are new directions for the Hub like AtomicIBC that will for instance drive requirements in CometBFT.
Absolutely. We even wrote a guide on a language for accountability called workflow: https://workflow.informal.systems/ . We strive to use it internally to get better at making and managing promises. I’m sure it could help here too 