Why won't the devs implement my feature or fix my bug?

Software
1

Lately I’ve seen a couple of threads like

“Hi, I’ve started using FOSS software program. Kudos to the devs for a great piece of software. Here’s all the problems I’ve discovered with the software. I’ve used paid software and this program doesn’t have my critical feature. Why haven’t the devs implemented this feature? Are they deliberately crippling the software?”

So, let me tell you what it’s like to be that mythical beast, a dev.

I’ll tell you my story. Other devs may have similar stories or different, but they all have stories.

I bought my first SLR, a Minolta SRT 101, 45 years ago. I keypunched my first line of code onto a card 44 years ago. I’m married with 10 kids, 8 grown and gone and 3 with special needs. I have 19 grandchildren, but most don’t live close. I have a 120 pound dog that hates delivery men and loves me. My wife lost most of her vision several years ago and is legally blind which makes me the cook, maid, chauffeur, etc. I have a house payment, 2 car payments, a computer services business, and a photography business. I mostly shoot sports and high school senior portraits.

Why tell you all of this? Just to show that I’m a person just like you, with bills, jobs, obligations, things that have to be done, etc. But, later in the evening around 9 or 10 o’clock I finally get to be a dev, unless I have to process pictures. I usually shoot 2 or 3 times a week, so that leaves me 4 or 5 nights a week to be a dev.

What’s it like to be a dev?

darktable is a large complex piece of code. The section I try and take care of is the embedded lua interpreter, the lua API and the lua scripts repository. I can and have worked on other parts of the code, but the the lua part is what I’m most familiar with and have stepped up to take care of. Other developers take care of other sections of code, or other items such as translations, documentation and testing.

Each day i read the issues with darktable and with the lua-scripts repositories. I read all the new messages on the darktable user and developer mailing lists. I come to pixls.us and read the new posts looking for issues with darktable and/or the lua-scripts. I read and respond to any e-mails I receive dealing with darktable and lua-script issues. If I see an issue that I think could impact the user base, I try to confirm the issue or understand it. If it’s related to a misunderstanding of how darktable or the lua-scripts work, I try and offer help. If it’s a bug, I try and confirm it and do a quick track to see what could be causing it. If it’s something that’s not part of what I usually take care of but I feel comfortable fixing it and have the time, then I take it on. If it’s something that I do take care of then it’s mine. The first thing I do is recreate the issue. Then I determine the cause which often involves adding print statements to sections of the code, rebuilding the executable, running it trying to create the problem, evaluating the results, then doing it again. It’s a repetitive process until I finally uncover the cause. Once I understand what is wrong, then I can go about fixing it. I determine a fix, code it, build darktable, then test it. Sometimes I get it right the first time, but usually it takes a few times. If it’s an issue with the lua API, then often I’ll write a lua script just to exercise that part of the API to make sure I didn’t miss something else. Once I have the fix, I create a pull request and submit it for review. It gets reviewed and accepted or there is conversation about the fix and sometimes I have to redo the fix because I made an error or failed to take something else into account. Usually fixing an issue takes me a week or so. I’ve had ones that I’ve fixed within hours and I’ve had others that took weeks.

Now for some numbers.

I just checked and there are 614 issues open on darktable. In the last 30 days, 28 devs submitted 120 pull requests which closed 99 issues. So, if no one submits an issue for the next 6 months and pull requests continue at the same rate we should have the issues all fixed by April.

In contrast Adobe, Inc., one maker of paid software has 22,000+ employees. How many work on each piece of software. 500? 1000? More?

So what’s it like to be a dev? When I fix a problem or add a new feature, it’s great. But there are other nights when I’m tired and can’t think, stumped by the problem or can’t figure out the fix so sometimes I just have to walk away and come back to it tomorrow.

And now to the question that I titled this with. Some answers in no certain order:

  1. We’re working on a bug fix or feature and need to complete it before taking on something else.

  2. We don’t understand what you are asking. While it may be clear to you, if we can’t understand it we can’t implement/fix it. Add to that language barriers which create misunderstanding, so sometimes it takes a lot of conversation to determine what to do.

  3. We don’t know how. We have to figure out how to do it, and how to make it fit with darktable and have everything work together.

  4. There aren’t a lot of us and it just takes time.

So, please try and remember that devs are people too. We are doing this because we are problem solvers and like fixing things, because we like helping users, because we are photographers and use darktable, and because it makes us happy.

Thanks,

Bill

P.S. I’m a professional photographer and I use darktable. It was the first raw developer I used, so my growth wasn’t stunted by paid software :grin:

