I know Aurélien Pierre is as popular here as AI derived posts but I do wish he’d leave his bile at darktable alone. Clearly he borrows updates from other opensource products so he is in effect part of the FOSS photography scene and not a lone figure with his software. ANSEL looks good (but I have crashed it a couple of times) and if you’re a darktable user its easy to get around. I just wish he’d let his animosity, go even his posts this year still have negative comments. Its sad to think that every time he opens up his PC to work on Ansel his mind is still feeling bitter towards other talented developers. Clearly a talented programmer but his comments on his webpage probably lose him a lot of followers. Its time to get over the divorce Aurélien, you have custody after all of a very decent package.
he only got removed from the forum after his behavior got too toxic.
nobody questions his technical skills and that he might pull in fixes and features which are happening elsewhere.
I don’t think he was removed, but he removed himself. It’s unfortunate that he left the under those circumstances, but the Darktable community has move forward admirably since then.
This is correct, he asked for his account to be removed and I obliged. His toxicity was (probably wrongly, looking back at it) tolerated because at the end of the day, he wrote some great code that helped move darktable forward.
As much as he’ll never ever admit it, darktable gave him what he has today in Ansel, and you can tell that he both remembers and hates that fact every time he interacts with Ansel.
I will be forever grateful to AP for the work he has contributed to DT. It is a shame that he struggled with being a team player. I tried Ansel briefly but he had removed many modules which he regarded as bloat but which I wanted the option to use. Shadows and highlights being at the time the module I most noticeably missed. In his view tone equalizer replaced the need for shadow and highlights so it should be gone. Wrong, they were very similar modules but different. Now DT is about to include AgX I couldn’t consider Ansel. AgX in my view is what filmic was trying to achieve.
Art is a fork of RT but I haven’t picked up on any bitter feelings from the maintainer of ART towards RT. He just seemed to be offering a fork of RT. I am sure if AP had wanted to offer a fork of DT it would have been very welcome. No need for animosity. He wanted to remove a lot of modules he felt where bloat. Nothing wrong with that as part of a fork.
Alberto did a bunch of work on RT before he forked off. You didn’t pick up on any hard feelings because there aren’t any.
I feel APs fork of Ansel would have been well received and there was no need for hard feelings. His philosophy about bloat was possibly a valid point but could best be handled as a fork of DT.
I reckon Alberto has done a great job with Art and it gives another option to RT users.
His bloat rant was mostly correct in my opinion, and you can really feel it if you boot Ansel up. If we ignore the advancements darktable has made in the darkroom pipeline, Ansel UI is just leagues ahead of darktable in UI responsiveness, it’s not even close sadly, as darktable is now much better even with a slower UI due to all the pipeline improvements in the backend and also the new modules (AgX, Capture Sharpening, etc).
In my opinion this fall off is a tragedy to darktable and a loss to the foss photography community as a whole. While mostly AP’s fault, I agree that more discussion should’ve been had around adding those MIDI shortcuts to darktable, along with other UI changes, which broke the camel’s back. While I have trust that the current maintainers of dt can handle it, what about the future?
This whole topic hits home because In my personal and work development I always strive for as simple code as possible. After years of dealing with thousands of lines of mess, and being the guy who was called to fix it, I became a bit radicalized in this topic. If it means sacrificing 20% of features to have 70% leaner code, than so be it, and that’s exactly what we see happening in darktable only in reverse. His arguments are strong even if delivered in a rude and disrespectful manner and the UI speed results speak for themselves.
I’m not a coder, but from my point of view this sentence is far too general. If this 20% of features are the features which makes the difference, I wouldn’t touch a single line of code. If these features are just a nice to have, we can talk about it.
I love to have options, that’s why I’m a KDE lover and why I love dt.
I’m sorry to say, but if I compare Ansel to darktable I always have the feeling that Ansel is a crippled darktable - just from my humble user view.
As already written, I’m not a coder, so I haven’t followed the quarrel between AP and the others. But if I look at his homepage, he seems to be extremely embittered. Bitterness is a bad companion!
Instead of leaving the project in bitterness, he should have chosen to simply fork it for his own ideas but work together for developing on shared goals.
Now he is wasting valuable lifetime for negative feelings and on writing longish articles, why darktable will be driven against a wall. And why this and that what is developed for darktable is rubbish.
Is it really worth? Life is too short for so much bitterness. Why waste the time you have for looking back in anger, use your time for positive things.
I usually try to keep it, like in Monty Python’s Life of Brian:
Always look on the bright side of life!
In the commercial world, features equal sales, so there must be features or the company will fail.
In the open source world, the project will fail if people stop contributing (maintainers included). Thus a leaner code base that is easier to contribute to is a necessity, while features are not.
Of course this is ultimately true for commercial software as well, but it’s secondary to being able to pay bills. I’ve been that guy, too, who has cleaned up the messes left by unfettered feature growth.
Not a coder either (nor a dt user, for reasons that I think are closely related to AP’s arguments), but I believe the word “features” does a lot of work here.
A “feature” in the sense of inefficient coding/computation and usage might simply consist of too much flexibility.
Too much inefficiency with particular regard to usage is, if I understand it correctly, the underlying reason for the ART fork of RT.
dt is very likely the most flexible RAW processing software in existence, but it’s probably precisely this flexibility, this lack of commitment/limitation to a certain processing philosophy, which leads to bloat and inefficiency in coding/computation and in usage. Again, not a coder, but I think it tracks.
Yes, this is what I meant. I meant features more in the sense of specific features within a general theme(or feature…) such as “Shortcuts”, “Light table filtering” etc. Of course in commercial software in my work we do need to do what the clients require, but there is always some leeway to making things properly and as lean as possible. Sometimes it really is the 5% that require 50% more code, and then turn into a nightmare when you need to work on the other 95%. This is not even an exaggeration.
Yeah of course, I 100% agree on this and I hope I made it clear in my post 
The argument is good, but the way it was handled was not
I am coder, and this sentence is far too general.
I have reviewed a rather of number of large projects (In my world 100.000 lines of code is small) in the past. Number of features, number of lines of code, these numbers don’t mean much.
The real complexity of software is in the dependencies between parts of the code. If you have 10 functions in your code and they all need each other to do the job, you have a very complex pieces of software. (you could see a piece of software as a graph and look at it’s complexity and connectivity)
I haven’t looked into the code of darktable too much. But the module approach doesn’t have to be a bad thing, and the modules code could be independent. I can very much understand why the crop and rotate and perspective modules are separate.
I agree with @Popanz on writing about the bitterness. I hope that someday reconciliation is possible.
In the case of a fully flexible processing pipeline, module interdependencies aren’t in the software itself, at least not in the sense of a computational necessity, but they can easily and inadvertently be created by the user.
In this sense, dt’s inefficiency goes beyond mere feature creep or software bloat. It’s usage bloat, it’s flexibility creep. Because how would the coders even tackle interdepencies when the overarching main goal is to preserve full usage flexibility?
With regard to AP’s tone, I haven’t been here for that long, all that happened before my time and I can’t really be bothered to look into it. All I can contribute to this point is my experience on another volunteer project, Wikipedia, which I left more than a decade ago. The reason I left was that the community was really eager to establish behavioral rules and even has a kangaroo court mostly focused on behavior, while at the same time the project steadfastly refuses to have any editorial oversight board. So, “civility” is far more important than any editorial arguments. And the result is that there are many pockets of articles where small groups have near total control to police articles to their liking because they’re smart enough to never violate civility policy and successfully goad other users into using a “bad word” once, which is usually enough to have them blocked by a likeminded admin.
If AP was very aggressive/condescending in his tone, I’m almost certain that there was a correlate to this on the side of the dt project, in terms of lack of editorial leadership. And “go create your own fork then” is a passive aggressive response from the established system that I’ve seen far too often. Just my 2 cents.
Is it really worth? Life is too short for so much bitterness. Why waste the time you have for looking back in anger, use your time for positive things.
Just a wild guess: since I am a RawTherapee user…
Since Aurélien wished to make a living from his work on darktable (which is 100% fine) and for various reasons (mostly lack of donations, in the end) this not worked out, he got frustrated and angry. Hence his disappointment towards the other darkable developers and his decision to fork the project.
As regards the bloat of darktable he might perhaps have a point.
However if you do take a look at the github web-page of darktable there are plenty of commits and even new developers who, regularly, join the project for some small fix and features. Therefore, in my book, as of today, darkable is in a very good health.
There are no other “similar” projects (e.g. ART - RawTherapee - Vkdt) with this amazing amount and diversity of commits.
The upcoming 5.4 version of darktable is a proof of that with its changelog
The discussions didn’t happen around the pipeline at all, it was mostly about UI features.
This is true. If you read his latest article (won’t link here, you can find it) you can see the interdependence introduced by the MIDI shortcuts as an example
Yes, and many of us agreed with the points he made. I for one remain frustrated by some of the more overly-complex UI features (especially when I have to work out how to explain them to users in the manual). Unfortunately when you approach these things with a combative tone, you push your “opponents” into a defensive position that it becomes hard to retreat from, hence the fork.
IMO one of the best things darktable could do right now is streamline/remove/revert some features, though I understand how hard it would be to come to a consensus on what needs to go (much easier with a single dev). A brief look at some of his documentation suggests to me that Ansel went too far with the feature bonfire.
Hello @elstoc
Yes, and many of us agreed with the points he made. I for one remain frustrated by some of the more overly-complex UI features.
Yep. Thanks to the recent initial port to GTK4 toolkit (from the current GTK3) I am 100% sure this problem will be tackled in the future.
However, since the darktable user base is huge is extremely likely there will be some of its users who will complain because their very personal important feature has been removed 
In the long past, I have read a survey of Microsoft. It showed that Excel users, generally, know and use only 10% of the options of this program.
Therefore, we might suppose that the other 90% is “bloat”
Yup, this is the problem, and is also why we have so many features in the first place (and so many options to toggle them).
Not sure I see how that follows TBH, though I’d like to think that’s true.