[clug] Software maintenance - was Watercooler

[Brenton Ross]

On Mon, 2020-09-07 at 16:07 +1000, Paul Leopardi via linux wrote:
> 
> Many of my open source projects are in an update phase.
> https://sites.google.com/site/paulleopardi/research/software
> I updated  GluCat to port PyClical to Python 3, and am now aiming to
> port
> the linear algebra from uBLAS to Armadillo. One problem is that
> Armadillo
> does not support quad precision or arbitrary precision arithmetic. At
> some
> point, I should also update the C++ idioms used in GluCat.
> I am currently updating Boolean-Cayley-graphs to Python 3 and am
> having
> issues with backward compatibility of pickles in Sage, as well as
> hosting
> of my PostgreSQL database.
> I should also update PySAFT to Python 3.
> My EQSP code at Matlab Central is out of date and I have had a new
> version
> waiting on GitHub for a few years.
> All in all, I haven't been spending enough time on code maintenance,
> but
> life has a way of taking priority.
> All the best, Paul

It is really quite amazing how something that doesn't physically
degrade still needs regular maintenance.

The reasons are many and various: Bug fixes, evolution of the language
[C++], complete revisions of the language [Python], compilers getting
better at finding dubious code, but the big one is the libraries and
frameworks we depend on changing, sometime a little and sometimes by
being completely deprecated or extinguished.

In the long term this will limit the size and complexity of the systems
we can build. Eventually the rate of change of the supports becomes too
expensive and it becomes impossible to build something larger.

It is bad enough in the commercial world [I spent a decade being paid a
lot of money maintaining a software system] but it is perhaps even more
of a problem for open source. Everyone seems to want to build something
new, very few want to spend their time maintaining someone else's code.

Part of the reason is that it can be a very big task to gain a level of
understanding of a software library sufficient to be able to maintain
it. While many projects publish their code it is rare to find the
design documents that correspond to it. This means you have to
carefully study the code to try to comprehend what was intended and how
all the constituent bits fit together. 

Unless you need to repair the code for your own project there is little
incentive for becoming a code maintainer.  This is a bit sad because
for new programmers they can learn a lot by studying existing code. But
without the design docs the initial learning curve is more like an
insurmountable learning step.

Brenton