P.P.S. darktable does support batch renaming. See batch rename · Issue #269 · darktable-org/lua-scripts · GitHub

47 Likes
2

:clap:

3

In some cases, it would be better for users to fix the bugs themselves. I had improved Krita a bit myself. Even incomplete work can help, like my guided selection patch for Krita which unfortunately has unresolved bug with no explanation.

1 Like
4

Strip-Vision-Open-source-650-finalenglish

17 Likes
5

Actually many Open Source Apps fall somewhere between the 2 with an occasional bunfight off to the side. Small projects most often have a single developer/maintainer, medium to large will often have multiple developers and a few have what most would recognise as a team.

A few things to remember:

  • Bug reports that are all of the following are most likely to be fixed soonest:
    • Clear, politely worded, details of the bug
    • A simple test or sample that reliably reproduces the problem
    • A clear use case of why & how this impacts lots of users
    • A suggested fix or pull request
  • Feature requests are more likely to be implemented if:
    • They have clear examples of possible use
    • They include examples or mock-ups of what they could look like
    • Fights are not picked over the lack of them
      Of course, if a feature is important enough to you then, under most open source licenses, you are quite free to fork the project, develop the feature yourself and try to interest people in switching to what is now your project, be prepared for a lot of work!
3 Likes
6

Maybe its time to open a new section in the FAQ to address the kind of issue presented by the anxious photographer in the last days.
In my opinion, there’s an increasing number of people considering switching to open source, given the current commercial policy from Adobe and maybe others. If I’m not wrong, we can witness this movement by an increasing number of new pixls members in the last year.
So, the probability of more people joining the forum with the same demands as the anxious photographer’s might be significant.
The new FAQ section could address those kind of expectations (“why open source sucks when compared to commercial software”), and it should point to the anxious photographer thread, as well as this one. I think that thread is exemplary because the anxious photographer expresses the mindset of many who make the move to open source better than us.
Our answers in that thread - as well as this own one - show how to bridge the gap, and how to handle the anxiety it might bring with it.
Next time an anxious photographer comes by, we wouldn’t have to repeat ourselves, just show him/her the FAQ.

4 Likes
7

This is perfect, even the time is about right. However my workspace is never this clean :rofl:

1 Like
8

That number comparison will throw a bad light on RawTherapee, except you would also count the ~ 2500 commits between RT 5.8 and current RT dev version :wink:

2 Likes
9

I think the most important thing for anyone considering switching is to understand what darktable is not. It is not like whichever paid software you use, doesn’t have the same features, doesn’t have the same workflow, etc. It’s not going to be learned in an hour, or a day, or longer. If you take the time to learn it, with an open mind, it’s a wonderful tool capable of producing great images.

When I first started using darktable (1.4.x) I knew nothing about raw processors other than Canon’s DPP, so I didn’t have to unlearn anything. However, I wasn’t very good at darktable, so I’d start an image in darktable then export and finish in GIMP. Then I’d import it back into the film roll and group it with the raw. Being lazy, I learned lua and figured out how to send the image out to GIMP and get it back, and thus started my road to devdom. Now the tools in darktable, as well as my skill, have improved to the point where I rarely use GIMP.

The other thing I would tell people thinking of switching, is watch the videos. There is an ecosystem that’s grown up around darktable so that there are many more learning avenues available besides reading the manual and trial and error. @Bruce_Williams , Rico Richardson, Hans Birkeland, Robert Hutton, and others have created lots of videos about how to use the features. @s7habo’s workflow videos showing what darktable is capable of are amazing and were really an eye opener for me. They taught me a new way of thinking about achieving what I wanted from my images and how to do it.

My last thought, but possibly the most important, is guidelines about how to interact with an open source project/community. The batch rename in darktable IIRC started here as a “is there a way…” or “I wish I had…” topic. There was some discussion about what it should look like and how it should work. I had the variable substitution coded as part of another script so I offered that. Someone else said there’s this function in the API that would help. I wasn’t busy, so I coded it up, created an issue on the lua-scripts repository, and pushed it out for people to play with. Everybody ended up a winner. People contributed ideas that turned into a useful addition. I got to create something. Someone got thier problem solved. Others in the community have used it and found it helpful. Perhaps we should try and capture the conversations as a how to/how not to example of community interaction.

6 Likes
10

I’m sorry. I didn’t mean to show RawTherapee or the community around it in a bad light. I really wanted to just use the number of active developers versus the number of issues trying to make people understand there is a resource issue and that’s why it takes awhile to get a feature or fix implemented. I used the github insights which didn’t really give me what I wanted, but I didn’t want to lose my train of thought by messing with git trying to get more representative numbers.

