That is museum-digital

This was originally a rant published on Mastodon. It deserves to be documented here in a referenceable form.

At the Herbsttagung (Autumn Conference), we were offered to participate in the vendor meeting not only as attendees, but also to be present with promotional materials or a laptop to demonstrate the system. First of all, that’s a nice gesture.

In the end, we put up a poster:

The poster’s origin story should be obvious just from looking at it. 10 p.m. the day before, plenty of alcohol, and a love of adbusting. A quick Google search for Bullshit Bingo and the confidence that the absurdly worded statements are actually, on the merits, sound.

Why adbusting? Because the category “vendor” is a problem. It turns software into something that some distant “vendor” produces and that you then consume.

museum-digital is a loose — and in different contexts constantly re-defined and re-constituted in different ways — coalition of people and institutions with overlapping interests, skills, and capacities. You give what you can; you take what you need.

For some, that might mean that they only want to use museum-digital as yet another publication platform, already have an OAI interface, and probably have no other relation to museum-digital. Everything is automated and out of the immediate field of view. The museum has found another publication channel; museum-digital has more content. Both gain reach. The museum is part of museum-digital; interests overlap.

That might mean you want to use musdb for collection management. Even if you find everything great, there are always reasons to provide feedback. Even if it’s just that the new design is awesome (which is something we regularly heard in recent days).

That feedback is incredibly valuable. Which requirements a given museum has, which workflows fit where and how — or don’t — is something each museum or each individual staff member knows best. Learning from other museums is in everyone else’s best interest. The museum or the person is part of museum-digital; the interests overlap.

Of course, this also requires infrastructure and people who collect that information and distill it into concrete actions. And people who take on the programming. The former is incredibly interesting; you learn an enormous amount. The latter is straight-forward — and meditative.

That both of these hold true is not least due to the radical enforcement of the principles of solidarity and mutual aid. Controlled vocabularies are maintained collectively; new features are never implemented in a museum-specific manner. Before a feature is built, it must be abstracted to the point where it is useful for several different types of museums.

There is one unified data structure for all users - again, with no institution-specific adjustments. And precisely because of this, a new feature can be built once and then be immediately available and fully usable for everyone.

In any conrext, museum-digital or not, locally specific adjustments and modificatopms quickly leads to an exponential growth in update and maintenance effort. The problem is not that development is inherently complex and difficult. But problems arise once one voluntarily commits to make it complex. For little direct gain, and great long-term damage.

Institution-specific adaptations can only work if your institution has either hired its own developers or pays for external ones. That costs a lot of money. The gain: “The data field is now called ‘Signature’ instead of ‘Inventory Number.’”

The loss, if the adaptation also affects the data model and is not purely cosmetic: interoperability is gone; every update suddenly comes with considerable maintenance effort; and often enough it also means commissioning an external firm, bringing with it additional costs and administrative overhead (even more costs). There are more sensible ways to spend taxpayer money. museum-digital doesn’t support this one.

Exception: some things can only work on a per-institution basis. If data from a database that has been set up locally according to institution-specific needs needs to be migrated or imported for publication, specific solutions are required. For regular publication imports, it can also make sense to implement those centrally at museum-digital.

In all other cases, we have documented interfaces and import templates through which museums and their staff can prepare and execute imports themselves.

The question was relayed to me about what museum-digital’s business model is. There is none. The question is wrong. The right question is: how do we manage to not be a business? The answer: solidarity and mutual aid. Self-interest channeled into the right tracks, and pure volunteer spirit. Structures that value small and large contributions alike and are committed to principles, rather than stifling innovation through management structures and hierarchical subordination.

That is museum-digital.

P.S.: There are things that companies inherently do better than losely defined, public-interest-oriented structures like museum-digital. Writing software is not one of them. Providing support, apparently, is not either (if one can somewhat believe the comments from the last ten years of the annual conference).

No — companies simply have the legal form that some requirements demand. A recent conversation with a freelance developer revolved around EU-wide public tenders. He often doesn’t meet the required minimum turnover. museum-digital would have neither the reason nor the structure to even apply.

That public tenders don’t lead to the selection of the best or most suitable — let alone the most economically sensible — software, but simply to the selection of those who are good at responding to tenders, is probably a problem not only in our field.

P.P.S.: That our poster was suddenly nowhere to be found during the cleanup is wonderfully ironic. That genuinely public-interest-oriented structures exist does not match the zeitgeist, and for far too many people it is simply unimaginable. And what you cannot imagine simply disappears from your field of view.

But: alternatives do exist.