5 ms·

The inability of the GIMP developers to work with others to incorporate needed features was the primary reason. Look at the difference between how different op

by rleigh 5y ago

The inability of the GIMP developers to work with others to incorporate needed features was the primary reason. Look at the difference between how different open-source projects operate. Some foster collaboration and encourage outside contributions, e.g. Linux. Others are completely insular and barely tolerate it. The GIMP maintainers fall into the latter category. Unless you're part of the inner clique, you won't get anything merged. It's kind of sad that the Cinepaint people got several paid staff to lift the GIMP functionality to the point it had very high-profile commercial use with some really useful features, and yet the GIMP developers were too stubborn to acknowledge this effort and work with them to get the functionality into the GIMP core. Sadly, this is not unique to the GIMP. I, and other commercial developers, had exactly the same experience with GTK+ and GNOME libraries. The developers wanted to hack on their pet thing, ignore outside contributions, and this is simply not compatible with commercial timelines and realities. But it can be, and it can work very well, for projects which are willing to engage with outside work. It can work out to be very mutually beneficial with some give and take on both sides. I was on the GIMP mailing lists at the time and followed this saga for years. It's a crying shame it was deliberately ignored.

deleted 5y ago
[deleted]
Sesse__ 5y ago
My first patch to an open-source project ever was to GIMP, as a 16-year-old with zero OSS experience. I actually didn't have much problems getting it merged, so I don't think it was as insular as you make it out. :-) But it wasn't a huge rearchitecting, like 16-bit support is. Part of the problem as I saw it is that GIMP felt into a second-system effect, where they would do things “right” using GEGL instead of taking back the Film GIMP patches, and GEGL took literally 15 years before it worked reasonably well.
- rleigh 5y ago
  Hi Steinar (long time, no see)! You are right that there are very big differences in scope with large features vs small bugfixes. I was one of the GIMP "Print" plugin maintainers for several years. It ended up being split off as a separate project, turned into a shared library, renamed to Gutenprint, and became the highest quality set of printer drivers on Linux, particularly for photographic printing, due to the use of speciality dithering algorithms (Raph Levien's EvenTone), custom dithering matrices and hand-tuned support for mixing light and dark inks with variable drop sizes, CUPS support, and eventually became the default MacOS X printer drivers in the early years of MacOS X. It went from a tiny plugin as part of a niche application, to being the default means of printing on all Linux and MacOS X systems. I would argue it is many times more successful than the GIMP application, despite being less recognisable to end users, it is nevertheless there under the hood quietly turning rasterised page input into individual ink droplets on pages (or toner on lasers). It far surpassed the quality of most/all commercial RIPs and vendor drivers at the time, and maybe still does. This occurred because the lead developer of this sub-project was willing to delegate responsibilities and collaborate with others. For example, as a young-but-keen amateur, I single-handedly converted it to build as a shared library, moved the build to use Autoconf/Automake/Libtool (this was 2001, today I'd have used CMake), and this enabled it to be used directly within the GIMP as the Print plugin, or as a CUPS driver, or as an IJS (InkJet Server) driver. That willingness to consider and accept contributions from others made this project an outstanding success. I wasn't the only one either, the project benefitted from the expert contributions from many people with a diverse range of interests and skills, with a good project manager to oversee it all (Robert Krawitz). In my humble opinion, that is what separates the projects. In order to grow both the developer base and the user base, you need effective project management. And managers need to be able to step back and delegate. The GIMP developers have never really been able to do this. They have to write every line themselves. This is why its development has basically been stagnant for over 15 years, because they had to do GEGL themselves, even though there's only one part timer on it. Having it all written in C doesn't help. Graphics does lend itself to higher level abstractions which they can't use. I'd consider GEGL a wasted effort myself; it was obsoleted by GPU compute before it was even part way complete.
  - Sesse__ 5y ago
    Yes, I remember all the traffic about gimp-print on the mailing lists :-) It was never really the core of my interests, and eventually, I moved to other things. Probably everything you say is right, but also, image processing is sort of a niche topic, so it's hard to attract people in the first place.