I understand why what I chose was a bad metric as far as project momentum and that shows another part of the issue which is incorporating things for the next release which takes resources from bug fixes. I’ll remove the statement about RawTherapee.

3 Likes
11

No need to do that :wink:

2 Likes
12

Yes, I think so, too. I am pretty active on the German “Nikon Fotografie Forum” and because I am pointing towards Linux and FOSS in general, I get more specific questions about darktable today than I got two or three years ago. Twelve years ago I was considered some exotic weirdo, today I am part of a minority.

If the same people who rant today about Adobe or (name of XYZ software) convert to FOSS, they won’t do it because they understand the idea behind FOSS. They will come over because they are so absolutely fed-up with some attribute or feature of the software they use (for years and years) that they finally swing over to an alternative solution. Very often that alternative solution is Capture One (for those who think that it can’t be good if it has no price-tag), sometimes - or rare occasions - that alternative solution is dt or RT or whatever.

These new users expect the new software to work the same it did before AND that problematic feature being solved. The idea is “I trade some weekends of learning the new software’s GUI in exchange for a better product” . They do NOT think “I now use a product that has been made by a motley crew of volunteers who gave hours and years of their time to make this work”. They measure dt or RT against what they know. How many clicks from RAW to the JPG they want, how “clear” are the labels, how understandable is the workflow?

I think dt is user-friendly. As far as raw-converters go, you ALWAYS need a couple of weekends until you know what you are doing. The learning-curve is flat in dt, but it is also in LR or C1 or RT or … you name it. At least that’s what I’ve been told because I do not know a lot of other RAW converters - I came to dt when RAWstudio was put to a halt and that’s it.

Are the … project crews (in lack of another name) ready to deal with the strictly consumer-oriented ways of former Adobe users who express their expectations for feature A and B to work at once and never stop ranting? Is there a benefit for the teams around FOSS if their product is in wide-spread use? By people who don’t understand the least bit of it and keep criticizing 24/7?

5 Likes
13

Here’s a thought… the devs could consider a hybrid development approach. By this I mean -

PARTLY - carrying on as now making changes which they like or see as worthwhile

and PARTLY - responding to development / feature requests by quoting a price, allowing users to sponsor the work with money, and then proceeding if enough is committed. Devs you can support sometimes have a target amount they’d like or need each month, this kind of builds on that. I appreciate it’s not without complications!

3 Likes
14

LOL! Quote of the day!

3 Likes
15

Isn’t this precisely why some developers are running Patreons and whatnots? We have some people on Pixls that do that too. There are of course also big open-sourced projects that are funded through commercial partners. Dear ImGui springs to mind. So methinks this hybrid already exists and you have options if you want to monetize your project.

16

Not really! dt people aren’t set up to work like that at present. There is no list of projects I might sponsor on github. There is no mechanism to pay. You can’t see how funding is progressing for a project you’re interested in. Etc…!

17

Some projects use bounties for targeted development, but I don’t know how popular they are.

18

I started contributing to RT in 2013 and still contribute to RT. Once in this period, I did a payed targeted development for RT (was 2K euros for 2 days of work), but that was the only one. As I did that, I thought, cool, but if you calculate it for 7 years, it’s just 2000€ / (365 * 7) = 0.78 cents per day…
Even power consumption of the machine I use to contribute to RT needs more than 0.78 cents per day…

1 Like
19

When I look at existing successful projects like Blender, Mozilla, or Godot, none of them propose bounties for specific features.
I remember that, in the past, some projects proposed features bounties but I don’t think it’s a popular funding way anymore.
As a developer or association, you need to have regular income to be able to plan, and to make your product evolve, add features, optimize, …
It’s difficult to achieve a sustainable income with bounties.
Just take an example: you need 1500 as income/month, you decide to put 3 possible features, each of those fully funded at 1000. After a pledge period, all of them are at 500.
None of those feature is funded, but with the promised donation you could work for a month on the project, and maybe make some progress on one feature.
And it’s quite the same for commercial software: you pay for support and development, but you don’t have a voice on the roadmap, or specific features.
Now, what a developer or association could do, is to create special communication channels, special builds, material, or stuff like that to allow their donator to participate or influence a bit more the project roadmap or priorities in development.
For example, Godot engine allows their higher tier patreons to submit questions before live QA sessions.

1 Like
20

I like the suggestion and have often wondered why you don’t see it in action already. Perhaps devs feel the monetary value gained would not be worth the hours spent, so they would rather just do their own thing. I would like to see someone trial it though.