GIMP 2.9.2 Released With GEGL Technical Preview

[ElectricPrism]

Krita had luck with crowdfunding. Maybe that's an idea for non-destructive editing etc. Else we might have to wait and get older...

Ironically they presently do Patron for a monthly subscription fund.

I'm really glad 2.9.2 is released as hopefully this will allow them to focus on GTK3 UI - GTK3 UI makes GIMP tolerable coming from a Photoshop User.

Their Leadership? Seems like they lack solid organization and are missing a huge financial profit the way Krita has found a niche, gotten cash and done amazing!

[caligula]

I think its unfair to call it a failure in leadership - the one person can lead him/herself.

But visibility can help attract atleast short term volunteers maybe even just for minor bug fixing help and time based release schedule may help in that.

Well GIMP has unsexy window toolkit with non-reactive/declarative description language, tight integration with GTK/Gnome desktops, weird user interface, bad reputation as a difficult to use application among ordinary users, legacy implementation language, hijacked Windows ports in Sourceforge, GNU coding style, OpenCL 2.0 with dynamic parallelism support is crap on Linux. Lots of reasons to start your own from scratch.

[plonoma]

Finally, some public movement.

The port to GEGL seems to have been a herculean effort which was not very visible.

I hope the GIMP developers consider a time base release schedule in the future - at a minimum it shows momentum and potential new contributors could be encouraged to work on smaller features/clean ups.

(After this one, GIMP 3.0 should be quicker as a lot of the work has been done in another branch. it just needs to be cleaned up and then any UI changes added).

Doing time-based release schedule is not a good idea.
It does not follow how long it takes to develop new features.
Release schedules can drive developer resources towards releasing new versions instead of new features.

Doing feature based releases is a good way to do releases.

Some communication wouldn't hurt, a time based blog/news/website update about what is going on would be a very good improvement.
Communication is important for creating community and interest in open source projects.

[prokoudine]

Some communication wouldn't hurt, a time based blog/news/website update about what is going on would be a very good improvement.
Communication is important for creating community and interest in open source projects.

We couldn't make more verbose communication via the old website, because there were no permalinks and no archive, so important stuff would go completely off the grid too fast. Actually, one of the reasons to launch Google+ page was to keep people updated. That page has over 50K subscribers now.

With the new website we can finally do more frequent posting, although we might skip posting about really small features.

[eltomito]

I installed it yesterday and then I spent like half an hour just playing around with the filters that have realtime canvas preview now. It's so much fun! For that feature alone, it's worth installing. Otherwise, the unified transform tool is cool, too. It's fairly intuitive, xcept I couldn't figure out how to do rotation with it. Can you?

[quikee]

Doing time-based release schedule is not a good idea.
It does not follow how long it takes to develop new features.
Release schedules can drive developer resources towards releasing new versions instead of new features.

Doing feature based releases is a good way to do releases.

That assumes there is only one feature being worked on, but usually you have more features that are being worked on in parallel and are completed at different times. If you would have a real feature based release then every time a feature is completed you would have a release - but this is not the case and especially not for gimp. So instead of feature based release you have "a couple of features" based release where the "don't know how long it takes to develop a new feature" backfires. You have a feature that takes ages to complete but you have completed features that could be released already ages ago but aren't - and this is not good (and sometimes insulting to the developer). Then you also have the problem of what features to put in a release - why not this feature in this release however that feature is included.

Time based release doesn't have this problems. With a time based release the completed features will get to the users at a predicted time. Yes, a release needs time to prepare, but a time based release is usually smaller so it may not require a whole lot to prepare (especially if you have build structure already setup - you know for continuous integration and automated testing). Also a release is not something a developer must do so you could find a skilled person in the community which could do releases. A release creates media coverage which means influx of new developers and other community members that want to help, donations and is just in general good for a community. A release also puts developers under pressure when the release date is nearing - which is good too as it will increase motivation to complete the task (and "force" the developer to do the "boring" parts that they avoid) and also other community members go into a higher activity state...

So no.. feature based releases is not a good way to do releases (not for open source projects at least), and if you look around the more successful open source projects you will see that most of them do time-based releases.