Co-Maintainers Wanted

I am terminally ill, there exists a poorly defined window of time before my Open Source projects are involuntarily orphaned. It would be handy to use this window of time to transfer domain knowledge of my various Open Source projects to new maintainers.

The general issue is that sometimes people move on, and we often end up with Open Source projects without maintainers.  (If you know of an old answer to this old problem, that can be employed in this instance, I’d like to hear it.)

Here are the majority of my Open Source projects requiring a maintainer.


The projects all use the Aegis DVCS.  The fact that the sources are not in Git may be a road-block for potential maintainers.  On the other hand, it may be enough to motivate a contributed refactoring that would allow Aegis to use a Git back-end.

I love geek humor:

You can move it to git over pmiller’s cold dead body? Might be a bit black.”

No, just a wee bit too soon.

I will have to a look at getting at least a copy of the trunk onto GitHub, for many of the projects.  If the code were already on GitHub then I am told that adoption would be repository transfer.


Perhaps Tailor can help with this, if the necessary Aegis source-end were written. The  destination-end already exists.  If you know Tailor well, I would also like to hear from you.

From User to Maintainer

If you use a piece of Open Source software, it’s worth going further than just expecting someone else to keep maintaining it.  This how I have become a contributor to numerous projects (e.g. GNU Gettext). Many of my Open Source projects are aimed at software developers (e.g. SRecord).  Stepping up to maintainer should be relatively simple.

Seen from another perspective, only step up as maintainer for projects in a subject area you personally are interested in.  Don’t do it just because it’s a community-minded thing to do.  Projects that need them will get maintainers, eventually.