4 ms·

Another comment mentioned GIMP may have assumptions of bad UX within their codebase which makes me think about long-lived and large scale projects like this in

Another comment mentioned GIMP may have assumptions of bad UX within their codebase which makes me think about long-lived and large scale projects like this in general. The technical debt of GIMP has been slowly amassing (like all projects) since 1995 (wow!) and I assume that as every year goes by it gets increasingly difficult to do a large scale re-write of any part of the logic. Tools like Photopea[1] come along and throw a fresh perspective at things all the time, these tools never have the breadth and depth of feature support that GIMP has but basically always manage to "one-up" it over something. How long will it take before GIMP has usability on-par with Photoshop? How long until it attains the aesthetic coherence necessary to win people over visually? I love GIMP, but is the battle against 20 years of technical debt even winnable? [1]: https://www.photopea.com/ https://www.photopea.com/

diggan 3y ago
The example to point to is Blender, for inspiration on how to manage this successfully. Ton has done a heck of a job making Blender into a real alternative, even with the codebase existing and being worked on since 1995. The UX and UI overhaul in 2018 (Blender 2.8) was a big undertaking, that had a big impact on the success of Blender, maybe something similar would be possible for Gimp too. Granted, Ton figured out a project of that scale needed funding, but overall, Blender is a huge success as a FOSS tool. Maybe the Gimp and Blender developers so sit down together and have a chat, the tools are often used together after all.
- bemusedthrow75 3y ago
  Exactly this -- as I just simultaneously pointed to in my sibling comment about the wonderful rebirth of FreeCAD.
