Don't be that open-source user, don't be me
jacobtomlinson.dev
jacobtomlinson.dev
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.
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 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.
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.
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!
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?
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.
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.
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.
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 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!)
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.
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.
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?
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.
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
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.
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'.
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.
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.
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.
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)
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.
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.
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.
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 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.
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.
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.
Brian Fox had a default reply for these messages back in the early 90s: “Please return bash for a full refund”.
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.
> 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.
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.
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.
> 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'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?"
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.)
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.
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.
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.
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.
* 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 (:
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.
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.
Good programmers don't waste their time making fancy web pages.
… to be honest, I never thought the +1 emoji would make someone mad.
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 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".
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.
The takeaway I am getting is: don’t interact or communicate with open source projects you use.
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.
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 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.
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.
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.
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...)
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.