15 min read
I have enjoyed reading Le Soin des Choses, which you may translate as “the care of things”, Jérôme Denis and David Pontille’s book about maintenance. It is not at all about software, but it nevertheless resonates with my experience of taking care of, and caring for, Gephi (a software tool I co-created). This post is not a summary or a review of the book, but a series of ideas I took from it and that helped me understand better what is going on with Gephi’s maintenance. They might be useful to other tool makers. And secretly, to STS academics interested in open-source practices. Or is it the other way around? Anyway, it’s a cross-over episode.
The book is currently in French only, but will be released in English soon. I hope this post will make you want to read it. Also, maintenance and repair studies are a thing, and here is a starting point, by the same authors, in English.
Maintenance does not make an event
Maintenance and repair are two different things, although related. The breaking (and the repairing) of a thing makes an event. Maintenance does not make an event, and goes unnoticed. The main problem of maintenance is its invisibility. I am pretty sure that every single open-source tool maker knows this. Maintenance is expected, yet most often, no resources are explicitly dedicated to it, whether that is as funding or as working time. The book makes it clear that it is because maintenance does not make an event.
From experience, I can tell that Gephi can get funds to add new features; it makes an event. Or to repair something broken; it makes an event. But we struggle to fund the mundane work of updating the code and keeping the codebase compatible with an ever-evolving software environment. The main takeaway, here, is that we need to make of maintenance an event to get it funded.
We kind-of did that with the Gephi Weeks, but those events want to become mini-festivals where we do many other things. Which is absolutely great, but the maintaining effort gets diluted. Another strategy is to disguise maintenance as repair. This happens naturally, as people are willing to get things fixed when they break. Failure is an event that summons a public who cares for maintenance; but that public will dispel as soon as everything gets back to working again. Maintainers have an incentive to let things break, because it makes their work visible. But I now understand that we could also invent a maintenance event, as paradoxical as it sounds. The “bug bash” we did during the 2021 Gephi Week might have been that kind of event, although I did not frame it that way at the time. I think of a maintenance event as a deliberately made-up event. I want to own its artificial character by making it explicit, on the motive that the lack of event is the main obstacle to funding maintenance. I would go as far as calling it that way, “maintenance event”, because it allows making the point that we just need any pretext to make an event that makes maintenance visible. That is not being deceitful or dishonest, just pragmatic.
A diplomacy of dependencies
As Denis and Pontille write, maintenance is a diplomacy of the interdependence relations of the maintained thing. It is care, in Annemarie Mol’s sense: a broad way of attending to relations and needs. Maintenance takes dependencies into account. It acknowledges fragility without attempting to make the maintained thing unbreakable. Maintenance is not the negation of decay. Its ideal is not the autonomous object that no longer requires maintenance, but the object that allows itself to be maintained, that does not resist to care. In that sense, it forces us to question the distinction between intact and broken, and makes us ask what it is to be in a “good shape”. There is a diplomacy of wear and tear, degradation, and so on.
Denis and Pontille mean “dependencies” in the general sense of existential attachments, but when it comes to software, it can be understood quite literally as “software dependencies”. Maintaining software entails a diplomacy of code dependencies. Diplomacy means, in this context, that there are tradeoffs everywhere and we need to compromise all the time, as there is absolutely no way we can make our piece of software independent of the rest of the ever-evolving digital infrastructure.
I have two examples. First, Gephi uses an OpenGL code library that is no longer maintained. When new compatibility issues arise, we only get unofficial fixes, with a delay, as unreliable patches from the community and released in obscure forums. As time passes, the delay gets longer, the patches get flimsier, and finding them (when they exist) is more and more difficult. Gephi’s main developers, Eduardo Ramos Ibáñez and Mathieu Bastian, spend more and more time on this. We want to replace this library by another one that is better maintained, to ensure the long-term reliability of Gephi. But this will require rewriting a significant part of the graphic engine into a new paradigm. Unfortunately, for this we need too much time than we have for now; until Gephi breaks for good and we no longer have a choice, or until we find enough resources.
Second example, that I get from Antonin Delpeuch, maintainer of Open Refine (another open-source tool). At some point, that project was in discussion with a foundation dedicated to open source software to get fiscal sponsorship. The foundation benchmarked their code, and found a legal issue with a code library that featured, as an addendum to its open-source license, “don’t do evil things with this package” (or something similar). The foundation’s lawyers had determined that it presented a legal risk, and asked for that code library to be removed. Unfortunately, Open Refine could not replace it with an alternative, as too much code would have to be rewritten in the process. It would break the tool. Ultimately, Open Refine had to find another fiscal sponsor because of this. In these two examples, we see that a negotiation took place, that involved not only the codebase and its architecture, but also legal terms, resources at disposal, various human actors, and organizations.
Annemarie Mol, who studies health care and medicine, tells us that care does not necessarily mean curing a disease to return to a healthy state, but being attentive to the needs of a person whose conditions of existence change. Similarly, maintenance differs from repair in that it does not aim to return to an intact state, but rather to be attentive to the dependencies of a thing whose conditions of existence evolve. The “normal” state of an object is to be maintainable, not intact; and maintainable includes a measure of wear and tear, degradation, and so on. Similarly, the health of a codebase boils down to its maintainability. Developers have been paying attention to this for a long time, forging concepts such as technical debt. A well-maintained tool is not one that never fails, but one that allows itself to be maintained. Good maintainability demands a specific kind of compromise, a diplomacy turned towards the practices of developers and other caretakers. At its heart lie these two questions: How do we realize that the conditions of existence of the tool change? And how do we intervene?
Attention to fragility
Taking care of a tool requires being attentive to the way it gets, or could get, changed by its environment. Gephi’s most common kind of fragility is to fall out of compatibility with a new OS, as it has happened multiple times with MacOS (but not only); or a new hardware (and its drivers); or new norms (security issues); etc. We are also aware that some fragility is inherited from code dependencies, like in my previous example. As Denis and Pontille note, attention to fragility requires proximity and movement. Fragility does not present itself as a stimulus to a consciousness that receives it, but rather emerges from bodily interactions with the maintained object.
The examples narrated by the authors typically consist of a technical and material investigation to understand its condition, where the maintainer must configure their sensitivity. A software tool is material in a different way, because the inscriptions it really consists of are mediated by the computer. But it is not less material. I do not deny that the bodily interactions of the developer do not entail any specific sense of touch, smell or sight. Those senses are not the place where attention to fragility takes place. Yet the software maintainer has to roam through their territory like a farmer inspecting their fields to check for anomalies. The maintainer’s work entails an inquiring movement that is not inherent to coding practices.
Gephi does have its own maintenance infrastructure. It consists of multiple things, and I may forget some. It starts from the senses we deploy to detect new problems. We need a certain proximity with the users, so that we can receive warnings. It might be me when I teach Gephi to students, or meet Gephi users. It might be over social media, or in the Facebook group. It might be through community members who know the core developers directly and communicate their observations. It might be through automatic error reports (we use a system named Sentry). But it is also about establishing a dialogue with the users experiencing failures, when necessary. We typically do this via GitHub Issues. Here is an example of an issue we have a hard time replicating. Indeed, it is critical for us to be able to inquire into a given issue (and replicate it) if we want to understand what is wrong, and fix it. We need allies in the community, we need some complicity with the users, we rely on their good will. So we need a space to cultivate this dialogue. This is why our Slack channel is also part of the maintenance infrastructure. Our infrastructure also comprises ways to keep updated on the technologies we use: expert watch on Java, OpenGL… and ways to reach out to more qualified people when we need to (developers networks). A software tool like Gephi needs an apparatus that broad, or it could not be maintained.
The software maintainer must cultivate a proximity to both the users and the technologies. Their attention cannot focus on everything at the same time, which is why their movement is necessary. The maintainer moves their attention from listening the the users, to the error reports, to the codebase (ex: unit tests), to technological watch, and so on. Fixing an issue or preventing problems entails an inquiry that leads the maintainer to navigate across multiple spaces.
No stable criteria
As Denis and Pontille note, maintenance is not a control operation conducted on the basis of stable criteria. It is not aimed at establishing conformity or non-conformity. Even the software environment changes; there is no status quo. Consequently, maintenance cannot consist of coming back to that fictional status quo, even under comfortable margins of error. Maintenance is about living with change.
Maintaining sometimes deeply transforms, or obliges to transform. For example by replacing a part that is no longer made with another, which sometimes can lead to a chain reaction through the dependencies, which in turn can lead to redesigning the object. The authors give the example of a smartphone, but it is also the case for Gephi. As we have seen, the software packages it relies on can also become obsolete (i.e., fail) and that can lead to cascading redesigns.
The internal discussion we have about Gephi’s visualization engine is exactly about consequences in cascade. Let me document this shortly. Our discussion has multiple levels. On a first level, we face the cost of removing the code dependency that may break soon. On the one hand, it is a lot of work; but on the other hand, if we are not prepared, it may break Gephi for many users and for a long time. It looks like we have no other choice than to remove that unmaintained library. On a second level, this might be an opportunity. The bad news is that we need to recode our engine into the contemporary paradigm of OpenGL. But the good news is that by doing so, we will be able to do new things and get a better performance. That work is not in vain. Maintenance may prompt a sensible improvement of Gephi with new features (that is not always the case). On a third level, the alternatives to the library we want to get rid of are not great. OpenGL is not used enough in Java to sustain a well-maintained package ecosystem. The best thing to do might be to get ready to move to a new library, in case of emergency, but without actually dropping the unmaintained library we currently use, at least for now. This requires to write an agnostic visualization engine, compatible with multiple OpenGL libraries at a minimal cost. Which is feasible, but that would transform Gephi’s architecture even more deeply. At the end of the day, that seemingly simple library issue triggers a broad discussion on how to architecture Gephi, with a sensible impact on our road map.
The ontological share of maintenance
Maintenance calls into question the nature of the thing maintained, which produces discussions or even conflicts. Denis and Pontille’s book is a journey that leads more or less to that point: maintenance necessarily has its ontological share that we need to think of. Maintaining a thing does not turn it upside down (exceptions aside), but it does not leave it untouched either. We must be aware of this change if we want to drive it in the direction we desire. Often, we are also forced to decide between different becomings of the thing maintained. We may want to resist, compromise, or conversely, seize an opportunity to drive change forward.
I can tell it is true, but I had not conceived it clearly until I read the book: maintaining Gephi changes it into something else, that I do not necessarily desire, or even just understand. I presume that the same goes for anyone who takes care of a piece of software, although we do not care for every tool we make. Some just fall out of fashion and into obsolescence and/or oblivion; we let them do so. The ontological share only matters for the tools that we want to last.
The temporality of what is maintained is at stake. What is meant to last? The initial object, or the object that lives and gets altered over time? That question is brutal for any physical object exposed to decay, less so for digital objects. Nevertheless, it remains true for a piece of software, because decay is not the only significant change. Gephi has already changed over time. We added features, but we also removed some, and it did not make everyone happy. What is Gephi? For the community of people who take care of, and care for Gephi, that question is very important even though we rarely talk about it. Is Gephi allowed to deviate from what it was initially intended to be?
I believe that we all want to be true to Gephi, but we cannot take for granted that Gephi means the same thing to all of us. We address this need with things like our road map: we discuss it, we make it public, and we use it to cultivate our alignment. But sometimes, opportunities arise that are not part of the road map and shape Gephi. For instance Gephi Lite, a web version of Gephi (you can try it now).
Gephi Lite came to us as an opportunity. Indeed, the necessary libraries in the web ecosystem were mature enough to support the project, and similar projects were already flourishing in different places, supported by a community of developers who knew and appreciated Gephi. When the OuestWare team proposed the Gephi community to take in charge a Gephi-like project for the web, we had a discussion about whether or not this should be part of Gephi. Everyone agreed quickly that it should be the case, as it was a great idea, and it became known as Gephi Lite (let me thank them here for their work!).
I believe that at the time, it did not feel like a dramatic change to most of us. After all, Gephi Lite was mostly developed by a different team, and we were very clear on the fact that it would not replace the original Gephi (they meet different needs). It would not disrupt our road map. That road map would remain the same, yes, but Gephi Lite would disrupt us, the “our” of “our road map”. Indeed, there was an ontological share to that move: Gephi was not a tool anymore, but a project with two tools. Yes, it had always been a project as well, but so far we could conflate the project and the tool. Now the Gephi project has two pieces of software under its umbrella, Gephi and Gephi Lite, each with their own trajectory. Hence the question: what is Gephi now? At least, it begs whether it refers to the project or to the Java software. But I think that the ontological change goes beyond that.
When Gephi Lite came into existence, I personally felt that it was a big change. Let me just clarify that I do not imply that I regret what happened; on the contrary, I wished for that change and supported it. But I must highlight this moment to make it clear that it changed Gephi’s time, to point at the change in the temporality of the thing maintained (in the words of Denis and Pontille). Gephi Lite came from the desire to keep Gephi relevant, which implicitly assumed that Gephi was more than the Java implementation. Gephi was understood by us as a certain approach to network visualization, a philosophy, and a set of methodological commitments. Before Gephi Lite, Gephi could be seen as just the Java tool, whatever it was. Now Gephi has two not-so-different but not-quite-the-same ways of existing. That is a change to the nature of Gephi. Gephi has become something else. Making things last is sometimes just making them exist; but that often entails shaping what they represent by selecting what remains of them.
Read the book.
Cite this blog post
Mathieu Jacomy (2023, May 11). The care of things (and Gephi). Reticular. Retrieved March 1, 2024, from https://reticular.hypotheses.org/7705