Absolutely. For my workflow, the XCF requirement and the need to manually export were completely wrong. In the 23 years I've used it, I've never once needed the XCF file format. I acknowledge that others will need it, but I don't, and the change to the workflow made it significantly less usable for me.
This again comes back to the project management and project goals. There is very clearly a desired workflow and feature set that users are expected to use, and deviations from this workflow are not desired or well supported, and accommodations for non-standard workflows are not well received.
As a minor developer of open-source software, I've always been surprised at the diverse range of uses people have attempted with my software. Often things I'd never considered. In most cases, I tried to accommodate these uses so long as they could fit within the application design, and occasionally with some refactoring to fit them in. Because in most cases this was of net benefit to the application, widening its appeal and usability, and driving cleanup of the architecture to make it more flexible and more amenable to extension.
The unwillingness of the GIMP developers to support fairly basic vector and path operations speaks volumes. There's clearly a demand for it. They would be self-contained and not have any major impact upon the wider application. And yet, they have been repeatedly rejected. If I was the maintainer, I'd have considered and allowed their addition. But it seems that the GIMP developers do not want to expand the remit of their application, even if it would be of net benefit.
Please don't blame open source volunteers for not having the right skillset or for not having enough time to address every concern or merge every patch that comes their way. Everyone's got their strengths and weaknesses. I'm sure the GIMP developers would love to make a program that is really good at everything, but reality has a way of making that difficult. If you've got some spare time and can help with reviewing and merging and maintaining patches, maybe you can talk to them and work something out? Remember that any patch that gets merged has to be maintained for several years, so maybe you can see their reluctance there.
I'm well aware of the constraints of open source development and project management, having been involved in it for nearly 25 years at this point. In the case of this project, I was involved with it for several years as a maintainer of the Print plugin, if you care to read some of my other posts about the history.
You're wrong about the GIMP developers wanting a program that is "really good at everything". If that was the case, then they wouldn't have deliberately rejected so many proposals for improving workflows and adding features over the years. Film-GIMP is the most high-profile example, but there are dozens more. This is nothing to do with not having enough time. It's a deliberate design choice, which is theirs to make. They chose not to foster a community of contributors around the project. And they chose not to implement many of the most basic features their user base asked for. Again, their choice.
As for "talking to them and working something out", that hasn't happened in the entire history of the project. What is missing here isn't a lack of time or a lack of technical skill. It's a lack of effective project management, a lack of direction, and an inability to delegate.
I think your characterization isn't exactly correct, they've declined to implement some features, but they've also implemented a lot of other ones.
>What is missing here isn't a lack of time or a lack of technical skill. It's a lack of effective project management, a lack of direction, and an inability to delegate.
Please don't do this, this is splitting hairs. Some people don't have the project management skills to do that. I've read your other posts, if you have the project management skills, then you'd be a great candidate to step in and do that. If you don't, then this still isn't helping the problem. The productive thing to do would be to find a capable project manager.
I'm not sure I see the problem: 'Export', and 'Export as' works as 'Save' and 'Save as'. This i like 'Export to PDF' in a word processor. If you never save in GIMP, I suppose you don't use layers?
The problem is that for those of us that used it since the beginning (1997 in my case), it's a change which broke the workflow which worked for 15 years for zero benefit for any user, old or new. I still get it wrong every time a decade on. The keyboard shortcuts are awkward, and it's all around a bad choice for usability. It has no actual benefit. Its only purpose is for the developers to force you to use XCF in a not-very-subtle manner.
I do use layers sometimes. But all of my input and output images are PNG, TIFF or JPEG and I have no use for the intermediate state. XCF is a non-standard application-specific format which has no use other than with the GIMP. It has its place, but the assumption that it is the central part of the workflow of end users is simply incorrect. It wouldn't have caused so many complaints if it was the case.
This again comes back to the project management and project goals. There is very clearly a desired workflow and feature set that users are expected to use, and deviations from this workflow are not desired or well supported, and accommodations for non-standard workflows are not well received.
As a minor developer of open-source software, I've always been surprised at the diverse range of uses people have attempted with my software. Often things I'd never considered. In most cases, I tried to accommodate these uses so long as they could fit within the application design, and occasionally with some refactoring to fit them in. Because in most cases this was of net benefit to the application, widening its appeal and usability, and driving cleanup of the architecture to make it more flexible and more amenable to extension.
The unwillingness of the GIMP developers to support fairly basic vector and path operations speaks volumes. There's clearly a demand for it. They would be self-contained and not have any major impact upon the wider application. And yet, they have been repeatedly rejected. If I was the maintainer, I'd have considered and allowed their addition. But it seems that the GIMP developers do not want to expand the remit of their application, even if it would be of net benefit.