blkhawk 5y ago
That inability doesn't only show in not implementing features but also in the way functions are implemented - A good example is the forced save to xcf introduced in 2.8. Apparently it is more professional. Anyway there is a patch for that by vitalif. You can find prebuild packages here: http://vmx.yourcmc.ru/var/debian/unstable/ http://vmx.yourcmc.ru/var/debian/unstable/ It will fix most problems by removing the save/export filetype restriction and disabling some forced warnings. Another thing I found recently when trying to use GIMP for a simple task was that GIMP is "not a drawing program". You have no good way to handle simple vector shapes and lines. There are some semi-functional workarounds using selections or the drawing tool or even a filter (render/gfig). These all have various downsides in that they cannot be easily adjusted once applied to an image. There is no good reason for simple shape vector editing not being in GIMP since you need some vector functions for say Font rendering. Similar Apps I cannot use in Linux (wine is not an option thanks to DRM) have had functions like that since the early 90ies.
- kongin 5y ago
  The whole ecosystem around gtk is extremely insular, the devs are hostile and think the users idiots for not doing things the right way. Compare to the qt krita and you see the difference. It's a paint program, but it already works better for most photo manipulation tasks. Give it another few years of development and gimp will only be used in scripting pipelines.
  - redis_mlc 5y ago
    I think most of the gtk maintainers are European, hence the hostility. I haven't had a lot of luck communicating with any Open Source projects in the EU over the years. I will probably end up forking any projects that are important to me. As I've mentioned before, HN should ban European IP addresses.
- trulyme 5y ago
  Agree 100%. About save/export debacle, someone made a plugin which makes saving to non-xcf easier [0] - big thank you to them. It allowed me to still use Gimp when I had to manually edit 100s of PNGs. It is incredibly frustrating to see good software (I love Gimp otherwise) tarnished with such rookie mistakes/decisions. [0] https://shallowsky.com/software/gimp-save/ https://shallowsky.com/software/gimp-save/
BeetleB 5y ago
> Some foster collaboration and encourage outside contributions, e.g. Linux. Others are completely insular and barely tolerate it. The GIMP maintainers fall into the latter category. Unless you're part of the inner clique, you won't get anything merged. I can't speak to this, as I don't contribute to them. However, for all the criticisms of Gimp and its development team, for photoediting no open source SW comes close to the power of Gimp.
bb88 5y ago
> The inability of the GIMP developers to work with others to incorporate needed features was the primary reason. I don't know. I felt like Adobe and other companies saw the market and wanted to win it. It's easier to grab marketshare when you can hire lots of developers to implement all the features your customers are asking. When Cinepaint announced that were moving off GTK+ and onto FLTK probably just accelerated the end of Cinepaint. I haven't seen an FLTK app in years. Does FLTK still look like it came from the 1990's/early 2000's, or did they upgrade the widgets to make them look more modern?
- app4soft 5y ago
  > I haven't seen an FLTK app in years. FLTK still widely used in various scientific apps. > Does FLTK still look like it came from the 1990's/early 2000's, or did they upgrade the widgets to make them look more modern? Probably the same. For example, here is screenshot[0] of the OpenVSP[1] - an actively maintained parametric 3D CAD app by NASA.[2] But also there is `fl_imgtk` — a small library for FLTK image toolkit, designed to use some useful effects in FLTK GUI (better image, better speed, better quality).[3] Yet another thing is `fltk-rs`[4] - Rust binding to FLTK, with custom theming module.[5] [0] https://twitter.com/app4soft/status/1352349523549577219 https://twitter.com/app4soft/status/1352349523549577219 [1] https://github.com/openvsp/openvsp https://github.com/openvsp/openvsp [2] http://openvsp.org http://openvsp.org [3] https://github.com/rageworx/fl_imgtk https://github.com/rageworx/fl_imgtk [4] https://github.com/fltk-rs https://github.com/fltk-rs [5] https://github.com/fltk-rs/fltk-theme https://github.com/fltk-rs/fltk-theme
  - bb88 5y ago
    It has improved a bit from what I can see, but I wouldn't say it's "modern". Interesting. It still appears to have the issue with text flow I ran into years ago where text would overlap with the button outline, rather than increasing the button outline to accommodate the text. That was the one thing I didn't like about it. It made the GUI's look kinda unprofessional.
    - app4soft 5y ago

