> With Qt you get "this is the API, live with it". This is true often, but not always. Quite a bit of Qt APIs get created collaboratively on gerrit; I've had A

> With Qt you get "this is the API, live with it". This is true often, but not always. Quite a bit of Qt APIs get created collaboratively on gerrit; I've had API changed based on my input. It's also possible to contribute APIs; I've done that, too. Some bigger new modules or API surface area is also moved through Qt Labs first before becoming part of the product, making for a longer feedback period. We've also had Qt folks actively attending events like Akademy to demo new WIP APIs and gather feedback and feature requests and engage in PoC ports of real software. There's also venues like the annual Qt Contributor Summit for larger discussions. You're right that this open approach is not the only channel for APIs into Qt, and in hybrid communities like his there's always some tension, and of course having to be a little "in the know" or engaged in the community means there's perhaps a higher barrier to entry in some ways. I respect not liking that and preferring if there's only a community-based channel. It's also worth pointing out that for the most part, Qt has a fairly healthy approach to low/mid/high level customizability and extensibility to its API. It has internalized this as one of the reasons for its success, even if it sadly fell a bit by the wayside during the early Qt Quick years. That means that "this is the API, live with it" is not really a straitjacket - you get to override, supplant, extend a lot.