Hacker News new | ask | show | jobs
by kakwa_ 2762 days ago
As the creator and maintainer of a project, it's really hard to let go of said project.

It's really hard to completely abandon a project you know people are relying on. You do feel responsible for it in the end.

Also, nearly every time someone opens a ticket, it points a deficiency in your project, and it's somewhat hard to accept that your project is not "perfect" (spoiler alert, it never is). Consequently you, as a maintainer, always want to fix issues or implement obviously missing features.

Also publicly admitting that your project is abandoned (by an header in the README for example) is quite hard, it feels like a failure and at least, you are publicly admitting something with a negative connotation.

"Maintained" forks that take over the initial project are extremely rare. In most cases, a fork will be tiny modifications done to fit one user's specific need. Nobody really wants to factorize these modifications into a common solution and maintain it. Well maintained forks do happen, but only for highly projects.

I'm speaking out of experience, I maintain a bunch of projects, not highly popular ones (a few dozen stars on github), but definitely used by other people. And in these projects I've a few that I definitely have nor the motivation nor the means to really maintain well. Typically I created a puppet samba module that is quite successful, but I've not used Puppet in 3 years, so I'm not a consumer of my own software anymore and I've not followed the evolution of Puppet in years, yet, I've not set my mind on publicly stating that this project is not maintained anymore.

Lastly if I do get PR for these projects, these are generally not really complete quite complete, documentation and unit tests are always missing, and the code quality is rarely on par, specially if the PR is quite complex. For every PR I accept I generally have a few commits to complete it/fix it.

1 comments

You can easily fix the low quality PR issue with a CI setup.

Setup a Travis job to fail often (build, lint, test, coverage, etc), so you pressure them PR author to complete it. This will make the entry barrier massive, but helps you focus your attention.

In addition, take an hour setting up issue and PR templates and guidelines in GitHub. A good readme with an FAQ section helps too.

See Symfony/Symfony for a good example.