Don't be that open-source user, don't be me(jacobtomlinson.dev)
jacobtomlinson.dev
Don't be that open-source user, don't be me
https://jacobtomlinson.dev/posts/2022/dont-be-that-open-source-user-dont-be-me/
172 comments
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.
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.
> "OK. Fine. Did you compensate every part of the chain you used? So weird."
GPL: "Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish)"
MIT License: "including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software"
Apache License: " each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work"
What's weird is giving people permission to do what they want, telling them it's because you value freedom, then when they do something you don't like, complaining.
"Freedom! ... not like that!"
GPL: "Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish)"
MIT License: "including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software"
Apache License: " each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work"
What's weird is giving people permission to do what they want, telling them it's because you value freedom, then when they do something you don't like, complaining.
"Freedom! ... not like that!"
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".
I think what you're describing here is more like free/libre software and not open source, although the lines between those terms have become fuzzy. IMO, open source is pretty much all about expecting something in return.
Free software isn't not commercial software. The GPL _encourages you_ to get paid for software. Free software is not good because of charitable reasons, or any contingent historical artefact. Counterfactually you can imagine a world without patents and software licenses, but the GPL would still be needed as a philosophical concept.
Free software (in FSF / libre sense) is traditional Kantian philosophy, viz. everyone takes part of the whole by attending to their own needs, the Kingdom of Ends. What's not Good -- and in software what the GPL intends to prevent -- is any action that superficially might benefit the actor but undermines the whole (and ipso facto the actor) in the long run.
Making money with proprietary software is a Wrong because proprietary software undermines the activity of writing software at all.
This is my understanding of it anyway YMMV.
Free software (in FSF / libre sense) is traditional Kantian philosophy, viz. everyone takes part of the whole by attending to their own needs, the Kingdom of Ends. What's not Good -- and in software what the GPL intends to prevent -- is any action that superficially might benefit the actor but undermines the whole (and ipso facto the actor) in the long run.
Making money with proprietary software is a Wrong because proprietary software undermines the activity of writing software at all.
This is my understanding of it anyway YMMV.
As an open source maintainer[1], the etiquette tips are great. However, I think +1 and status check comments are ok in certain situations where the issue might have been forgotten or it's a high priority issue.
I also like when someone reminds me they're blocked by an issue. It helps me prioritize fixing bugs so I work on things actually affecting people instead of things nobody is using. Just be polite and your comments are welcome.
[1] https://github.com/alanhamlett/pip-update-requirements
I also like when someone reminds me they're blocked by an issue. It helps me prioritize fixing bugs so I work on things actually affecting people instead of things nobody is using. Just be polite and your comments are welcome.
[1] https://github.com/alanhamlett/pip-update-requirements
This exactly! I am a solo maintainer on a very small Android app. I find it very useful when users vote for issues with the :thumbsup: emoji. Otherwise I have no real way of knowing which new features are popular with the community.
Comments that add nothing to the issue but just create noise in the notification feed are annoying.
Comments that add nothing to the issue but just create noise in the notification feed are annoying.
Prioritisation often becomes harder the closer you become to being an open source maintainer, since you're often more focused on software maintenance/internals than on using the software in real-life contexts. I feel like creating systems for open prioritisation is going to be an important "next step" in open source project management. Igalia did an experiment in open prioritisation in web browser development, but they tied it to funding, which helps with project viability but introduces a prioritisation bias towards people who have money to donate.
https://www.igalia.com/open-prioritization/
https://www.igalia.com/open-prioritization/
>Prioritisation often becomes harder the closer you become to being an open source maintainer, since you're often more focused on software maintenance/internals than on using the software in real-life contexts
i contribute to a FOSS project. I am not a dev nor can i hire someone to do dev work so i assist the actual dev team into giving them real life use cases which brings out a lot of bugs which get fixed along the way.
That way, instead of trying to achieve some sort of tangent "idea" of what a software is going to be and it becomes something the users can actually use and relate to.
the software in question, when people are going to use it and will face "normal workflow bugs" for example, we can forget about adding new features. right? maybe they can go side by side but unless you are working on the bleeding edge software and do not expect anyone to use in production it can work but not otherwise.
Also, by pointing out edge cases, the present software itself would become what would be called "battle tested" because most if not all the issues are fixed.
that said, if a project had a good budget, a good roadmap, a thriving developer community and users who are using it, reporting bugs and people volunteering to fix stuff, we can think about experimenting but otherwise not
i contribute to a FOSS project. I am not a dev nor can i hire someone to do dev work so i assist the actual dev team into giving them real life use cases which brings out a lot of bugs which get fixed along the way.
That way, instead of trying to achieve some sort of tangent "idea" of what a software is going to be and it becomes something the users can actually use and relate to.
the software in question, when people are going to use it and will face "normal workflow bugs" for example, we can forget about adding new features. right? maybe they can go side by side but unless you are working on the bleeding edge software and do not expect anyone to use in production it can work but not otherwise.
Also, by pointing out edge cases, the present software itself would become what would be called "battle tested" because most if not all the issues are fixed.
that said, if a project had a good budget, a good roadmap, a thriving developer community and users who are using it, reporting bugs and people volunteering to fix stuff, we can think about experimenting but otherwise not
I think when an issue becomes highly ranked by users, it’s important that devs give clear feedback. In communication, acknowledgement is very important. Just say it if it’s not on the current to do list and when you project to be working on it (or not at all)
It gives a clear feedback, and allow people to move on, fork it, stick with it, their choice. Politeness should be key.
It gives a clear feedback, and allow people to move on, fork it, stick with it, their choice. Politeness should be key.
[deleted]
The author followed up by stating:
> As time went on the wording of the +1s got stronger, people demanded that it be implemented and expected it to be scheduled into future milestones.
I don't think they thought the +1 was an issue with respect to prioritization. Rather, it is an issue because it is a form of confirmation for users to behave in entitled ways.
> As time went on the wording of the +1s got stronger, people demanded that it be implemented and expected it to be scheduled into future milestones.
I don't think they thought the +1 was an issue with respect to prioritization. Rather, it is an issue because it is a form of confirmation for users to behave in entitled ways.
> I also like when someone reminds me they're blocked by an issue.
As a user, this feels weird to me. If I’m actually blocked by a bug you’ll receive a PR, not a +1. If I have the leisure to +1 I’m clearly not blocked enough for you to consider it pressing.
As a user, this feels weird to me. If I’m actually blocked by a bug you’ll receive a PR, not a +1. If I have the leisure to +1 I’m clearly not blocked enough for you to consider it pressing.
I think this needs a big qualifier. I feel the same way, when it's a project I'm capable of doing the work for. For example, I recently needed a way to deal with Stripe early fraud warnings and the library I used didn't have those yet, so I added them over a weekend[1].
However, there are tons of dependencies that we use for all sorts of things that are highly complex where very few people would be able to send a PR (openssl for example). Things in highly complex codebases, or deeply unfamiliar languages, etc. I maintain a forked linux driver for a wireless card for example, and I don't expect there's more than a handful of people that could hack on it without introducing tears and devastation.
For the projects I maintain, I would just say, "if you can, please consider a PR. If you're not sure it would be accepted I'm happy to be asked! If you can't send a PR, give as much info as you can and be polite. With that we're good.
[1]: https://github.com/beam-community/stripity_stripe/pull/728
However, there are tons of dependencies that we use for all sorts of things that are highly complex where very few people would be able to send a PR (openssl for example). Things in highly complex codebases, or deeply unfamiliar languages, etc. I maintain a forked linux driver for a wireless card for example, and I don't expect there's more than a handful of people that could hack on it without introducing tears and devastation.
For the projects I maintain, I would just say, "if you can, please consider a PR. If you're not sure it would be accepted I'm happy to be asked! If you can't send a PR, give as much info as you can and be polite. With that we're good.
[1]: https://github.com/beam-community/stripity_stripe/pull/728
While in theory this would be great some issues are really not feasible for a first time contributor to work on.
I'm not so sure +1's or emojis are useful, except for maybe a few cases like you have a very large audience and they all send a thumbs-down emoji to protest a bad product or design decision -- recent c#/dotnet for example. Or the reminder ping from an affected user who is still interested in and using your project.
The problem I believe is that a +1 or another reaction to an issue is simply a sample from all developers that viewed the project that bothered to leave a note. Chances are people are not using an open source project if they see a reasonably filed issue a long time ago that either was not addressed in any fashion whether it be a principled statement on why it can't be addressed yet, or that the project isn't interested in working on it. That obviously only works for small projects without a product manager.
The issue persists on the large projects as well. The issue reactions set is just a sample of the all developers set that used or looked at the project. The only way to really know what is going on is telemetry and crash reports.
Larger companies with thousands of crash reports, bug reports, and features requests can cluster them and figure out what to work on, along with a touch of good taste. Good taste is unfortunately important too.
Unfortunately for telemetry a lot of people think it is a privacy issue... which it can be if the developer implements it poorly. And looks like GitHub only exposes traffic overall to your site [1] so you never know the population size is for people that are possibly affected by that issue -- so the relative +1 count is not reflective of reality. You might have a fighting chance if you use self-hosted GitLab or something with which you can grab granular traffic stats.
[1] https://docs.github.com/en/repositories/viewing-activity-and...
The problem I believe is that a +1 or another reaction to an issue is simply a sample from all developers that viewed the project that bothered to leave a note. Chances are people are not using an open source project if they see a reasonably filed issue a long time ago that either was not addressed in any fashion whether it be a principled statement on why it can't be addressed yet, or that the project isn't interested in working on it. That obviously only works for small projects without a product manager.
The issue persists on the large projects as well. The issue reactions set is just a sample of the all developers set that used or looked at the project. The only way to really know what is going on is telemetry and crash reports.
Larger companies with thousands of crash reports, bug reports, and features requests can cluster them and figure out what to work on, along with a touch of good taste. Good taste is unfortunately important too.
Unfortunately for telemetry a lot of people think it is a privacy issue... which it can be if the developer implements it poorly. And looks like GitHub only exposes traffic overall to your site [1] so you never know the population size is for people that are possibly affected by that issue -- so the relative +1 count is not reflective of reality. You might have a fighting chance if you use self-hosted GitLab or something with which you can grab granular traffic stats.
[1] https://docs.github.com/en/repositories/viewing-activity-and...
It's often not immediately obvious if a request is something a lot of people want but only one person took the time to write up, or if it's a very niche thing that only that person cares about. People who +1 an issue are not a great data set, but it's a lot better than nothing and it's basically zero effort to check. If I'm looking for something to work on and there's two issues that look like they'll take similar amounts of time, both seem like good ideas to implement, and I'm not sure which is more valuable, the number of +1s is a pretty decent tiebreaker.
For me (participating in a small open source project) upvotes are useful - it is a confirmation that anyone else cares about that idea and that someone read what is being proposed and at least is not protesting.
Multiple times I have no preference between two issues and worked on one with more reactions.
Multiple times I have no preference between two issues and worked on one with more reactions.
This. It can be an important signal an issue that a maintainer might think is low priority in reality isn't. Don't forget that a maintainer doesn't really know how their software is used.
I guess the "be excellent to each other" note at the end of the post is basically be polite. Often there is a reason why simple request take time. It can be hard to describe why.
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 comments.
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 comments.
> This can be useful to maintainers because they can sort by thumb up and see the most popular ones.
TIL, but I also think it's not really clear what a reaction does. Does adding a reaction to a comment in an issue thread bump the whole issue, does it have to be added to the top issue to show up in sorting? I think a global "Vote for this issue" button would make this a bit more clearer than just a reaction within the issue.
I was always under the impression that just adding a reaction wouldn't actually give the issue a bump. Maybe it would be good if Github actually guides people towards it by either saying something like "You added a comment reflecting a +1, do you want to add a vote for the issue instead".
TIL, but I also think it's not really clear what a reaction does. Does adding a reaction to a comment in an issue thread bump the whole issue, does it have to be added to the top issue to show up in sorting? I think a global "Vote for this issue" button would make this a bit more clearer than just a reaction within the issue.
I was always under the impression that just adding a reaction wouldn't actually give the issue a bump. Maybe it would be good if Github actually guides people towards it by either saying something like "You added a comment reflecting a +1, do you want to add a vote for the issue instead".
The point here is to not bump the issue. My GitHub notifications are a mess, and bumps cause me to unsub from notifications to issues in my own repository. There’s also a 0% chance a bump is going to cause me to reallocate my evening, so it doesn’t help get the issue moved forward.
Bumping doesn't necessarily mean "sending an email to the maintainer and everyone on the issue", adding a reaction can also "bump" an issue in the sense that it bumps it to the top of the list if sorted by "thumbs up reaction".
> Does adding a reaction to a comment in an issue thread bump the whole issue, does it have to be added to the top issue to show up in sorting?
Yes it needs to be added to the top post. It's not really an official thing I guess, but for popular projects these reactions add up, and it helps getting a clearer picture of what matters to users.
Yes it needs to be added to the top post. It's not really an official thing I guess, but for popular projects these reactions add up, and it helps getting a clearer picture of what matters to users.
It is "official" in the sense that GitHub lets you sort by these reactions.
Perhaps I misunderstood the author, I assumed '+1' in this context meant the thumbs-up reaction. I'm certainly feeling much more charitable towards the OP if they literally meant people commenting "+1" (which is unfortunately a thing), but I think in a lot of contexts "+1", "thumbs-up", "like" are interchangable.
OP here. Thumbs up is great, commenting with the string “+1” is not great, commenting with “Why this this not done yet, this is very important to me. I might switch to another project if you don’t implement this.” is terrible.
Totally fair, and for what it's worth I agree. When I read the original post, I thought by '+1' you just meant the thumbs up reaction
It’s literally people commenting. There’s a subset of users that haven’t noticed or haven’t understood the reaction buttons.
Then again, adding a comment may prevent a bot from auto-closing the issue.
I've never really understood the point of these bots. I could understand if an issue had a test case attached to it, and the bot was auto-closing the issue if/when the test passes. That way, if it is resolved when fixing some other bug, or when refactoring, the issue is closed. But closing an issue due to inactivity gives the false impression that the issue has been resolved.
I think they are basically an attempt at form of "issues/tracker bankruptcy" -- we have too many open things here, leaving them all open like we're going to get to them all eventually is a fantasy, and is overwhelming and makes it harder to find the ones we might actually address, so trying to algorithmically close the ones least likely to be actionable is just trying to make the situation more manageable.
I think it's a desperate measure -- if any maintainers are seeing it as reasonable management technique rather than desparate measure, I think they're making a mistake. It has a lot of downsides, some of which you outline, I agree with you. It also generally raises user frustration, leading to even more adversorial relationship between users and maintainers, which is what the OP is about and I think part of what's going on in this "issue bankruptcy" situations too.
Notably, Rails just turned off their auto-closer for Pull Requests (not sure about Issues), with this commit message from a maintainer:
> While the idea of cleaning up the the PRs list by nudging reviewers with the stale message and closing PRs that didn't got a review in time cloud work for the maintainers, in practice it discourages contributors to submit contributions.
> Keeping PRs open and not providing feedback also doesn't help with contributors motivation, so while I'm disabling this feature of the bot we still need to come up with a process that will help us to keep the number of PRs in check, but celebrate the work contributors already did instead of ignoring it, or dismissing in the form of a "stale" alerts, and automatically closing PRs.
https://github.com/rails/rails/commit/acf48169943011834c4c88...
I think it's a desperate measure -- if any maintainers are seeing it as reasonable management technique rather than desparate measure, I think they're making a mistake. It has a lot of downsides, some of which you outline, I agree with you. It also generally raises user frustration, leading to even more adversorial relationship between users and maintainers, which is what the OP is about and I think part of what's going on in this "issue bankruptcy" situations too.
Notably, Rails just turned off their auto-closer for Pull Requests (not sure about Issues), with this commit message from a maintainer:
> While the idea of cleaning up the the PRs list by nudging reviewers with the stale message and closing PRs that didn't got a review in time cloud work for the maintainers, in practice it discourages contributors to submit contributions.
> Keeping PRs open and not providing feedback also doesn't help with contributors motivation, so while I'm disabling this feature of the bot we still need to come up with a process that will help us to keep the number of PRs in check, but celebrate the work contributors already did instead of ignoring it, or dismissing in the form of a "stale" alerts, and automatically closing PRs.
https://github.com/rails/rails/commit/acf48169943011834c4c88...
Reading over the Rails committer message there… So Rails, decided that they did not want to discourage code PR contributors (despite getting some poor quality ones, I'm sure).
But other projects may actually want to discourage PR's, or especially Issues, so consider this a plus not a minus. Of course, you can just turn off Issues/PR's, or only allow maintainers to make them, if you really don't want them. But sometimes I'm guessing someone really don't want them but doesn't really want to say so...
But other projects may actually want to discourage PR's, or especially Issues, so consider this a plus not a minus. Of course, you can just turn off Issues/PR's, or only allow maintainers to make them, if you really don't want them. But sometimes I'm guessing someone really don't want them but doesn't really want to say so...
Same, I find these bots really annoying. I guess they might be necessary/useful for popular projects where a small team of maintainers is trying to stay on top of a massive pile of incoming issues. But for the most part they seem misguided. (Especially the ones with a really short (like 30 days) activity window.) If an issue still exists in the project, why should it be closed? That will just require the next person who notices the issue to open a new one... Also, no activity on an issue can just mean that folks are waiting patiently for someone to get around to implementing it (or, more commonly, for some project dependency to release the patch that is necessary for fixing the issue
..).
[deleted]
It depends a bit in the project and maintainers motivation.
However: Many projects swim in a sea of open tickets. Too many for the maintainers to keep an overview. By auto closing you make it clear to observers that currently this thing likely won't change and by forcing to reopen the maintainers can get users to tell them whether the issue still persists without having to try themselves. Generally there is little worth in keeping many years old tickets open, hiding recent issues while probably not being an issue anymore for whatever reason.
However: Many projects swim in a sea of open tickets. Too many for the maintainers to keep an overview. By auto closing you make it clear to observers that currently this thing likely won't change and by forcing to reopen the maintainers can get users to tell them whether the issue still persists without having to try themselves. Generally there is little worth in keeping many years old tickets open, hiding recent issues while probably not being an issue anymore for whatever reason.
How do old tickets hide recent issues? The default is to show the newest ones first, isn't it?
Project with autoclose bots is not worth wasting any time by contributing to it, even by making an issue.
Edit: Nevermind, we're saying the same thing since you're talking about commenting with a +1 not reactions.
> Adding a +1 comment really does nothing - it's just one more useless notifications for everyone
I don't think reactions trigger notification emails.
> Adding a +1 comment really does nothing - it's just one more useless notifications for everyone
I don't think reactions trigger notification emails.
It's bad either way. "Me too" should not be mixed with "I got a reliable reproduction, here's how".
Edit: I mean people probably want a notification on the second one but not the first.
Edit: I mean people probably want a notification on the second one but not the first.
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.
Just something to keep in mind in encouraging contributors to use the upvote and reacts.
"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 those whose first language is not the same as the maintainers, but putting thosr aside, the list of inept/time wasti reports is very very long.
- subject only issue with only vague adherence to a complete sentence!
- no unambiguous description of the problem
- no indication why it's thought to be deviating from (reasonably) expected functionality
- no indication of steps before issue
- nor if it's a one off, repeated, always happened/just started/happens to others
-no mention of context (eg system, installation method, any reasons it might be expected not to work)
and more!
The issue i observe is countless people do such a stunningly bad job at reporting problems. I've some sympathy for those whose first language is not the same as the maintainers, but putting thosr aside, the list of inept/time wasti reports is very very long.
- subject only issue with only vague adherence to a complete sentence!
- no unambiguous description of the problem
- no indication why it's thought to be deviating from (reasonably) expected functionality
- no indication of steps before issue
- nor if it's a one off, repeated, always happened/just started/happens to others
-no mention of context (eg system, installation method, any reasons it might be expected not to work)
and more!
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 worthwhile to explain what’s happening (common with non-technical folks)
- lacking time: to take the necessary effort to describe and explain something is expensive if you have a very full schedule
- too lazy: can’t be bothered to care enough to take the time to explain themselves properly.
I’d like to think it’s more of points 1 and 2 that are causing this problem, but I have a feeling the majority of it is point 3 based on my interactions with humanity.
What are your thoughts on this? Ideas for how we could improve bug submission given this very clear and arguably difficult problem?
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 worthwhile to explain what’s happening (common with non-technical folks)
- lacking time: to take the necessary effort to describe and explain something is expensive if you have a very full schedule
- too lazy: can’t be bothered to care enough to take the time to explain themselves properly.
I’d like to think it’s more of points 1 and 2 that are causing this problem, but I have a feeling the majority of it is point 3 based on my interactions with humanity.
What are your thoughts on this? Ideas for how we could improve bug submission given this very clear and arguably difficult problem?
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 <link with bug ID number>". 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.
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.
Interesting you should mention about submitting details like app version number, OS version etc.
Although it's not within an app, and only partially automated, i tried building a tool to help people gather Python environment details etc to help them create richer Github issues with less effort: https://github.com/nmstoker/gatherup
The demo video needs work to explain it better and as a project it didn't really go anywhere but it was interesting to work on a few years back.
Although it's not within an app, and only partially automated, i tried building a tool to help people gather Python environment details etc to help them create richer Github issues with less effort: https://github.com/nmstoker/gatherup
The demo video needs work to explain it better and as a project it didn't really go anywhere but it was interesting to work on a few years back.
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.
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.
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.
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.
You're absolutely right to ask why, and the reasons you give do drive the difficulties here.
Although I'm fairly technical, I think I have a fair understanding of those in the non-technical camp due to my background and general experience, but I sense I sometimes expect too much of the average person (not meaning this to sound superior!)
Improving bug submission is worth consideration because there's value to be unlocked: the people in need of a solution have insights the developers etc benefit from and they themselves would benefit (one hopes!) from the solution but there's a good chance it could apply for others too.
From the little I've read about behavioural science, i suspect that a selection of nudges may help but it could take time and perseverance to get it right. There are little tricks that Github and SO already use to shift things the right way. It's important to base these on how they'd work for target users, as designing them for how people who design such systems or already have well developed problem solving serves no one and will fail! It's also important not to be overly Draconian or pushy (keeping the nudges reasonable) seems important too, and the smartest ones probably lead people on to better submissions as much as block bad ones, the earlier the better (no one wants to fill in some onerous form only to be told off by a computer!)
Although I'm fairly technical, I think I have a fair understanding of those in the non-technical camp due to my background and general experience, but I sense I sometimes expect too much of the average person (not meaning this to sound superior!)
Improving bug submission is worth consideration because there's value to be unlocked: the people in need of a solution have insights the developers etc benefit from and they themselves would benefit (one hopes!) from the solution but there's a good chance it could apply for others too.
From the little I've read about behavioural science, i suspect that a selection of nudges may help but it could take time and perseverance to get it right. There are little tricks that Github and SO already use to shift things the right way. It's important to base these on how they'd work for target users, as designing them for how people who design such systems or already have well developed problem solving serves no one and will fail! It's also important not to be overly Draconian or pushy (keeping the nudges reasonable) seems important too, and the smartest ones probably lead people on to better submissions as much as block bad ones, the earlier the better (no one wants to fill in some onerous form only to be told off by a computer!)
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.
Thank you to the author for writing this.
Entitlement in open source is a massive problem, I have experienced it first-hand many times. The problem is that it discourages contributions not only from the existing maintainers but also from people who may volunteer to fix issues in the future. Would you be willing to contribute if most of the issues are just asking for things (often rudely) and not even saying thanks when an issue is resolved?
Unfortunately I have seen far worse examples than the one linked in the article[1]. I would encourage people to not only think twice before acting this way but to also call out people that are acting entitled in open source to discourage such actions.
1 - https://github.com/dom96/httpbeast/pull/35#issuecomment-7218...
Entitlement in open source is a massive problem, I have experienced it first-hand many times. The problem is that it discourages contributions not only from the existing maintainers but also from people who may volunteer to fix issues in the future. Would you be willing to contribute if most of the issues are just asking for things (often rudely) and not even saying thanks when an issue is resolved?
Unfortunately I have seen far worse examples than the one linked in the article[1]. I would encourage people to not only think twice before acting this way but to also call out people that are acting entitled in open source to discourage such actions.
1 - https://github.com/dom96/httpbeast/pull/35#issuecomment-7218...
OP here, glad you enjoyed this post. Sorry that you’ve also experienced the bad side of things.
I’m not sure what you mean by this example. From what I see, somebody submitted a bug fix that hadn’t been approved/merged by you for 6 months. Then some quite rude conversation happened “Don’t act as my free time is owned by you”. I mean both sides look quite ugly in this particular case to be honest.
> From what I see, somebody submitted a bug fix that hadn’t been approved/merged by you for 6 months.
From my perspective the PR was reviewed and was stuck on a test case being created. The author of the PR even stated "I'll try to make a simple test case." so as far as I'm concerned the ball was in their court.
But you know, reviewing PRs takes time too. Acting entitled about a review taking a long time shouldn't be done either.
From my perspective the PR was reviewed and was stuck on a test case being created. The author of the PR even stated "I'll try to make a simple test case." so as far as I'm concerned the ball was in their court.
But you know, reviewing PRs takes time too. Acting entitled about a review taking a long time shouldn't be done either.
> But you know, reviewing PRs takes time too.
I agree. I’m just saying you were rude too.
I agree. I’m just saying you were rude too.
He was rude, but he didn't initiate it. Frankly, he openly communicated his priorities (other things are on the list) and then got snark. So he responded in kind. Very little to blame the maintainer here.
Sometimes you can just go fix the software yourself.
Maintainers always seem to say you should file an issue before working on a PR. However, I find for features you really need, you should just fork the software yourself[0] and implement what you need, then put up a quick PR with your changes. The worst they can do is reject your changes, in which case...well, you're using your fork anyway.
[0] Github forks are lightweight, easy(ish) to keep up to date, and integrated into a lot of package managers.
Maintainers always seem to say you should file an issue before working on a PR. However, I find for features you really need, you should just fork the software yourself[0] and implement what you need, then put up a quick PR with your changes. The worst they can do is reject your changes, in which case...well, you're using your fork anyway.
[0] Github forks are lightweight, easy(ish) to keep up to date, and integrated into a lot of package managers.
> The worst they can do is reject your changes, in which case...well, you're using your fork anyway.
Actually the worst result is ignoring the PR for years. I've seen this happen quite a lot, and it puts me in an uneasy spot where I don't know whether it's something with the PR or the way I communicated it or what.
After having this experience one too many times, I've started opening issues and if I'm really serious about getting it into the project, disucssing with people in the related IRC/forum/whatever before starting to work on it. This helps notify people that hey, I'm doing a bit of effort and I'd love to at least get a "sorry I'm too busy/uninterested in this feature to look at your PR".
Actually the worst result is ignoring the PR for years. I've seen this happen quite a lot, and it puts me in an uneasy spot where I don't know whether it's something with the PR or the way I communicated it or what.
After having this experience one too many times, I've started opening issues and if I'm really serious about getting it into the project, disucssing with people in the related IRC/forum/whatever before starting to work on it. This helps notify people that hey, I'm doing a bit of effort and I'd love to at least get a "sorry I'm too busy/uninterested in this feature to look at your PR".
Or even ignoring it for a year and then automatically close it for inactivity. Feedback, even negative feedback, I better than that.
It doesn't matter if they ignore the PR. You've got a working fork. Merging your changes back into the upstream is a happy side effect.
We’ll, maybe. It depends on what kind of project it is. What happens when your fork introduces hard to reproduce bugs? What happens when there are security updates to the project that cause merge conflicts with your fork? What happens when the project makes architectural changes that require reimplementing your feature? What happens when you leave the company, and your former coworkers have the responsibility to maintain your fork?
A couple of times I’ve come across issues in OSS and gone to raise a bug report while digging through the code to see if I can fix it or propose a solution. But when I opened the issue and saw it required me to write a novel I’ve just closed it, worked around or patched it and moved on. It’s too much of a hassle.
The ones that demand reproduction always get me. I get it: reproduction instructions make it infinitely easier to repair software. On the other hand, there are many cases like race conditions that can be very hard to reproduce and sometimes you can get enough context from stack traces/logs/debug info to figure out and fix the problem anyway.
Your quick PR becomes the maintainer's burden, and rejecting a pull request can also come with a substantial time cost. It's best to conform to the contribution process described by the maintainer to avoid wasting their time as much as possible.
> It's best to conform to the contribution process described by the maintainer to avoid wasting their time as much as possible.
It’s not their prerogative to waste my time, just as it’s not mine to waste theirs. If they’re not happy with a PR they’re welcome to reject it, ask me to fix it, or completely ignore it.
When they make a project public they’re explicitly condoning the fact they may get a PR (and nothing else).
It’s not their prerogative to waste my time, just as it’s not mine to waste theirs. If they’re not happy with a PR they’re welcome to reject it, ask me to fix it, or completely ignore it.
When they make a project public they’re explicitly condoning the fact they may get a PR (and nothing else).
> When they make a project public they’re explicitly condoning the fact they may get a PR
I don't think that's true. It appears you just assume that because pull requests cannot be disabled on GitHub.
Sending unsolicited pull requests to people that clearly told you to open an issue first is disrespectful. You don't have to engage with a project or a community, but if you decide to participate by submitting a pull request, you should follow their contribution guidelines.
I don't think that's true. It appears you just assume that because pull requests cannot be disabled on GitHub.
Sending unsolicited pull requests to people that clearly told you to open an issue first is disrespectful. You don't have to engage with a project or a community, but if you decide to participate by submitting a pull request, you should follow their contribution guidelines.
[deleted]
No, I think it's fair to work backward: GitHub doesn't offer a way to disable PRs, the service is explicitly 'social coding', therefore those using it should not be disgruntled about PRs showing up.
The healthy maintainer-side attitude is that these impose no obligation whatsoever to review, apply, or even look at, the fork in question.
The healthy maintainer-side attitude is that these impose no obligation whatsoever to review, apply, or even look at, the fork in question.
GitHub is indeed a platform that can be used for social coding, and it is also a service that encourages the use of contribution guidelines. If the maintainer asks you to open an issue to discuss your contribution before submitting a pull request, you are expected to follow their wishes.
https://docs.github.com/en/communities/setting-up-your-proje...
https://docs.github.com/en/communities/setting-up-your-proje...
Which of course I do.
The emotional side of the burden of closing PRs which don't follow guidelines is the part which can be set aside. It's just a bit of housecleaning, it's seldom done from malice, English is not everyone's first language, etc.
Getting upset that a mechanism which exists and won't change gets used is not healthy.
The emotional side of the burden of closing PRs which don't follow guidelines is the part which can be set aside. It's just a bit of housecleaning, it's seldom done from malice, English is not everyone's first language, etc.
Getting upset that a mechanism which exists and won't change gets used is not healthy.
The issue wasn't an occasional mistake done in good faith. The commenter has decided to explicitly dismiss contribution guidelines, and for that the healthy response is to call out their lack of respect for the time of open source maintainers. The focus wasn't on emotional burden either, it can simply take a lot of time to sort out issues and pull requests that do not follow contribution guidelines when you maintain a popular project. It isn't a bit of house cleaning, but hours wasted every week, depending on the project.
> Sending unsolicited pull requests to people that clearly told you to open an issue first is disrespectful.
You do you. I do not think it is, and so far nobody has made an issue out of it.
> It appears you just assume that because pull requests cannot be disabled on GitHub.
It’s more that people that make a public repo on Github and expect no pull requests on even mildly popular software are living in fairyland. Don’t make a repo on Github when you know PR’s can’t be disabled. Or I dunno, install a bot that automatically rejects everything.
You do you. I do not think it is, and so far nobody has made an issue out of it.
> It appears you just assume that because pull requests cannot be disabled on GitHub.
It’s more that people that make a public repo on Github and expect no pull requests on even mildly popular software are living in fairyland. Don’t make a repo on Github when you know PR’s can’t be disabled. Or I dunno, install a bot that automatically rejects everything.
It's one thing to stumble upon a repository that does not have contribution guidelines and submit a pull request, that is obviously fine. But you're advocating against respecting the wishes of strangers, and disregard their request to coordinate with them before submitting your work.
You have the option to walk away and not contribute if you don't like the rules for interaction that have been set by the people that manage the project. Or just follow the rules. Those are your only two sane options, unless you become a maintainer yourself at that project, and modify the contribution guidelines.
To be very clear, you have to understand what NO means in this context, and realize that "I don't like bureaucracy" is not a valid reason to push forward on your own terms.
You have the option to walk away and not contribute if you don't like the rules for interaction that have been set by the people that manage the project. Or just follow the rules. Those are your only two sane options, unless you become a maintainer yourself at that project, and modify the contribution guidelines.
To be very clear, you have to understand what NO means in this context, and realize that "I don't like bureaucracy" is not a valid reason to push forward on your own terms.
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 any significant extra work or change to the desired workflow of the person who "just" wants to file a PR.
Am I misunderstanding the issue?
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 any significant extra work or change to the desired workflow of the person who "just" wants to file a PR.
Am I misunderstanding the issue?
> 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.
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.
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.
The best thing is to fork it, use your fork, get as far as you can through their process, but give up quickly if it looks too hard. That way you don't have to deal with overly complicated processes and you still get to use working software.
Yes, and when for the times that you can't fix yourself should work as a reminder that you should be paying to support those who can.
This is a thoughtful and important article for anyone who uses or creates open-source software, which is everyone.
But, if we follow this advice? If some more thoughtful and considerate users kindly reduce their input into support conversations to avoid overwhelming developers, doesn't this mean that support conversations will become dominated by users who are not thoughtful and considerate?
But, if we follow this advice? If some more thoughtful and considerate users kindly reduce their input into support conversations to avoid overwhelming developers, doesn't this mean that support conversations will become dominated by users who are not thoughtful and considerate?
The point is not reducing input per se, but reducing entitled input that doesn't give back anything to the community.
It’s a problem everywhere in software, the ones who give back the least feel the most entitled. Having a some form of a treshold is good, whether that is money, or some sort of on-boarding (e.g. can’t comment until you are a member for x days)
Usually the ones with loudest mouths have the shortest attention span and don’t bother with those things. I have seen this in many communities.
Usually the ones with loudest mouths have the shortest attention span and don’t bother with those things. I have seen this in many communities.
>The point is not reducing input per se, but reducing entitled input that doesn't give back anything to the community
That's true, and it's a good goal.
But, my point is that if we try to reduce entitled input by simply asking people not to behave entitled, then the result may be that we increase entitled input (as a proportion of all input), because many 'entitled' users will ignore the request, because they feel entitled.
In the common scenario where developers are already overwhelmed with suggestions and demands, then they will have even less time to separate out the good suggestions from the bad.
That's true, and it's a good goal.
But, my point is that if we try to reduce entitled input by simply asking people not to behave entitled, then the result may be that we increase entitled input (as a proportion of all input), because many 'entitled' users will ignore the request, because they feel entitled.
In the common scenario where developers are already overwhelmed with suggestions and demands, then they will have even less time to separate out the good suggestions from the bad.
OP here, thanks for the kind words!
I hear your point. I’m not saying don’t make a comment, just that folks should try and consider the human on the other side more.
I hear your point. I’m not saying don’t make a comment, just that folks should try and consider the human on the other side more.
I don't know what the best answer to that potential problem is: I think users should continue to be allowed to comment on any issue.
However I do think that the amount of analysis and effort that the user has done for each comment is relevant.
Silly hypothetical example: if a project is a Fibonacci function that (incorrectly) prints nothing but repeated "1" values, then the potential range of comments may include:
- "it's wrong"
- "it's printing the wrong output"
- "expected to see 1 1 2 3 ... but found 1 1 1 1 ..."
- "line two is missing an addition operator near character five"
- "please see #3 for a pull request to add an addition operator on line two"
(roughly in order of estimated "most frequent" to "least common" comment volume -- and not coincidentally, also ordered from "least analysis" to "most analysis" performed)
Not all participants have the same level of analysis and development ability - and for many projects there's a lot of surrounding domain knowledge (and/or history) required to post more valuable comments.
Also worth noting: high-frequency, low-analysis comments along the lines of "it's broken" can still be useful - they're often an indicator that a bug has been introduced, and can be the equivalent of comment storms on Twitter asking whether a service is down after a website/API has an outage.
Coming back to the problem: it's difficult to scale the ability of small groups of maintainers to respond to large volumes of comments - as the article alludes to, it can become a kind of "time denial of service" attack. I'd guess that problem is most pronounced for developer-and-end-user-facing projects (web frameworks, for example).
One solution could be tools that help maintainers cluster and categorize comments -- customer support tools are often designed to do this.
Another idea is whether it'd be possible to challenge the commentor gently to check whether they've provided all the relevant information. This could theoretically be conversational (human or automated) -- and that's similar to tech support in traditional IT.
Finally, a structural solution is to attempt to choose software architectures that distribute the support load and allow clusters of maintainers and developers to develop expertise in particular areas. This is, to a large extent, naturally the way that open source evolves. If one project becomes too heavyweight, then frequently we'll see smaller libraries emerge that provide the core functionality elements with a smaller code surface. If development slows unacceptably or moves in problematic directions, then motivated actors generally step in to fork or create an alternative.
In summary: I think that these ticket entitlement issues have likely existed in closed environments for a long time, and there are patterns and tools for dealing with them that may be valuable. Also it's a software-and-organizational architecture issue (in an evolutionary environment with no central authority).
However I do think that the amount of analysis and effort that the user has done for each comment is relevant.
Silly hypothetical example: if a project is a Fibonacci function that (incorrectly) prints nothing but repeated "1" values, then the potential range of comments may include:
- "it's wrong"
- "it's printing the wrong output"
- "expected to see 1 1 2 3 ... but found 1 1 1 1 ..."
- "line two is missing an addition operator near character five"
- "please see #3 for a pull request to add an addition operator on line two"
(roughly in order of estimated "most frequent" to "least common" comment volume -- and not coincidentally, also ordered from "least analysis" to "most analysis" performed)
Not all participants have the same level of analysis and development ability - and for many projects there's a lot of surrounding domain knowledge (and/or history) required to post more valuable comments.
Also worth noting: high-frequency, low-analysis comments along the lines of "it's broken" can still be useful - they're often an indicator that a bug has been introduced, and can be the equivalent of comment storms on Twitter asking whether a service is down after a website/API has an outage.
Coming back to the problem: it's difficult to scale the ability of small groups of maintainers to respond to large volumes of comments - as the article alludes to, it can become a kind of "time denial of service" attack. I'd guess that problem is most pronounced for developer-and-end-user-facing projects (web frameworks, for example).
One solution could be tools that help maintainers cluster and categorize comments -- customer support tools are often designed to do this.
Another idea is whether it'd be possible to challenge the commentor gently to check whether they've provided all the relevant information. This could theoretically be conversational (human or automated) -- and that's similar to tech support in traditional IT.
Finally, a structural solution is to attempt to choose software architectures that distribute the support load and allow clusters of maintainers and developers to develop expertise in particular areas. This is, to a large extent, naturally the way that open source evolves. If one project becomes too heavyweight, then frequently we'll see smaller libraries emerge that provide the core functionality elements with a smaller code surface. If development slows unacceptably or moves in problematic directions, then motivated actors generally step in to fork or create an alternative.
In summary: I think that these ticket entitlement issues have likely existed in closed environments for a long time, and there are patterns and tools for dealing with them that may be valuable. Also it's a software-and-organizational architecture issue (in an evolutionary environment with no central authority).
> If you were to develop a closed source iOS app and charge for it in the Apple App Store your user base will have certain expectations.
What's weird is that paying users have lower expectations and are much nicer than those who don't pay. Why do free users feel entitled? It's a bit of a mystery, yet can be observed often.
What's weird is that paying users have lower expectations and are much nicer than those who don't pay. Why do free users feel entitled? It's a bit of a mystery, yet can be observed often.
This is not my observation at all. I encounter the exact opposite with paying users, and much prefer interactions with free users who are very understanding and empathetic.
Then again, it depends on the prices that you pay.
If you have customers paying somewhat decent prices for your service/product, they interact in an empathetic manner. However, if you price your services too low, you'll get a bunch of entitled people who want things to be done "right now" and throw a tantrum if their demands aren't met immediately.
If you have customers paying somewhat decent prices for your service/product, they interact in an empathetic manner. However, if you price your services too low, you'll get a bunch of entitled people who want things to be done "right now" and throw a tantrum if their demands aren't met immediately.
free - medium support
$1 - high support
$100,000 – low support (after the initial deal)
Choose which you want to build :)
$1 - high support
$100,000 – low support (after the initial deal)
Choose which you want to build :)
Paying users are often not the ones using and making reports of the software.
In companies you're told "use this software that we have a license for" and that's that. You don't get a choice to use it or not, and so you gotta roll with it.
If the device were the ones making the decision to use or not, you'd see a different attitude
In companies you're told "use this software that we have a license for" and that's that. You don't get a choice to use it or not, and so you gotta roll with it.
If the device were the ones making the decision to use or not, you'd see a different attitude
The biggest thing that I failed to understand was that with every user commenting
this feature is essential for me to keep using Grafana
or asking
why hasn’t this been implemented yet?
a barrier was being built to stop anyone from ever working on it.
Other points have been reiterated a million times, and still worth to be reiterated. Sure, the most useful attitude for free software is free to contribute to, not free as in beer. Recently I discovered that Photoshop is pretty poor in handling color for the industrial standard it is. Could I suggest an improvement? Nah. In addition to their imaginary "average consumer" (who of course always wants bells and whistles instead of core improvements), Adobe often cater to the requests of large companies, which I am not. Moreover, they have their own business interests such as market segmentation - they had great software called Speedgrade that they butchered and integrated into Premiere, so video folks got everything and photo folks like me got nothing. Meanwhile, Darktable was free to contribute to, which I did.
> a barrier was being built to stop anyone from ever working on it.
I looked in the grafana github issues, sort by +1's and the top one "Templating: Reuse template variable definitions across dashboards"[0] opened in 2015 has these comments (and others):
"yea, with Grafana 2.0 and the new backend, it would be possible in a future release (maybe next year or this winter), to add template variables as independent entities that you can reuse across dashboards."
"Torkel, this is exteremely important for us, any chance you could prioritize this?" +1 (23x), -1 (1x)
"no, maybe if it would get a lot of +1 :) People have been fine without centralized storage of template vars this far, just define them for one dashboard and then copy that dashboard. Not ideal. [...]"
This is exactly how I expect these interactions to go. I suspect the difference is that this is an issue that is on the radar and close to where the contributors are working vs many of the other 2.2k issues that are not.
July 2021 comment "[...] we do plan on tackling this issue as part of our evolution of Library Panels. We don't have a timeframe to communicate yet, but consider it 'on the roadmap'." So even ones that are on the radar don't necessarily get immediate attention.
What may be missing is clear up-front communication to set expectations for those creating, commenting, or up/down-voting on issues. We as a community can also default to interpreting a non-response as being 'lower priority or relevance than contributor bandwidth allows'.
[0] https://github.com/grafana/grafana/issues/1959
I looked in the grafana github issues, sort by +1's and the top one "Templating: Reuse template variable definitions across dashboards"[0] opened in 2015 has these comments (and others):
"yea, with Grafana 2.0 and the new backend, it would be possible in a future release (maybe next year or this winter), to add template variables as independent entities that you can reuse across dashboards."
"Torkel, this is exteremely important for us, any chance you could prioritize this?" +1 (23x), -1 (1x)
"no, maybe if it would get a lot of +1 :) People have been fine without centralized storage of template vars this far, just define them for one dashboard and then copy that dashboard. Not ideal. [...]"
This is exactly how I expect these interactions to go. I suspect the difference is that this is an issue that is on the radar and close to where the contributors are working vs many of the other 2.2k issues that are not.
July 2021 comment "[...] we do plan on tackling this issue as part of our evolution of Library Panels. We don't have a timeframe to communicate yet, but consider it 'on the roadmap'." So even ones that are on the radar don't necessarily get immediate attention.
What may be missing is clear up-front communication to set expectations for those creating, commenting, or up/down-voting on issues. We as a community can also default to interpreting a non-response as being 'lower priority or relevance than contributor bandwidth allows'.
[0] https://github.com/grafana/grafana/issues/1959
I also run a few popular open-source projects (eg. Nodemailer) and what grinds my gears the most are the support requests disguised as bug tickets. It takes so much time to handle these – first to verify that this in fact is not a bug, and then come up with some kind of response.
For example - someone uses Nodemailer and the server they are running their code on has the firewall configured to block non-HTTP/S ports, including email ports. Now their app gets timeouts left and right and the obvious thing to do in that case seems to be to go and file the 1000th bug ticket in Github with the same "works on my developer machine, but not in the server" subject.
For example - someone uses Nodemailer and the server they are running their code on has the firewall configured to block non-HTTP/S ports, including email ports. Now their app gets timeouts left and right and the obvious thing to do in that case seems to be to go and file the 1000th bug ticket in Github with the same "works on my developer machine, but not in the server" subject.
Very much the same here. I'm the maintainer of Outline (https://github.com/outline/outline) – which uses Nodemailer by the way, thanks! – and folks still push through all of the GitHub workflows that try and direct self hosting support tickets to the discussions board and post them as bugs instead . This is much more annoying and time consuming than the +1 comments which can largely be left without a direct response.
Counterpoint: you have a successful open source project and you even “branded and marketed” it (like Grafana). You obviously want it to be successful? Then listen to your users and respond to their questions.
Entitlement is a two way street.
Entitlement is a two way street.
The company Grafana and the open source project Grafana have different customers with different requirements and requests.
If BigCorp wants purple widgets for their next massive migration towards Grafana and a bunch of free users are asking for the Foobars to be yellow then I don't see why it would make any sense for Grafana to take widget purplelization manpower away from their paying customer to yellowify foobars.
You've placed your upvote, your request has been noted and noticed. Next time there's dev capacity free there will be an evaluation of the most pressing open source issues and your concerns will probably be taken into account.
If you really need or want a feature, either build it yourself and send a PR or pay someone (probably the Grafana devs) to build it for you. Don't expect Grafana to solve your problems for you if you're not an important, paying customer, because they're a business; the focus should be on what keeps the lights on, not on which issue attracts the most vocal crowd on Github.
Maybe Grafana doesn't want what you want. Some features should not be in some products or implemented in some ways. Maybe something is of such little influence that you can be reasonably sure that only the free users will ever use a feature (i.e. features that compete with your paid offering).
I agree that entitlement is a two way street, but not in the way you probably think about it. If your users act entitled to support and attention, you're entitled to some kind of compensation.
If BigCorp wants purple widgets for their next massive migration towards Grafana and a bunch of free users are asking for the Foobars to be yellow then I don't see why it would make any sense for Grafana to take widget purplelization manpower away from their paying customer to yellowify foobars.
You've placed your upvote, your request has been noted and noticed. Next time there's dev capacity free there will be an evaluation of the most pressing open source issues and your concerns will probably be taken into account.
If you really need or want a feature, either build it yourself and send a PR or pay someone (probably the Grafana devs) to build it for you. Don't expect Grafana to solve your problems for you if you're not an important, paying customer, because they're a business; the focus should be on what keeps the lights on, not on which issue attracts the most vocal crowd on Github.
Maybe Grafana doesn't want what you want. Some features should not be in some products or implemented in some ways. Maybe something is of such little influence that you can be reasonably sure that only the free users will ever use a feature (i.e. features that compete with your paid offering).
I agree that entitlement is a two way street, but not in the way you probably think about it. If your users act entitled to support and attention, you're entitled to some kind of compensation.
Not sure if Grafana operates this way but some companies make it doubly confusing by running all their feature requests through public issue trackers. It's unclear if there are users replying to issues that already pay but don't pay enough to get exclusive dev team access (which can still be a pretty hefty fee--you could pay $10k/mon but still pale in comparison to the customer with a $1m/year contract)
Azure, AWS, GCP, and Okta all have products I've used with shared issue trackers (for at least some of their software)
Azure, AWS, GCP, and Okta all have products I've used with shared issue trackers (for at least some of their software)
that's not necessarily a recipe for success. As the (admittedly over-quoted) Ford quip goes."if I had asked them what they wanted, they'd have said faster horses".
Software development requires a solid amount of confidence to ,at times, be willing to disappoint users to keep a project on track. If you listen to what is likely an incredibly scattered and unfocused sea of requests you're going to lose control quickly. Torvalds and Linux are one positive example of someone who has maintained control often against demands.
Software development requires a solid amount of confidence to ,at times, be willing to disappoint users to keep a project on track. If you listen to what is likely an incredibly scattered and unfocused sea of requests you're going to lose control quickly. Torvalds and Linux are one positive example of someone who has maintained control often against demands.
This jumped out at me. Software has always had grandiose marketing and I figure that a successful large-business image usually works better than mom & pop imagery. But it probably encourages people to see the person or team behind an OSS product as at least a cog in a big machine, if not a successful entrepreneur.
I'm reminded of the scene in Cinderella Man where Jim's wife Mae goes to tell off Joe Gould calling him rich and entitled, basically, and they invite her into the big apartment and they've sold all the furniture except a table and two chairs.
I'm reminded of the scene in Cinderella Man where Jim's wife Mae goes to tell off Joe Gould calling him rich and entitled, basically, and they invite her into the big apartment and they've sold all the furniture except a table and two chairs.
True.
If someone clearly describes their project as an experiment or a hobby project then no responsibility should be attached to it.
But if they advertise it as something production-ready or secure they are capturing user's trust, attention and time.
Some company-driven projects even use open source as a foot in the door to get user's data or corner a market and charge money later on.
As a developer your time is valuable and users should not be demand it.
As a user your trust, attention and time are valuable and not every random project on github should get it.
If someone clearly describes their project as an experiment or a hobby project then no responsibility should be attached to it.
But if they advertise it as something production-ready or secure they are capturing user's trust, attention and time.
Some company-driven projects even use open source as a foot in the door to get user's data or corner a market and charge money later on.
As a developer your time is valuable and users should not be demand it.
As a user your trust, attention and time are valuable and not every random project on github should get it.
As a maintainer of a graph OSS project with an optional commercial tier, we are 100% fine with his original approach.
A clearly written issue or a +1 vote (not comment, which causes an alert) is definitely appreciated. We get to learn usage patterns to optimize, bugs to fix, etc, before they hit users in our paid tiers. Sometimes feedback isn't well thought out, so we added templates to steer users, and that worked pretty well. Various tricks like that have helped over time.
Likewise, when there is a commercial tier or outside funding, as in his case of Grafana, much less expectation of code giveback. Typically the maintainers have blown the path to open governance, and through that, significant OSS community It's freemium, and the interactions are more about issues vs PRs. Yes it's better when a true OSS community, not just license, but that's just not how most big ones work nowadays. So a helpful ticket is fine.
A clearly written issue or a +1 vote (not comment, which causes an alert) is definitely appreciated. We get to learn usage patterns to optimize, bugs to fix, etc, before they hit users in our paid tiers. Sometimes feedback isn't well thought out, so we added templates to steer users, and that worked pretty well. Various tricks like that have helped over time.
Likewise, when there is a commercial tier or outside funding, as in his case of Grafana, much less expectation of code giveback. Typically the maintainers have blown the path to open governance, and through that, significant OSS community It's freemium, and the interactions are more about issues vs PRs. Yes it's better when a true OSS community, not just license, but that's just not how most big ones work nowadays. So a helpful ticket is fine.
> we added templates to steer users
I think this is great.
Often, by the time someone gets to the point of figuring out how to comment at all, they have a real need and are more than willing to spend some time... but they have no idea what would help and you end up with an annoying demand or "+1" comment. A template directs the energy on a useful path (and implicitly balances/settles things a little bit... the user has to stop, think, and contribute a little bit back and a maintainer hears it in response)
I think this is great.
Often, by the time someone gets to the point of figuring out how to comment at all, they have a real need and are more than willing to spend some time... but they have no idea what would help and you end up with an annoying demand or "+1" comment. A template directs the energy on a useful path (and implicitly balances/settles things a little bit... the user has to stop, think, and contribute a little bit back and a maintainer hears it in response)
I kinda blame Github for all this.
In the past, there was just a bit of friction before filing a bug or dropping a comment on a project.
You had to sign up for bugzilla. You had to sign up for the mailing list. Something. Anything.
It was just enough friction that you had to want to post that comment or file that bug. You weren't going to waste your time just to be a shit.
With everything on Github, it's simply too easy to quickly slap a thoughtless comment on a project (guilty as charged--sadly).
I know that if I were releasing a project today, I would make sure to use anything other than Github.
In the past, there was just a bit of friction before filing a bug or dropping a comment on a project.
You had to sign up for bugzilla. You had to sign up for the mailing list. Something. Anything.
It was just enough friction that you had to want to post that comment or file that bug. You weren't going to waste your time just to be a shit.
With everything on Github, it's simply too easy to quickly slap a thoughtless comment on a project (guilty as charged--sadly).
I know that if I were releasing a project today, I would make sure to use anything other than Github.
I see what you are saying. But on the other hand, I definitely neglected to report bugs in the past because I had to subscribe to a mailing list or sign up for another yet another bugzilla account (combined with bugzilla often being terribly slow).
I think GitHub has provided a net improvement because many smaller project get bug reports now (whereas they usually didn't in pre-GitHub times), while they usually do not have to deal with frivolous comments. I have many smaller projects that do get issues filed, but never useless comments.
I think GitHub has provided a net improvement because many smaller project get bug reports now (whereas they usually didn't in pre-GitHub times), while they usually do not have to deal with frivolous comments. I have many smaller projects that do get issues filed, but never useless comments.
> With everything on Github, it's simply too easy to quickly slap a thoughtless comment on a project
THIS! The UI really encourages drive-by comments from anybody.
Like social networks, it's designed to maximize views and clicks instead of building communities.
THIS! The UI really encourages drive-by comments from anybody.
Like social networks, it's designed to maximize views and clicks instead of building communities.
If you want to do some harm, you’ll jump through any hoops, including signing up for mailing lists. But if you want to make a meaningful contribution, and you’re faced with too many absurd requirements, you might just give up.
This is actually a fair point and shouldn't be getting downvotes. Github has decreased the barrier to entry and sadly that has its disadvantages.
One pattern I've noticed that leads to low quality bug reports is that high quality bug reports take time, and bug reports, even if they're high quality, are often ignored if they're not an absolutely critical issue.
After spending an hour of time writing the perfect bug report a couple of times, and each time receiving no reward (= fix), often not even seeing a sign that anyone looked at the report, this gets incredibly frustrating, and creates a temptation to not put in the effort anymore.
Which results in low quality bug reports, which exacerbates the issue (makes work harder for the maintainers, makes bugs less likely to get looked at/fixed, makes it more likely that the user encounters more such frustration).
I see the pattern, but I don't have a solution. One thing I've started to do is filing an initial low-quality bug report and offering to follow up (and actually doing it) once anyone shows any amount of interest, but that still leaves a crappy and non-actionable bug report.
After spending an hour of time writing the perfect bug report a couple of times, and each time receiving no reward (= fix), often not even seeing a sign that anyone looked at the report, this gets incredibly frustrating, and creates a temptation to not put in the effort anymore.
Which results in low quality bug reports, which exacerbates the issue (makes work harder for the maintainers, makes bugs less likely to get looked at/fixed, makes it more likely that the user encounters more such frustration).
I see the pattern, but I don't have a solution. One thing I've started to do is filing an initial low-quality bug report and offering to follow up (and actually doing it) once anyone shows any amount of interest, but that still leaves a crappy and non-actionable bug report.
>After spending an hour of time writing the perfect bug report a couple of times, and each time receiving no reward (= fix),
Something that may be happening in that case is that the demand for making the bug report high quality is not sincere, but is just meant to kill it by filibuster. The developers won't fix the bug regardless, but by making it easy to say "you didn't follow all these steps in submitting the bug", they can put the blame on the user rather than just admitting they won't fix it.
Something that may be happening in that case is that the demand for making the bug report high quality is not sincere, but is just meant to kill it by filibuster. The developers won't fix the bug regardless, but by making it easy to say "you didn't follow all these steps in submitting the bug", they can put the blame on the user rather than just admitting they won't fix it.
Something I believe is overlooked that is relevant here is the effect of large volumes of feedback, even positive. Sara Chipps wrote about it in her blog post on Stack Overflow[1].
I don't believe we as people are desgined to handle feedback and opinions from a large number of people, and it's very easy for even neutral or benign questions ("is this planned for a release?", "any news on this?") to become grating.
Kinda similar to when kids go "Mom, mom, mom, mom" - nothing harmful is being said, but the cumulative effect is exhausting.
IMO it's a good idea to question, has someone else asked this? has someone else already stated this opinion? before posting on forums.
1. https://stackoverflow.blog/2019/07/18/building-community-inc...
I don't believe we as people are desgined to handle feedback and opinions from a large number of people, and it's very easy for even neutral or benign questions ("is this planned for a release?", "any news on this?") to become grating.
Kinda similar to when kids go "Mom, mom, mom, mom" - nothing harmful is being said, but the cumulative effect is exhausting.
IMO it's a good idea to question, has someone else asked this? has someone else already stated this opinion? before posting on forums.
1. https://stackoverflow.blog/2019/07/18/building-community-inc...
Don't be entitled but at the same time nothing wrong with respectfully asking for support. User support is the whole point of maintainance. Replying to issues to add "weight" allows maintainers to prioritize fixes.
I think asking for support is fine unless it is against the project guidelines.
I think reporting bugs is almost always great.
But I think that few if any projects and maintainers appreciate adding just "weight" in a comment. These comments just add load to whatever channel the maintainer uses to follow these things. If the comment has more valuable, like explaining a new use case that is affected by the issue then I think it has value. Otherwise just use the reactions feature.
I think reporting bugs is almost always great.
But I think that few if any projects and maintainers appreciate adding just "weight" in a comment. These comments just add load to whatever channel the maintainer uses to follow these things. If the comment has more valuable, like explaining a new use case that is affected by the issue then I think it has value. Otherwise just use the reactions feature.
Mostly agree, but personally I comment when it is a bug impacting production stuff(outage for me). I don't know how else to get support, if they have a paid support option my company would be all over it for most of these projects. But therein lies the usability issue of OSS. With commercial software I can open a ticket and at least get some response that will help me make plans on how to deal with the issue.
There really needs to be some org that simply lets devs get paid for supporting paying customers and let customers procure such support.
For personal stuff I don't care but after fighting many battles to sell OSS when I have some issue what other recourse do I have than to politely explain my situation and hope I get therir attention. I literally beg for help! I am sorry if that annoys devs, but it is either that or I give up on OSS and be permanently pessimistic about anything related to it.
There really needs to be some org that simply lets devs get paid for supporting paying customers and let customers procure such support.
For personal stuff I don't care but after fighting many battles to sell OSS when I have some issue what other recourse do I have than to politely explain my situation and hope I get therir attention. I literally beg for help! I am sorry if that annoys devs, but it is either that or I give up on OSS and be permanently pessimistic about anything related to it.
For better or worse, open source software is competing with paid software, so expectations for basic support and maintenance need to exist. If there is not enough capacity for this, the maintainers should make it clear upfront in very visible ways so people can use that information when deciding what to use.
I'm an open source developer (and user of course), and I don't like people acting entitled. However I don't mind people commenting on bugs that they're also have the bug, because it gives some indication about which bugs are affecting lots of people and which are rare. I also have a rule of thumb that for every user who comments on a bug, probably another 9 are affected.
Also please file bug reports that I have some hope of reproducing locally, or if not, include all the information you have, such as the full commands and errors, the versions of everything that might be relevant etc.
Also please file bug reports that I have some hope of reproducing locally, or if not, include all the information you have, such as the full commands and errors, the versions of everything that might be relevant etc.
I see this almost as a technical problem.
Developers want polite, clear, obvious, deduplicated, fully fleshed out bug reports. They want to hear the praise but dont want the shit talk.
Users want somebody to talk to who can help fix their problem and to lobby for their pet feature requests. They generally dont know what to file under bug or support request.
A system with a different UI for both that could be intermediated by some low-time-investment support roles filled by enthusiastic power users would help immensely.
Developers want polite, clear, obvious, deduplicated, fully fleshed out bug reports. They want to hear the praise but dont want the shit talk.
Users want somebody to talk to who can help fix their problem and to lobby for their pet feature requests. They generally dont know what to file under bug or support request.
A system with a different UI for both that could be intermediated by some low-time-investment support roles filled by enthusiastic power users would help immensely.
> …I was one of those open source users who had service expectations despite never paying for anything.
Brian Fox had a default reply for these messages back in the early 90s: “Please return bash for a full refund”.
Brian Fox had a default reply for these messages back in the early 90s: “Please return bash for a full refund”.
I can partially agree but we live in a day and age where asking someone their name may be considered offensive. I think there is a lot more value in teaching people self-worth and to not be so easily offended by people asking questions and then they run sway and hide and say that you hurt their feelings by asking them.
A simple disclaimer that says they don't have any obligation, or heck most open source licenses indicate that. Who cares it people +1 something. If open source developers want to focus on perfecting their code to be a haiku there is nothing wrong with that.
However, if they don't get around to implementing important features or merging PRs then they shouldn't be surprised nor offended when people abandon their projects either.
Sometimes people can be demanding and rude, but the key to get anything accomplished is learning how to interact and deal with people. If you can't handle people asking questions or +1 or +2'ing your public GitHub issues then you're probably not cut out for software development even as someone who is an unpaid open source contributor.
A simple disclaimer that says they don't have any obligation, or heck most open source licenses indicate that. Who cares it people +1 something. If open source developers want to focus on perfecting their code to be a haiku there is nothing wrong with that.
However, if they don't get around to implementing important features or merging PRs then they shouldn't be surprised nor offended when people abandon their projects either.
Sometimes people can be demanding and rude, but the key to get anything accomplished is learning how to interact and deal with people. If you can't handle people asking questions or +1 or +2'ing your public GitHub issues then you're probably not cut out for software development even as someone who is an unpaid open source contributor.
This goes both ways. It's also fine to ignore your open source users, or refuse their requests. What will they do, fire you? Stop paying you? If they don't like it, it's on them.
> While some open source projects are created by large companies in a structured and planned way I think it is fair to say that most grow organically.
> Coming back to the Grafana example, I was one of those open source users
Well, Grafana is definitely a large company. They recently devoured Prometheus community, that was really open source before.
> Coming back to the Grafana example, I was one of those open source users
Well, Grafana is definitely a large company. They recently devoured Prometheus community, that was really open source before.
I see this a bit more nuanced. On the one hand I believe it’s important that users communicate what they’d like the software to be, and also when they are frustrated about a lack of progress, but on the other hand they shouldn’t act like entitled assholes about it and/or constantly complain about the same thing over and over again. It’s possible to express dissatisfaction with the software while still being respectful towards the maintainers. And the number of “me too”s (+1) can be useful information.
With regard to time and attention, that’s more a matter of tooling and push vs. pull. As a maintainer, I’m responsible to not let my time and attention be strained too much, just as with any other communication. For example, by auto-filtering issue tracker notifications into a dedicated folder and only looking into it at scheduled, time-boxed intervals.
With regard to time and attention, that’s more a matter of tooling and push vs. pull. As a maintainer, I’m responsible to not let my time and attention be strained too much, just as with any other communication. For example, by auto-filtering issue tracker notifications into a dedicated folder and only looking into it at scheduled, time-boxed intervals.
> As time went on the wording of the +1s got stronger
I think a +1 (as a thumbs up reaction, or similar) can’t be a bad thing. Comments that turn more passive/agressive (or just agressive) most certainly can. I don’t think the later should be mixed up with the former.
I think a +1 (as a thumbs up reaction, or similar) can’t be a bad thing. Comments that turn more passive/agressive (or just agressive) most certainly can. I don’t think the later should be mixed up with the former.
I think a +1 (as a thumbs up reaction, or similar)
If you refer to +1 comments (which the second sentence seems to imply), these are a bad thing, since it sends a notification to everyone who is subscribed to an issue. If you are maintaining a popular open source project, useful comments (reproducers, potential solutions) get buried between all useless +1 comments.
If you refer to +1 comments (which the second sentence seems to imply), these are a bad thing, since it sends a notification to everyone who is subscribed to an issue. If you are maintaining a popular open source project, useful comments (reproducers, potential solutions) get buried between all useless +1 comments.
Yes, should have been clearer. I meant reactions. Even as a reader of issues, all the +1 comments are annoying, can only imagine how it is for the maintainer.
[deleted]
Reminds me of the wiring pi debacle. Gordon got tired of supporting novice users for free and stopped publishing updates to his project in 2019.
> I’ve had over 10,000 emails from people who upgraded their Pi and found that code stopped working because they were reliant on a system, which had statically linked an older version. This sheer incompetence on their part has saddened and depressed me hugely.
https://www.i-programmer.info/news/136-open-source/13036-wir...
> I’ve had over 10,000 emails from people who upgraded their Pi and found that code stopped working because they were reliant on a system, which had statically linked an older version. This sheer incompetence on their part has saddened and depressed me hugely.
https://www.i-programmer.info/news/136-open-source/13036-wir...
Here is the main problem, highlighted by this comment, from user itmecho:
> I'm subscribed to it because I want to know when it gets implemented, not because I want to know every time someone else wants it implemented.
> I'm now unsubscribing because I'm finally fed up of the +1 emails so I'll have to manually check this issue periodically instead. All because people can't just put a reaction on the initial message
Maybe Github should a conditionally shown dialog box which says: "your comment will generate a notification seen by 150 watchers; do you want to proceed?"
> I'm subscribed to it because I want to know when it gets implemented, not because I want to know every time someone else wants it implemented.
> I'm now unsubscribing because I'm finally fed up of the +1 emails so I'll have to manually check this issue periodically instead. All because people can't just put a reaction on the initial message
Maybe Github should a conditionally shown dialog box which says: "your comment will generate a notification seen by 150 watchers; do you want to proceed?"
Yeah or the ability to subscribe to status/tag updates. I have a few issues I've been tracking and get spammed with meaningful discussion when I mostly just want to know if it gets implemented.
My general advice on this is to never rely on other people reading your mind. It's a path to frustration for you and the other people.
In this article I see a lot of phrases where OP is hoping other people share the same perspective. Like, "Hopefully we agree that...", "I want to argue here...", "Users... shouldn’t expect..."
It's just not going to happen like that automatically, though.
I suggest that if, as an open source author, you're seeing seeing potential for broad usage of your project, spend some time to think about what you're willing (and able) to give, and make an explicit statement to that effect (and put it somewhere that potential new users will see it).
I suggest that if you're considering using an open source project in something, spend a few minutes to think about what you will do if you get no more support than what is explicitly promised and/or paid for (which means no support in most cases). If that's not acceptable for your project, then don't use it.
(Oh, and sadly, I think this the purpose of this article is a bit hopeless. I think there are thoughtful people that will read this and take it to heart, but those people are probably only causing a tiny fraction of the unpleasantness that open source maintainers experience.)
In this article I see a lot of phrases where OP is hoping other people share the same perspective. Like, "Hopefully we agree that...", "I want to argue here...", "Users... shouldn’t expect..."
It's just not going to happen like that automatically, though.
I suggest that if, as an open source author, you're seeing seeing potential for broad usage of your project, spend some time to think about what you're willing (and able) to give, and make an explicit statement to that effect (and put it somewhere that potential new users will see it).
I suggest that if you're considering using an open source project in something, spend a few minutes to think about what you will do if you get no more support than what is explicitly promised and/or paid for (which means no support in most cases). If that's not acceptable for your project, then don't use it.
(Oh, and sadly, I think this the purpose of this article is a bit hopeless. I think there are thoughtful people that will read this and take it to heart, but those people are probably only causing a tiny fraction of the unpleasantness that open source maintainers experience.)
Author of the article here. Thanks for this comments, really great points and sadly I agree with everything you’ve said.
Although I would say many projects snowball into something bigger than the creator imagined so upfront planning about how much time you can put into something is hard.
I wrote this post with the intention of directly sharing it with folks in issues when situations flare up from time to time in the projects I work on. I never imaged it getting shared on HN.
Although I would say many projects snowball into something bigger than the creator imagined so upfront planning about how much time you can put into something is hard.
I wrote this post with the intention of directly sharing it with folks in issues when situations flare up from time to time in the projects I work on. I never imaged it getting shared on HN.
If you don’t pay for something and that something is written by a volunteer and shared for free then sit down and shut up and wait for that volunteer to maybe get to your feature request. One can always propose a PR implementing that feature. Or wait.
Even more egregious is if you’re a company making money on this free software and yelling about a missing feature and not willing to sponsor its development then you’re even further behind in the line.
Even more egregious is if you’re a company making money on this free software and yelling about a missing feature and not willing to sponsor its development then you’re even further behind in the line.
the other part: https://polite.technology/preview
Just a thought (vaguely connected here) but voting on features to be implemented is ... pretty much same as voting IRL on policies not parties.
I have often wondered what would be the thing to trigger companies to stop being totalitarian dictatorships and become democratic to their (employees / stakeholders) - is it crazy to say voting on features to build would be the one?
I have often wondered what would be the thing to trigger companies to stop being totalitarian dictatorships and become democratic to their (employees / stakeholders) - is it crazy to say voting on features to build would be the one?
Unless you have an absolute monopoly market position you are a democratic institution where the ‘votes’ are people giving you their hard earned money in exchange for whatever you’re selling.
Where things go wrong is ‘stakeholders’ (aka non-paying people/customers) demanding influence for whatever is important to them like savings baby seals or whatever. They know they can’t influence the company by ‘voting with their wallet’ so seek out other means to change the company’s direction. Like, as a totally random example, wanting voting rights to the future plans of the company as an outsider with no knowledge of internal goals and/or if the proposal would even be profitable.
Where things go wrong is ‘stakeholders’ (aka non-paying people/customers) demanding influence for whatever is important to them like savings baby seals or whatever. They know they can’t influence the company by ‘voting with their wallet’ so seek out other means to change the company’s direction. Like, as a totally random example, wanting voting rights to the future plans of the company as an outsider with no knowledge of internal goals and/or if the proposal would even be profitable.
I'm pretty sure that as a society we realised a very long time ago that for things that matter, tying votes to money is a really bad idea.
Oh there are so many ways to play this game - kickstarter is basically voting in advanace with your money.
The word you are looking for is consumers' co-operative (https://en.wikipedia.org/wiki/Consumers%27_co-operative).
Oh I am not so sure.
Socialism is basically about public ownership.
But the history of capitalism seems to show you don't need to own something to control it.
So this is about control. such as regulation. not necessarily ownership.
conflicts might arise !
Socialism is basically about public ownership.
But the history of capitalism seems to show you don't need to own something to control it.
So this is about control. such as regulation. not necessarily ownership.
conflicts might arise !
[deleted]
> I also occasionally returned to issues that hadn’t been resolved to [..] ask if there was an ETA on a fix. I felt I was being helpful.
I irrationally get annoyed when someone asks for an ETA like this, I'm sure it's a genuine question but it just feels like a nag to "hurry the fork up already!"
I irrationally get annoyed when someone asks for an ETA like this, I'm sure it's a genuine question but it just feels like a nag to "hurry the fork up already!"
Sometimes people would like just a ballpark. Is this going to be looked at this year? At all? Is it on roadmap? Should I wait a week or just carry on with my own patch, work around it, or go with an alternative solution? A ballpark response may at least add enough clarity for people to know how to proceed in the meantime. "I'll look into it real soon now" out of some unwarranted sense of duty and then a year of radio silence is not helpful.
"ETA" sure is a wrong term. (You're not my manager! Argh!!!) However, work enough in a corporate setting, and those words firmly suck into you and it takes a time to unlearn them. ETA, touch base, circle back to (or worse, faux military vocabulary in a company that has jack to do with military, my pet peeve). Unless they go out of their way to be pushy, you may as well not assume ill intent where there's only a professional deformation.
"ETA" sure is a wrong term. (You're not my manager! Argh!!!) However, work enough in a corporate setting, and those words firmly suck into you and it takes a time to unlearn them. ETA, touch base, circle back to (or worse, faux military vocabulary in a company that has jack to do with military, my pet peeve). Unless they go out of their way to be pushy, you may as well not assume ill intent where there's only a professional deformation.
Amazing write up! Something I would add as open source maintainer:
* Feedback is needed. After years I built up a filter to annoying users, and I would simply ignore their feedback, but +1 and mentioning the feature would be useful is invaluable (and why you cannot use workarounds). Please do that in a nice, productive way (:
* It might be that the feature you and others are asking for was in paid version of the project, thus maintainers actively ignored it. Not the healthiest thing to do, but this happens, business matters, especially if governance is poor (single vendor behind the project).
* I think it would be useful to mention that if it's just a work needed and not other blocker, anyone would be welcome to create PR for the needed feature or at least moving it forward 10%. Sometimes faster that motivating your rights in issues (:
* Feedback is needed. After years I built up a filter to annoying users, and I would simply ignore their feedback, but +1 and mentioning the feature would be useful is invaluable (and why you cannot use workarounds). Please do that in a nice, productive way (:
* It might be that the feature you and others are asking for was in paid version of the project, thus maintainers actively ignored it. Not the healthiest thing to do, but this happens, business matters, especially if governance is poor (single vendor behind the project).
* I think it would be useful to mention that if it's just a work needed and not other blocker, anyone would be welcome to create PR for the needed feature or at least moving it forward 10%. Sometimes faster that motivating your rights in issues (:
Hey HN folks! Author of the post here, wow I didn’t expect this to make the front page. It’s really fun to see all the discussion here around this topic. I’d originally written this post to just have something up my sleeve to send to folks who were being unkind to open source maintainers. I’m enjoying seeing some of the counter arguments too.
The general intent of this post is to try and communicate to folks that if you consume open source software the authors of that software don’t owe you anything. However they all contribute for a reason, whether that is personal enjoyment, presence in the market, user testing, etc. They are excited to have folks use their software and they definitely want to hear from you. But it’s important to remember that this isn’t a commercial arrangement like when you buy Photoshop. So if you want to interact with a maintainer remember to be kind and respectful (you probably should be with all humans anyway). It is up to them where they focus their effort, and if they have a choice between interacting with nice folks or rude folks who do you think they will choose?
I also regularly see folks being rude on the most important issues, which results in maintainers avoiding them and even more folks being rude. It can snowball into having things that are critical to the community becoming a low priority to the maintainers.
TLDR; Be kind to folks who give you things for free.
The general intent of this post is to try and communicate to folks that if you consume open source software the authors of that software don’t owe you anything. However they all contribute for a reason, whether that is personal enjoyment, presence in the market, user testing, etc. They are excited to have folks use their software and they definitely want to hear from you. But it’s important to remember that this isn’t a commercial arrangement like when you buy Photoshop. So if you want to interact with a maintainer remember to be kind and respectful (you probably should be with all humans anyway). It is up to them where they focus their effort, and if they have a choice between interacting with nice folks or rude folks who do you think they will choose?
I also regularly see folks being rude on the most important issues, which results in maintainers avoiding them and even more folks being rude. It can snowball into having things that are critical to the community becoming a low priority to the maintainers.
TLDR; Be kind to folks who give you things for free.
> What I didn’t consider was that my interactions were taking time/attention/resources/patience from the project. User support is a cost.
A lot of it - especially what OP mentioned - is an _investment_ in the project: Bug reports and feature requests are important input for developers, and often even save them more time than they take away.
> Lastly you always have the option to fork the project.
Mostly not. I mean, a fork for creating a merge request, sure, but maintaining a fork is either impossible or overly costly in the large majority of cases AFAICT.
A lot of it - especially what OP mentioned - is an _investment_ in the project: Bug reports and feature requests are important input for developers, and often even save them more time than they take away.
> Lastly you always have the option to fork the project.
Mostly not. I mean, a fork for creating a merge request, sure, but maintaining a fork is either impossible or overly costly in the large majority of cases AFAICT.
Rude and entitled behavior is of course unacceptable.
That said I think the project developers and maintainers often share a large portion of the blame.
Most projects are very keen on telling you about their amazing new features and the awesome stuff you can build with it. What they don't do is properly document limitations of their software or honest comparisons with competing solutions. Additionally many developers overhype the status of their project. They'll call it production ready, mature, claim it has a vibrant community and ecosystem and so on, when these things really bend the truth.
That builds expectations and running into critical, well known bugs that don't get fixed can be extremely frustrating.
My solution to this problem is to avoid libraries and projects that have one of those darkmode Web 3.0 scrolling pages as home that tell you in countless ways with lots of graphics why their project is so great. They usually aren't, and they are nearly always unfinished. In contrast, I've never had any problems with libraries whose home page is text only + links generated from Emacs org mode.
Good programmers don't waste their time making fancy web pages.
Good programmers don't waste their time making fancy web pages.
Wrote about this several months ago, and specifically the vastly larger scale on which corporations do it: https://tylerberbert.substack.com/p/cooperation
Reading all this, I realise it’s very hard not to piss people off on the Internet. Mostly avoidable by not coming off as entitled, and being patient.
… to be honest, I never thought the +1 emoji would make someone mad.
… to be honest, I never thought the +1 emoji would make someone mad.
this is all true. and yes, one should never be rude and one should always be respectful of others' time and efforts.
but there is indeed another side to the equation: software does not succeed in a vacuum. it is a symbiosis between users and developers that make software great. a software package gains momentum because users invest time and effort into making use of it or building on it. these investments are nontrivial! the maintainers enjoy notoriety and potential financial benefits (sometimes massive) as a result of this notoriety.
so while yeah, entitled attitudes on oss issue trackers are pretty odious, so are illusions that all open source software is built upon a world of altruism. there's money involved, and sometimes quite a lot of it.
that said, we do need better funding models. one thing that open source does teach us is that some people do their best work outside of a classic corporate structure. some of that best work is literally the best work in software. the problem with funding is that it typically comes with hooks which then drive the projects towards what you see coming out of most corporate environments, so the challenge is to figure out how to fund open source software in a way that doesn't actually influence or drive its design.
but there is indeed another side to the equation: software does not succeed in a vacuum. it is a symbiosis between users and developers that make software great. a software package gains momentum because users invest time and effort into making use of it or building on it. these investments are nontrivial! the maintainers enjoy notoriety and potential financial benefits (sometimes massive) as a result of this notoriety.
so while yeah, entitled attitudes on oss issue trackers are pretty odious, so are illusions that all open source software is built upon a world of altruism. there's money involved, and sometimes quite a lot of it.
that said, we do need better funding models. one thing that open source does teach us is that some people do their best work outside of a classic corporate structure. some of that best work is literally the best work in software. the problem with funding is that it typically comes with hooks which then drive the projects towards what you see coming out of most corporate environments, so the challenge is to figure out how to fund open source software in a way that doesn't actually influence or drive its design.
One thing I've done from time to time is just say "hey, I would like this a lot, I'd put a $100 bounty on it". Probably wouldn't work in the corporate case described here, and certainly is below the "actually paying for a developer's time" level.
But I've thrown a bonus in there for doing it. Maybe if it's already something they wanted to do, it moves the needle into "sure, let me give it a shot".
But I've thrown a bonus in there for doing it. Maybe if it's already something they wanted to do, it moves the needle into "sure, let me give it a shot".
I like "business first" approach: https://drewdevault.com/2021/03/03/To-make-money-in-FOSS-bui...
Yeah, it can be very hard depending on the case, at least some premium features/merch/books/guides should be used to keep an open source project alive.
Yeah, it can be very hard depending on the case, at least some premium features/merch/books/guides should be used to keep an open source project alive.
[deleted]
I think the wrong message is getting made.
The takeaway I am getting is: don’t interact or communicate with open source projects you use.
The takeaway I am getting is: don’t interact or communicate with open source projects you use.
I feel like this is the end result of giving away hard work for free when it should have been charge for all along. When you give your work no value, people will perceive no value in your work.
[deleted]
Grafana is a bad example.
They switched to agpl and pushing companies in paying for it.
Which is okay of course but grafana labs is no longer a free open source project.
Of course potentially feature request might come in by key account manager or other hidden business agreements but I myself still comment on the opensource front like GitHub issues.
When my company now pays money for it, my expectation definitely changes.
They switched to agpl and pushing companies in paying for it.
Which is okay of course but grafana labs is no longer a free open source project.
Of course potentially feature request might come in by key account manager or other hidden business agreements but I myself still comment on the opensource front like GitHub issues.
When my company now pays money for it, my expectation definitely changes.
> When my company now pays money for it, my expectation definitely changes.
Familiarize yourself with the difference between "free beer" and "free speech".
The F in FOSS refers to the latter, you're fixating on the former.
The FSF has never objected to charging money for Free/GPL software. Programmers need to eat too.
Familiarize yourself with the difference between "free beer" and "free speech".
The F in FOSS refers to the latter, you're fixating on the former.
The FSF has never objected to charging money for Free/GPL software. Programmers need to eat too.
I feel like there is a lot of articles lately that call for empathy towards oh so ever poor and overworked and burned out maintainers. All true, but this is only half of an issue.
The issue is that the concept often brandished in those articles, empathy, is a two-way street. There are maintainers on one side of this, and there are, on the other hand, users, who often are integrating multiple software projects and products to produce a solution of some kind. Mind you, those users are not always entitled prima donnas at FAANGs making another service to track you or something inconsequential like an online game. Sometimes they are integrating stuff at your local ISP. Or it's some system at a local school. Or they are making systems that are just means to an end, like in a hospital, or a bakery, or whatnot. Or it's an automotive shop. You get the idea; the world doesn't run on cat pics alone, and sometimes a complex software system is just an ingredient.
And you know what? When integrating all this stuff, you end up not with that small insignificant bug in that one project, but with multiple bugs in many pieces of software that have all to work together and be reliable. You also deal with not so much bugs per se as impedance mismatches that you have to paper over. It really ends up bleeding from a thousand cuts.
"Fix it yourself" is possible, but it doesn't scale. Upstream doing it scales.
And before you tell me, "well if you're so upset then don't use it", or "nobody owes you anything so fuck you", I have to say that it works the other way too.
I get a feeling that many open source software maintainers get into this business because they think that either a big company is going to pay them dearly, or their résumé will be stellar, or that they will become rockstars and get all the bitches from it. And when harsh reality sinks in, they start writing about being overworked and burned out. Not every maintainer does it, but many do, or at least it looks like it.
And if you get burned out and whatnot, you have an option to just stop working on stuff that is deteriorating your health. Walk away. If a popular project is hinging on an unhealthy development model and is going to die if you walk away, so be it! The market will cope, believe you me. The community will find a way around it. What is not good, though, is if you, the maintainer, are burned out, or overworked, but stubbornly insist on being a bottleneck in the project under your inept stewardship nevertheless, and just whine and moan about your burnout to get internet points and worldwide pity.
The issue is that the concept often brandished in those articles, empathy, is a two-way street. There are maintainers on one side of this, and there are, on the other hand, users, who often are integrating multiple software projects and products to produce a solution of some kind. Mind you, those users are not always entitled prima donnas at FAANGs making another service to track you or something inconsequential like an online game. Sometimes they are integrating stuff at your local ISP. Or it's some system at a local school. Or they are making systems that are just means to an end, like in a hospital, or a bakery, or whatnot. Or it's an automotive shop. You get the idea; the world doesn't run on cat pics alone, and sometimes a complex software system is just an ingredient.
And you know what? When integrating all this stuff, you end up not with that small insignificant bug in that one project, but with multiple bugs in many pieces of software that have all to work together and be reliable. You also deal with not so much bugs per se as impedance mismatches that you have to paper over. It really ends up bleeding from a thousand cuts.
"Fix it yourself" is possible, but it doesn't scale. Upstream doing it scales.
And before you tell me, "well if you're so upset then don't use it", or "nobody owes you anything so fuck you", I have to say that it works the other way too.
I get a feeling that many open source software maintainers get into this business because they think that either a big company is going to pay them dearly, or their résumé will be stellar, or that they will become rockstars and get all the bitches from it. And when harsh reality sinks in, they start writing about being overworked and burned out. Not every maintainer does it, but many do, or at least it looks like it.
And if you get burned out and whatnot, you have an option to just stop working on stuff that is deteriorating your health. Walk away. If a popular project is hinging on an unhealthy development model and is going to die if you walk away, so be it! The market will cope, believe you me. The community will find a way around it. What is not good, though, is if you, the maintainer, are burned out, or overworked, but stubbornly insist on being a bottleneck in the project under your inept stewardship nevertheless, and just whine and moan about your burnout to get internet points and worldwide pity.
>What is not good, though, is if you, the maintainer, are burned out, or overworked, but stubbornly insist on being a bottleneck in the project under your inept stewardship nevertheless, and just whine and moan about your burnout to get internet points and worldwide pity.
The problem is when there are no other maintainers to the project, and you quite firmly believe the project itself has a future, just that nobody else is able to do so. Yes, you can quit, but if people truly do rely on your project (but nobody is actually willing to take the reigns) then it can become an issue of pride for some. To be clear, I'm not suggesting that people burn themselves out (I myself have gone down that road before), just that "Walk away" isn't always such an easy option for some people.
The problem is when there are no other maintainers to the project, and you quite firmly believe the project itself has a future, just that nobody else is able to do so. Yes, you can quit, but if people truly do rely on your project (but nobody is actually willing to take the reigns) then it can become an issue of pride for some. To be clear, I'm not suggesting that people burn themselves out (I myself have gone down that road before), just that "Walk away" isn't always such an easy option for some people.
> you quite firmly believe the project itself has a future, just that nobody else is able to do so.
Looks like some unwarranted feeling of self-importance combined with the sunk cost fallacy.
You still have options: make it paid only, stop taking contributions at all, hire someone to sort it out or find a volunteer to do so. Or walk away and see how quickly Amazon will copycat you.
Or accept that that’s the cost of having your pride.
Otherwise it’s almost a textbook example of emotional blackmailing some parents are known for.
Looks like some unwarranted feeling of self-importance combined with the sunk cost fallacy.
You still have options: make it paid only, stop taking contributions at all, hire someone to sort it out or find a volunteer to do so. Or walk away and see how quickly Amazon will copycat you.
Or accept that that’s the cost of having your pride.
Otherwise it’s almost a textbook example of emotional blackmailing some parents are known for.
Looks more like the new US youngsters becoming more like brainwashed Chinese or Russian apostates, who need to make public apologies before being allowed into society again. mea culpa, mea maxima culpa. What's wrong with you? Seriously.
There's nothing wrong in these tickets to apologize for. Issues are for public discussions of issues. If maintainers cannot deal with public issues, they cannot be maintainers. Problems don't come with silverspoons, And this case there were not even problems at all.
There's nothing wrong in these tickets to apologize for. Issues are for public discussions of issues. If maintainers cannot deal with public issues, they cannot be maintainers. Problems don't come with silverspoons, And this case there were not even problems at all.
People mature and the way they interact with others can change. I see this post not as a public self-shaming, but as the output of a personal retrospective that the author felt would be helpful to others to learn from instead of having to repeat the same mistakes...
IMHO, content like this is very useful to my development as a person and a member of a community. (Not as a rule-set that must be blindly adhered to, but as an opportunity for self-reflection on my actions and how they impact others...)
IMHO, content like this is very useful to my development as a person and a member of a community. (Not as a rule-set that must be blindly adhered to, but as an opportunity for self-reflection on my actions and how they impact others...)
So… guessing you have never contributed to an open source project in any meaningful fashion?
I somewhat agree with you though, try to work on a project that has artists as the primary users sometime if you really want to see entitlement. Not that I have anything against artists in general but they usually have no clue how much work goes into their “simple” feature request from a demo video they saw from siggraph and now they absolutely have to have or they will quit using the free software — after completely spamming the mailing list and bug tracker to get other users behind this must have feature to show the devs how important it is to implement.
Makes me kind of miss working on that program.
—edit—
And there were the occasional rewrite it in Java people, now they were really fun. There was one who actually machine translated the entire C codebase into Java and wanted the whole project to fork on that. Loved the Java ones.
I somewhat agree with you though, try to work on a project that has artists as the primary users sometime if you really want to see entitlement. Not that I have anything against artists in general but they usually have no clue how much work goes into their “simple” feature request from a demo video they saw from siggraph and now they absolutely have to have or they will quit using the free software — after completely spamming the mailing list and bug tracker to get other users behind this must have feature to show the devs how important it is to implement.
Makes me kind of miss working on that program.
—edit—
And there were the occasional rewrite it in Java people, now they were really fun. There was one who actually machine translated the entire C codebase into Java and wanted the whole project to fork on that. Loved the Java ones.
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 gets when someone uses a tool/piece of software without paying money (source: my company has a full feature free tool that competes with our paid offering, and often wins).
* awareness of the solution in the marketplace
* developer attention (way way easier to get a developer to try a free tool vs one that costs $0.01)
* bug finding (often in environments that would be hard to stand up for the company)
* user testing (related to bug finding, but often users will give feedback about feature direction)
* market share (if they are picking your free tool, they aren't paying for a competitor)
At my current job, we often leverage this (our GitHub issues repo and forum are main sources of our roadmap).
That's not to say that you should expect the same kind of service when you are a free user as when you are paying money. But attention is valuable too, esp of developers.
And it's not like if you pay money, a product company jumps to build whatever you ask for. Unless you pay a large amount compared to their current revenue and even then, if what you want conflicts with their long term vision, wise leaders won't.