@═╦╣╚╗ A mazing engineer 30-May-2021 An advice to open-source project maintainers For some strongly opinionated individuals it's possible to have a "benevolent dictator for life" style of governance. Open-source projects are perceivably more often criticized than praised publicly. This drains emotional energy, and leads to the burn-out sooner or later. Etymologically, "maintain" means "to keep in a condition of good repair or efficiency". It doesn't mean "to make all modernization, repair and improvement". But those are still needed to be done to keep the project alive and well. It's getting even harder to hit all those goals at once in an ecosystem. Neighbour projects evolve, and your project has to play well with them. Being a maintainer implies having a good high-level view, and in-depth knowledge of the topic and a fair amount of use cases. But it's impossible to know all the possible use cases. The project is not your property. It's not for your sole usage. It is public, and for the public. From my rather limited experience, people scratch their itch, fix what stands in their way, and never come back. This is rather sufficient to get the project going in most cases. Reasons for this behaviour is more or less clear: - open-source contributors don't get paid nor get any reputation for doing this - their employers don't motivate them to pay back for what they use in their daily routine and as their work's foundation - for certain projects the bar is set too high to make a contribution - they don't get any appreciation, and it feels like wasted time apart from fixing what bothered them - there is no sensation of doing good for a big audience To overcome all this, my personal preference to maintaining an open-source project is to foster contribution. It boils down to just a few simple rules: Welcome allies, and encourage contributions: - instil confidence in potential contributors - provide guidance early on - help to get contributions to the finish line to meet your project's standards - be thankful Don't scare people off if you're hesitant, not convinced, or plain don't like their request or contribution: - listen carefully - explain the why - make your expectations clear - have an opinion, but be open - say "no" when it's needed, but be open to saying "yes" even if it goes against your personal vision What I currently maintain: - one of the three active co-maintainers of RSpec - maintainer of the community RSpec Style Guide - editor of the Ruby Style Guide - one of the three active co-maintainers of RuboCop RSpec - the original author and sole maintainer of ActiveJob/Sidekiq Style Guide - few minor repositories (e.g. `noclamshell` macOS utility) Patience, and peace of mind to you.