Live data from Hacker News

My boundaries as an open source developer

joeldenning.com

21–30 of 251 posts

Re: My boundaries as an open source developer

#21
post #3

I only have one rule: I only contact an open source developer if I believe resolving the problem would make the product better unless I am willing to offer them reasonable money to do it.

Doesn't (almost) every bug report/feature request meet this criterion?

This post is about when it is or isn't appropriate to directly contact the principal developer instead of using the established Slack or Github flows.

Re: My boundaries as an open source developer

#22

Is this person OK? Doesn't seem it. I use single-spa. I'm now worrying about it's future with the sentiments and apparent dislike of users expressed here.

Do you not see the irony that as a user of their free software you completely missed the point of their post that is basically saying, the people using my software are asking so much and giving so little that I'm burning out?

Re: My boundaries as an open source developer

#23
post #5

Once again I wish github would allow the ability to limit who could open issues and PRs in order to do development in the open with a trusted/vetted set of collaborators without being subject to every zero-effort bug report from users.

I'm shocked that it doesn't. What would you do if you were being harassed?

You can block specific users and you can temporarily limit all interactions if getting spammed.

Re: My boundaries as an open source developer

#24

Is this person OK? Doesn't seem it. I use single-spa. I'm now worrying about it's future with the sentiments and apparent dislike of users expressed here.

This person is more than OK. They're learning how to set boundaries and not let crappy people bother them.

Open Source will eat your soul if you let it. Low effort drive by issues, questions, or comments are crushing. On my humble project, something like 40% of people who open issues completely ignore the issue template, which means every. single. conversation. begins with asking for the bare minimum of details needed to even help them. Then you've got PRs with literally zero info, which you're expected to spend time reviewing / understanding.

Some people will even violate the Github boundary and email you directly to ask why their issue isn't being responded to, or why their PR isn't getting merged, or whatever. Honestly? Fuck these people.

OP is spot on.

Re: My boundaries as an open source developer

#25
post #3

I only have one rule: I only contact an open source developer if I believe resolving the problem would make the product better unless I am willing to offer them reasonable money to do it.

The preference of the developer doesn't feed into your decision to contact them? What if the repo readme says "this is provided as-is, I don't offer support"?

Re: My boundaries as an open source developer

#26
I had a very similar experience with running open source projects. I was getting frustrated with people not contributing in any significant way. Functionally useless bug reports. Coding bootcamp students submitting PRs that did nothing but change some grammar in the README (and never actually changing it correctly). Feature requests for things I had explained in several other issues that I would never do. Requests for support in setting up other people's software.

But if people are contacting me about my project, they must be using it, right? Isn't that the point? Can't I just ignore the noise? What's the problem?

I eventually realized my motivations for developing open source software were rooted in vanity. Just making programs is something I do all the time, I find it very rewarding. But the part about open sourcing it, that was the vanity.

Before opening the project, nobody else was contributing anything to it, either. After opening it, all that changed was that my expectations for how people would react to it were not met. Expecting people to want to use my software in exactly the way I wanted was a hell of a lot of arrogance. Those people who were requesting features, they weren't "wrong", they just wanted different software. More like a service that did the things my software could enable, rather than building things with my software.

I don't write the software to get rich or escape a dead-end job. I used to have that fantasy, but nowadays life is pretty happy, and I also have realized the fantasy was always a myth, anyway. So in the end, the difference between writing software and writing open source software is nothing more than me wanting recognition for the thing I created; aka a vain search for glory.

I didn't like that view of myself, so I stopped opening my software.

Re: My boundaries as an open source developer

#27
post #18
post #5

Once again I wish github would allow the ability to limit who could open issues and PRs in order to do development in the open with a trusted/vetted set of collaborators without being subject to every zero-effort bug report from users.

You can already turn on repository interaction limits limiting issues/PRs to collaborators. It needs to be re-enabled every 6 months https://docs.github.com/en/communities/moderating-comments-a...

It's not the same thing, because of the flow:

- developer finds a cool project - developer consumes the cool project - developer finds opportunity for bug fix or enhancement - developer forks and starts working on the enhancements - developer spends hours/days writing code - developer submits a PR - developer gets a notification (upon filling the PR, or after, from a bot) - developer is now extremely frustrated - developer complains - maintainers and the developer start debating - the Pull Request storm goes viral - developer threatens to stop using cool project - maintainers handle the situation poorly (they are coders, not Public Relations people) - the community makes things worse

And so on...

Re: My boundaries as an open source developer

#28
post #3

I only have one rule: I only contact an open source developer if I believe resolving the problem would make the product better unless I am willing to offer them reasonable money to do it.

A counterpoint:

You may view this feature as making the product better, but it might not fit the vision of the owner/developer and to them it will only generate a maintenance burden and bloat.

Re: My boundaries as an open source developer

#30
post #29

Quoted post unavailable.

The license very clearly tells you that you should not assume that the software is "production ready" and that if you do, that's on you.

> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE ...

Post reply on HN