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?
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.
>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.
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).
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.
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.
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.
Usually the maintainer's work is more money than they would ever get from monetization. Also the maintainer is one person, they can only do so much, eventually more people need to step up and do code/etc contributions.
>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 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.
> 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.
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.
> 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.
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.
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.
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.
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.
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 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.
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.
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.
> 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".
> 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.
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".
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.
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.
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.
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
..).
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.
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...
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.
> 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)
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.
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.
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.
> 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.
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.
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
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?
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.
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.
AGPL has been accepted as libre by all of OSI, FSF and Debian.
Some folks and types of companies don't like it due to the extra code distribution provisions that trigger for modified versions that users interact with over a network.
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.
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.
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.
> 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".
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?
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).
> 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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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!"
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.
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.
> However I now see that my use of the tool provided no value to the company, and I was not a paying customer of any of their services, so why should they provide me with free support.
That is not true. If the use of the tool provides "no value" to the company, then why on earth are they making the tool available. Yes, there is no money exchanging hands, but there is definitely some value.
Here's some value a company 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.
What? Open source is about giving to the community. It's not about what you get from it. It's about providing something useful to people without expecting something in return. It's a core part of computing that makes it so wonderful to be a part of and so aggravating when people abuse it.
I 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.
> "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.
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.
172 comments
[ 2.4 ms ] story [ 217 ms ] threadBut, 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?
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.
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.
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).
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 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
https://www.igalia.com/open-prioritization/
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
It gives a clear feedback, and allow people to move on, fork it, stick with it, their choice. Politeness should be key.
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.
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
> 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.
Comments that add nothing to the issue but just create noise in the notification feed are annoying.
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...
Multiple times I have no preference between two issues and worked on one with more reactions.
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.
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
I don't think reactions trigger notification emails.
Edit: I mean people probably want a notification on the second one but not the first.
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".
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.
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.
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...
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...
Just something to keep in mind in encouraging contributors to use the upvote and reacts.
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.
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.
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 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.
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.
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.
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.
$1 - high support
$100,000 – low support (after the initial deal)
Choose which you want to build :)
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
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?
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 !
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.
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.
Some folks and types of companies don't like it due to the extra code distribution provisions that trigger for modified versions that users interact with over a network.
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.
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.
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.
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".
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).
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.
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 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.
The healthy maintainer-side attitude is that these impose no obligation whatsoever to review, apply, or even look at, the fork in question.
https://docs.github.com/en/communities/setting-up-your-proje...
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.
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 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.
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.
Entitlement is a two way street.
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.
Azure, AWS, GCP, and Okta all have products I've used with shared issue trackers (for at least some of their software)
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.
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.
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.
> 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 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.
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 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.
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...
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...
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.
I agree. I’m just saying you were rude too.
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!"
"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.
The takeaway I am getting is: don’t interact or communicate with open source projects you use.
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.
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.
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!"
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.