I detest the stale bot :-)

And I really think it only is a disservice to the project, 99% times I see it used. If the code has a genuine, real defect, it will not "go away" magically just because nobody complained again, or the authors didn't have time to look on it.

See, the issue is there. Don't have time? Ok leave the issue open, it acts as a documentation about, well, that there is an unsolved issue.

I really hate when googling about some problem and then finding a promising bug tracker conversation that then... got comments closed because of old age. That's literally swiping the problem under the rug.

Now regarding burnout and burden of OSS maintainers, I might lack a bit of empathy here, but I just don't get it. Really the license text says it all: THIS PROJECT IS OFFERED AS-IS. Most if not all OSS licenses have a phrase like this. Just quote those words 100 times if it's needed. My mental health as an OSS maintainer is very well and I cannot see it being changed by some, even lots, of demanding users at any point. Every time someone takes my code and uses it, there is an implicit conversation where I go "hey, here you are take this work for free, I'm lending it to you AS-IS, do whatever you want with it!". Absolutely at no point in time I feel pressure about defects in the code, after having this imaginary conversation.

I guess we need more spreading of the notion of "not giving a sh*t" so the idea gets extended to more and more OSS maintainers, helping them have a happy life not encumbered by the work they decided to release by sheer goodness. EDIT: with this last phrase I mean that one should have the mentality of contributing up to, and not more, what one is able to do within their own limits. The "not caring" I mention is for after reaching this limit: it will help not pushing through the burnout line, and thus as a result being happier in the long term.

Not all maintainers do the same. And some even _lock issues_, which I hate, because even closed issues can have a very fruitful discussion long after the issue was originally posted.

> even closed issues can have a very fruitful discussion long after the issue was originally posted

100% agree! In some occasions I've learned a lot from reading long related conversations in a bug report that had been closed or resolved long since.

Shame when it's set to be aggressive, it can be a serious hindrance. Issues almost act like a user forum, and can be super useful even if the maintainer doesn't want to put energy into that particular issue. I've found some really helpful work-arounds in "stale" issues.

Discussion can eventually lead to a shift, repeating this argument can't.

This overlooks the emotional burden of having a large, unbounded backlog.

When I see that I have a missed call, I feel an obligation to call that person back. When I see that I have a text, or a DM, or an email, I feel an obligation to respond. Individually these are all minor obligations, but in aggregate they eventually coalesce into anxiety. PRs, too, get thrown onto this pile.

Burnout is a self-imposed "boiling the frog slowly" scenario caused by gradually taking on more responsibility than you can successfully deal with. Realistic ways to prevent burnout are by either aggressively preventing new obligations from being thrown onto the pile, or by periodically defaulting on obligations and resetting the pile entirely. It appears to me that the stale bot is an instance of the latter. An instance of the former would be to just outright forbid PRs entirely.

And if anyone thinks that they have the mental fortitude to handle an ever-growing and unbounded pile of obligations, then that only reiterates the call for them to fork these projects and accept the burden personally.

Now, granted, it's likely that if nobody did anything then it's still broken, but it's still the case that a bug database, considered as documentation, gradually becomes outdated and increasingly misleading if not maintained.

Stale bugs are still in the database and you can still query them. Nothing is lost. The question is how relevant old history is when it comes up in search results?

Maybe querying on open bugs only is the wrong default? Stale bugs should probably be included but with much decreased rank.

In this case I'm not sure what's the best solution. I have suffered myself finding an open bug but so old that it didn't really apply any more. However in those cases, it has happened that attracting attention from a dev, or just testing by myself, has driven the conversation into quickly realizing that the issue didn't apply any more with current state of the source code...

Maybe it's a good idea having the feature of specifying which version the bug was reported against. GitHub doesn't have this, but I've seen it in some other bug trackers.

Of course, that takes time and effort and some bugs are harder to evaluate than others.

They are still there, exactly as described.

It definitely is. Of course OSS authors and maintainers want to see people using and enjoying it, but nothing is black or white.

What you really mean is that you want people using and enjoying your software within the limits of time and abilities that you can employ on it without it affecting your mental health.

Some people are worse than others at finding out about this latter part, and as a consequence they suffer.

My point of view is that if you don't care as default state, then you put work into actually caring, when you get to your limit you'll be able to very easily see that you cannot contribute any more hours today, because you're almost depleted how much you actually care. Thus avoid crossing that thin line that is burnout and all mental health issues that come with it.

