Science tools are not made for their users

5 min read

I often get to talk about Gephi, an open source tool to visualize and analyze networks that I co-created a decade ago. The project is in a semi-dormant state since a few years, but despite some issues it still works. As frustrating as it can be, Gephi has its fans – kudos to its amazing community! The feedback I receive from these well-meaning enthusiasts makes me think that our motivation is sometimes misunderstood. Nothing surprising, since it is mostly implicit. But making it explicit may prove useful.

I get sometimes asked why we do not push Gephi further. This feedback comes with different assumptions: that we want to but cannot; that creating a business may solve our problems; that Gephi gets behind in a race against other tools… But I do not think that Gephi should “take over the market” and that is why I prioritize other tasks over developing or designing Gephi, or doing community management – writing, for instance.

The sustainability of our project does not depend on a business model; but if I had to paint the situation under that light, I would say that our “business model” does not care that people use other tools. Less users does not mean less money for us, and money is not the problem anyways. What we need the most is (1) a healthy community, and (2) time from trained developers to fix major issues. The rest is secondary.

There are many similar tools. Did you know that there was already another French open source graph analysis tool out there when we created Gephi? It’s called Tulip, and it’s still alive and well. We were also inspired by Pajek and Eytan Adar’s GUESS. We created Gephi to be able to do things that we could not do with these tools, but it does not mean that we aimed at being better, only different. Of course, we were excited to get known and radiate out of the French circles. I remember how happy was Mathieu Bastian, our lead developer at the time, to shake hands with Duncan Watts, or Marc Smith, the creator of NodeXL, another network tool still going strong today. There are many nice solutions out there, all with their own specificities: Cytoscape, UCINet, Visone, iGraph, GraphViz, Voson… But it is fair to say that there is a large overlap between them. There are more tools than necessary. Why?

There are too many tools than necessary to the users; but tools are not mainly made for the users. Or if you prefer, their real “users” may be the participants of the project. From my perspective, Gephi is also an experimental device through which I enroll participants into a large-scale epistemic design experiment about complexity. You’re my guinea pigs, folks; but everyone is someone else’s guinea pig anyways, and at least Gephi is a win-win situation (note: we do not track Gephi usage – we are not Facebook).

Open source tool creators, especially in science, do not create tools to meet user’s needs. People create tools because (1) the tool has benefits, (2) the process of making it has benefits, (3) the tool is reusable, (4) the tool happened by accident.

The benefits of creating your own tool include:

• It meets your needs. Sometimes no existing tool does what you want – that is how Gephi started.
• Retaining technical skills in your lab, because it is a key piece of the puzzle of making your lab work. Ex: the Sciences Po médialab.
• Visibility, assuming that you make the effort of associating your name(s) with the tool. It can also disseminate “your” method – although users repurpose tools in unexpected ways.
• Collaborations with other people whose interest was sparked by the tool, including open source developers. Big tools can bring many people together, e.g. Media Cloud.
• Citations. As a goal, it is overrated: the Gephi paper is cited 5000+ times, but it is not that many academic magic points considering the amount of work involved.
• Dedicated funding – this can make it harder to open the source code, since it often comes with pressure for patenting and/or creating a business.
• Students can afford a free tool. And in a pedagogical setting, a simple tool is often more efficient than a complicated one.

The benefits of the process of creating a tool include:

• Learning how to code, because you want to become methodologically independent (look at the success of Jupyter notebooks).
• Engaging with computers because you study them (I look at you, Bernhard Rieder, and your upcoming book on algorithmic techniques Engines of Order).
• By redoing something, you understand how it is done. And it is sometimes faster.

Most of these good reasons apply regardless of whether the device is made public or not. But dissemination, as a value, has a strong currency in science – a point in common with open source software. Once you have created your gizmo, why not allow others using it? And that is how you sometimes inadvertently end up with a tool. You put your gizmo online, you mention it in some slides, and the next thing you know a PhD student asks about “your method” and you’re booked to give a workshop.

Most gizmos do not meet a large public – most fall back into oblivion. But of all popular open-source tools, most probably started as unexpectedly successful small-scale experiments. They were not created to meet user needs. Meeting user needs made them successful, but it was not the initial motivation. And it does not have to be.

Gephi’s development is slow and it does not bother me too much, despite a number of frustrating points that are, unfortunately, difficult to solve. To be completely honest, the current state of Gephi can be useful in unexpected ways, for instance when it comes to remind everywhere that developing it has a cost – and it is not just money. I agree however that the situation is precarious, which is problematic: we are not in a too bad spot, but we could too easily fall into one.

Gephi is a collective project and each participant has its own motivations; here I only speak for myself. My position is quite self-centered. It’s not that I disregard users: I deeply care about them. But I am just not so interested in the problem they think they have. I am interested in the problems I think they have, I think we have. I think we have a problem with complexity, a problem akin to a collective blindness to our own limitations, a denial. That is what I find interesting, in the current state of affairs. Despite what users desire, a moderate amount of frustration can be fruitful to that end.

---

---