Hacker News Reader

Comment by vallode | Hacker News Reader

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/

View on HN

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.

> 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?

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://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/

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.

If you want an open-source kernel, you don't have much choice.

Truck and Fornjot are incomplete and not quite ready for prime-time. libfive is FREP, not BREP.

OCCT is the useable of all. But it also has old architecture, all sorts of imperfections (some of them described by the other guy here), and the code quality isn't great, I'm told (by much more experienced people).

I tried to use FreeCAD a few years ago to do some simple object modeling for 3D-printed prototypes. The GUI was so complex and idiosyncratic that I found it more efficient to just learn OpenSCAD's modeling language instead (which served me really well).

Yes, absolutely. It was where GIMP still is now, for artists.

It's definitely been idiosyncratic (if not solipsistic), and still has IMO some maddening features. And it still [0] has a core flaw that is being mitigated.

OpenSCAD is actually very limited in ways that don't become obvious until you get into a bRep CAD system at least. But it's how I also got into CAD. I wanted to know there was at least something I'd be able to use for my own ideas, and the fact that OpenSCAD exists is definitely a blessing.

If you like it, you might find Build123D [1] interesting: this is a Python (and very pythonic) environment built around the same kernel as FreeCAD.

But I got from OpenSCAD to FreeCAD and I am very glad of it; it's an amazingly capable bit of software once you get past the pain (in the same way Blender is, I gather).

FreeCAD 0.21 has many nice new things in it. 0.22-dev has more, and 1.0, due at some point in this year now, is going to be a pretty major leap forward.

And at least now we have the amazing Mango Jelly Solutions videos on youtube. I recommend them; you'll learn the right way into FreeCAD.

GIMP is not an amazingly capable bit of software for typical designers. It's broken and hobbled.

[0] the topological naming problem: being corrected in the core distribution at the moment as they head to 1.0

[1] https://github.com/gumyr/build123d

Thanks for the pointer to Build123D -- I really like the idea of building 3D models as code, so this might be a great alternative.

My use case back then was working on prototypes for plastic products we'd eventually be injection molding. I found OpenSCAD to be an extremely effective tool for quickly iterating on designs. I'd tweak some parameters or code, 3D print a batch of samples, hand them out to testers for feedback, rinse and repeat.

Then, once the design was production ready, we'd hand off the final protos to the engineers who would design the injection molds. I'm sure they were using Solidworks or the like. OpenSCAD added a lot of value in the early design phase of these projects, but wasn't involved past prototyping, so I suppose we never encountered its limits.

FWIW I just picked up FreeCAD a few weeks ago with zero prior CAD experience and I was able to create a few simple widgets for my 3d printer (a shower soap dish and a bottle for my daughter's toy doll) without too much fuss (took a few hours of learning and few hours of actual CAD work). I did have to ask a few questions on the FreeCAD forum (and got a bunch of friendly, helpful responses), but that's to be expected learning complex software like a CAD program.

In short, the latest version of FreeCAD (I'm using 0.21.x) is absolutely approachable for beginners and apparently works well for advanced users. I'm quite impressed with the project!

> 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.

GIMP is critically underfunded. Seriously I think it's like one guy making most of the changes[0].

> 7 core developers contributed 10 or more commits in GIMP’s main repository:

> Jehan: 649 commits

> Jacob Boerema: 64 commits

> Nikc: 50 commits

> Daniel Novomeský: 25 commits

> lloyd konneker: 25 commits

> Lukas Oberhuber: 18 commits

> Niels De Graef: 15 commits

People keep asking the world of Gimp as if they have even 1% of Adobe's funding. IIRC no one is working on Gimp full-time, while Krita is able to pay four full-time developers[2].

1. https://www.gimp.org/news/2023/01/29/2022-annual-report/

2. https://docs.krita.org/en/KritaFAQ.html#license-rights-and-t...

IIRC, GIMP chose this path. Krita got serious about funding and GIMP didn't. Krita has two straightforward donation pages (https://krita.org/en/support-us/donations/ or https://fund.krita.org/) meanwhile GIMP discourages direct donation to the project (https://www.gimp.org/donating/)

In truth, GIMP maintainers deeply enjoy the control that "no strings attached"/"no obligation" development brings them. They've alienated most potential sponsors because they're happy with their lack of results. The missing funding angle only matters as an excuse for their own disorganization.

I haven't double checked but I think at least one of your listed names is banned from twitter.

> I haven't double checked but I think at least one of your listed names is banned from twitter.

Even if true, what does it have to do with anything? :)

Stole my response. At this point being banned from Twitter is a badge of honor in some circles.

I mean, anyone can report anyone for whatever and you will never reach tech support, because tech support at big social platforms never ever responds. Facebook, Twitter, YouTube are all the same. You have to have some serious connections to get a ban lifted.

Actually, I'm a former team member and my personal account is banned on Twitter (which I discovered when I tried to log in after half a year of absence). He could be thinking of me, in fact! :)

> GIMP is critically underfunded.

Not really, no. They have sufficient funds to hire several developers for several years full-time. They are just dragging their feet to organize themselves into a non-profit and start using those funds. The latest news is that they will probably finally announce a non-profit later this year. Hopefully.

Other CAD programs haven't solved toponaming issues, they mitigated them. You can still break a model in SW and other commonly used 3D CAD programs, it's just more difficult to do.

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.

Exactly this -- as I just simultaneously pointed to in my sibling comment about the wonderful rebirth of FreeCAD.

Blender actually hosted the GIMP team last year (https://developer.gimp.org/conferences/wilberweek/2023-amste..., https://www.youtube.com/watch?v=TnHFG_SBc6c), so there have been on-going conversations between the two projects. :)

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.

> 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.)

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.

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'.

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.

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?

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.

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

Photoshop 1.0 : February 1990

Reply on news.ycombinator.com