I.e., be in a defensive mental state. Ironically, it will make you work happier and over a longer period of time, which ends up being positive for the health of the project itself.

I just told you that for me, it's not. Repeating your view isn't adding anything. Restating it doesn't make it so. I understood you the first time.

> My point of view is that if you don't care as default state, then you put work into actually caring, when you get to your limit you'll be able to very easily see that you cannot contribute any more hours today, because you're almost depleted how much you actually care. Thus avoid crossing that thin line that is burnout and all mental health issues that come with it.

I completely believe that's how the mental process works for you. That's not how it works for me. If I detach myself from the project enough to not let it affect my mental state then I do zero work on that project.

You might be able to perfectly handle your OSS projects despite of this tendency, you probably have your own complementary techniques (like limiting the number of simultaneously accepted PRs at any given time? I'd be interested if you want to share any), or if a bad wave of burden arrives one day, you might end up burning out and either throwing the towel or growing a thicker skin. Hopefully the latter!

I think this is really important. In some projects, the number of open issues is always zero. Most people see this as a good thing. I think it is not. we need projects where there are hundreds of open issues and these issues are visible. it is important to solve problems if they want to be followed clearly. I think it is a very important issue to be able to follow up the problems clearly.

That’s just a little bit beyond what the average open source maintainer has on their plate.

Regardless, the attitude of recommending that people fork a project if they really need something is the way to go. It’s okay to say “no” to an influx of requests and demands. The maintainers who burn out the fastest are the ones who view every comment, suggestion, request, or piece of feedback as equally important. It’s okay to let something be your personal project and not let the community take a sort of control over your time.

Do it long enough and you will develop a thick skin, if only out of necessity. Open source will expose you to some of the nicest, smartest, most thoughtful people you’ve ever worked with. It will also expose you to some of the most demanding, manipulative people who will use every social pressure technique they know to try to make you feel bad about not doing exactly what they want.

1. How to maintain a healthy approach to your popular code.

2. How / why to say no without looking like the jerk.

3. How to find / manage help when you need it.

Handy skills for life too...

Granted plenty of folks do it very well, but there's nothing about Open Source that necessarily provides any of that and some folks who love to help, share, and solve problems fall into bad places.

That also leads me to wonder how much complexity for most projects is even needed. I kinda wonder if for most projects maybe 90% of the people using the code use it for a handful of tasks, and yet the vocal loud folks demanding more are a very small minority...

I made a point of setting it up right from the beginning. Easy build system, fully unit tested, code of conduct, automated CLA signing, examples, good documentation and most importantly, I am excessively kind to anyone who comments or gives feedback. This took an inordinate amount of time up front, but was worth it.

I'd say the result of this is that I've gotten a couple high quality contributions, zero stress and very very little feedback. It has been a pleasure to maintain this project because it causes me no pain at all.

I'd say that maintaining 200+ projects is just insane really. You've overdone it. It is impossible to do any of them extremely well and of course you're just going to invite 200x more drama. Don't do that.

[0] https://github.com/lookfirst/mui-rff

Yeah, I have to agree with this.

Please stop "sharing" projects by default. All you do is suck the oxygen out of the space for someone who might actually be willing to spend the time (Rust is particularly bad about this--I suspect it's carried over from Ruby).

No project in a space is better than a half-assed project in a space.

Yeah I don't want to call out the writer or anything because I don't know but that ... that number worries me.

Unless we're talking about one off packages nobody uses, can only do so much well.

That security vulnerability or bug isn't going to vanish into the ether because a "helpful" bot closed the issue. It'll still be there - but it'll get lost in every other closed issue.

I will happily just comment on the issue every single time the bot closes it out of spite to force it to be re-opened. Hell, it's probably overdue someone writing an anti-stale-bot that does exactly that.

Related: https://drewdevault.com/2021/10/26/stalebot.html

I think people are objecting to un-triaged issues being able to go stale, and you then have to keep fighting the bot every month because the maintainer doesn't spend the time to confirm it while demanding you waste your own time to bump it.

This is really the right answer a lot of the time. The first few times I submitted a PR and got rejected or ignored, I took it personally. Then a maintainer explained it to me (ran into him at an in-person meetup), and it was very similar to Jeff's explanation here. Also, what makes it really hard for maintainers is that a lot of the requests they get are from people who don't have the ability or desire to fork the project (and even less ability/desire to maintain the fork).

I develop open source projects too, so I'm intimately familiar with both sides. It's a bizarre feeling when I realize I am acting (as a user) the same way other users act towards me (as a maintainer). I think being a maintainer is a healthy reminder that I should lower my expectations as a user of free stuff.

The reason I create open source stuff is there was a problem I wanted to solve, and I want to share my solution with others so they don't struggle with the same problems. I try hard to make it easy for people to use my solution, and I hate the feeling that someone might be inconvenienced by using it. I really do want to fix all reported bugs. But at the end of the day I have a life (and a job) that gets in the way. I feel bad about any bugs, but I don't feel bad about taking a long time to fix them, because my quality of life is more important.

There's a feeling of indignation, but I constantly remind myself that on the other end of the PR is a maintainer like myself, so I try to remember to bite my tongue and be extra nice.

As the project gains traction you'll develop a community of trusted developers around you and you could consider granting commit access to some of them to help reduce your workload.

It can also reduce the stress of feeling that you'll be blamed if something goes wrong and it becomes more of a community effort which is one of the benefits of open source.

One of the of the points Rupert drives home is that open source with the goal of sustainability doesn’t have a framework in place that doesn’t lead to burnout. Everyone just learns lessons the hard way without any real manual for successful outcomes.

I don't think it should be built in by default to any software that is released open-source. But, I do think having guidelines for how software can be developed in such a way that doesn't lead to burnout.

The linked article pertains to avoiding the path to burnout, which if you are sharing code that an author a.) expects to "own" and maintain and b.) hopes other people will use, then you need should educate yourself as to how this can be achieved. Good literature on the subject is limited IMO.

