FOSS maintainers "confessing" maintainer burnout to each other at conferences is a very real thing!

· · Mastodon Twitter Crossposter · 6 · 14 · 26

It takes intentional effort to keep projects maintainable and aim for the long run.

Maintainability is as much about management as it is about design or coding.

@hisham_hm Personally I think you should not try to make the project maintainable for you. Aim for forkability. The easier it is for people to fork projects and maintain themselves the less you have to worry about taking time off.

And it's not just about taking time off, but you might also lose need or interest in the project and therefore want to end it. If a project it easy to fork, someone who considers the project important, will maintain it.

@hisham_hm pls hit the "detect text from image" button when uploading screenshots of text. it's in the media settings thingy.

@deejoe all good pieces of advice there! I think I've done all of these in different occasions.

I think it helps to let contributors know that the struggle is real on the other side as well!

Agreed. The link I posted is the one that sticks in my head the most, and so it tends to be the one I throw out there when the topic comes up.

Usually, when it does come up, there is this sentiment of "this needs to be talked about more" or something like that. So, I try to gather some of these links links in hopes that we can build awareness and even some consensus around how this works and doesn't work.

Some other links in this vein:

and of course there's Karl Fogel's book, VM Brasseur's book, Nadia Eghbal's essays and recent book that cover aspects of these questions.

@deejoe @hisham_hm Karl Fogel's book, "Producing Open Source Software: How to Run a Successful Free Software Project" (CC-by-SA, electronic versions provided free of charge):

VM (Vicky) Brasseur's book, "Forge Your Future with Open Source: Build Your Skills. Build Your Network. Build the Future of Technology.":…

Nadia Eghbal's book, "Working in Public: The Making and Maintenance of Open Source Software":…
@deejoe @hisham_hm In "carry the patch", e.g. github by default (if the contributor doesn't uncheck the box) allows maintainers to add to the original PR. Is this discouraged?

@clacke @deejoe I don't think it is. In any case, picking and choosing contributor's commits before merging can be done via the CLI even without the GitHub interface. I have fixed up contributor's PRs several times this way. The Co-Authored-By tag allows documenting that the original commit was modified.

@clacke @hisham_hm @deejoe I think that article might be from before GitHub allowed maintainers to commit to contributors' branches.

We sometimes do it in #akka (preferably by pushing to the contributors' branch, but if that's inconvenient e.g. because it also needed a rebase we might open a new PR). We typically ask for confirmation from the contributor that they're OK with us taking over before carrying.

@hisham_hm Proposals for large changes should always be discussed with the maintainers before doing any work. IME most people who make large contributions have already been involved in the community for a long time and understand how it works. It is only occasionally that someone shows up out of nowhere with a large pull request without discussing it first.

@be Maybe this happens more for certain kinds of projects. I see more people showing up wanting to add features than wanting to help maintaining the existing ones.

@hisham_hm IMO the best the solution to maintainer burnout is inviting more people to be maintainers, which is facilitated by proactive mentorship of people who show sustained interest in contributing.

@be I agree, but it also needs to be clear that adding more maintainers does not simple "reduce the burden", but it also adds in communication and management overhead. This is well known in management/business, but FOSS projects are often notoriously bad at acknowledging the management aspects of a project, since they tend to grow organically and often end up following unspoken rules.

@hisham_hm One way I found over the years that prevents wastage of effort of contributors is to do things in the order of low effort to high effort.

1. Open a discussion on the project's forum or mailing list discussing the large feature. The idea is discussed with the existing maintainers and gets approved or rejected.

2. If approved, create an issue about the feature with what's been concluded on the forum discussion.

3. Implement the feature in a pull request.

Sign in to participate in the conversation

The original server operated by the Mastodon gGmbH non-profit