- CmykStudent 3y ago
  Blender actually hosted the GIMP team last year (https://developer.gimp.org/conferences/wilberweek/2023-amsterdam/ https://developer.gimp.org/conferences/wilberweek/2023-amste..., https://www.youtube.com/watch?v=TnHFG_SBc6c https://www.youtube.com/watch?v=TnHFG_SBc6c), so there have been on-going conversations between the two projects. :)
rabf 3y ago
Photoshop 1.0 : February 1990
bemusedthrow75 3y ago
Another really long-lived package, FreeCAD (it's about six years younger), has tremendous parallels: - bad (in places better called solipsistic) UX - underlying architectural issues from its dependencies (e.g. OpenCascade's OCCT and Coin3D) - a flood of competing workbenches and plugins so users struggle with initial workflow, many abandoned or undermaintained - something of a reliance on knowledge of Python scripting to solve advanced issues - and (akin to GIMP avoiding non-destructive-editing for two decades) a fundamental architectural issue: topological naming problems that other CAD packages have solved But things in FreeCAD land are changing really fast -- there's a TNP implementation coming quite soon to core FreeCAD, there's a core assembly workbench, a materials system and really significant GUI and UX improvements. The reason is things are changing is that that people central to FreeCAD looked across the open source landscape to Blender, and saw how a project can be run, and how commercial companies could consult on top of it. Everything has changed within a matter of three years. Despite its issues, FreeCAD is now exciting to watch. Whereas GIMP seems to still be circling around looking for the best solutions to things they never finish. Krita has become the thing GIMP could have been, and it is nine years younger.
- andybak 3y ago
  > underlying architectural issues from its dependencies (e.g. OpenCascade's OCCT and Coin3D) Curious to know more. I occasionally look at CAD kernels and wonder about writing a C# wrapper. Is OCCT to be avoided?
  - bemusedthrow75 3y ago
    OCCT is definitely difficult. I am almost as far as you can get from an expert (and I am sure there is one here who can explain it better and hopefully correct me) but: For example the TNP issue derives from OCCT (or something in the stack close to it, I am not exactly sure) not really handling face naming at all. So if you want to avoid topological naming issues (which is a hard problem in CAD), you apparently have to do some work to track before and after and reconstruct your face naming from either side of the OCCT black box. https://wiki.freecad.org/Topological_naming_problem https://wiki.freecad.org/Topological_naming_problem https://forum.freecad.org/viewtopic.php?t=27278 https://forum.freecad.org/viewtopic.php?t=27278 Then there are various fairly entrenched issues to do with filleting and chamfering. Basically, both these operations will fail if a chamfer or fillet would completely consume an existing edge. It also sometimes creates impossible objects when filleting, or used to. Booleans can be slow. And more generally, it seems if you track the FreeCAD project that OCCT can be inscrutable when things fail; error messages aren't the greatest etc. The flip side of OpenCascade is that it seems to be highly portable and has for example been compiled to JS with Emscripten for this astonishing thing: https://zalo.github.io/CascadeStudio/ https://zalo.github.io/CascadeStudio/ It's a monumental open source project, for sure, and it's definitely not nothing that we have an open source CAD kernel; these are projects that perhaps have to extend beyond the working life of an individual developer if they are to be stable. And there are loads of projects built around it. So it's absolutely consequential and we're lucky to have it.
Pingk 3y ago
The problems with GIMP are the same as Musescore before it was bought out - Having dedicated designers/programmers allows more sweeping and coherent changes to be made. Voluntary fixes are necessarily smaller in scope and suboptimal as a result, leading to more complexity when those systems need to be changed later. I'm also reminded of Casey Muratori's talk about software architecture being a reflection of the organisation that made it. Open source projects are at the extreme end where contributors and org charts are highly fluid, and communication between contributors is low-bandwidth, accelerating the complexity increase.
- deleted 3y ago
  [deleted]
drums8787 3y ago
Technical debt and “feature debt”? I imagine some people would object to things being taken out or significantly altered. An existing & happy (?) user base probably carry weight.
crote 3y ago
Blender and KiCad are both great examples of what's possible. They were technically reasonably complete but absolutely awful to use - until they started focusing on UX and features desired by industry professionals. In just a few years they went from being cute open-source toys to being serious alternatives for the expensive proprietary market leaders.
mschaef 3y ago
> How long will it take before GIMP has usability on-par with Photoshop? Here's the bleak assessment: It's been almost thirty years - If it was going to happen, it would have happened already. The economics and development model just don't support the same sort of usability and in-depth feature development work that can be supported within a large commercial software organization. You can also observe this in software like language implementations. Ruby, Python, and Java are all rough contemporaries of each other. They were all released in the early to mid 1990's, and they were all released at approximate technical parity. (Basic automatic memory management techniques and simple/slow bytecode interpretation.) Now, flash forward thirty years. While Python and Ruby are still mostly interpreted, Java has been through multiple generations of increasingly sophisticated runtime implementations, now has first rate GC and JIT compilation to machine code. This is the sort of improvement that can only really be bought by continual long term investment in dedicated engineering. It's what takes to escape local maxima in the design space. If a project can't assemble the resources to do this, it winds up stuck wandering around its current local maxima and maybe making marginal improvements, but never able to break free of the fundamental constraints of its current design. This will remain true unless there's some sort of investment in additional resources, which brings me to my more optimistic assessment. With GIMP (and other open source software), it's at least possible for outsiders to make the investment. It's possible to make a contribution, and it's possible to improve the situation. This can itself be a useful and profoundly enabling aspect of software, particularly over the longer term. (I also think this suggests that open source software should tend to be developed in ways that emphasize the discoverability and customizability of the codebase. It's for this reason that I think open source is the key enabling factor for tools like Emacs.)
- llm_trw 3y ago
  Python is the most popular language in the world and used by all machine learning and AI applications. If that's what failure looks like I don't know what success looks like.
  - mschaef 3y ago
    I wasn't talking as much about marketplace success as I was about the ability to support engineering efforts to develop specific features requiring high amounts of sustained, focused effort. There's a big difference between 'high engineering spend' and 'widespread adoption'.
redeeman 3y ago
it will never be having "usability" like photoshop, because what it seems like people mean with that is "a clone of photoshop"
walteweiss 3y ago
I have a suspicion theory that Photopea is not some magical one-man project that is so good in the browser, but just a Remote Desktop from browser. It looks very Photoshop CS2-ish to me, and in the very beginning it looked identical, iirc. I don’t believe it’s some genius (graphic-terms) project, but just a genius remote-desktop implementation. Hence it works well in the browser. What do you think guys? Maybe someone who uses the project all the years noticed it’s very different and evolved over time, and is not just a PS reskin?

diggan 3y ago

The example to point to is Blender, for inspiration on how to manage this successfully. Ton has done a heck of a job making Blender into a real alternative, even with the codebase existing and being worked on since 1995. The UX and UI overhaul in 2018 (Blender 2.8) was a big undertaking, that had a big impact on the success of Blender, maybe something similar would be possible for Gimp too. Granted, Ton figured out a project of that scale needed funding, but overall, Blender is a huge success as a FOSS tool. Maybe the Gimp and Blender developers so sit down together and have a chat, the tools are often used together after all.

bemusedthrow75 3y ago
Exactly this -- as I just simultaneously pointed to in my sibling comment about the wonderful rebirth of FreeCAD.
CmykStudent 3y ago
Blender actually hosted the GIMP team last year (https://developer.gimp.org/conferences/wilberweek/2023-amsterdam/ https://developer.gimp.org/conferences/wilberweek/2023-amste..., https://www.youtube.com/watch?v=TnHFG_SBc6c https://www.youtube.com/watch?v=TnHFG_SBc6c), so there have been on-going conversations between the two projects. :)

rabf 3y ago

Photoshop 1.0 : February 1990

bemusedthrow75 3y ago

Another really long-lived package, FreeCAD (it's about six years younger), has tremendous parallels: - bad (in places better called solipsistic) UX - underlying architectural issues from its dependencies (e.g. OpenCascade's OCCT and Coin3D) - a flood of competing workbenches and plugins so users struggle with initial workflow, many abandoned or undermaintained - something of a reliance on knowledge of Python scripting to solve advanced issues - and (akin to GIMP avoiding non-destructive-editing for two decades) a fundamental architectural issue: topological naming problems that other CAD packages have solved But things in FreeCAD land are changing really fast -- there's a TNP implementation coming quite soon to core FreeCAD, there's a core assembly workbench, a materials system and really significant GUI and UX improvements. The reason is things are changing is that that people central to FreeCAD looked across the open source landscape to Blender, and saw how a project can be run, and how commercial companies could consult on top of it. Everything has changed within a matter of three years. Despite its issues, FreeCAD is now exciting to watch. Whereas GIMP seems to still be circling around looking for the best solutions to things they never finish. Krita has become the thing GIMP could have been, and it is nine years younger.

andybak 3y ago
> underlying architectural issues from its dependencies (e.g. OpenCascade's OCCT and Coin3D) Curious to know more. I occasionally look at CAD kernels and wonder about writing a C# wrapper. Is OCCT to be avoided?
- bemusedthrow75 3y ago
  OCCT is definitely difficult. I am almost as far as you can get from an expert (and I am sure there is one here who can explain it better and hopefully correct me) but: For example the TNP issue derives from OCCT (or something in the stack close to it, I am not exactly sure) not really handling face naming at all. So if you want to avoid topological naming issues (which is a hard problem in CAD), you apparently have to do some work to track before and after and reconstruct your face naming from either side of the OCCT black box. https://wiki.freecad.org/Topological_naming_problem https://wiki.freecad.org/Topological_naming_problem https://forum.freecad.org/viewtopic.php?t=27278 https://forum.freecad.org/viewtopic.php?t=27278 Then there are various fairly entrenched issues to do with filleting and chamfering. Basically, both these operations will fail if a chamfer or fillet would completely consume an existing edge. It also sometimes creates impossible objects when filleting, or used to. Booleans can be slow. And more generally, it seems if you track the FreeCAD project that OCCT can be inscrutable when things fail; error messages aren't the greatest etc. The flip side of OpenCascade is that it seems to be highly portable and has for example been compiled to JS with Emscripten for this astonishing thing: https://zalo.github.io/CascadeStudio/ https://zalo.github.io/CascadeStudio/ It's a monumental open source project, for sure, and it's definitely not nothing that we have an open source CAD kernel; these are projects that perhaps have to extend beyond the working life of an individual developer if they are to be stable. And there are loads of projects built around it. So it's absolutely consequential and we're lucky to have it.

Pingk 3y ago

The problems with GIMP are the same as Musescore before it was bought out - Having dedicated designers/programmers allows more sweeping and coherent changes to be made. Voluntary fixes are necessarily smaller in scope and suboptimal as a result, leading to more complexity when those systems need to be changed later. I'm also reminded of Casey Muratori's talk about software architecture being a reflection of the organisation that made it. Open source projects are at the extreme end where contributors and org charts are highly fluid, and communication between contributors is low-bandwidth, accelerating the complexity increase.

deleted 3y ago
[deleted]

drums8787 3y ago

Technical debt and “feature debt”? I imagine some people would object to things being taken out or significantly altered. An existing & happy (?) user base probably carry weight.

crote 3y ago

Blender and KiCad are both great examples of what's possible. They were technically reasonably complete but absolutely awful to use - until they started focusing on UX and features desired by industry professionals. In just a few years they went from being cute open-source toys to being serious alternatives for the expensive proprietary market leaders.

mschaef 3y ago

> How long will it take before GIMP has usability on-par with Photoshop? Here's the bleak assessment: It's been almost thirty years - If it was going to happen, it would have happened already. The economics and development model just don't support the same sort of usability and in-depth feature development work that can be supported within a large commercial software organization. You can also observe this in software like language implementations. Ruby, Python, and Java are all rough contemporaries of each other. They were all released in the early to mid 1990's, and they were all released at approximate technical parity. (Basic automatic memory management techniques and simple/slow bytecode interpretation.) Now, flash forward thirty years. While Python and Ruby are still mostly interpreted, Java has been through multiple generations of increasingly sophisticated runtime implementations, now has first rate GC and JIT compilation to machine code. This is the sort of improvement that can only really be bought by continual long term investment in dedicated engineering. It's what takes to escape local maxima in the design space. If a project can't assemble the resources to do this, it winds up stuck wandering around its current local maxima and maybe making marginal improvements, but never able to break free of the fundamental constraints of its current design. This will remain true unless there's some sort of investment in additional resources, which brings me to my more optimistic assessment. With GIMP (and other open source software), it's at least possible for outsiders to make the investment. It's possible to make a contribution, and it's possible to improve the situation. This can itself be a useful and profoundly enabling aspect of software, particularly over the longer term. (I also think this suggests that open source software should tend to be developed in ways that emphasize the discoverability and customizability of the codebase. It's for this reason that I think open source is the key enabling factor for tools like Emacs.)

llm_trw 3y ago
Python is the most popular language in the world and used by all machine learning and AI applications. If that's what failure looks like I don't know what success looks like.
- mschaef 3y ago
  I wasn't talking as much about marketplace success as I was about the ability to support engineering efforts to develop specific features requiring high amounts of sustained, focused effort. There's a big difference between 'high engineering spend' and 'widespread adoption'.

redeeman 3y ago

it will never be having "usability" like photoshop, because what it seems like people mean with that is "a clone of photoshop"

walteweiss 3y ago

I have a suspicion theory that Photopea is not some magical one-man project that is so good in the browser, but just a Remote Desktop from browser. It looks very Photoshop CS2-ish to me, and in the very beginning it looked identical, iirc. I don’t believe it’s some genius (graphic-terms) project, but just a genius remote-desktop implementation. Hence it works well in the browser. What do you think guys? Maybe someone who uses the project all the years noticed it’s very different and evolved over time, and is not just a PS reskin?