> Not everyone should be publishing their code and definitely not everyone should be OSS maintainer.

I partially agree with this. I do think not everyone is up for the task of OSS maintenance and development, some of which is likely stemming because they don't have a good framework for how to do so sustainably.

I do think anyone should be able to freely publish their code if they like. Sometimes folks want to share things for fun or education or demonstration purposes, when they don't intend to accept or want PRs or contributions or downstream consumption or maintain it. There is value in OSS for many different reasons. I think GitHub in particular does a poor job of signaling to readers which software is sustainable and which is not.

I do agree that anyone should be able to publish, but then should also consider bigger picture when "stars", "likes", "downloads" are rolling in.

As noted there are no materials that show what is it like when you have to work on something for years because you built expectations in others.

Just like kids want to be youtubers and then youtubers were all "burned out" because yt algorithm will take away their likes if they are not on top of the things all the time.

It's not a job.

It's not a résumé.

It's not a damn lifestyle or an in-group to define yourself through.

It's a way of saying "I wrote this. I allow you to look at it and use it for yourself, if you like". Nothing more, nothing less.

> randoms from around the globe should keep their leftpads for themselves and their friends.

That seems like a bizarre inversion of responsibility to me. Randoms can publish whatever they please; if you use their left-pad, that's on you and you alone.

We need a valuing of non-coding contributions, and a way of welcoming them into projects.

I like building community and dealing with people. I like project management, planning, and thinking about funding opportunities. I even like (but am not good at) writing documentaiton - but only if the author of the code is willing to explain _why_ they wrote the code this way rather than get me to write how it works.

I haven't come across a project that is open to welcoming people who bring these skills. People do these things have got to that place through long-term involvement, or because the role fell to them. Or no one does it.

A decade ago there was a drive to get designers and UX people involved in open source projects [0]. It came to little, to the detriment of the entire open source community. Writing code isn't the only skill important in a project, and if we embrace that the whole experience of using the framework, library or software improves.

0. https://markboulton.co.uk/journal/design-in-open-source/

Incidentally, this work has led to an official role with the project, tons of professional experience and contacts, and some well-paid consulting gigs. I have a very strange and spotty resume due to health issues, so it's been frankly life-changing.

[0]: https://github.com/bevyengine/bevy

Sure, especially if your (meta) goal is minimizing individual maintainer effort. But if you want instead to maximize maintainer and contributor return on effort (counting both the originator and the polisher as contributors), a different approach may be called for.

Maintainers "just" need to figure out for themselves not just how much work they are willing to put in, but what sort of work, and what work (if any) they are able and willing to delegate or offload onto others.

For a maintainer who isn't willing or able to do the work of polishing contributions or handholding potential contributors, and doesn't have anyone they trust that is willing or able to do that work, rejecting most PRs (and even issues, for that matter) outright can be an entirely valid approach.

