Our great sponsors
-
Outline
The fastest knowledge base for growing teams. Beautiful, realtime collaborative, feature packed, and markdown compatible.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
bootstrap-vue
BootstrapVue provides one of the most comprehensive implementations of Bootstrap v4 for Vue.js. With extensive and automated WAI-ARIA accessibility markup.
-
-
gatherup
Helps you post essential Python config details to GitHub or Discourse, all beautifully formatted
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.
Thank you to the author for writing this.
Entitlement in open source is a massive problem, I have experienced it first-hand many times. The problem is that it discourages contributions not only from the existing maintainers but also from people who may volunteer to fix issues in the future. Would you be willing to contribute if most of the issues are just asking for things (often rudely) and not even saying thanks when an issue is resolved?
Unfortunately I have seen far worse examples than the one linked in the article[1]. I would encourage people to not only think twice before acting this way but to also call out people that are acting entitled in open source to discourage such actions.
1 - https://github.com/dom96/httpbeast/pull/35#issuecomment-7218...
alerts, and automatically closing PRs.
https://github.com/rails/rails/commit/acf48169943011834c4c88...
Yes. Please have the courtesy to feedback with a roadmap or prio of the issue. Especially for popular issues.
Asking, politely, for this should not label you as entitled freeloader. It is important input to make an informed decision wether one should just wait for the fix, workaround it, contribute a PR yourself, fork the component or drop it and consider alternatives.
One has to be careful with estimates though so they don’t become false promises. All respect to these maintainers but if I have to give one concrete example, consider following issue in a very popular Vue component, https://github.com/bootstrap-vue/bootstrap-vue/issues/5196 creating a upgrade deadlock for almost the entire Vuejs community. It’s the type of dependency that get so entrenched in everybody’s application that upgrading or moving away from it becomes very expensive and requires long term planning. As such, hundreds of comments there asking for estimates and also dozens of heavy names offering help in forms of PRs, forks or donations, all on a very polite level, but the maintainers kept promising it will be done “very soon” for almost 2 years straight. It appears the last months the war has been adding more obstacles so all respect for that, but even before the roadmap was hopelessly unpredictable.
I get it, as a volunteer other things in life often have higher prio, estimates tend to be optimistic and you might want to work on things in no particular order at all. What’s important is to be transparent, polite and communicate.
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 (this was all on my own time I should add)[1].
However, there are tons of dependencies that we use for all sorts of things that are highly complex where very few people would be able to send a PR (openssl for example). Things in highly complex codebases, or deeply unfamiliar languages, etc. I maintain a forked linux driver for a wireless card for example, and I don't expect there's more than a handful of people that could hack on it without introducing tears and devastation.
For the projects I maintain, I would just say, "if you can, please consider a PR. If you're not sure it would be accepted I'm happy to be asked! If you can't send a PR, give as much info as you can and be polite. With that we're good.
[1]: https://github.com/beam-community/stripity_stripe/pull/728
Interesting you should mention about submitting details like app version number, OS version etc.
Although it's not within an app, and only partially automated, i tried building a tool to help people gather Python environment details etc to help them create richer Github issues with less effort: https://github.com/nmstoker/gatherup
The demo video needs work to explain it better and as a project it didn't really go anywhere but it was interesting to work on a few years back.