Live data from Hacker News

Don't be that open-source user, don't be me

jacobtomlinson.dev

131–140 of 173 posts

Re: Don't be that open-source user, don't be me

#131
post #78

> However I now see that my use of the tool provided no value to the company, and I was not a paying customer of any of their services, so why should they provide me with free support. That is not true. If the use of the tool provides "no value" to the company, then why on earth are they making the tool available. Yes, there is no money exchanging hands, but there is definitely some value. Here's some value a company…

We're decades into the open source era and people still need to be reminded of this. Incredible.

What? Open source is about giving to the community. It's not about what you get from it. It's about providing something useful to people without expecting something in return. It's a core part of computing that makes it so wonderful to be a part of and so aggravating when people abuse it.

Re: Don't be that open-source user, don't be me

#132

"If you take anything away from this post I hope it is that these costs need to be paid by someone, the maintainer." - there will be a minimal cost attending to any interaction but provided the efforts made by a reporter are sufficiently well focused then that reporter is saving time for the maintainers. The issue i observe is countless people do such a stunningly bad job at reporting problems. I've some sympathy for…

I understand, agree, and feel for you. It sucks when people are vague when asking for something. From what I can tell though, a lot of folks are vague in general. They’ll avoid putting in the effort to clarify as long as possible, hoping others will do that clarification work for them. The question I then ask is “why?” I think the answer lies in three categories of people: - lacking knowledge: to know what’s worthwhi…

It’s definitely laziness, but they’ll argue it’s lack of time (and lack of knowledge is really just too lazy to self inform). It’s not just a problem with open source, but commercial product support as well.

I’ve had customers who invest no effort in a support request then get annoyed when we try to politely extract what the actual issue is from them.

For open source I’d lean towards a policy of 0 investment from you, then 0 investment from me. You can always archive low effort issue reports to peruse at a later date when you have free time to see if you can discover something meaningful in them.

Re: Don't be that open-source user, don't be me

#133

Earlier quoted context omitted.

We're decades into the open source era and people still need to be reminded of this. Incredible.

What? Open source is about giving to the community. It's not about what you get from it. It's about providing something useful to people without expecting something in return. It's a core part of computing that makes it so wonderful to be a part of and so aggravating when people abuse it.

I took the comment to mean "there's more to value than pure $$$, and that open source has been a prime example of this truth".

Re: Don't be that open-source user, don't be me

#134
post #118

Earlier quoted context omitted.

I assume the PR describes the thing you are fixing anyway? (It better if you want it to have a chance of getting reviewed/merged!) I don't see why you couldn't just file an issue with the copy-paste of that description, and then immediately file the PR too with a proposed solution. I don't understand this issue/dispute. I don't understand the problem with filing an Issue to correspond to the PR, it doesn't seem to be…

> I don't understand the problem with filing an Issue to correspond to the PR I positively detest pointless bureaucracy? I can live with it when someone is paying me 200k/year for it. Not when I’m trying to give my work away for free. I’m honestly a bit surprised about how strongly I feel about this.

OK, I wasn't missing anything.

As a favor for the the person giving you free labor who finds it easier to organize things that way, even if to you it seems like pointless beurocracy, we all have different organizational styles and they find it useful to make sure bugs/scopes/requirements are in Issues with the solutions in Projects?