Open source success and sustainability don't look the same for every project or for every maintainer.

Second… I desperately want a post describing how one person maintains 200 projects! Wow!

The optimistic take (and what I prefer to believe) is that if a project works, and solves the problem the maintainer wants it to solve, it doesn't need to be changed unless/until it breaks.

In the long run, the only monetary solution is to go back to some kind of PD/Shareware, which is what all those public core, commercial full solution end up being.

30 years ago we called those public core parts, playable demos.

Well, perhaps they are doing it properly, and everyone else has the wrong definition of “proper”. Good stewardship does not mean accepting every patch and every new feature.

If you have reviewed a patch and you don't think it's the way to go, or you don't think it can be maintained going forward, that's fine. If you set up stalebot to close and lock merge requests because you don't have time to review, that's something else.

When the products turns out to have problems, an issue arises between the supplier of the product and the supplier of the fame and praise.

I think that's why people feel entitled to customer service. If the developer fails to provide a good customer service, the users demand refund, that's why it feels very similar to regular customer support.

In fact, the users of the free software can often be much more demanding. Maybe they are rightfully so, since they paid with social capital that is limited, precious thing - unlike money that can be earned in by doing work for a bit.

The pain as a result of the product failure is also the same, it doesn't matter if you paid for it by a monetary transaction or tapping the like button. Even if you haven't done anything directly, you inflated the developers stats - which are the main KPI anyway.

IMHO, if someone wants to make money from their work they should explicitly charge for it. You can't expect to receive all the street cred for giving away your work for free and also receive money for your work. The maintenance is simply, street cred maintenance.

Many years ago I learned my lesson for giving stuff away for free. It's tough to sell your stuff in exchange for a reputation, the demands of the customer never ends. Your part in the deal is also not clearly defined, you are expected to fulfil your obligation by working on every single request no matter what is the scope and if you fail to do that your free users will be mean as if you scammed them.

edit: Sorry for not being able to reply to you all but my account seems to be rate limited. Unpopular opinions have consequences I guess. Shouldn't hold them.

Users might invest time in using your software, and it is this time they feel robbed of when things go awry. I have been on both sides of this. I used to become very angry when something doesn't work right out of the box after quickly skimming a setup tutorial. At the time I was working for salary. Any free time I had was very valuable and couldn't be sucked up doing the same thing I do at work - debugging config issues, retrying with different options or environmental changes, etc. It was only after becoming a part time independent contractor that I developed the patience to really deal with open source software. To feel I had enough mental energy to really read the documentation or look inside the source code and debug what's going on - totally different from the customer service experience of dealing with proprietary software.

People become frustrated when the effort needed to understand or deal with something is beyond what they are willing to put in. I don't think open source can escape its problems until a substantial portion of users have the time and energy to really engage with it. We should be working far fewer hours than we actually do.

From the users perspective, the joy and the pain is the same as with the paid product. If you promised them something and underdeliver, they feel scammed.

If anyone else needs it, they are free to copy and use it. If they find a problem that I think needs fixing or my stuff will cause me problems, I'll fix it. Otherwise, they are free to fix it and(if kind enough) submit it.

I have 0 obligation to fix anything that I don't personally need and anyone that copies it has 0 obligation to give me anything in return. I only published it to save someone else the time for the bulk of the work. I'm not doing it for money or cred. I do it because it's something I already finished(more or less) and it won't cost me anything to share. Anyone elses needs(family and friends exempt) are not my problem unless It's my (paid) job to make them my problem.

There is no such thing as this "social contract".

I publish software on github with MIT or (A)GPL licenses for various reasons:

* In case someone else has the same issue I did

* In case someone is working on something similar and wants to learn from my code

* As an external backup in addition to my hard drive / private git repo / etc.

* Because I can. (deal with it.)

There is NO expectation or "contract" or anything. People can open issues or politely request things, but getting upset or pushy over F/OSS released on someone else's own terms is just entitlement.

Even if someone asks you the directions to the gas station, you are expected not to deceive them and give them the best instructions to you your ability and they are expected to show some appreciation for helping out the society. You will face backslash if you don't help a fellow human or deceive them despite the fact that you are not receiving direct payment for your act.

Imagine you put a sign that says "The mall is in this way" and the sign is not entirely correct. It was a free sign, no one contracted you to put that sign but if it happens that your sign wastes someones time you will receive negative feedback and probably requests to correct your sign.

