Though disappointing Aurelien became increasingly difficult to work with, it seems to me equally disappointing that many of his excellent points are now dismissed because of it. Kind of like throwing the baby out with the bath water.
5 Likes
This is false reasoning aka fallacy. You would have to prove that because. I have been writing software since mid 80s (still have my diskettes with Atari 6502 code laying around) and can tell you that by the end of the day you can do just so much. I have seen literally millions of lines of code, personally hacked Linux kernel modules, had my Slackware pre 2.0 running on my 486 back in 94 and solved numerous software mysteries, maintained SunOs/HPUX/AIX/Apollo system for a few years. In all cases, the success is not a function of talent or brilliance but how much energy, dedication and most of all time you invest into given technology.
Unlike AP, I looked into the source code of Darktable and find it quite well organized. There are tons of inherent complexity in it, perhaps in some cases self inflicted, but hey, with 3 major platforms to support, so many special cases and exceptions, the gold requirement of never never break systems of existing users, even with user experience simplified, it would still be quite a beast to manage.
I also do like uniqueness of user experience of Darktable. Personally.
7 Likes
But many of his points are not the objective truth but opinions that you can share or not. Especially, all the UX topics. Unlike what others have stated, I don’t fear complexity on the user end if it helps getting the job done. And I really love the direction darktable is heading. E.g., I really love the new collection filters and also the way they work, also the much discussed rating filter makes sense to me. I love the possibilities that come with the new input system, e.g. for midi devices or hold key and mouse wheel actions.
The counter argument about lost responsiveness fails for me at the point where essential features/functionality are removed for the sake of speed. And during the last year, many speed improvements have been implemented anyway.
8 Likes
What it actually originally meant is someone who does it fot the love of the thing (and therefore wouldn’t NEED to be paid).
In cricket there was a long time snobbery in favour of the amateur.
People have stated in this thread (and other forums) that they find diatribe like this difficult to read and either give up or need to take some effort to get through it all. Obviously if people are unwilling to read/watch such arguments they will be unable to respond to them. I have seen an influential darktable developer (I’ll not name names and drag them into this discussion if they don’t want to participate) state that they ignore everything AP says because they distrust his motives (that he is just trying to discredit the project and throw mud). I don’t think this is true but he makes it hard to avoid this conclusion.
I think darktable could benefit from a period of reflection – asking what features are well-used and appreciated, what features should, on reflection, be removed. I think AP goes too far in feature removal but I agree with 80-90% of his core suggestions. I think darktable does have some UI feature bloat and would be much better for some simplification / removal of unnecessary features. But I prefer to try to make changes from within, and offer reasoned arguments rather than polemic.
3 Likes
Hello everyone,
I have read Aueréliene’s post with great interest because, IMHO, he is a VERY highly intelligent guy 
I still recall his very first posts, many years ago, on this same forum, where he proposed some interesting python code.
Later on, he invested himself into learning the C code to work on darktable full time
As Thomas Edison wrote: “Genius is one percent inspiration and ninety-nine percent perspiration”
Some points he raised, as already acknowledged by some previous posts on this thread, are valid even though they may be expressed with too much virulence and anger.
Probably, in my view, he has invested too much time on darktable and, consequently, he is now burn out.
As he himself explained, in the end, he didn’t felt “rewarded” for his work (especially by donations and such)
I am a RawTherapee user and I have never felt the urge to learn a new software to develop my Raws (Nefs) files
In addition, RawTherapee was born on Windows and I have always primarily worked on this proprietary platform (later on was ported on Linux as well)
However, I do follow darktable development. Especially on github. Just out of geek curiosity.
In my view, it is an incredible piece of software.
I DO admire the work done by his maintener (aka TurboGit) over the years.
The other darktable developers are incredibly talented as well: ralfbrown last contributions to speed up the code are extremely useful in the long term.
Some features of darktable have even been ported to RawTherapee (and Art) over the years. For instance, recently, the hightlight reconstruction code by jenshannoschwalm
Considering only the fact that darktable runs on Linux - Windows and Apple is nothing short of outstanding. Not even many expensive proprietary softwares (Lightroom, Capture one etc) allow this on Linux.
The comnplexity of darktable is, in my view, strictly due to the huge amount of its features.
It is aimed at “professionals” and, as every complex thing in life, it require a LOT of time to be truly mastered.
However, on YouTube, just to name one, there are tons of video tutorials and they are all free to watch. It just takes time
If you read the forums of proprietary softwares you often encounters users who criticize the same difficulties in learning as regards Capture one, Photoshop and the like.
I have read VKDT (GitHub - hanatos/vkdt: raw photography workflow that sucks less) might be the best option in the future. In my view, it will require many years before it is on par with darktable in terms of features.
At present, it only runs on Linux just to mention one drawback. As soon as it is ported on these 2 platforms it is very likely that many bugs and regressions will occur
As soon as you are forced (e.g. by users’ requests) to add to it a “true” GUIs (QT, GTK etc) it will be much more complex to develop it considering the lack of time for open source projects.
Usually softwares are quick to develop as regards basic features but as soon as you add more options they slowly become a burden.
GIMP and KRITA, just to give an example, are more than 15 years old and if you take a look at their bug-tracker you might be scared to death: this is not a criticism if only because with open source software you are allowed to take a look at this list
Just my 2 cents on this very different topic (sorry to have derailed a bit)
Best regards to all and please continue posting new messages on this forum
6 Likes
I’ve been following the discussions around Darktable & Ansel as well, because as an end user, I find Darktable to be a great piece of software to quickly get results I like with my workflow. I think the workflow issue is an important part of where AP and other Darktable developers disagree. Basically, Darktable is set up for several possible workflows. I have the choice of various modules to achieve the same goal, can arrange these modules in the pipeline as well as the UI as I like, etc. I agree with AP that this is problematic for many users and reasonable default values are necessary. Steps have already been taken to do this with scene-referred workflow etc. I can’t say much about code visibility, I’ve seen AP’s examples and they really are examples of code that is not well maintainable, whereas you can find something like that in any larger project. I also think that some points certainly apply, especially if COde you fixed yourself is later made worse. There is always the question to what extent this can be prevented in an open source project, there are mechanisms such as code reviews by maintainers, etc. but they also work in their spare time and therefore do not always have the time to check all changes carefully or to think about the effects.
On the other hand, the approach of AP, which on the one hand tries to provide a uniform workflow for users. I have tried Ansel and get along with the defaults largely well, but have a central problem with the arrangement of the modules in the edit area. They are logically sorted into tabs, but I have a default set of modules that I need and I just put them in a tab underneath each other in DT so I can access all the modules with one click. In Ansel it often takes up to three clicks (1x scroll horizontally to get to the appropriate tab, 1x select tab & 1x select module). This is much slower in Ansel than in Darktable, where I could configure the view myself. Furthermore, AP with ANsel does not have the problem that others contribute “bad code”, but buys this by shouldering the project alone and must be himself maintainer with Contributions. I don’t know if this is feasible for a single person in the long run, since he is also financially dependent on the success of Ansel - I think this is a good setup for burnout. If AP gets sick or similar, Ansel will also stagnate in development. In general, the goal of AP will be decisive, currently he seems to remove / change things that bothered him and then work on individual modules and accordingly strive for a slower development speed than DT - perhaps the project is manageable by largely one person contributes the main work. I don’t think this is a bad thing, in general DT/Ansel is already perfectly usable today and there is not much I personally miss.
Overall it’s a situation with no real way out, generally I would also say that it still has something good and ideas from AP can flow into DT as well as visa versa.
I never said it was objective truth. Also note I did not say it was my opinion that all his points were excellent. Merely that he did have many excellent points.
Yes, of course I read it. But I just focus on the technical points, and ignore the drama, so that part is not relevant for me.
I find that this is the best response in most life situations; the more people do this, the sooner we converge to a fixed point of finding a solution.
Photography is interesting. Software can be interesting. Drama is only interesting in the theater.
4 Likes
You can look at Blender. It is a successful libre software, yet developers decided to not rely on what you call “true GUIs” and instead develop their own UI. This makes sense because of the nature of the software.
3 Likes
For a long time, due to lack of a garage and/or second/backup vehicle, despite having done a lot of my own vehicle maintenance in the past, I was taking my car to shops.
I had a few bad experiences, including one that had my car out of commission for 3-4 days, and I swear I overheard in the back room “I didn’t realize that was threaded” (likely referring to my steering knuckle that they had cracked). When starting to do my own maintenance, I found all sorts of issues that were the result of incompetence. For example, one of the mounting bolts for the brake caliper brackets has its threads completely stripped. I know exactly why - it’s well known in this country that lots of “professional” mechanics rush (time is money) and will fasten a bolt with an impact wrench without any form of torque limiter. As a result - lots of overtightened bolts, frequently with resulting damage.
Oh my… You would have been amused by one of my company’s internal meetings about adopting components from a FOSS project that had an internal “quality level” rating system. There were proposals to only accept the highest quality level, a number of engineers pointed out that the vast majority of our software was nowhere close to that in terms of process. (We’re getting there/improving, but there’s a lot of inertia to compensate for…)
3 Likes
For giggles, how would you rate the code quality of dcraw.c? In terms of maintainability, probably zero, but have you ever had it segfault on you?
For all its warts pointed out here and elsewhere, darktable weathered a rather wrenching change in adopting a scene-referred workflow. Is that worth something in the “quality” angst?
Gotta sit back and say, “What’s really important here?”
5 Likes
Oh, on my morning walk I thought a lot about this discourse. And, a particular utterance of mine that disparaged AP’s propensity to cooperate. I’d like to take that back, it was not at all constructive like I really want things to be. Indeed, he demonstrated remarkable cooperation in his willingness to learn C/C++ to actually contribute major PRs to darktable.
Aurélien, my profound apologies…
6 Likes
Apparently yes, yes, yes, yes.
Of course no software is perfect, but these days
- not having a test suite with a bunch of images,
- not running automatic checks for memory leaks
is kind or archaic. Setting up CI has such a high benefit/cost ratio that not doing it is kind of silly.
Welcome to dcraw !
4 Likes
Interesting. Big reveal: dcraw is a maintained Debian package!!
1 Like
I am not sure what your point is though. Being packaged by a Linux distro is not a signal of software quality or maintainability.
Note that I have nothing specific against dcraw, and I don’t claim that it is badly written etc. I was just responding to your question about segfaults, which was kind of a low hanging fruit (because every nontrivial piece of software has bugs, and bugs in C frequently lead to a segfault).
I think my point is that there are a lot of aspects to consider regarding software quality, and not all of them correlate to use cases. dcraw.c is a really good example of coding done to facilitate the understanding of one person, but the executables produced from it are quite reliable. I’ve never had dcraw crash on me.
I tracked down who’s maintaining the dcraw .deb, a fellow named Filip Hroch, apparently a member of the Debian Astronomy Team. That doesn’t change the quality or maintainability of it, but it is being maintained. Who’d you think resolved those bug reports?
1 Like
I agree with the point you were making in your post, sorry if this was not clear. I just wanted to point out that, besides some really valid points, there are also a lot of points which are not necessarily valid: In particular regarding the lighttable UX. Furthermore, one thing that was criticised many times is the maintainer’s work, in particular the early merges of half-finished features. This is something I cannot agree because the alternative such as having a roadmap and sticking to it is hardly possible for a purely volunteer driven project. In the oft-mentioned blender project it is different as there is a foundation and a team of paid devs. This is not comparable, so I think what Pascal does is close to the best you can do.
But I guess I am drifting away from the topic …
2 Likes
This is why I like the Portuguese word for it, amador
1 Like