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
17 Likes
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
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
This is perfect, even the time is about right. However my workspace is never this clean 
1 Like
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 
2 Likes
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
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
No need to do that
2 Likes
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
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
LOL! Quote of the day!
3 Likes
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.
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…!
Some projects use bounties for targeted development, but I don’t know how popular they are.
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
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
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.
As I explained just above, that kind of process existed a lot around 2005.
If patreon, tipee or libreapay are more popular today , it’s probably because the bounty model does not answer the need of user and developers that well.
1 Like
I believe there’s two main issues with bounties and micro-payments of any sorts: 1. Many devs already have a job and tons of other obligations (see OP), and they like those (mostly) and the open-source project is very important to them, but as a hobby. Here money isn’t a factor. 2. The unreliability and up-front cost/risk that needs to be taken by a dev that would like to make it their job. You need to deliver first to get people to trust you and pay you. And even then it’s an up-hill battle. See e.g. @anon41087856 which is working full-time on open-source since what feels like quite a long time now (about a year?) and definitely does deliver great value, and he is approaching 200 euros/week on liberapay - that’s not a living wage.
Even with a foundation backed with some funds it’s hard to pay for development, because contracting is super hard. You usually can’t just take anyone to do the feature, you need someone that knows the code-base well. Finding a contractor that can familiarise themselves with it and then implement the feature in what’s usually a pretty constraint budget is almost impossible, respectively a time-demanding job in itself.
1 Like