In the same way, if someone posts some code you can file a bug or give a patch, but that doesn't entitle you to anything from the original author. Maybe you helped him making the code better and you're scratching each other's back. Maybe the author is just extra nice to you. But just because you've received a gift, you're not entitled to more gifts.

I think some of the disagreement in this thread is just over whether someone is being an asshole if they leave buggy code lying around with no warnings attached, and rejecting /ignoring requests to remedy the situation.

That's why forking exists.

That's the risk of pulling in external libraries from random developers. Unless you're willing to put money where your mouth is, then all you reasonably can do is politely request a fix or for them to merge your PR.

Let's say I release some code that is isn't fit for purpose. For example, it corrupts user data 5% of the time.

The code has a README that doesn't mention the issue, and I close all issues that refer to the problem. I also reject any PRs that try to fix it, and so on. I don't, however, disable issues or say the code is unmaintained, so there is a steady stream of people whose data gets corrupted when they download and use my code.

Since you don't seem to like the term "social contract", would you at least admit that I am violating a few norms and acting like an asshole?

The freedom to fork (for any reason) is orthogonal to the question of whether the maintainer is being an asshole or not.

Of course, people are also free to be assholes (for any reason). But it shouldn't be controversial to say "don't be an asshole".

You could argue there is a social contract between the repo maintainer and various submitters. Not so much between the repo owner and users/consumers.

1. There is no contract, not even implicitly, that promises software maintenance in exchange for praise. The praise may be a motivating factor for the developer, but anyone who thinks they are entitled to anything just cuz they showed some appreciation has not read the Open source License, which almost always states the software is provided as is without warranties.

2. Genuine praise is not transactional. The only factor affecting praise or criticism should be merit. Any other quid pro quo makes praise into hollow lip service, meaningless fungible gibberish uttered for personal gain. Praise is more like a donation than a payment.

3. Even if praise/fame somehow could function as currency, then any individual is not providing enough of it to earn themselves any significant privileges. Maybe in aggregate the community would have a 'claim' (if the developer agreed to this contract), but even then the obligations incumbent on the developer would be limited and unclear, because no one person can speak on behalf of the community and for most projects their community does not organize itself in such a way as to permit concerted group action that can be recognized as the will of the community.

4. if you feel like you have been robbed of your praise, you simply withdraw it or voice criticism. Or you recognize that your praise was still applicable and valid to the parts of the project that you were aware of at the time of voicing your opinion, so therefore is still deserved. If you think you provided more praise than is merited by the project, then that's an error in judgment on your part. No one asked you to proclaim project [projectname] the best thing since sliced bread and the hope of humanity that is literally gonna change the world. Just be more careful with who you choose to praise.

I'm sorry, but I think you're exaggerating a lot here about the worth of "fame" in something as niche as writing open source software. It's like when people try to pay artists with "exposure" -- flashy, but worthless in every imaginable way.

Case in point: The creator of Homebrew who famously failed to get a job at Google despite having all "street cred" imaginable.

There is no "the" social contract. There are many social contracts, and they are not all compatible with one another. The whole point of written, legal contracts is due to a recognition of this fact.

I don't abide by that (or any) social contract when I put something on Github, and nor should I. When I say that I can't guarantee this code won't cause harm (e.g. destroy HW or files on your HD), I mean that. If you want to labor under unspoken, unwritten contracts, be my guest.

Okay, but imagine for a moment that you don't say that. The README is silent on the issue of potential problems. Are you violating any social contract then?

Or suppose an issue is reported to you. You don't feel like fixing it, close the issue, and even delete it, and don't add a mention of the problem to the README. Are you violating any social contract at that point?

If you don't like the term "social contract", would you agree that you would be violating some norms?

> There is no "the" social contract. There are many social contracts, and they are not all compatible with one another.

Similarly, those expecting my code won't cause damage are also violating certain social norms.

The code is there for anyone to do what they want with it. Do with it what you will, and own the consequences.

> Or suppose an issue is reported to you. You don't feel like fixing it, close the issue, and even delete it, and don't add a mention of the problem to the README.

My Github repositories are very low in importance on my list of important things in life. I reroute most notifications to a folder and will go through that folder only a few times a year, so I likely won't even know about any such issues for months.

Now personally, I do put a disclaimer in the README stating that people should view the code as unsupported and unmaintained (even though I do update the code from time to time), but I do it merely as a courtesy, not as an expectation. I do not at all endorse that people should put such disclaimers.