It Doesn't Work
00f.net
00f.net
The port had some major bugs, but I opened Github issues, and one by one, the developer fixed them. In a couple of cases, I helped track down the offending code, but he's done the vast majority of the work.
At this point, I have definitely opened more issues on Chromium Legacy than anyone else. I opened two more just hours ago, and I was going to open a third... but then I didn't, because I was feeling guilty. He's always thankful for the reports, but he usually apologizes (!), which makes me worry I'm just creating all this work for him... so I don't quite know what to do.
People underestimate how valuable a good bug report is - with details, minimum examples, and workarounds. Especially workarounds - as you may be the only useful response people find.
"X is broken" is about the worst JIRA ticket you can ever get :/.
I think this is very developer-esque thing to do.
If it was me, I'd just be happy that someone else is using the code I wrote!
I wouldn't worry too much if I was you :).
Haha, seriously. As I was reading this article I was thinking to myself "well shit, at least people are bitching about this guy's projects; that means people are actually using 'em".
Not that I'm complaining, of course. I'm quite content in my obscurity :)
> He's always thankful for the reports, but he usually apologizes (!), which makes me worry I'm just creating all this work for him
The maintainer appears to be Japanese. I suspect this is just a cultural thing surrounding apologies you're reading too much into.
But now I have some money. I am not mega rich but it is time to give back, if not in time then in $.
I have very little open source experience, but I am thinking of the experience of support engineer sending requests to development. If you hit them with too much too fast, you will tend to provoke worries or exhaustion.
That being said, making 3 issue reports when the repo had only 1 besides that doesn't seem like a problem. Developers do like to feel like their work is getting some attention.
So, this is probably a cultural issue.
Have you tried heading this off by apologizing first, in the report? Alternately, being thankful in the report may work out better. Or you can try both.
Note that mirroring like this can come across as sarcasm or ridicule if you recycle their exact phrasing or exaggerate it, so don't do that.
The term "GitHub" appears nine times on that page. One way to resolve this problem, if it is a problem for you, is to not use GitHub. If you use a tool that was designed to incentivize exactly the scenario described in this article, you shouldn't be surprised when that scenario is realized.
Post your code in another form, such as on a website as source.zip. If this doesn't work - often because the developer feels there are personal benefits to being the maintainer of a highly visible project - I'm less sympathetic. Even releasing your project on GH with a readme that says you're posting your code but don't have time to deal with issues will solve the problem.
The real problem is buried within the text: "Failing to handle it directly affects your online reputation." That is the motivation for the project. This person wants to enhance their online reputation (for whatever personal reasons). This is all fine if that's your thing, but online reputation doesn't come for free, just like a YouTube channel with 100k subscribers doesn't come for free.
I wouldn't expect people to read that. The real issue, I think, is still that many fail to understand that open source software is free, in multiple ways.
The worst of the examples in the article is the: "We are waiting for a solution". If you pick open source software for critical infrastructure, then you need to be prepared to provide solutions for your own problems. Sometimes that means fixing stuff yourself, sometimes it means paying external developers to do it for you. People/companies forget that part.
The OpenBSD approach of just shutting down request with a the comment: "Show us the code." is a little hard, but not unreasonable.
I feel as if many have not been exposed to this approach and without questioning it buy the concept of your open source projects being advertising for you as an individual and that lest you provide support for each operating system (and their many versions…), etc. you are unworthy of the honour of giving away your labour of love free of charge and deserve to be scorned publicly. Maybe this is because I entered the community in the early 2000s and things were “different” back then, but I have never understood this perspective. Did it rise to dominance with the likes of GitHub? Note that I am not suggesting that GitHub et al. are a “source of evil” here.
OpenBSD is an operating system made by its developers for its developers. If you can not “handle” Theo [1], dislike the fact that there is for example no Bluetooth stack because they were happy with the code quality, or zero tolerance for binary blobs, it is perfectly fine! Want the codebase to steer a new course? Fork it! Want something else? I am sure there are other communities out there better aligned with your goals and maybe they are open source ones too? “It does not work” or “We are waiting for a solution” is to me akin to marching down to your local volunteer orchestra and insisting on them changing their repertoire or perhaps incorporating your accordion this very moment or you will throw a tantrum. It is silly, it is childish, and it frankly pretty much deserve the response that people that behave like this get from the OpenBSD community.
[1]: https://en.wikiquote.org/wiki/Theo_de_Raadt
“Why are you guys so fork paranoid? Do you want everyone to vote for the same political party, too?” – Theo de Raadt
Perhaps it's the understanding that projects like Apache and Linux came from a large community of people, and companies, who all fix bugs they cared about, or implemented features that they need. If someone else could benefit from the work you where going to do anyway, then that's wonderful, but it's was something you did because you needed it.
HTTP 402 Pay me
My favorite in recent history was a developer (who had never made any contributions to the repo, nor even filed the original issue) saying something to the effect of "if this issue is not resolved shortly, we will move our company to use a different software." Talk about threatening the maintainers with a good time.
(It often doesn’t work for either.)
I was talking generally about JavaScript and another dev who likes to surf the web without JS enabled (more power to him) mentioned how in a given case there's no reason to use JS. I mentioned a side project that I felt kinda fit that use case (in a way). This is an entirely a casual project that has no intent to do much other than explore something myself and uses JavaScript, if folks like it, that's cool, it's free.
I got litany of reasons that person would NEVER use my product that sounded a lot like an angry customer rant.
Entirely free service, and I got a rant for it ;)
I suspect your misunderstanding there is some misplaced assumption that "developers" are some sort of tribe who respect and look out for each other.
It's easy to exist in a small "developer tribe" bubble where that's true, but there's a universe full of "unpassionate devs" just scrabbling to get project managers or bosses off their backs, and who'll cut-n-paste from StackOverflow answers and harass open source maintainers just to get their next Jira ticket completed before whatever arbitrary time estimate/deadline has been imposed on them.
Granted years ago I once worked at a call center and a coworker, just after complaining that they just got yelled at by customer for something they didn't do and couldn't change, placed a personal call to a local pizza place, and did the same thing to them.
Bummer to see.
I'm not always sure I wouldn't rather be the second kind...
No problem, there are other software projects that achieve similar goals to this one such as $ExpensiveOption from Microsoft or $outrageousLicenceClauses from Oracle - perhaps their support services are more in line with your company's expectations? Good luck, have a nice day...
Ideally the complainer will see how positive the developer is being and reflect on their own attitude, but even if they don't, it gives a good image to other people who read the messages and sets expectations for how people should behave, so that a project doesn't devolve into toxicity.
Sarcasm is easy to disguise in pure text communication.
Back in the day when I spent as much time on comp.lang.perl.misc and scarydevilmonastery as I do in HN these days, that sentiment was less ambiguously delivered as "HTH, HAND, FOAD"
My response was "So if I follow your demands you'll stick around and maybe demand more, of I tell you to get stuffed you'll go away and bother someone else? In that case: feel free to get stuffed."
Some just went away, I got one "I'll make it so you'll never work in the industry again!", and one started to beg profusely that I implement what he wanted because he would lose his job without it (not sure how that worked, I assume completely made up, didn't care either way).
Of course that was long before current social media outlets made it relatively easy to create a made up shit-storm, I might be a bit more diplomatic (but no less definite) in the same position these days.
Most of the time is not on purpose. Thinking how something should work (or using it once done) is way easier than doing it(hundreds or thousand times easier actually), so the only person that really knows how much effort something takes is the person doing it.
Because they don't know how much something takes, they don't value it. Specially if it is given for free.
"The only people entitled to say how open source 'ought' to work are people who run projects, and the scope of their entitlement extends only to their own projects.
Just because someone open sources something does not imply they owe the world a change in their status, focus and effort (...)
As a user of something open source you are not thereby entitled to anything at all. You are not entitled to contribute. You are not entitled to features. You are not entitled to the attention of others. You are not entitled to having value attached to your complaints. You are not entitled to this explanation.
If you have expectations (of others) that aren't being met, those expectations are your own responsibility. You are responsible for your own needs. If you want things, make them."
Emphasis mine:
** If you want things, make them **
From "Open source is not about you" https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
Another one that I highly recommend is "Open Source Is Free As in Baby", with quotes like:
> I think of someone releasing open source software as a gift to the world, not as claiming a responsibility to maintain it for you. Some projects do claim that responsibility, but it’s not automatically conferred just because someone released a project on GitHub. I think much more of the responsibility falls on the person using it. It’s your code that will be using it, your code that will need to be upgraded, and your code that will break.
In that sense, I advocate documenting your response policy on the top of your README.
If I don't have the right to fork off, then it wouldn't be open source at all. And that might seem like a small thing, but it is a lot more than I get from e.g MS. Otherwise I would still be running WinXP.
Not only must the code be well organized, run perfectly, and handle all users needs; I myself must be of proper moral character, never have publicly uttered words that could be considered objectionable, and fully willing to endorse the fashionable fascism of the day.
... I don't buy it. I think that "hey this solves my problem" is viable and code doesn't carry the stain of its creators. We don't need to know or care who wrote our favorite text editor, they might be wonderful people or they might be gnarly gnomes dripping ichor; "here's the tool, it works" is sufficient knowledge to judge the tool.
"Any suggestions are welcome, but I won't promise I'll implement them :-)" -- Linus Benedict Torvalds 25 Aug 1991
Your sentiment is increasingly common. However, Hans Reiser's conviction for first degree murder of his wife has not eliminated his name from various filesystem projects, let alone caused the code to vanish, so maybe there should be a bit of cognitive dissonance there?
But more importantly, the story of Hans and Nina Reiser is of the kind that the various forms of fashionable fascism over the past two decades did not find interesting. It's not the act that makes people make other people remove references from software projects - it's how the act ties into current hot topics.
Possible alternative hypotheses I'd consider to your logic - maybe people don't care because it's old news? Maybe people just think of the comedian when they hear the name? Maybe people do care and it just hasn't hit HN?
My impression is that ReiserFS was just sort of gently dropped due to disuse, disinterest and lack of maintenance. That's about what I'd expect - nobody wants to touch it, but nobody expects anyone to signal their disgust either, because it's not in doubt.
I haven't been paying attention but it looks like it was followed up with Reiser4 and Reiser5?
https://en.wikipedia.org/wiki/Reiser4
https://www.phoronix.com/scan.php?page=news_item&px=Reiser5-...
Reiser5 surprises me though. I didn't expect it to be that uncontroversial. Guess CW topics have skewed my perception.
People mostly get cancelled by committing the latest heresy.
I’ve maintained a lot of (reasonably popular) open source projects, and the ones I supported I do so because I wanted people to use them. Offering a quality product is part of that, and I was willing to dedicate my time and effort to it because I wanted that success from it.
The difficulty with open source is not so much in doing this, but in scaling it. Unlike commercial (i.e. paid) projects, there’s no built-in incentive that really scales with usage. Once you get past the point of “I made something people want to use”, it easily becomes a victim of its own success, and it can become overwhelming to deal with. Your best hopes are either that you find a business model (if you even want to!) or find people willing to help in the community.
But nothing stops you from creating projects that you don’t want to support. I throw tonnes of code out there (particularly since writing it isn’t my primary job anymore) with fairly explicit disclaimers that I’m not going to support it, and I think the article’s advice on this is pretty good. You need to be willing to say no sometimes.
I find it’s best to know which sort of project you’re creating going into it, and try to communicate this clearly to your users but also to yourself.
People used to glance over codes of conduct (as in RTFM first, post on such channel, and other practical stuff like that, not like the ones projects are creating today) before contributing, and did so with the intention of interacting for a while.
Projects always tried to remove barriers for casual collaboration, but nobody managed to remove the long-term nature of it before. Now, well, too much of a good thing stops being good. Github finally fully succeeded, and this may be the main reason to abandon the platform.
One thing that worked pretty well for me was to move to Gitlab. Very few people currently bother to create an account on another website to report an issue, and as a result the quality of feedback and reporting has always been very high. Gitlab has also less gamification, which helps in keeping project popularity from skyrocketing just due to stars and network effects instead of actual project merits.
I initially moved a single project when GH was acquired by Microsoft. GH/GL are totally equivalent for me, but due to this I ended up moving all my public projects and never looked back.
Nah, you can totally say that you don't care, you just gotta phrase it right. "Sorry, we have no plans to support that use case." Or -- if you don't mind leaving the issue open -- "I don't think fixing this is a priority right now, but feel free to submit a PR yourself!"
Really, it just sounds to me like the person writing this hadn't yet learned how to say no. Going by the end, they've since gotten better at this, so good for them. But the point is, there absolutely are polite ways to convey that you have no interest in solving a particular problem.
If someone promotes something that doesn't work, they can expect the feedback you have described.
Many developers suffer from lack of empathy: they can't understand how their work will look to others, and, if there is documentation, it doesn't answer the obvious questions others will ask. Fine, so long as they don't waste my time with self-promotion of something that they are unable to see through the eyes of others.
The negativity is fair payback for my wasted time getting sucked into something that the developer falsely promoted as fit for some purpose.
Here is my stupid proposal: If you (the company or person or team) do not want to devote serious time to maintaining your project, take it off the package manager listing. Let's try at least keep the package managers with sane, up to date and maintained projects. What often happens (especially with old languages or god forbid languages which had breaking changes) is that most of the things you find is no longer maintained and worked at some point on some older version of the language/framework. As language evolves and matures, the original package manager listing if more and more full with things which no longer work. This is horrible experience. Can we agree to keep the package manager up to date and have a simple mechanism to have the hobby projects sideloaded directly from github
I am totally ok with you no longer wanting to support something but please do not take our time. This is especially a problem where people chose a hobby project whose scope is way too big for them and it's impossible for a single person to maintain it. Could you please split it up into multiple projects and try to finish at least a part of it?
We are all wasting each other's time and feeling horrible at the same time
[1] https://docs.github.com/en/github/managing-your-work-on-gith...
- The unforgeable "WHERE HAVE YOU BEEN ALL MY LIFE" https://news.ycombinator.com/item?id=18295453 - my all time favourite comment that I don't stop mentioning when telling the story of my project, and that always makes my heart go warm.
- The pure "Just wanted to give you a thumbs up!" 'issue' - no strings attached, no "but [could you do this or this for me]"... https://github.com/akavel/up/issues/14 - plus, for some bonus love, a few follow-ups from other wonderful people... not even counting the people expressing their appreciation via the emoticons...
- A person came back a couple years later and said, they use and like my tool so much, they decided in act of gratitude to give me not one but three logo sketches that I could choose from; then they had enough patience to bear my pickiness until I fortunately finally came back to senses and took the first one of the sketches, which was IMO the best one from the beginning. https://github.com/akavel/up/issues/48
I still would say "yes, and no..." by which I mean, I'm still tired of this project enough that I can't muster strength to get back to it... sure, there were bug reports, and honestly, I understand and appreciate... I would open them too, and I treat them with respect... as I feel treated too (though also I have the fortune to be able to ignore or shut down occasional stupidity or demands). Yet I am still tired and drained of energy for now for this project. I sometimes muster a bit of it and improve some small parts. Sometimes. Maybe some day I'll get enough energy to again put more work in it. To finish some neglected PRs in need of love. So, as much as random demands can be part of the stress, and certainly don't make things easier, especially for some creators; as much as this, I think there must be also other psychological factors at play.
Did you ever get a Mac? I see from the page that it's now in Homebrew.
Holy shit, this is awesome. Thanks for sharing!
However, I've always been curious - what motivates people to continue to maintain open source software?
Why put up with rude people and improve a package for them, for free? Is the issue because monetizing it is too difficult? Or is there some other reward for doing this that I'm not seeing?
For projects I lose interest in, I unsubscribe from everything and either mark the project as maintenance mode or try to find a maintainer. To find maintainers, I've had good success granting write access to anyone who lands a few good PRs and telling them they have free reign over the code.
Also, there should be more ways to "praise" a project.
What would you change to make that happen?
Keep issues separate from the repos but allow tagging the repos in the ticket. Would allow multiple projects to get associated with one ticket. Community owned issues, a bit like stack overflow.
GitHub projects are structured from the url to give the idea of total ownership by the the author of all the tabs of the project. So the issue tracker looks like it is "owned" by the author. Perhaps the author could choose to disown the tracker related to the project in some way. And then they could choose to own individual issues. Opt in instead of opt out and close.
Maybe github should implement a "feedback" tab where people can post their experiences of using the project. Perhaps some of those experiences would be negative too, but it would also allow people to give you neutral or positive feedback on what they like about the project, how they are using it, and what they have achieved with it.
Why are your errors useless?
Or sometimes it's just more practical to have that information given to you than spend hours REing it.
It usually takes me one or two days of back-and-forth to get the basic set of information to be even able to diagnose a problem. And this is with people that I've worked with for years, and have hammered and hammered on the kind of details I need, and have even built features to collect all the diagnostics with a single click...
I wish more people saw documentation and source code as a gift rather than cause for free, on-demand support.
But it goes both ways. Bug reports and feature requests are gifts that you and your corporation receive from the software's users.
My experience is clearly different from the author's, who seems to have complaints about solo project maintenance. I just wanted to share my perspective.
I'm glad articles like this exist and are getting shared around. Maybe more maintainers will start with a healthy attitude of "I'm not going to address every issue." Maybe we'll get a technical solution... Make it possible to close all channels? Find ways to encourage satisfied users to leave positive feedback? Buttons to close an issue with "Sorry, but I don't have time to provide support for free, but feel free to contribute your own solution to the project!" or "This might not be related to the software and I don't have time to address it, advise doing more research on your own."?
Most people dislike getting tons of negative unconstructive feedback on something they put effort and love into. Detachment can easily turn into indifference about the project itself. That's not even getting into the more aggressive feedback that some people will casually throw at you if you tell them no.
As an engineer if you leave a manhole cover open and people fall down, it is your responsibility. If you leave your code incomplete, people will discover your bugs.
When I was young I made that mistake: Leaving too much code to document and open that we had no time to make perfect(it was impossible,there was no physical time on our entire life for that).
Today we create a library, and a program with limited functionality but PERFECT and make people shooting on their feet impossible(limiting the functionality too). Very few things to document. It works as it should.
I learned that from Steve Jobs "saying no to things". Deciding who is your customer, deciding what is your problem is essential.
People don't want to do that. They don't want to select a customer and make a decision that could be wrong. So they leave it open.
In an OSS project, you can just provide it as-is without any kind of warranty and clearly tell this in the license.
Maybe you are confusing OSS with actual paid work and paid software (services)?
Of course sometimes the business has OSS components that customers expect to have a certain quality but still... nobody is obliged to work for free, especially if the end user is a for-profit corporation.
Yes, people file bugs, but I want to hear about the bugs so I can fix them. They're always polite, often file PRs and fix the bugs themselves, and always thank me in the end and I thank them back.
I've either never had a rude/demanding user, or don't remember one if I did. Is it because I mostly write developer libraries? Is it end users that are terrible?
Even one of the most permissive and popular open source software license, MIT, states:
"IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE."
You can write, in a file linked you README.md (e.g. CONTRIBUTION.md, github issue is a contribution instead of a request after all) that all contributions in the form of github issues must ticks a certain criteria in order to be prioritized, e.g. issues title must be specific in describing the problem, issues with proposed solution will prioritized, etc.
Also, for the article author, thank you for making an effort to help. To help others solve problems you have encountered and triumphed over is a very generous gesture.
then I looked at his biggest project, libsodium, and this is the second most recent bug
https://github.com/jedisct1/libsodium/issues/1038
```
invalid usage on desktop chrome when running crypto_pwhash
Error: invalid usage
at h (sodium.js:formatted:17589)
at Object.qA [as crypto_pwhash] (sodium.js:formatted:19328)
```
(this is the whole issue, no more information provided.)
OK I feel the author now.
My rule of thumb is not to pick up random open source projects unless I am confident they have a stable user base and some active maintenance. I may take code from a random open source project if I understand it well, but I'm not going to rely on some packaged solution unless I know that their is some community behind it.
FWIW, when I find a tool that I really like, or that solves a problem I'm having, I try to send the maintainer a (very) short email. Something like:
> Hi $person, just wanted to say thanks for writing and maintaining $tool. I just used it for $purpose, and it worked really well!
Sometimes I get a reply, but I don't expect one. I don't want to add clutter or be a burden to someone who probably gets a lot of email, but hopefully this can be a nice gesture to counter the endless onslaught of bug reports and complaints.
As a counterpoint, I'd never wish to see such comments made in GitHub issues for my projects. To me it's just spam. I also feel really awkward replying to such comments. A bug report (if it is an actual bug) is however welcome to me, because it lets me see that there is an issue in something I wrote. The first time someone filed a bug against my program (not a thank you, but an actual bug report), I was really happy that someone made the effort to let me know about a flaw in my insignificant creation.
That said, when the volume of tickets filed on the bug tracker is big enough, I'd consider having the bug tracker open only for paying users. Handling those tickets is real work and the author is entitled to payment for it when someone demands it. Doing it right from the start regardless of volume is also totally reasonable.
Alternatively, the author may decide that they just don't care about bug reports from others. In this case, GitHub doesn't seem to be the best platform for their project. A basic cgit instance should suffice or a tarball on a website - no place to file bugs.
From yet another perspective, when I want to contribute to a project, I outline on the bug tracker a potential contribution, ask whether that would be welcome, if I should start working on it or maybe there are some changes needed, and then I don't get any kind of response for months, it's off-putting. A "no", "I don't care" or "I don't have time for it" would suffice. It's comparable to ghosting in the world of dating. Just say "no" and everyone will be better for it.
Absolutely. It's hard to explain this. I maintain a mildly popular open source project. There's a strange dread when I think of reading my Github notifications. An issue or question influences my mood for the entire day. I can only imagine what maintainers of popular open source project go through.
I don't agree with this part. An issue should stay open _until it is resolved_. A timeout is not a resolution. It is extremely disappointing from the issue author's perspective to see their issue closed without any feedback from the developer. The developer should either provide a solution, or manually close the issue with a specified reason, e.g. "wontfix", so at least the issue author knows what to expect.
Just recently I reached out to a maintainer on Gitter and offered $600 for something that would’ve taken an hour of their time or less (I know that because I eventually solved it myself). The maintainer didn’t take me up on the offer which isn’t a big deal, but it’s just a miss opportunity overall. I’m sure someone could’ve help, there just isn’t a system in place to pay for casual help.
One thing helps a lot: you don't owe "them" anything, also when working on proprietary code inside corporations. Don't feel like looking at it? Just ignore the bug report. Literally - don't even read the report.
(If you haven't shuffled through hundreds of poorly formulated issues you may not realize just how much effort that is).
Presumably this is what product management is supposed to function and give attention to, isn’t it-at least to an extent? Or have I misunderstood what those staffers do?
Seems lately I’ve seen developers frustrated about this because they want to be developers, but the company wants them to be everything and anything more (sometimes, maybe often-times because of poor resource allocation/chronic understaffing on the part of the business) from triaging feature builds to project managing entire releases.
Maybe I’ve worked at shitty companies.
In fact...now that I think about it.......
Yeah, I've fielded quite a few internal bug reports that amount to "it doesn't work". My stock response is becoming "what is the symptom you're actually experiencing when you say 'it doesn't work'?"; that usually gets more information.
(The internal ones are perhaps worse, as you are beholden to respond to them, since it's from a coworker.)
I maintain an R package, an API wrapper for a popular electronic data capture framework, which was peer-reviewed by rOpenSci (https://ropensci.org/). They put extreme care into making software as accessible and inclusive as possible, which I like a lot. Especially the rOpenSci community (see their CoC (https://ropensci.org/code-of-conduct/)) is full of considerate, caring human beings. One could call them the Anti-SO.
Through the peer review process, community requests and GH issues, there's probably a year's worth of spit-polishing added on top of the "works for me" level. This is my first publicly used software package, so I'm taking this as a learning curve and I'm bending over backwards to making this package as inviting and usable as possible. I get away with this as I'm a public servant and paid to deliver value to the general public. And I must say, every improvement over my initial "good enough" version has paid off against the main project I'm using this package for.
So my experience with this tiny, niche, package is overwhelmingly positive. I blame the audience - R programmers, rOpenSci members, and members of the community of the software I'm API-wrapping, which all are stressed out researchers grateful for help. These communities have also a good code of conduct. Maybe also issue templates with friendly guidance to give me very precise feedback (and the advice to take common sense over my guidance) help. Maybe they also repel low effort "could you please do my homework for me" queries.
Thanks for the hard work boys and girls! You set an example of how the world should work.
Thanks!
Thanks!
Thanks!
— a setting to allow PRs but only if they already pass all tests & linting (using a Dockerfile supplied by the source repo). You're PR doesn't show up on the radar for the maintainer until it's already some way mergeable (and you can't edit the build agent).
— allowing issues only in the form of a PR with a new failing test case (again, ran through the pipeline created by the maintainer). Also, allowing a repo maintainer to have required fields in an issue form rather than having a template that may or may not get followed.
— some type of settings that maintainers can turn on to enable "Kudos" or thank you posts, separate to the issue tracker.
Maintainers could ask for/enforce all of those things at the moment manually, but it's putting all the friction onto their plate (rather than the people offering fly-by criticism).
Most of the time OSS libraries are completely free and provided as-is without warranties of any kind. Still people act as if they were a customer who has signed an SLA with the maintainers.
It's OSS, fix it yourself. Or pay someone real money to fix it. Or just buy a SaaS version or paid library. Or DIY.
Why would anyone be obliged to work for free for you?
(yes, some businesses have an OSS product, it changes things a little bit but even still it's as-is without any warranties)
Having a couple of projects on gitlab, with proprietary naugthiness like issue trackers duly disabled, I don't think any human, entitled or not, has noticed them. It's a quiet life at the end of the long tail.
Even in actual businesses, people are generally too eager to follow the "customer is always right" mantra, rather than getting rid of bad customers that generate more work and stress than they are worth.
Using your software is lending you reputation, power, and influence. In high profile projects, this mindshare is more valuable. If your software would be unreliable, the trust and reputation would be misplaced.
For example, if an update script in a major "stable" distribution would clobber user data, the tone in these comments might be justified. But mostly, this is bad form.
Seems straightforward for a lot of what this post is about.
Make it very clear in the README and give a paid option to offer paid customer service. No need to stress.
To be frank, that sounds like an addiction.
It takes literally zero effort to just ignore the complaints. Let them complain all they want. You don't have to care about them.
It doesn't apply to everyone but I can see how to some people this would be really problematic.
For every company which does that, there's another whole bunch of companies who would rather prefer you not have a GH account.