At this point it feels like a prank that's been going on for a quarter century.
You're not wrong, I wish you were but you're not. By any measure GIMP is a dog of a program. I wish it weren't so as I stopped upgrading my various Adobe products some years ago, but alas it is. It would take me as long as this 'The Decline of Usability' essay to give an authoritative explanation but I'll attempt to illustrate with a few examples:
1. The way the controls work is awkward, increasing or decreasing say 'saturation' is not as intuitive as it is in Photoshop and the dynamics (increase/decrease etc.) just isn't as smooth as it ought to be. Sliders stick and don't respond immediately which is very distracting when you're trying to watch some attribute in your picture trend one way or other.
2. Most previews are unacceptably slow; they really are a pain to use.
3. The latest versions have the 'Fade' function removed altogether. I use 'Fade' all the time and I don't like being told by some arrogant GIMP programmer that the "function never worked properly in the first place, and anyway you should use the proper/correct XYZ method". You see this type of shitty arrogance from programmers all the time[1].
4. GIMP won't let you set your favourite image format as your default type; you're forced to GIMP's own XCF format and then export your image into say your required .JPG format from there. (I understand the reason for this but there ought to be an option to override it, if the GIMP developers were smart they'd provide options for various times, for instance: 'session only'.)
5. As others have mentioned, there's icon and menu issues, menu items aren't arranged logically or consistently.
Essentially, the GIMP's operational ergonomics are terrible and there's been precious little effort from GIMP's developers to correct it. (GIMP's so tedious to use I still use my ancient copy of Photoshop for most of the work, I only then use the GIMP to do some special function that's not in Photoshop.)
[1] The trouble is most programmers program for themselves—not end users, so they don't see any reason to think like end users do. (I said almost the same thing several days ago in my response to Microsoft's enforcing single spaces between sentences in MS Office https://news.ycombinator.com/item?id=22858129 .) It doesn't seem to matter whether it's commercial software such as Microsoft's Office, or open software such as the GIMP or LibreOffice, etc., they do things their way, not the way users want or are already familiar with.
Commercial software is often tempered by commercial reality (keeping compatibility etc.) but even then that's not always so (take Windows Metro UI or Windows 10 for instance, any reasonable user would have to agree they're first-class stuff-ups). That said, GIMP is about the worst out there.
"At this point it feels like a prank that's been going on for a quarter century."
Right again! GIMP developers seem not only to be hostile towards ordinary users but there's been along-standing bloody mindedness among them that's persisted for decades; effectively it is to not even consider ordinary users within their schema. Nothing says this better than the lack of information about future versions, milestones, etc. All we ever get are vague comments that don't change much from one decade to the next.
Perhaps it would be best for all concerned if GIMP's developers actually embedded this message in its installation program:
"GIMP is our play toy—it's prototype software for our own use and experimenting—it's NOT for normal user use. You may use it as is but please do not expect it to work like other imaging software and do not bother us with feedback for we'll just ignore you. You have been warned".
>they do things their way, not the way users want or are already familiar with
In my experience, a program that has never had a feature removed (or unintentionally broken) is an exception, not the rule. It takes a lot of effort to keep things working over the years, and if there is no will to maintain that, then those things will disappear.
Users, show precious little allegiance to any app when it balks them or they cannot find an easy way to do what they want to (run a help desk for a week and you'll get that message loud and clear).
As I see it, there are great swathes of poor and substandard software on the market that shouldn't be there except for the fact that there's either no suitable alternative, or if reasonably good alternatives do exist then they're just too expensive for ordinary people to use (i.e.: such software isn't in widespread use). I base this (a) on my own long experience where I encounter serious bugs and limitations in both commercial and open source software as day-to-day occurrences; and (b), data I've gathered from a multitude of other reports of users' similar experiences.
(Note: I cannot possibly cover this huge subject or do it reasonable justice here as just too involved, even if I gave a précised list of headings/topics it wouldn't be very helpful so I can only make a few general points.)
1. The software profession has been in a chronic crisis or decades. This isn't just my opinion, many believe it fact. For starters, I'd suggest you read the report in September 1994 edition of Scientific American titled Software's Chronic Crisis, Wayt Gibbs, pp 86-95: https://www.researchgate.net/publication/247573088_Software'... [PDF]. (If this link doesn't work, then a search will find many more references to it.)
1.1 In short, this article is now nearly 26 years old but it's still essentially the quintessential summary on problems with software and the software industry generally (right, not much has changed in the high-level sense since then, that's the relevant point here). In essence, it says or strongly implies:
(a) 'Software engineering' really isn't yet a true engineering profession such as chemical, civil and electrical engineering are and the reasons for this are:
(b) As a profession,'Software engineering' is immature, it 'equates' [my word] to where the chemical profession was ca 1800 [article's ref.], (unlike most other engineering professions, at best it's only existed about a third to a quarter the time of the others).
(c) As such, it hasn't yet developed mandatory standards and consistent procedures and methodologies for doing things—even basic things, which by now, ought to be procedural. For instance, all qualified civil engineers would be able to calculate/analyze static loadings on trusses and specify the correct grades of steel, etc. for any given job or circumstance. Essentially, such calculations would be consistent across the profession due to a multitude of country and international legally-mandated standards which, to ensure safety, are enforceable at law. Such standards have been in place for many decades. Whilst the 'Software Profession' does have standards, essentially none are legally enforceable. Can you imagine Microsoft being fined for, say, not following the W3C HTML standard in Windows/Internet Explorer to the letter? Right, in this regard, software standards and regulations are an almighty joke!
(d) Unlike other engineering professions, software engineers aren't required by law to be qualified to a certain educational standard [that their employers may require it is irrelevant], nor are they actually licensed to practice as such. When 'Software engineering' eventually becomes a true profession then these requirements will almost certainly be prerequisites for all practitioners.
(e) With no agreed work procedures or mandated work methodologies across the profession 'software engineers' are essentially 'undisciplined'. As such, the SciAm article posits that software programmers work more akin the way of artists than that of professional engineers.
(As a person who has worked in both IT/software and in an engineering profession for years, I have to agree with Wayt Gibbs' assessment. There are practices that are generally acceptable in software engineering, which if I attempted to equate them to an equivalent circumstance with my engineering hat on, then I'd likely end up in court (even if no one was killed or injured by what I'd done. Here, the rules, the structure—the whole ethos is different, and both ethics and law play much stronger roles than they do in software-land).
2. You may well argue that even though Computing Science is not as old as the other engineering professions, it, nevertheless, is based on solid mathematics and engineering foundations. I fully agree with this statement. However, without enforceable standards and licensed/qualified software practitioners, the industry is nothing other than just 'Wild West' engineering—as we've already seen, in software just about anything goes—thus the quality or standard of software at best is only that of the programmer or his/her employer.
3. As a result, the quality of product across the industry is hugely variable. For example take bloatware: compare the biggest bloatware O/S program ever written, MS Windows, with that of tiny, fast and highly efficient Kolibrios OS, built on Assembler https://kolibrios.org/en/ (here I'm referring to methodology rather than functions — we can debate this later).
4. The commercial software industry hides behind the fact that its software is compiled, thus its source code is hidden from public view and external scrutiny. Its argument is that this is necessary to protect its so-called intellectual property. Others would argue that in the past loss of IP was never really the main issue, as manufacturing processes were essentially open—even up until very recent times. Sure, it could be argued that some manufacturing had secrets [such as Coca Cola's formula, which really is only secret from the public, not its competitors], but rather industrial secrets are normally concerned with (and applied to) the actual manufacturing process rather than the content or parts of the finished product. That's why up until the very recent past most manufacturers were only too happy to provide users with detailed handbooks and schematics; for protection from copies they always relied on copyright and patent law as protection (and for many, many decades this protection process worked just fine). It's a farce to say that commercial 'open source' isn't viable if it's open. Tragically, this is one of the biggest con job the software industry has gotten away with—it's conned millions into believing this nonsense. More the true reason is that the industry couldn't believe it's luck when it found that compilers hid code well — a fact that it then used opportunistically to its advantage. (Likely the only real damage that would be done by opening its source is the embarrassment it'd suffer when others saw the terrible standard of its lousy, buggy code.)
4.1 'Software engineering' won't become a true profession until this 'hiding under compilation' nexus is broken. There are too many things that can go wrong with closed software—at one end we've unintentional bugs that cannot be checked by third parties, at the other we've security, spyware and privacy issues that can be and which are regularly abused; and there's also the easy possibility of major corruption—for instance, the Volkswagen scandal.
5. Back to your comment about 'good design not being free'. I'm very cognizant of the major resource problems that free and open source software developers face. That said, we shouldn't pretend that they don't exist, nor should we deliberately hide them. I accept that what we do about it is an extremely difficult problem to solve. My own suggestion to up the standard of open software is a sort of halfway house where cooperatives of programmers would be paid reasonably acceptable remuneration for their contribution to these major open projects. In turn, there would be a small nominal free (say $5 to $20) levied on large scale open software programs such as GIMP, LibreOffice, ReactOS etc. to ensure that development could go ahead at a reasonable pace (the projects otherwise would be revenue neutral—there would be no profits given to third parties).
Let me finish by saying that whilst commercial software has the edge over much free/open software (for example MS Office still has the Edge over LibreOffice), that edge is small and I believe the latter can catch up if the 'funding/resource' paradigm is changed just marginally. Much commercial software such as MS Office is really in a horrible bloated spaghetti-code-like mess and with better funding it wouldn't take a huge effort for dedicated open software programmers to beat their sloppy secretive counterparts at their own game. After all, for many commercial programmers, programming is just a job, on the other hand open software aficionados are usually doing it for the love of it—and that's a true strategic advantage.
I firmly believe that for open software to really take off it has to be as good as and preferably better than its commercial equivalent. Moreover, I believe this is both possible and necessary. We never want a repeat of what happened in Munich where Microsoft was able to oust Linux and LibreOffice. With Munich, had it been possible to actually demonstrate that the open code was substantially and technically superior to that of Microsoft's products, then in any ensuing legal battle Microsoft would have had to lose. Unfortunately that was not possible, so the political decision held.
One thing is for certain, we urgently need to raise the standard of software generally and it seems highly unlikely that we can do so with the way the industry is currently structured.
This wouldn't work. Most software isn't life-and-death. That's a big difference from bridge engineering, nuclear engineering, and aeronautical engineering.
If you're hiring someone to do Python scripting, there's little point insisting they have a grounding in formal methods and critical-systems software development. You could hire a formal methods PhD for the job, but what's the point? The barrier-to-entry is low for software work. Overall this is probably a good thing. Perhaps more software should be regulated the way avionics software is, but this approach certainly can't be applied to all software work.
If your country insisted you become a chartered software engineer before you could even build a blog, your country would simply be removing itself from the global software-development marketplace.
> compare the biggest bloatware O/S program ever written, MS Windows, with that of tiny, fast and highly efficient Kolibrios OS
I broadly agree, but in defence of Windows, Kolibri is doing only a fraction of what Windows does. Does Kolibri even implement ASLR? One can build a bare-bones web-server in a few lines, but that doesn't put Apache out of a job.
> My own suggestion to up the standard of open software is a sort of halfway house where cooperatives of programmers would be paid reasonably acceptable remuneration for their contribution to these major open projects. In turn, there would be a small nominal free (say $5 to $20) levied on large scale open software programs such as GIMP
This doesn't work. It means a company can't adopt the software at scale without implementing licence-tracking, which is just the kind of hassle Free and Open Source software avoids. If I can't fork the software without payment or uncertainty, it's not Free even in the loosest possible sense.
The way things are currently is far from ideal, but we still have excellent Free and Open Source software like the Linux kernel and PostgreSQL.
> open software aficionados are usually doing it for the love of it—and that's a true strategic advantage.
Agree that this can be an advantage. Some FOSS projects are known for their focus on technical excellence. That said, the same can be said of some commercial software companies, like iD Software.
> One thing is for certain, we urgently need to raise the standard of software generally and it seems highly unlikely that we can do so with the way the industry is currently structured.
Software firms today are doing a good job of making money. If the market rewards regressions in UI design, and using 50x the memory you really need (thanks Electron), what good would it do to regulate things?
Apparently most people don't care about bloat, and they prefer a pretty UI over a good one. That doesn't strike me as the sort of thing you can tackle with regulation.