Help Me Help You, Maintainers | Hacker News Reader

Help Me Help You, Maintainers

matduggan.com

43 pointszdw21 comments

As the maintainer of several popular open source projects (e.g. https://chezmoi.io), the forms of help I appreciate the most are:

* User support. Answering questions in discussions, social media, and GitHub issues. This helps on multiple levels: it saves me time that I would otherwise have to spend, and builds a community around the project.

* Documentation improvements. Better documentation means less user support work and helps everybody.

* Issue reports with a clear, minimal, way to reproduce the problem.

* Pull requests that follow the contributing guidelines of the project. This means that they follow the project's conventions, include tests, don't break any existing tests, and so on.

I don't write open source software to make money. I write open source software because I enjoy building high-quality software and I get a buzz from helping people.

Thanks for your work on Chezmoi! I've been using it for years. Straightforward tool with clear and concise documentation.

> "We need to support open-source maintainers better!"

> "Let's have a conference to discuss how to help them!"

> "We should provide resources without adding requirements."

> "But how do we do that without more funding or time?"

> "Let's ask the maintainers what they need!"

> Maintainers: "We need more support and less pressure!"

> "Great! We'll discuss this at the next conference!"

> "We need to support open-source maintainers better!"

Maybe some maintainers should be invited to these conferences? And maybe more direct communication with the projects you want to contribute to? I get the impression from the article that these conferences the author describes are more virtue signalling than an attempt to solve the issue.

I do think that advice at the end of the article is useful, but the opening makes me feel that no one's actually having a conversation with maintainers.

The list at the end isn't that good though. It's basically dictating this Matt Dugan's preferences. The third one about seven systems is both an exaggeration and a demand.

The rest of this page makes me think it would be really hard to work with Matt, and I'd probably just pass back when I was running projects. It's not worth the effort.

>The third one about seven systems is both an exaggeration and a demand.

I don't know how many times in the post they say some variation of "it's your stuff, do whatever you want", but it's certainly more than once. While they didn't explicitly say it (again) in this particular sentence, "do what you want" is repeated enough times throughout the page that it's pretty clear that nothing on this page is a "demand".

"You provide an amazing service and I want to help. But part of helping is I need to understand what is it that you would like me to do."

Is a pretty reasonable take. I don't know how that translates to "really hard to work with", but, in their own words: "It's your project, you are welcome to do with it whatever you want".

Other than the one about using only one platform, which you referenced, it seems like he's really just asking for clarity from maintainers about what contributions they would like, and how they would like them to be provided.

What items on the list do you think are just the author's preferences, but other potential contributors wouldn't like? It seems unlikely that contributors would prefer NOT to know if the maintainer doesn't want PRs, or would prefer NOT to have an example of how to contribute, e.g.

Two things to think about:

One, as the article points out, supporting Maintainers is important.

Two, many software engineers don't enjoy writing documentation. Even if it would make their lives easier.

From that perspective, the majority of these complaints revolve around communication. However, this article frames documentation as something only the maintainer should write.

Why not make a PR to update the documentation yourself instead of asking the maintainer to do it?

Instead of getting frustrated about opening a bug in the wrong place, why not document the right place?

If the description around PR criteria doesn't match your experience, why not create a PR updating it to include undocumented requirements?

I had the misfortune to yet again interact with the world of FOSS today. This is how it panned out:

1. Heard that something called Rustdesk is a good VNC solution.

2. Installed it on my host and client devices fine. The client is an Android tablet

3. Finger touch input works, but stylus input doesn't work.

4. Search the internet and find the GitHub issue

5. In it the developers at Rustdesk have responded "Fund it if you really need this feature."

6. Cool, I'll put in $18 and hope that they fix this issue. It's a shame that there's no guarantee whatsoever or timeline, but I'll put my money where my mouth is.

7. ERROR! MINIMUM DONATION $20!

8. Give up. Why did I give the sewage world of FOSS another chance?

As a counter example:

The other day I had a bug in a paid software I've been using for years, that cost me less than $100. Mailed the company, and a few hours later the developers sent me a new executable with the bug fixed. The next day they released an update for every user with the bug fixed.

If that software has some thousand of users it has made a lot of money. Your report and the fix is in their best interest to stay competetive in the market.

18 dollars for a feature request pales in comparison. Even if it was a 1 line fix it wouldn't be economical work.

That's 18 dollars I was willing to donate without anything in return, so that they maybe perhaps possibly would implement this feature. Which is a lot more money than 100% of FOSS users are willing to contribute.

With paid apps you get exactly the features you pay for, you get customer support, and you get a fair and polite exchange.

It is already a lot for people to swallow to be asked to donate in advance for a feature you need, without any guarantee or even likelihood that it is going to be implemented. But it's a whole different level to put a minimum amount of $20 for such a donation.

I'm just telling my experience as an end-user, and why I avoid FOSS at all costs. Maintainers have only themselves to blame for the situation they've put themselves in.

"I care enough to cast $18 of my cold hard earned cash into a black hole for altruistic purposes, but nay shall it be $20, as I am but a humble mortal"

Everybody has their limits of patience. When it comes to charity, you shouldn't annoy donors. It takes a microscopic amount of time for me to close their tab and forget about them. So fuck them.

Closing the tab is enough, I don't think the "fuck them" is warranted.. fuck them for what? Not accepting less than $20?

Who gives a shit dude

It's not charity though.

You're paying them in expectation of a return.

Charitable giving is exactly that - giving, with no expectation of return.

There is little expectation of return, the way they present it. Contrast that to actually purchasing software, where they are required by law to deliver what you pay for or give your money back.

I get what you are saying, but I think a more charitable interpretation is warranted.

He's saying he asked for a feature, they asked for money, he offered a little money and they said it wasn't enough so he balked.

We can agree on that much, right?

I think, and this is my assumption, that he wasn't expecting the rustdesk devs to come running and immediately roll out his suggestion for his generous $18.

I think he just wanted to put the suggestion onto the pile for consideration, and then when rebuffed for another $2 decided that if he can't even make a suggestion for $18 then it's not worth $20.

Then he went on to complain that they wouldn't even put his concern on the pile for less than $20 and now he's getting (imo unfairly) dragged for it.

This is my interpretation of the events. I might be wrong but I don't think I am.

Wow, I still can't get over your generous nature - $18 to fix an issue for you, you sir, are the veritable milk of human kindness.

Bloody hell, my teenager earns more than that for 1.5 hours of gardening.

I'm not sure if you're trolling, because if you're not, your concept of economic incentives is busted. Completely busted.

But hey, you avoiding FOSS is probably the best outcome for both you and FOSS maintainers, so I do appreciate your decision there.

How much money have you given to FOSS? (Let me guess: 0). But it's good that you are giving them your moral support here online. That's surely worth something.

If your teenager behaves like FOSS developers, then he probably won't get any repeat customers: "Hey man, I might mow your lawn or I might not. Pay me 20 dollars right now and you'll find out, maybe."

I will continue to avoid FOSS. I congratulate the developers and maintainers for all the free labour they provide to make sure the likes of Amazon, Google and Microsoft stay profitable. Their shareholders are surely grateful.

For me, I will continue to purchase high quality software from independent developers.

I have contributed to multiple FOSS projects, so, if we assume my time has value, probably about $20K equivalent at least?

$18? Big roller there lol. How much would you expect to be paid an hour to code?

Is it more than $18? And is the bug fixable in an hour?

Your sense of entitlement is like 98% of the reason FOSS developers burn out. GG champ.

You have completely misunderstood my comment.

Reply on news.ycombinator.com