Verksamhetsberättelse 2020/Story: Maintenance, maintenance, maintenance

Enabling

2020

In this Story we are focusing on the importance to plan for maintenance when developing tools and the preparatory work we have done in advance of organizing a larger developer team.

Continuous maintenance of digital tools, services, libraries and platforms is important. One might assume that this won’t be a problem until something actually breaks, but uncertainty about if something will be supported creates real costs already before that. It is also a fact that things which are not maintained slowly but surely deteriorate until they break.

Wikimedia Sverige has been building, supporting and sometimes hosting technical tools since before it had staff. As the organisation grew and time limited project based funding became more prevalent, especially for technical projects, tools were often produced without there being a natural project to inherit responsibility for it once the funding ran out. Without clear responsibilities, and allocated funding, the maintenance of such tools, when it did happen, have often been ad-hoc upon an internal need for them or a requested fix from the community. But the larger part of the community is not likely to get in touch when they have an issue with a tool which they use, especially if the experience has just deteriorated rather than if it has stopped working altogether. Additionally we have users, and sometimes institutional partners, who might be hesitant to incorporate a new tool into their workflow without assurances that it will remain viable for at least some predetermined amount of time. Finally uncertainty about if something is still maintained or not makes it difficult to determine when not to put time and effort into enhancing or improving it, independently of if that effort is volunteer or staff based.

For these reasons Wikimedia Sverige invested time into developing a first draft of a maintenance guideline meant to, in addition to the issues raised above:

• Give an indication of the resources needed for maintaining old tools, securing budgeting for this and weighing this into the decision of whether to commission a new tool while highlighting the long term costs of implementing a quick and dirty solution.
• Setting up routines for proactive maintenance of tools and for the discovery and addressing of security issues, in both cases handling such before they become an issue for the end-user.
• Making it clear to end-users how long a tool is being maintained and whether improvements, suggestions and bug reports are still worth the effort.
• Improving community trust in our projects and tools by being transparent, from the start, about our long term intentions for a tool.
• And finally, when we abandon a tool, to do this in such a way that the community has a chance of adopting it if they so desire or at the very least being explicit about it no longer being maintained and that it is used at the users own risk.

We wanted to do this in such a way that it created a framework to give guidance in individual cases while still being flexible enough to handle special cases. We also wanted to have this basis in place in advance of the launch of a thematic hub which will drastically increase both the number of newly developed tools and adopted tools and the incurred long term maintenance costs.

While a first draft now exists it still needs to be finalized with input from affected parties, internal and external after which a thorough inventory of the tools we have been involved in developing and setting a maintenance level for each of these.