Unfortunately the primary maintainers of GIMP basically have an attitude of "we want to do it our way, and at our pace", and are not willing to accept any patches outside of that pattern.
Which is both a blessing and a curse - on the one hand, consistency, on the other hand, not welcoming to people who want to try something different.
I don't understand this comment, every single software project in existence is like that. The pacing and threshold of what they'll accept is just different between projects. If you had some patches that get rejected, that's unfortunate. But that's a risk you take with any project, and you're also asking the developers to take a risk by accepting your patch. Some may have higher risk tolerance than others.
Yes that's true. But by accepting an unusual patch you could also risk having a feature that doesn't fit in well with the rest of the project, breaks something unexpected in another area of the project, takes up a lot of maintainer time that could be spent on other things, could break further in the future and need to be removed, which would further upset the users... So it's a trade-off that every project must decide to make in their own way. AFAIK it's not possible for a project to bend to every potential contributor's will, else the project drifts into the old unmaintainable big ball of mud.
If you knew a way to develop software like that where everyone could get their way all the time, please let me know, we could turn that into a product and get really rich selling it to every software company.
> an attitude of "we want to do it our way, and at our pace"
In Japanese, there is a term for this, and it's actually borrowed from the English "my pace" (マイペース). If somebody has this attitude, you can call them a my-pace. From what I've seen, that term is always an insult: nobody ever calls someone else a my-pace as a compliment.
Main problem for gimp now is under-funding. Although slow, their approach may be sound: features will land once they are good enough to work and well written enough to be maintainable. This may be slow but keeps the mechanism working for decades even with a very small team.
Studios need features implemented immediately. That usually generates functional but unmaintainable solutions. Note that filmgimp/cinepaint was abandoned by studios as well as gimp developers.
What studios should have done: fund main gimp developers and hire other developers to help accelerate the development of GEGL or other multi bpp lib. What gimp developers should have done: try to merge enough of the studios changes to keep them interested.
We can look back in hindsight and say that, but at the time it may have just been that nobody had the resources to do those things.
I agree with your sentiment that some forking is preventable, but other times it isn't. Changing the fundamental design of the program tends to be one of those things that can't really be merged without causing a lot of other problems.
Which is both a blessing and a curse - on the one hand, consistency, on the other hand, not welcoming to people who want to try something different.