by rleigh 5y ago

deleted 5y ago

[deleted]

Sesse__ 5y ago

My first patch to an open-source project ever was to GIMP, as a 16-year-old with zero OSS experience. I actually didn't have much problems getting it merged, so I don't think it was as insular as you make it out. :-) But it wasn't a huge rearchitecting, like 16-bit support is. Part of the problem as I saw it is that GIMP felt into a second-system effect, where they would do things “right” using GEGL instead of taking back the Film GIMP patches, and GEGL took literally 15 years before it worked reasonably well.

rleigh 5y ago
Hi Steinar (long time, no see)! You are right that there are very big differences in scope with large features vs small bugfixes. I was one of the GIMP "Print" plugin maintainers for several years. It ended up being split off as a separate project, turned into a shared library, renamed to Gutenprint, and became the highest quality set of printer drivers on Linux, particularly for photographic printing, due to the use of speciality dithering algorithms (Raph Levien's EvenTone), custom dithering matrices and hand-tuned support for mixing light and dark inks with variable drop sizes, CUPS support, and eventually became the default MacOS X printer drivers in the early years of MacOS X. It went from a tiny plugin as part of a niche application, to being the default means of printing on all Linux and MacOS X systems. I would argue it is many times more successful than the GIMP application, despite being less recognisable to end users, it is nevertheless there under the hood quietly turning rasterised page input into individual ink droplets on pages (or toner on lasers). It far surpassed the quality of most/all commercial RIPs and vendor drivers at the time, and maybe still does. This occurred because the lead developer of this sub-project was willing to delegate responsibilities and collaborate with others. For example, as a young-but-keen amateur, I single-handedly converted it to build as a shared library, moved the build to use Autoconf/Automake/Libtool (this was 2001, today I'd have used CMake), and this enabled it to be used directly within the GIMP as the Print plugin, or as a CUPS driver, or as an IJS (InkJet Server) driver. That willingness to consider and accept contributions from others made this project an outstanding success. I wasn't the only one either, the project benefitted from the expert contributions from many people with a diverse range of interests and skills, with a good project manager to oversee it all (Robert Krawitz). In my humble opinion, that is what separates the projects. In order to grow both the developer base and the user base, you need effective project management. And managers need to be able to step back and delegate. The GIMP developers have never really been able to do this. They have to write every line themselves. This is why its development has basically been stagnant for over 15 years, because they had to do GEGL themselves, even though there's only one part timer on it. Having it all written in C doesn't help. Graphics does lend itself to higher level abstractions which they can't use. I'd consider GEGL a wasted effort myself; it was obsoleted by GPU compute before it was even part way complete.
- Sesse__ 5y ago
  Yes, I remember all the traffic about gimp-print on the mailing lists :-) It was never really the core of my interests, and eventually, I moved to other things. Probably everything you say is right, but also, image processing is sort of a niche topic, so it's hard to attract people in the first place.

blkhawk 5y ago

