About six months ago, I stumbled across a Github repository with zero stars, called Chromium Legacy (https://github.com/blueboxd/chromium-legacy). A seemingly-unknown Github account, with no profile and no other notable projects, had single-handedly backported Chromium Canary to work on very old versions of OS X, alongside an automated build system to keep everything up-to-date. Due to my interests, I was delighted!
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.
I think you should continue opening issues for bugs you find and try not to feel guilty about it. I know I'm personally delighted when someone opens an issue on any of my repositories with a similar amount of care you seem to put into your reports. The maintainer you're reporting to likely appreciates you and wants to continue discovering bugs and fixing them (you can always just outright ask if you're unsure).
> 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.
Be polite and unexpecting of any fix and do all you can in the report to make it easy to fix and you’ll be appreciated (even if just by others who find your report).
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.
Why not ask him? Maybe give him a call? You have already spent lots of time “together”. You are de facto some kind of companions. I’d definitely be delighted. Mostly it’s me reaching out to users.
> If it was me, I'd just be happy that someone else is using the code I wrote!
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... so I don't quite know what to do.
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.
I think pacing yourself can be important. Sometimes it does help to hold off on that request till the next day.
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.
> I take a quick glance at my GitHub notifications via Octobox
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.
> 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.
My introduction to open source software was in the early 2000s as well, and I think you're right in that things where somehow different.
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.
"It doesn't work" issues are bad for all the reasons described in the article, but the ones that really boggle the mind are the _demands_ people think they can make of maintainers they have zero leverage over.
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.
Last time I had some free software actively out there, I got that several times.
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.
It shouldn't, but it amazes me that developers will do this to other developers.
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.
> It shouldn't, but it amazes me that developers will do this to other developers.
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.
I think it is more that I would hope that folks who have an unfair or just not fun thing happen to them, wouldn't do the exact same thing to others in almost identical situation.
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.
> "if this issue is not resolved shortly, we will move our company to use a different software."
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...
I really respect this way of dealing with unreasonable complaints. I guess the term for this is "killing them with kindness", and it's much more healthy than escalating things with a rant about how "entitled" the complainer is.
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.
I'm glad you took the face-value interpretation there.
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"
Most people in most teams are pissed off, their projects are behind, and their software is a mess. No one in a well-functioning, high-morale team would write something like that. In such scenarios, people pursue greedy-like algorithms for any short term reprieve they can get. Coming from a place like that, maybe making a mild threat seems like a good idea at the time.
Many people use the same methods for commercial software and open source — and think threatening to move their non-existent purchases elsewhere will light a fire under someone.
Your 50-person company is not going to move the needle on $BigCo's bottom line if you cancel because $BigSoftware doesn't have such-and-such a feature. And also, where you gonna go? Take a few months and migrate everything to $OtherBigCo, then do it again when you find out their product also isn't perfect and they also won't dedicate a dev team exclusively to you?
You train them. If you let people take advantage of you, they will take advantage of you, of course.
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."
The essay you shared, "Open Source is Not About You", is excellent.
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.
I do think there is an obligation, but it's one of expectation management. If you have an issue tracker, it affords filing issues - then there is some expectation that those issues will be looked at. If you're visibly giving people an opportunity to talk to you, and then don't respond, that's rude.
In that sense, I advocate documenting your response policy on the top of your README.
>As a user of something open source you are not thereby entitled to anything at all.
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.
it's a weird bouncing effect that open-source was a way to unlease more collaboration by sharing the source but it turned into a MMO-feature-request tsunami.
20 years ago, when I shared some code with the world, because it worked for me and i hoped others might benefit from it; that was all i was doing. Today, it seems, there's implied responsibilities to your users in that situation.
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.
>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.
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?
Yeah but that's not a controversy - because nobody is defending him. So ironically it's "safer." If someone is a controversial figure, you can score points and grab attention and praise by removing their code from your project. If someone is uncontroversial - even uncontroversially bad - what are you indicating that way? That you, too, frown on murder?
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.
...yet. It persisted as an awkward anecdote in the industry.
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.
The story seems to me very easily tied into current hot topics - I'm not going to regurgitate the details which are on Wikipedia, but they are pretty disturbing and link to some key themes for MeToo.
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?
I couldn't agree more. If I ever decided to make any of my work public, it would be under "Good luck with that" license (https://github.com/me-shaon/GLWTPL)
I feel like more and more developers are opting for the second form. I'm reminded of litestream (https://github.com/benbjohnson/litestream) for example that is closed to contribution
Github is adding the discussions feature, which adds a sort-of forum to repos (needs to be enabled)
(although generally a "just wanted to say thanks" "issue" is also well-received, even if thats not what issues are for. Or reaching out through any other channel, if the dev advertises one)
You’re under no obligation to offer support for your projects, but vice versa is also true: no one’s under any obligation to use them.
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.
We lost something when we centralized collaborative development and made it look like a social network (with even gamified activities).
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.
This is a result of the popularity of Github. Low barriers are good, but as a result of this you're getting also inexperienced/low-effort people alongside the rest. And they're the majority. Github is so popular that it has become almost a one-stop shop for some users, while explicitly _not_ catering to non-technical users at all.
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.
That would be a pretty easy thing for GitHub to fix, just add a prominent banner about reading the code of conduct files for the repo before sending issues/etc. Could you file a support request?
Github is far from just a git repository. It's a ticket tracking system, a discussion system, a release binaries host, a CI/CD component and a pastebin. The linux kernel has no CI/CD, no binaries, it doesn't even have a centralized server (only a copy of Linus' tree) and does everything through mailing lists.
Well, if you want all of those things in one place, then that means github, practically by definition. But the example of the kernel shows that open source can carry on, on a massive scale, with no need for that.
GitLab also has all of these features, and it had many of them before GitHub, like built-in CI/CD. But for some reason I'm being downvoted for suggesting it on HN, curious why.
> “I don’t know” and “I don’t care” would be honest answers. The former is not a valid justification for closing the issue. The latter would backfire.
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 posts something on GitHub, I will appreciate it for what it is, whether it "works" or not. Maybe I will adapt it to my needs. Maybe I will open an issue. Whatever.
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.
The problem is that expectations are not communicated correctly. There are projects with devoted maintainers and there are projects where someone did something one time.
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
Exactly. I think a few people have called for Github to allow disabling PRs and Issues, but considering that it would destroy their business model, I don't think it'll happen. Oh well, there's always Sourceforge.
Hm; and yes, and no... in my case at least, I personally remember having more of those others - and for which I'm super grateful, they mean A LOT to me - i.e. the likes of, literally:
- 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.
I've benefited tremendously from open source software and have used an open source library in virtually every project I've done. Totally grateful to the community for enabling me to build faster.
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?
My initial motivation for my (small) projects was always to scratch my own itch. Beyond that, it feels really good when someone else uses the code. For my current side-project, I keep up maintenance because it's interesting work and because I can plausibly benefit from bug fixes. It's neat to see how other people adapt the code and open up new use-cases. For that reason, I love high-quality bug reports and treat them with some urgency.
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.
Rude people are rare. If your project is big, most users of it never even interact with the issue tracker. A desire to help those and provide something in return for OSS tools you use yourself.
I feel that the way that GitHub and others do social coding is a bit backwards in regards to this article. Issues shouldn't implicitly be owned by the owner of the repo but by the reporter. The reporter cares about the problem. The issue tracker should be a way to find others who care about the same problem. If the repo owner doesn't care they should feel no obligation. But the way the issue trackers are structured those issues implicitly becomes the repo maintainers problem.
Also, there should be more ways to "praise" a project.
I don't have a "good" solution in mind but perhaps some partial solutions off the top of my head:
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.
>Also, there should be more ways to "praise" a project.
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.
The thing that bothers me the most are the users of your code that are not able to create a reproducible test case and instead post a useless error without the conditions that led to it. Bonus points for the laziest bug reporters with a screen shot of the error with a red circle painted around it - like that "emphasis" would help. Seriously, the programming profession cannot be taken seriously when the vast majority of github users cannot make a proper bug report. They cannot place themselves in your shoes and ask themselves "What would I need to solve this problem if I were running the project?". No amount of issue template creation will help - they won't read it anyway and erase the template.
If you get a screenshot, you're doing better than I typically am with my paying customers. It's usually not more than a vague two sentence email, and a meeting invite for 7:30 AM sent at 3 AM my time...
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...
It's impossible to fully print out the environment and state of the program. There's an infinity of combinations of hardware and software a user may have. Also, different mistakes may lead to the same error. This is a reality since it's impossible to predict every error state in a program of any complexity.
Or sometimes it's just more practical to have that information given to you than spend hours REing it.
You're mostly correct, but I was poking at the fact that a tremendous amount of software has errors akin to "Something happened (0xcafebabe)" with all the documentation hidden. Error messages common in the industry are the reason most don't bother reading them - they're useless, unactionable and vague.
As a maintainer for an open source repo that is "owned" by a big corporation I feel this but on both ends. I empathize with reporters and I would love to be able to help them all (when sufficiently detailed reports come in) but the reality is that simply ingesting the issue and queueing for prioritization still means it'll likely sit for many months before someone gets to it. I suppose my point is that whether you're running an open source repo for a personal project or for a corporation, the problems persist.
I wish more people saw documentation and source code as a gift rather than cause for free, on-demand support.
Maybe whenever you navigate to the repo of an open-source project, GitHub should have a fancy animation of a gift box opening. "Ta-da! This project is open-source and FREE for you to use AS-IS, without any guarantees!" Then they can play it three more times whenever you try to open an issue.
If only it was that simple. But obviously the corporation has an incentive in open source as most do. There is pressure to present as open but internally the priority is not on reported issues, unless they are security related or something is broken.
Of course! It's the way users can alert us to issues and provide feedback. That's why I feel stuck in the middle -- overwhelmed from the incoming issues and unable to move the needle by myself or with whatever support were allocated from corporate.
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.
Man. I can't help but feel like some stories like this are caused entirely by pressure that the project maintainer is putting on themselves. Like the solution in this article was, "Finally, I learned to say no..." But maybe I would be the same way, diving deep into some obscure issue out of a sense of obligation to fix the thing I built and made available for others to use, and not realizing how much it was affecting me until reaching a breaking point.
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."?
>I can't help but feel like some stories like this are caused entirely by pressure that the project maintainer is putting on themselves.
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.
Yeah, the more I think about it, the more I can understand that. Something is needed to prioritize and filter the queue of issues without causing too much detachment on the maintainer's part.
I feel the generally remote or solo work of open source developers makes it even harder. I talked to the customer support people at work and it's the shared team bonds that keep them from burning out. They can commiserate and provide mutual emotional support if a bad customer berates one of them. They can share and reinforce positive comments amongst each other to lift morale. That is all much harder for most open source projects.
In some way it is self inflicted damage. Remember Murphy was an engineer, and "if you let something go wrong, it will go wrong" means as an engineer it is your responsibility not letting people shoot their feet, because if you do, they will(and blame you).
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.
> As an engineer if you leave a manhole cover open and people fall down, it is your responsibility.
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.
I created and/or maintain various semi-popular open source projects (please join codeshelter.co!) and I always feel like I'm in a different universe from people like the author here.
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?
It is never the author's responsibility to provide support, unless somehow a contract is formed and agreed upon beforehand.
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.
While I know the maintainer of an open source project has no real obligations to random developers, I have also spent a lot of time struggling with getting open source projects to work as advertised in the documentation. So I can understand the frustrations that users might have. But that is a reason to be careful in the projects you use, not to harass the developers.
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.
I think that third option is my primary one. For small dependencies I'll often use code by copying the relevant source into my project with links back to the original source. It forces me to understand the code base better. Usually I find I can fix the issue. _Sometimes_ i contribute it back.
Contributing code back is tricky for a lot of the same reasons that leaving your open source repo's issue track open is...fwiw I don't use code with licenses that require contributing back.
> “Thank you, this is exactly what I needed” would be a heartwarming thing to read, but you will never see such a comment ever.
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.
> The issue tracker may quickly start to fill in. “Thank you, this is exactly what I needed” would be a heartwarming thing to read, but you will never see such a comment ever.
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.
> However, what is often overlooked is the psychological impact this can have.
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.
> After 30 days of inactivity, issues are closed with a timeout label. If there hasn’t been any activity for that long, it is unlikely that leaving the ticket open is going to change anything. Maybe it was a feature request that no one is interested in implementing. Maybe the reporter was asked for details but is never going to provide them. Maybe nobody knows how to answer the question or what it even means.
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.
The article explains exactly about how a growing list of issues, with every ticket needing time and effort to figure out is bad for their mental health. Then your response is: "no, every ticket should stay open until it gets a response"? That is the exact mindset that drove the original author to tears.
Doesn’t sound like a bad way to weed out less important work. If an inactive issue is closed an nobody cares: good, that’s the intention. If someone does care enough to re-open/open a new issue: no harm done, and maintainers have clear signal that someone still cares.
For personal spare time projects, the only way it won't spiral into what's described at the top of this post is if the burden for making an issue useful is on the reporter, not the author. There's one author and millions of possible users.
The problem really is that it’s difficult to get help on open source projects. When I’m using a piece of free software that doesn’t do what I want it to do, I’m happy to pay anywhere from 15 mins to several hours of someone’s time to help me fix it. I’d rather pay for an hour of your time than to wrestle with the problem for 8 hours.
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.
To be fair, software in general is a complete shit show. The amount of things that don’t “just work” are staggering. Then we built 10 or 20 shaky layers of abstraction, one upon the other, until we ended up with the computing landscape of 2021. I tried gettin a Radeon driver to work on a laptop running ubuntu recently. What a disaster. Getting stuck in dependency hell, strange compiler errors, seg faults. Bleh. I gave up after 3 days of messing with it. Sadly this is a very common experience. It was more economical to just buy a macbook and move on with my life. So I do feel bad for this guy and see where he is coming from. But software and the ecosystems around them are just so bad.
It's hard to imagine rolling into a car shop and telling the mechanic that your car "doesn't work", leave it at that and have him try to figure it out. Most people would at least try to describe the symptoms of what is going wrong, even if they don't understand a lot about cars. Imagine if the person who tells you "it doesn't work" is also a mechanic.
"CEL" being "Check engine light"? As a customer, if that light comes on, but the car is otherwise fine, what exactly am I supposed to do apart from take it to the shop?
Very real, also within corporations in proprietary code.
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).
Don't feel like looking at it? Just ignore the bug report. Literally - don't even read the report.
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.
> Very real, also within corporations in proprietary code.
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.)
More broadly: always set boundaries for yourself. You may not have a choice to ignore the bug in a corporate setting, but you need to be willing to kick issues back to the originator for lack of information and /or lack of willingness on their part to help isolate a way to reproduce the problem.
I've experienced this from the opposite side (positive feedback) and wanted to share that the tone and structure of the rOpenSci community seem to foster positive feedback and community interactions.
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.
Github and SO are the infinite source of good stuff that we devs need to solve our problems. I could not image my job w/out it. That being said, in so many years using OSS, I have never posted an issue or question. Digging around for a bit always shows the answers for "it doesn't work".
Thanks for the hard work boys and girls! You set an example of how the world should work.
Github could tweak the tools available to make this easier for maintainers to manage I think, for example:
— 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).
One of the big mistakes we the OSS developers made is to give people the impression that software is not associated with costs. Be it personal time you put into developemnt, be it the time you spend fixing problems someone else has. All these things are costs for yourself and people don't value that.
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)
Related question - is there an organization with a clearly formulated “issue bankruptcy” policy? That is you periodically close all issues, announcing that anyone who cares even a little bit can re-open? I dream of it..
Not publishing on github probably removes 99% of the entitled crowd who think github is some sort of google/facebook thing you get some free service from in exchange of losing your privacy or something.
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.
If people are being assholes, you might as well politely tell them to take a flying fuck at a rolling donut. It's not like they are paying customers, so there is no justification for taking their abuse.
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.
Probably GitHub needs some way to allow projects to have projects define how they want their defect workflow to look. For eg discussion -> triage -> debugging -> issue -> code change, with each of these layers accessible to a different set of people.
Maybe the author doesn't want community engagement in the way that you want it. You decide how to manage your projects; allow others to decide what will best help them maintain their sanity.
I don't think it's true for most people that ignoring complaints about something you've invested effort into requires zero effort. I would say it typically requires tremendous effort.
This though is one of the terrible things about people adopting Github as a pseudo-resume for job applications. It's now routine to demand "Could I see your github respository" and strike out anybody who claims not to have one. Because of this just ignoring issues can create a huge amount of anxiety as you imagine your future employer's reading through the litany of complaints about your software and / or your failure to address them.
It doesn't apply to everyone but I can see how to some people this would be really problematic.
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.