My answer to the
Perceptions
of Software Sustainability Survey.
I focus on what I think is a software, which seems important
to me regarding sustainability. This briefly summarizes
previous posts (in french), including:
For me, software sustainability is about making a software remain
a software and not become a program. Let me explain.
I make a distinction between a software and a program. A software
has a high potential of evolution, while a program has a low
potential of evolution. This potential can be expressed in terms
of cost or time; the idea is that software can evolve, while a program
is rather kind of petrified, i.e. its cost to make it evolve, to
improve it, is high.
In Simondon's philosophy, the program is in a stable state (like
death, ultimately), while the software is in a metastable state: it
is at an equilibrium but with a little energy it can change to
another state.
Each piece of code is on a line of tension between a "pure program",
which will never evolve, and a "pure software", able to evolve in
any direction. A code can be seen as a program regarding some
directions of evolutions, and as a software regarding other directions.
For example, an image manipulation program will surely be able
to evolve to support new image formats and new image transformation,
but will remain stable regarding where to store images, in files.
The only software able to evolve in any direction is the empty code.
With this distinction, software sustainability consists in always
keeping the code able to evolve in some directions. In research,
these directions should be the same as the researches which are
implemented in the software.
This means that the future roads of the related reseach must be
known, or at least perceived. This means also that the developers
must be able to always project themselves further than the current
feature or functionality to implement, to anticipate the next
developments. This requires a balance between action and reflexion.
But it is impossible to have a middle-term of long-term view when
developers are assigned to the development of a software on a
per-project basis, for a limited time. Indeed, the date of the
end of the projet is like a wall which prevents developers to
see the horizon they need to aim at to anticipate future developments.
In a sense, project kills software. Driving a car while looking
at the hood will not get you very far. You need to look far to
anticipate events, difficulties of the path.
Software sustainability requires long-term assignment, as
does research, i.e. sustainability of persons working on it.
It does not stand against developers on short-term contracts
being assigned one after the other to the software. In this case
the software is already dead, it is just a program.
There is a culture around each software, supported by its authors.
Welcoming a new author in this culture takes time. If at a moment
nobody is working on a software any more, this culture disappears
and the vision of the future of the software (with the knowledge
of its limits, what should be done, ...) disappears too.
So software sustainability requires constant investment, both
in term of persons working on it, but also in term of personal
interest of the authors.
Of course it requires technical artefacts (version management,
bug tracking system, continuous integration, documentation, ...)
but these are quite common now.
What is often invisible is the human part of a software, i.e. the
continuous investment of its authors.