I will counter that question with this…
What is the purpose of having conflicting flatpaks?
Flatpaks is intended to be a federated solution, how we are choosing to construct Fedora flatpaks puts us in direct conflict with upstreams who want to use the flatpak technology as intended, and build for the entire linux ecosystem of distributions as a single platform target.
We have to address that conflict. The opt-in filter lets us ease into addressing the problem, and will create an environment where we can discuss.. at length.. how to more optimally address that conflict by restructuring how (not why!) fedora flatpaks are constructed.. so that we are no longer in direct conflict. If we are able to make the necessary structural changes, then the existence of the filter should become moot… because we will have found other more optimal means to remove the conflict.
I’m not going to get into the value proposition of Fedora Flatpaks here. There is value there, but as long as we are constructing it in a way that is in direct conflict with upstream outputs it will be be difficult to articulate. Because right now what is blazingly obvious is that the conflict with upstream is damaging to project health, and its not clear to me that the conflict is necessary. So the opt-in filter is a compromise that we can implement right now, while we figure out the full technical solution and restructure our flatpak offerings so that they are not in direct conflict with upstream efforts.
We’ve put ourselves in a bind here because its clear we didn’t really think through how a federated flatpak environment should work to minimize conflict, before we spun up our own collection of alternative application builds. We missed something vital about what the flatpak federated landscape should be and we need to address it with some structural changes. The discussion I plan to lead will start in earnest at the Council strategic summit, from which I plan to have wider discussion to refine proposals.