We are shutting down Ondsel

Sometimes I envy that although I am not a SWE. I work in a field that is so close with the open source and tech scene that we don't have to rely on commercial products like some other fields. It is hard to compete or gain enough interest in some fields of engineering to any open or free solutions.

Unfortunately, I've noticed that non-SW engineers frequently turn their noses up at open-source solutions, and really the entire concept of open-source software, and seem to prefer proprietary solutions, the more expensive the better. I've seen this in the software world too, with embedded systems engineers, though Linux, gcc, etc. has made huge inroads here, though it took decades, and mainly came from the Linux adherents pushing downwards into the embedded space from the desktop space, not from any interest by the existing engineers in the embedded space.

Just look, for instance, at FPGAs: almost all the tooling is proprietary, very expensive, and very buggy too. Or look at PCB design: Altium seems to be the standard here still, despite Kicad having made huge advances and by most accounts being as good or even better. It took decades (Kicad started in 1992) for the FOSS alternatives here to really catch on much, and only really because PCBs became cheap enough for hobbyists to design and construct their own (mainly because of Chinese PCB companies), and because CERN contributed some resources.

I'm not sure what the deal is with engineers hating collaboratively-developed and freely-available software, but it's a real thing in my experience. It's like someone told them that FOSS is "socialism" and they just reflexively dismiss or hate it.

I don't think it's simply "engineers hate open source". Most of the open source tools in the embedded space are just a bit crap. The reality is that good software needs many thousands of hours of development time. The embedded space is actually pretty small in development budget terms - so fewer engineers who might devote time - and also there's less overlap in skillset - electronic design engineers rarely have the software skills required to develop EDA software.

Most of the incredibly well used robust open source packages are sponsored by large tech companies. The embedded space just hasn't had that kind of sponsorship.

I suspect it's the ways in which they are a bit crap. All software is a bit crap one way or another.

FreeCAD's UI is "a bit crap". The "workbench" metaphor is fine as a metaphor, but the specific way the workbenches are put together in FreeCAD is oriented more towards the way the functionality is implemented than what the user wants to do with it. You have no choice but to understand technical implementation details.

That's just one example, but that attitude to UI in FreeCAD is absolutely pervasive.

I think that's a general problem in the space. The user interfaces in general aren't designed, they're an outgrowth of the direct implementation of the underlying functionality.

Yes. You’ll have a hard time finding a full-time professional photographer that hasn’t tried Gimp, and an even harder time finding one that still uses it. That’s not even getting into graphic designers— Gimp’s typography tools are awful. Open source software that’s useable— more recent blender versions, Inkscape, Firefox, Signal— is the only stuff that’s caught on in large part because they deliberately enfranchise designers. As an experienced, art school trained designer with far more than enough full-time coding experience to implement my own designs, I still exclusively contribute code to FOSS projects as a developer. I’ve seen both sides of this and am perpetually dispirited by the dismissive, haughty, and frankly ignorant attitudes towards designers among many developers. FOSS interfaces are put together by and for people who a) have a working mental model of software functioning, so they reason about interfaces differently, b) know more about the code than the problem domain, c) are used to and pride themselves on learning complex systems based on a set of complex docs. Until changes, user-facing FOSS applications will be used by developers no matter how useful they would be to others.

The sad thing is that the current car-crash state of GIMP's UI is what, 15 years after they received the input of a professional HCI designer? In some ways it's improved a great deal in that timespan, and in others it got significantly worse. To this day it lectures you like some bratty kid playing Simon Says if you try to use File -> Save to save a TIFF image. (Complying with my instruction and then telling me why Export would have been better is fine. Recognising and understanding the instruction but refusing to comply with it is not fine.)

> a) have a working mental model of software functioning, so they reason about interfaces differently

You're 100% correct, they do reason about interfaces differently, and thus have wants and needs which are different from those of non-technical users. Those wants and needs are not met by mainstream software, but are met in some OSS software, so it should come as no surprise that such types want to defend that software against the incursion of those who want to make it just like the mainstream offerings!

Like you I have a slightly different perspective here, having been a hobbyist software developer for some years, but having worked in print and design as a day job.

But I still bemoan such things as the awful keyboard handling of the current GTK file dialog, when compared with the old GTK1.2 file dialog. The old one was truly hideous to look at, but handled filtering files by keystroke far better than any current file dialog.

2004: STOP TELLING ME I'M GOING TO LOSE MY LAYERS WHEN SAVING TO JPEG!

Also 2004: HOW DO I RECOVER LAYERS FROM JPEG?

2024: STOP TELLING ME YOU ONLY SAVE TO XCF AND I NEED TO EXPORT TO JPEG!

Also 2024: crickets

I'm not kidding you. That is exactly what I've been witnessing all these years. Project loss complaints went from daily routine to almost zero. But there's a price to pay.

> But there's a price to pay.

And I resent the fact that I'm expected to pay that price when I'm not the one who was losing projects.

And as I said, carrying out the instruction but then telling me that I should be using Export instead would be acceptable. Refusing to carry out the instruction, even though the software has identified and understood the instruction just because I failed to say 'Simon Says' is not acceptable.

(Hi, by the way! I think you did some translations for PhotoPrint and CMYKTool some years back?)

Hi Alastair :)

Yes, I understand the frustration. The team didn't come up with anything better although maybe they could. I think another suggestion in this thread could very well be posted to GIMP's issue tracker.

Looks like they created a separate gimp-ux repository a few mos ago at least. I'd gladly contribute design work and code there if my experiences would be more collaborative and less painful than they were before I just gave up trying like a decade ago. In my experience, anyone making a design contribution could only do it in a discrete standalone PR-- with gimp's foundational lack of UI design, that's like someone that owns a crumbling dam saying they will only accept proposals to fix individual broken spots because the pieces that are still intact work just fine. The only real options were to make a fork and change it, or... go fork yourself-- and there was no way I was taking on all of that design and coding myself.