That inability doesn't only show in not implementing features but also in the way functions are implemented - A good example is the forced save to xcf introduced in 2.8. Apparently it is more professional. Anyway there is a patch for that by vitalif. You can find prebuild packages here: http://vmx.yourcmc.ru/var/debian/unstable/ http://vmx.yourcmc.ru/var/debian/unstable/ It will fix most problems by removing the save/export filetype restriction and disabling some forced warnings. Another thing I found recently when trying to use GIMP for a simple task was that GIMP is "not a drawing program". You have no good way to handle simple vector shapes and lines. There are some semi-functional workarounds using selections or the drawing tool or even a filter (render/gfig). These all have various downsides in that they cannot be easily adjusted once applied to an image. There is no good reason for simple shape vector editing not being in GIMP since you need some vector functions for say Font rendering. Similar Apps I cannot use in Linux (wine is not an option thanks to DRM) have had functions like that since the early 90ies.

kongin 5y ago
The whole ecosystem around gtk is extremely insular, the devs are hostile and think the users idiots for not doing things the right way. Compare to the qt krita and you see the difference. It's a paint program, but it already works better for most photo manipulation tasks. Give it another few years of development and gimp will only be used in scripting pipelines.
- redis_mlc 5y ago
  I think most of the gtk maintainers are European, hence the hostility. I haven't had a lot of luck communicating with any Open Source projects in the EU over the years. I will probably end up forking any projects that are important to me. As I've mentioned before, HN should ban European IP addresses.
trulyme 5y ago
Agree 100%. About save/export debacle, someone made a plugin which makes saving to non-xcf easier [0] - big thank you to them. It allowed me to still use Gimp when I had to manually edit 100s of PNGs. It is incredibly frustrating to see good software (I love Gimp otherwise) tarnished with such rookie mistakes/decisions. [0] https://shallowsky.com/software/gimp-save/ https://shallowsky.com/software/gimp-save/

BeetleB 5y ago

> Some foster collaboration and encourage outside contributions, e.g. Linux. Others are completely insular and barely tolerate it. The GIMP maintainers fall into the latter category. Unless you're part of the inner clique, you won't get anything merged. I can't speak to this, as I don't contribute to them. However, for all the criticisms of Gimp and its development team, for photoediting no open source SW comes close to the power of Gimp.

bb88 5y ago

> The inability of the GIMP developers to work with others to incorporate needed features was the primary reason. I don't know. I felt like Adobe and other companies saw the market and wanted to win it. It's easier to grab marketshare when you can hire lots of developers to implement all the features your customers are asking. When Cinepaint announced that were moving off GTK+ and onto FLTK probably just accelerated the end of Cinepaint. I haven't seen an FLTK app in years. Does FLTK still look like it came from the 1990's/early 2000's, or did they upgrade the widgets to make them look more modern?

app4soft 5y ago
> I haven't seen an FLTK app in years. FLTK still widely used in various scientific apps. > Does FLTK still look like it came from the 1990's/early 2000's, or did they upgrade the widgets to make them look more modern? Probably the same. For example, here is screenshot[0] of the OpenVSP[1] - an actively maintained parametric 3D CAD app by NASA.[2] But also there is `fl_imgtk` — a small library for FLTK image toolkit, designed to use some useful effects in FLTK GUI (better image, better speed, better quality).[3] Yet another thing is `fltk-rs`[4] - Rust binding to FLTK, with custom theming module.[5] [0] https://twitter.com/app4soft/status/1352349523549577219 https://twitter.com/app4soft/status/1352349523549577219 [1] https://github.com/openvsp/openvsp https://github.com/openvsp/openvsp [2] http://openvsp.org http://openvsp.org [3] https://github.com/rageworx/fl_imgtk https://github.com/rageworx/fl_imgtk [4] https://github.com/fltk-rs https://github.com/fltk-rs [5] https://github.com/fltk-rs/fltk-theme https://github.com/fltk-rs/fltk-theme
- bb88 5y ago
  It has improved a bit from what I can see, but I wouldn't say it's "modern". Interesting. It still appears to have the issue with text flow I ran into years ago where text would overlap with the button outline, rather than increasing the button outline to accommodate the text. That was the one thing I didn't like about it. It made the GUI's look kinda unprofessional.
  - app4soft 5y ago