The first step

is admitting you have a problem; so with that in mind:

Hi. My name’s Jeff, I maintain several OSS projects you may be familiar with1, and I’m burned out.

I lie awake at night, unable to sleep, crippled by guilt. During the day, it’s anxiety and fear that cripple instead, making the thought of facing the issue tracker unbearable.

Development on my projects has slowed far more than I ever intended, and while I have excuses2, push has clearly come to shove. Something must change.

Sat, Dec 15, 2018 | maintainership, paramiko
Intro When it comes to software maintenance tradeoffs, most of what I laid out in “The why & when of software releases” remains accurate. An ‘iron triangle’ exists between speed, stability, and ease of maintenance – it’s impossible to prioritize all three. I historically prioritize stability, specifically via bugfix-oriented release branches – users can stick to a given minor version even after subsequent feature releases appear, with the implied contract that they can install updates from those branches without anything breaking. But as I’ve burnt out, I lean more towards ease of maintenance (at least when push comes to shove) though I still do my best to backport fixes anytime it’s easy enough. Today’s post is about a specific conflict between stability and ease of maintenace, as seen in my efforts to drop Python 2.6 and 3.3 support from Paramiko. That is not dead which can be eternally supported Paramiko 2.0 came out in spring 2016, heralding a switch of crypto backend from PyCrypto to Cryptography (though no API incompatibilities were introduced). At the time, my commitment to Python 2.6 was still firm, despite slowly decreasing support elsewhere. By late 2017, the combination of a vastly shrunken 2.6 user pool and similarly decreased ecosystem support (in Cryptography especially) finally prompted me to drop it too, in Paramiko 2.

Sun, Sep 29, 2013 | documentation, maintainership, sphinx

Most open source projects store documentation in the source repo itself. This is easy to do, allows the doc builder to reference in-code documentation (like Python docstrings), makes contributions from others simpler, etc.

However, it doesn’t always play nice with “meta” information such as how to contribute, project roadmap, and so forth.