Author: John Bradley
King’s College London (UK); formerly University of Toronto
john.bradley@kcl.ac.uk https://kdl.kcl.ac.uk/about/people/john-bradley/
It is probably obvious that the Voyant Consortium has been created to keep Voyant and Spyral alive. Since Voyant and Spyral are complex pieces of software, a significant part of what the consortium does is to facilitate technical work in the form of software development and maintenance.
This is quite clearly reflected in the listed “purposes” for the consortium, as they are given on the consortium’s “About” web page: 4 of the 8 have at least some technical aspect to them (and the first three, are the first three listed):
- Provide strategic direction for Voyant and associated technologies;
- Maintain and expand the tool suite, including Voyant Tools, Spyral and associated assets, for the use of digital humanities researchers;
- Continue developing Voyant Tools and Spyral to meet changing user needs and to take advantage of new techniques/technologies;
- Maintain the platforms upon which Voyant/Spyral run and relevant partnerships such as that with Digital Research Alliance of Canada;
(https://voyant-tools.info/About/)
Of this group, the middle two (maintaining and expanding the tool suite: which, to me at least, involves maintenance and relatively modest software development in the form of new tools, and the continuing of development to meet newly emerging needs—think of Generative AI, for example, and how it might fit into Voyant) clearly have large technical – software – components.
Of the other two: the last one about software maintenance listed here is essentially technical but involves other issues and digital technologies than software development tools, and even the strategic directions developed for Voyant/Spyral will contain some technical considerations as well as significant non-technical ones.
So, the Consortium forms a kind of community which is involved in the support and development of these two pieces of highly technical software. What structures are needed in the consortium to facilitate the community’s engagement in this?
Figure I: The structure of the Consortium
Figure 1 shows the structure of the consortium. The software maintenance and development aspect is clearly recognised in it by the formation of the Voyant Technical committee. The technical folk in this quite small team will be focusing most of the time on the actual technical matter of the code. Although the idea of forming an explicit component in the consortium in this way seemed like almost a non-brainer, it wasn’t entirely clear how the technical committee was supposed to actually do their task.
I think one of the key things here is communication: Communication between members of the consortium and the technical folk is clearly one central element of this. However, what mechanisms for enabling communication need to be set up?
Figure 2: Three Models for Technical management
So in light of this question, I looked into three major very successful digital projects to see how they managed their technical work. Figure 2 shows the three projects, what they produce, and summarises how they each manage the technical development.
For the DH community of which Voyant/Spryal is a part, considering how TEI does things was an obvious choice. However, TEI’s purpose and community and in particular the kind of digital things it maintains is rather different from Voyant. The other two – which are aimed primarily at maintenance and development of pieces of software as the Voyant consortium is –also perhaps have some commonalities with Voyant. One has to bear in mind, however, that in one particular important way all three of these projects are quite different from Voyant: all three have many technical people all active in the maintenance and development of their respective platforms. And indeed, the management structures for Eclipse and Apache are created in light of this. Both Eclipse and Apache operate a development management environment which they call a meritocracy, and in both the role of committers – the persons who are allowed to update the “official” version of the software – is central. The “principal committer” idea is less helpful to us here, because Voyant doesn’t have a set of programmers who might vie for the honour of being the official committer.
Nonetheless, In spite of these admittedly important differences, one common element in all three projects that also applies to Voyant can be found in the use of version management software (like GitHub) to handle the code base, and this helps us a bit too. In particular, one part of this management software platform, the issues manager, is an idea relevant to this discussion.
Issues management
Issues management software provides a way for the user community to report bugs and issues to the technical team, and helps the developers manage the resolution of these reported bugs and issues and to report back to the user, through an online conversation, about what has been done. Thus, it provides some structured and focused communication between the software developers and users.
Figure 3: An issue in the Voyant Issue Manager
Indeed, as I just mentioned, this “issues” mechanism is already in operation with Voyant via its GitHub site: Figure 3 shows an example of a recently posted Voyant issue. However, when one looks at the list of issues contained in Voyant’s issue list, one sees very few contributors: a quick cruise through the issues online shows almost all issues are posted by the Voyant team themselves to help manage software changes they are making. Perhaps, then, more Voyant/Spyral users need to be informed about Voyant’s issues management component, since I suspect most Voyant users are unaware of its existence, and wouldn’t know how to make use of it if they did know.
Towards a technically broadly informed community
Issue management within GitHub provides one communication path from user to software development folk and Voyant already makes use of it. However, I think the Voyant consortium needs a richer set of communication mechanisms than this to promote the growth of what I am would like to call a “broadly informed community”, where as much as possible both the programming/technical folk and the text analysis user community work together towards a common technical vision of how Voyant/Spyral currently works, and potentially could work, to support text analysis or similar scholarship.
What does one need to support the appearance of a widely understood “big picture” vision for Voyant/Spyral: to support, say, the development of newer applications into Voyant: generative AI, for instance? To achieve this, we need to promote a much broader conversation between users and developers that is based on a shared understanding at the technical level. Getting to a broadly based informed community from the present starting point presents challenges, however:
- On one hand, the technical folk who can work with the code have only a limited sense of the research needs of the user community, and,
- On the other, the user community has only a limited sense of the formal structures and mechanisms that are used in Voyant/Spyral and that define what the software is capable of doing.
Clearly, the technical folk need to have sufficient understand of the scholarly and teaching needs of Voyant/Spyral’s users, and the user community needs to have a sufficient understanding of the technical structures that underpin all of Voyant/Spyral.
New ideas about what Voyant/Spyral can do from users can be most readily considered when they are framed in the context of the technical structures of Voyant/Spyral as it is right now. How, then, might this understanding be spread out more evenly through both groups of people? Of course, it’s communication again: they must talk to each other and one needs mechanisms that create a fully informed community where the technical folk and scholarly users can interact directly together. And this works best when ideas not only flow from the users to the technical team, but also flow the other way.[1]
More thinking needs to be done to arrive at strategies for achieving this broadly-based technically informed community. Something the TEI does might be helpful here: their regular “Community Call” could well be a model of what might be done by the Voyant consortium. Figure 4 shows a recent invitation and proposed agenda for the TEI May 2025 community call e-gathering.
[1] For a discussion of a similar problem, see Bradley, John (2024). “Building a Digital Prosopography: towards a scholarly / technical partnership”. In Digital Classics Online Vol 10 No 2. https://journals.ub.uni-heidelberg.de/index.php/dco/issue/view/7383
Figure 4: A TEI Community Call Invitation
Perhaps Voyant should try this too? Community call discussions would not need to be always about technical matters, of course. But a properly planned set of informal discussions could deepen the understanding of both the technical team and the larger Voyant user community, and thereby enhance thinking about future developments for Voyant and Spyral.
Perhaps it is time to give this a try?