Yeah, I think you're being unreasonably weird, and on further reflection I don't think this is even a generalizable enough problem to be worth talking about, it's just some weird idiosyncracy of yours to refuse on principle to do trivial organizational work that the maintainers of the project you'd like to contribute to have said makes it easier for them to deal with your contribution. (trivial work; you aren't even saying it would be a burden in terms of time/energy, just that it's a weird principle you have not to do anything you don't want to do even if it makes things easier on other people).

It's kind of just a true-ism of any kind of work we do collaboratively (and submitting a patch to a project that others maintain is such) that you need to do sometimes do things out of consideration for what works for the other people.

I guess I am curious why you are insisting on sending a PR that you know doesn't follow the process the maintainers have asked for -- instead of just not submitting the PR at all though? If you're worried about your time being wasted, wouldn't it be best not to submit the PR at all? Make your own fork that meets your purposes, don't interact with them at all. Now you don't risk wasting the 30 seconds it took to make the PR, when they just close it for not following their procedure since you didn't want to waste the 30 more seconds it might take to do so.

Re: Don't be that open-source user, don't be me

#135

Regarding adding +1 to issues - rather than doing this, up-vote the issue on GitHub (thumb up). This can be useful to maintainers because they can sort by thumb up and see the most popular ones. Adding a +1 comment really does nothing - it's just one more useless notifications for everyone, and it won't allow filtering or sorting issues. People might even unwatch the issue because of this and thus missing useful comm…

I agree with you, but old habits die hard. Reacts are a late addition to the GitHub interface, and in ye olde days adding a +1 comment was what you had to work with.

Just something to keep in mind in encouraging contributors to use the upvote and reacts.

Re: Don't be that open-source user, don't be me

#136

"If you take anything away from this post I hope it is that these costs need to be paid by someone, the maintainer." - there will be a minimal cost attending to any interaction but provided the efforts made by a reporter are sufficiently well focused then that reporter is saving time for the maintainers. The issue i observe is countless people do such a stunningly bad job at reporting problems. I've some sympathy for…

I understand, agree, and feel for you. It sucks when people are vague when asking for something. From what I can tell though, a lot of folks are vague in general. They’ll avoid putting in the effort to clarify as long as possible, hoping others will do that clarification work for them. The question I then ask is “why?” I think the answer lies in three categories of people: - lacking knowledge: to know what’s worthwhi…

Bug report templates work wonders. Ours is just some checkboxes and a few lines for OS version, package manager, etc. but it’s been effective at filtering out low effort reports.

Re: Don't be that open-source user, don't be me

#137

"If you take anything away from this post I hope it is that these costs need to be paid by someone, the maintainer." - there will be a minimal cost attending to any interaction but provided the efforts made by a reporter are sufficiently well focused then that reporter is saving time for the maintainers. The issue i observe is countless people do such a stunningly bad job at reporting problems. I've some sympathy for…

I understand, agree, and feel for you. It sucks when people are vague when asking for something. From what I can tell though, a lot of folks are vague in general. They’ll avoid putting in the effort to clarify as long as possible, hoping others will do that clarification work for them. The question I then ask is “why?” I think the answer lies in three categories of people: - lacking knowledge: to know what’s worthwhi…

The naive approach is to have bug submission be part of the product you ship to customers. If you run into an issue - "a report has already been sent. If you want to follow the status of your report, click here ". If the user runs into an issue that doesn't trigger the automated bug report submission, then have a UI with the relevant questions, which can automatically attach stuff like application version number, OS version, etc.

The problem? a) Pretty expensive to implement. You basically need to be FAANG with a huge install base and measurable reduction in customer service costs to justify the expense. b) This pattern doesn't integrate well into developer workflows, i.e. if you try to automatically open a GitHub issue with it, then who opened the issue, a bot? How do you ensure users stay notified, even if they don't have a GitHub account? If the issue is a duplicate of an existing issue, how do you auto-subscribe the user to the existing issue? What if the repository is private?

You can't really come up with technical solutions to human problems. The human problem is that users need to be listened to, and you need to talk with them. Maybe it's a bug, maybe it's a feature. Maybe the user has an issue with their Internet access. Maybe the user didn't RTFM. You run into this problem with poor GitHub issues because GitHub issues is not a platform for Product, and you should not force it or expect it to become one just because it seems easier to do so when everything else relating to the open-source library is already there on GitHub.

GitHub Discussions is a step in the right direction, but GitHub's UI is currently lacking in terms of helping projects start to move Product and Customer Support into Discussions and creating a consistent user experience across projects for doing so.

Re: Don't be that open-source user, don't be me

#139
post #132

Earlier quoted context omitted.

I understand, agree, and feel for you. It sucks when people are vague when asking for something. From what I can tell though, a lot of folks are vague in general. They’ll avoid putting in the effort to clarify as long as possible, hoping others will do that clarification work for them. The question I then ask is “why?” I think the answer lies in three categories of people: - lacking knowledge: to know what’s worthwhi…

It’s definitely laziness, but they’ll argue it’s lack of time (and lack of knowledge is really just too lazy to self inform). It’s not just a problem with open source, but commercial product support as well. I’ve had customers who invest no effort in a support request then get annoyed when we try to politely extract what the actual issue is from them. For open source I’d lean towards a policy of 0 investment from you…

I agree with this.

In my experience often people want to push the problem to someone else - if you can say in your team status update "I've opened a ticket with X, waiting on them to solve the issue", you can get away with being blocked. If the aforementioned ticket is closed for lack of detail, it becomes more obvious to others on said team that the person needs to do more exploratory work.

Re: Don't be that open-source user, don't be me

#140

Earlier quoted context omitted.

We're decades into the open source era and people still need to be reminded of this. Incredible.

What? Open source is about giving to the community. It's not about what you get from it. It's about providing something useful to people without expecting something in return. It's a core part of computing that makes it so wonderful to be a part of and so aggravating when people abuse it.

Quite.

I find this doubly troubling, when someone using Linux for a desktop, learned how to code via free websites, with free software, builds a product using OSS libraries, etc, etc, and then wants to be compensated handsomely for their product.

Which is, of course, a tiny tiny little thing, compared to everything it depends upon.

OK. Fine. Did you compensate every part of the chain you used?

So weird.

AWS seems paricularly bad here. So does anyone who doesn't contribute back.

Ah well.

Post reply on HN