Wherever I Lay My Hat is Home?: A Complex Case Study of Crowd-Sourcing, Coordination, and Cross-Platform Integration for Hosting Open Humanities Data

1.1 OpenScore at MuseScore: Open Software, Closed Platform

‘OpenScore’ is an effort to digitise and freely distribute public domain sheet music under the maximally permissive ‘CC0’ licence. All readers will recognise that text files in machine readable formats (e.g., ‘.txt’) support wider use cases than images of the same (e.g., ‘.pdf’). The enhanced utility of editable music files over static images is even starker, with additional utility including: playback with synthetic audio, transposition to any key, muting one or more parts (for ‘music minus one’ practice), and more.

While some OHDers may start projects with a relatively ‘free hand’, our story begins already immersed in the world of platforms. OpenScore began in 2017, initiated by the then owners of ‘MuseScore’ which is at once a music notation app and a website/platform for sharing scores.⁶ The notation app is free, open source software released under a licence that guarantees it will remain so; the same is not true of the website-platform. Both have seen major changes over the years since 2017, not least with the changing ownership of MuseScore as a commercial entity and the establishment of ‘MuseGroup’.⁷

In this initial phase of OpenScore, specific items of sheet music were chosen by sponsors of a crowdfunding campaign, transcribed by MuseScore users (volunteers incentivised by one month fee waiver for ‘pro’ access to this freemium web platform per item), and reviewed by the OpenScore manager, Peter Jonas (also at MuseScore). Peter is the only point of continuity from that initial effort, both at OpenScore, and probably also at MuseScore as a commercial entity. The last surviving web presence of this initial phase is internal to MuseScore; all other links have now expired.⁸ Both these cases (of personnel and links) are salutatory reminders of how quickly things can change and the precarity of data maintenance for all, OHDers and otherwise.

1.2 OpenScore takes an academic turn

A year later, that initial phase was slowing down. Transcribers were keen but other aspects were not keeping pace: having Jonas as sole reviewer was not sustainable and the crowdfunding was running out. As such, it was time for a new approach. The present author (Gotham) approached the problem from a perspective more familiar to OHDers: supporting public-benefit work from a starting point in academia, including the frame of ‘academic impact’. Gotham and Jonas had been in discussion about this topic since before the beginning of OpenScore and set out to collaborate on experimenting with the new approach together.

We aimed to take the best parts of OpenScore’s workflow to date, and adjust those that were less effective. Initial work on OpenScore had positively established some brand recognition and also identified a set of keen and competent individuals ready to contribute to the project on the given terms. Gotham sought and gained academic seed funding from the University of Cambridge for the new venture which was ultimately to become the ‘OpenScore Lieder Corpus’. As will be clear from the name, this phase introduced a repertoire focus on songs from the long nineteenth-century. The choice of this repertoire was based on several key considerations as discussed in previous papers which do not need re-exposition here.⁹ What is relevant to the story here is the continued centrality use of the MuseScore platform to OpenScore’s operations at this stage, and the emerging effort to traverse different use cases.

The case for funding was made in relation to a wide range of prospective users who would benefit from editable and adaptable scores. This included academics conducting data science research on the musico-cultural heritage encoded in those scores as well as musicians performing them. From the perspective of academic work this later group perhaps falls under the banner of ‘impact’. From any perspective, having multiple use cases for the same data strengthens the case for a project.

Targetting multiple use cases is laudable, but it is also complex. Some academics are quick to point out that different use cases call for attention to different aspects of the same data. This is as clearly true of musical data as in any domain. For example, musicians and musicology-oriented use cases prioritise fidelity to the source. Some academic-computational tasks, by contrast, prioritise aspects such as strictly reliable alignment between sources which require pragmatic adjustments to those sources that are unpalatable to the former group. This consideration is part of the OpenScore lieder data: while the version of record data is our focus here and reflects the ‘musical’ priority, research use cases in machine learning have required sufficient adjustment to further require the splitting off of an altered (near duplicate) dataset.¹⁰ There are real issues here, without easy answers. At the same time, the protestation that a dataset must be created with exactly one research question in mind is often overstated. One key, clear motivation for creating datasets is to support multiple use cases.¹¹ The importance of this to the field is recognised by efforts to make datasets interoperable, notably the ‘MIR data’ project (Bittner et al., 2019).

1.3 Incentives and Support

In this first phase of the ‘lieder corpus’, we experimented with an adapted personnel structure and workflow. Transcribers were recruited and incentivised in the same way, this aspect having proven successful to date. Jonas now shared management with Gotham, and we recruited reviewers externally, to be paid directly from the grant. Most of this proved more effective and broadly remained for subsequent phases of OpenScore. The exception is the case of ‘reviewers’; later phases gradually settled on recruitment of reviewers from among transcribers. All good transcribers are invited to become reviewers and are incentivised in the same way (per item). Some individuals decide to accept, others prefer to remain transcribing only.

As for funding, the funded period of the lieder corpus was brief. Later funded periods of OpenScore efforts have followed a similar approach of paying some reviewers and/or corpus managers (never Gotham or Jonas), but these are rare, brief moments. The majority of review work has been rewarded on the same basis as transcribers: pro membership. It is far from self evident that this ‘perk’ is a meaningful incentive overall. While some clearly and explicitly appreciate it, it seems clear that the main incentive overall is contribution to the OpenScore effort and the associated values.

The ‘OpenScore Lieder Corpus’ continued to grow, extending far beyond the initial phase thanks to the volunteer efforts of all involved. When that initiative started to show signs of slowing down, we embarked on a second corpus of string quartets (reflecting the interest of the community at that time), and then orchestral works.¹² At the time of writing, the Lieder Corpus is having a renewed lease of life, in parallel with the quartets. It is important to emphasise that these changes reflect the priorities of those keen to participate: the community contributed not only scores, but also to the direction.

We set out the above history in some detail for two reasons. First, it is highly relevant to the story of platform migration which follows below; second, it is important to be realistic about support for such initiatives, particularly for OHDers reading this who may be planning similar initiatives. Overall, external support for this initiative has centred on the following:

• Peter Jonas’ time has been supported by MuseScore more or less formally as part of his work there. This is welcome support, though it is clearly (and understandably) not a commercial priority for the company, so Jonas has to make the case for it and there are no guarantees it will continue, particularly as the ownership, management and priorities change.

• Mark Gotham justifies his time on this project through academic means, including via articles that present the data for research use cases, and by conducting such research.¹³ Broadly speaking, this justifies the time to a limited extent; there is nothing wrong with using academic time in this way, but it is far from what academic structures tend to incentivise.

• Occasional academic funding, sought by Gotham and supplied to those leading the management of individual corpora. Please see the acknowledgements (section 5) for more details.

• In-kind support for transcribers and reviewers from MuseScore in the form of pro membership.

We are of course very grateful for all forms of financial and in-kind support. At the same time, it is clear and worth emphasising that the real powerhouse behind this initiative is the commitment of those involved, predominantly as volunteers. This includes the many transcribers, reviewers and contributors, and even Gotham and Jonas, none of whom is really incentivised to do this for any substantial reason beyond their internal belief that the project is worthwhile – even important – as a mechanism for modernising cultural heritage. We are mindful that this is a precarious set up. Then again, the project is still growing, and that precariousness is not unusual for digital projects around cultural heritage.

2.1 MuseScore.com

The choice of MuseScore has been broadly effective, however we have to distinguish between the ‘two MuseScores’ here. The desktop software (now called ‘MuseScore Studio’) continues to be free and open source. This is the app we use to transcribe (create data). The online platform (MuseScore.com) serves as the commercial arm of MuseScore. We traverse both in that we create scores using the desktop software and store/present them on the online platform. As has been anecdotally reported by other crowd-sourced initiatives, we have found the platform effective as a starting point whereby the large community serves not so much to create a correspondingly large team of contributors, but rather a large number of users and a much smaller group of highly enthusiastic participants.

As a commercial operation, the online platform is naturally driven by complex decision-making with commercial concerns front-and-centre, and details of those criteria not made known to the public (including us). Suffice to say, although we have had a connection to the company from the start, we do not have any influence in that kind of decision-making, and we do know from users that these decisions affect their readiness to participate in an effort like OpenScore. One clear trend is the gradual change to the platform’s freemium model, which has made accessing scores hosted there increasingly difficult, especially for those without a pro account (and therefore payment).

We do not know the relative importance of the two MuseScores (platform and app) to this venture. The distinction between the two MuseScores is central to story of platform migration here, notably with a continued use of the app and a gradual independence from the platform through mirroring data elsewhere. We set out the context and principles for these choices, but cannot easily compare the effect of such a change, and nor can we know whether an entirely different starting platform might have been more effective.

2.2 GitHub.com

Given the changes to the MuseScore platform mentioned above, it seemed clear to that to honour the core value of ‘openness’ at the heart of OpenScore, we would have to arrange a secondary hosting of the data not suject to those controls. We arranged (openly, and in collaboration with MuseScore) to create a GitHub mirror of the data, and enhanced this (manually) with a degree of linked open data, including linking to (and in many cases creating) Wikidata entries for the composers involved. As such, GitHub is the second platform in our story.¹⁴

GitHub is highly popular with computational users, including as that group intersects with OHDers.¹⁵ Computational benefits include the relative ease of managing complex, distributed curation with customisable automation (including via continuous integration). For a discussion and example use case in this field of musical scores, see Hentschel et al. (2025). This functionality is of high importance to those computational OHDers charged with managing datasets. Any benefits this may bring to non-computational users are more secondary, complex, and typically determined by what the computational maintainers do with the data. This is a topic to which we return continually in this paper.

GitHub is also a platform and commercial entity, owned in this case by Microsoft. It may therefore be subject to the same changes and volatility outlined above. That said, files hosted there have always been more freely, openly, and directly accessible even without login. While users need to login to engage with the GitHub platform (add content, comment, propose changes, …), all that is needed to access the files hosted there is the correctly formatted URL. Anyone can download either an individual file or the whole collection with one click and without login. There is, of course, no guarantee that this will continue to be the case, but it has been that way since the beginning of GitHub, and has remained so since the Microsoft buyout.

Some academic teams prefer to avoid GitHub in favour of alternatives like GitLab.¹⁶ According to the criteria discussed here, these alternatives are broadly similar in design, at least currently. Like GitHub, GitLab allows individual file download without login as long as the repository is public. Whether on GitHub, GitLab, or elsewhere, this direct access to files improves the true ‘openness’ of the data for researchers, but for a project focussed on impact for a wide range of users, GitHub’s clear code-centric focus makes it a solution for correspondingly code-centric parts of the workflow and code-centric users. It is not practical or inviting for non-computational musicians.¹⁷

2.3 Zenodo.org

Further serving research uses cases, and at the specific request of some researchers, we later added Zenodo as a third platform to this story. One clear benefit of this move is that all additional platforms increase visibility to some extent. (Additional platforms come at the cost of integration and maintenance, but GitHub-Zenodo integration is especially low-maintenance, as discussed in §2.4 below.) Zenodo is a well-known, and much-visited platform which further enhances visibility, though again Zenodo’s primary focus is on researchers, making for a strong overlap with GitHub and limited added value.

Zenodo also offers the demarcation of fixed, and semantically numbered versions. GitHub also offers this; where Zenodo separates itself is in the minting of a DOI for project, both overall and for each of those versions. This was the reason for the researchers’ request in our case: the wish to cite a specific, fixed version of a corpus liable to change over time. Finally, Zenodo benefits from the host organisation: CERN, an academic institution subject to a governance which is fundamentally different from commercial companies. Related, Zenodo commits to store data as long as CERN is operational,¹⁸ which is a commitment uncommon in the commercial sector. CERN took physical form in 1954. If the past longevity is a measure of future prospects, it may be more durable than any firm in the highly volatile world of ‘big tech’.¹⁹

Some research teams treat Zenodo more focally, largely or entirely bypassing GitHub and equivalents. This means having a DOI and whole corpus download, but not history (beyond those numbered versions), nor individual file download, unless handled in some other way. Perhaps most relevant to the present domain are datasets from the ‘AudioLabs’ (Erlangen, DE) with datasets including Weiß et al. (2023); Zeitler et al. (2024) and most relevantly Weiß et al. (2021). AudioLabs’ data is often spread across platforms or ‘access points’.²⁰

In short, the traversal of multiple platforms is a common experience for teams dedicated to getting their data ‘out there’, AudioLabs very much included. In cases like ours where the data and full history is present on GitHub, little is gained from this additional platform, beyond slightly increased likelihood of discovery, reducing single point of failure (for the extreme scenario of GitHub failing), and ease of direct citation to a specific state for reproducibility.

2.4 Platform Comparison

As will be clear from the above, this story of journeying across platforms is relatively confusing, and traverses not only many platforms, but many criteria for meaningful openness. A summary is in order. At this stage in the story, users can download OpenScore files from one of three platforms, specifically from:

• MuseScore.com, one score at a time, only if they have an account, and subject to the terms of those accounts. Many variables (including the price of account and the ease of discoverability) are subject to change.

• GitHub, individually or entirely, but only if they know to look there and can navigate the public-facing site or command-line interface methods, both of which are clearly designed for computational users. This is a clear case of open in principle, but not in practice, at least not to non-computational users.

• Zenodo, for the whole corpus (not individual score files), again primarily serving computational research use cases.

Two tables serve to summarise information about these platforms along with some other, select platforms which are included because they are either popular or closely related to this task. Table 1 summarises general usability features discussed above as they pertain to platforms that are central to this story (above), and others that are not used or only more peripherally relevant: The International Music Score Library Project (IMSLP), and Wikidata which are discussed elsewhere in this piece,²¹ and Figshare and OSF which are not.²² The columns focus on those considerations most relevant to the present story and as discussed in the main text. We ignore other standard points of comparison such as storage given that all offer relatively generous storage limits, beyond the needs of most OHDers’ projects like the one discussed here. The details of the limits vary by number of files, largest file size, total project size, and whether the project is public or private. They are relatively comparable and the specific numbers vary too frequently to warrant inclusion in an academic paper.

Table 2, in turn, concerns the specific question of automated integration. We re-emphasise the important of this: almost all OHDers’ projects have limited resources and so the maintenance burden is a key consideration. Automation is essential for doing any at-scale work across platforms. In our case, we have organised an automated script for MuseScore-to-GitHub synchronisation, which is easy for us, but not readily available or repeatable for other projects. We cannot make that code public and eliminate MuseScore from the integration table. GitHub to Zenodo, by contrast, is extremely easy and well supported by both platforms (no specialist insight or techniques are required) and highly relevant to other projects. With a small degree of set-up (permission, credentials), GitHub-to-Zenodo syncing can be automated to take place with every GitHub release. As the table shows, this ease of integration is uncommon in other platform-pairs.

4.1 IMSLP and CPDL

Non-academic initiatives include the IMSLP which is the standout success story of music score data sharing on a scale far beyond others discussed here. IMSLP has weathered legal troubles (including a brief take down in 2008) and seems to have been in rude health ever since. It is, however, very strongly focussed on score images (PDFs) with encoded scores in a very subsidiary role. OpenScore engages directly with IMSLP by taking a specific IMSLP-ID as the source of each transcription. We benefit from their vetting of public domain status (we only consider editions they have approved in this way) and provide a complementary service in the form of transcribed data. We see a need for the complementary provision described here (centred on digital scores), and IMSLP does not seem to have any plans in that direction.

IMSLP’s focus on PDFs is also an interesting statement with respect to digital longevity. ChoralWiki is the home of the ‘Choral Public Domain Library’.²⁵ Like IMSLP, this is a user-upload, wiki-style site. Unlike IMSLP, there is an explicit focus on choral music and the format question is more balanced: there are transcriptions in a range of formats, and PDFs are typically made from those transcriptions. ChoralWiki introduces the question of vetting and quality control. IMSLP primarily hosts PDFs that are now in the public domain but were originally produced by professional, named publishers for sale (though there are some user-editions too). The quality still varies of course,²⁶ though clearly the emphasis on professionally produced editions tends to guarantee a decent level of quality overall.

CPDL hosts user-created transcriptions that have not been vetted. They may all be excellent, but there is simply no mechanism for verifying, and so no way to know without manual inspection. CPDL’s de-emphasis of PDF in favour of encoded scores (relative to IMSLP at least) does not mean prioritising any specific non-PDF format: CPDL files may be in any number of formats, including proprietary ones. Clearly, proprietary formats reduce usability: users wishing to use those scores must purchase the software in question, these days usually on a continuous, subscription model. Proprietary formats are especially liable to become deprecated, as seen in the recent (2024) case of ‘Finale’.²⁷ Many files on CPDL are in the Finale format, and while recovery of those files is not impossible, the barrier is considerably increased. The Finale scenario could be seen as a validation of IMSLP’s focus on PDFs, or as a motivation for more community-driven work around open source standards.

4.2 ‘Verovio’ and ‘mei-friend’

Open source standards leads us towards the academic projects in this space: producing corpora of scores, supporting standards for that effort, and developing platform software for engaging with that resource. Between-corpora there is variability in the format/s used and quality of encoding. Within a corpus, there tends to be relative consistency of format and quality. Open standards are almost always used, and all choices (format, workflow and more) are usually made clear in a paired academic paper.

Academic projects also yield yet further platforms for us to consider, notably for the online display of digital scores in open source formats. Apart from specific projects discussed above (from Algomus, Erlangen, and Tours) notable between-project initiatives include Verovio.²⁸ Verovio supports the online display and editing of the MEI format,²⁹ and support for further formats via conversion. For example, the ‘Verovio Humdrum Viewer’ is a notable extension, building on Verovio to enable viewing and editing of the light-weight ‘humdrum’ (aka ‘krn’) format.³⁰ Online MEI editing is further served by the ‘last mile editor’ mei-friend.³¹

These resources are geared towards the creation, adaptation and versioning of scores in supported formats. For that they are are far superior to our OpenScore workflows: while we have some provision for versioning (discussed above), there is no collaborative platform (commercial or otherwise) for editing MuseScore files in this way. There are two issues, however, with the emphasis on:

• code-centric editing. The raw format is displayed alongside the rendering, allowing the parallel editing of either. This is excellent for users who are comfortable with the code as well as the notation. For that user, some edits are easiest to make on the rendered score, some lend themselves to working on the code, and it’s certainly useful to have both options available, linked, and side-by-side. By the same token, this is off-putting for the majority of musicians: even those that are comfortable encoding scores into digital formats typically use GUI music notation software (MuseScore, Finale, …) and simply never see the raw encoding. The code can theoretically be ignored, but this is a barrier in the same way as discussed above concerning the status of GitHub as a platform for file sharing.

• online-only. Both tools are clearly geared towards online use cases. It is certainly possible to create and adapt humdrum and MEI files off-line, but there is no off-line GUI desktop app for this purpose.³² The creation of a desktop app for MEI might significantly shift the usership.

One conclusion to draw from the above might be that these provisions are complementary to the ‘MuseScore Studio’ desktop app, particularly if the very promising MEI ←→ MuseScore conversion tools continue to develop (integrated into MuseScore since v4.2, Hankinson et al. (2024)). There is always friction when changing between encoding standards (even between successive versions of MuseScore); the practical utility depends on how much friction and of what kind.

That complementarity could motivate integration of humdrum and MEI files in fourscoreandmore, or a similar site. Third-party sites can embed MEI scores using the Verovio toolkit; in that ‘read-only’ scenario, the raw-code side can be hidden (which affects usability as discussed above). These viewers also support files in the relevant formats that are publicly-hosted on external sites. For example, any corpus with score files hosted on GitHub, GitLab, or similar can engage the viewer by extending the URL in a fixed and regular way to render that file. This is another significant motivation for the direct file download option as discussed above.

As such, a site designed like fourscoreandmore could present these additional corpora, using the viewer relevant to each with html embedding similar to that currently used for the MuseScore.com files. Alternatively, it could see itself as a complement to the humdrum-specific ‘Verovio Humdrum Viewer’ which includes a dropdown ‘Scores’ menu for many corpora in that format.³³ That is, perhaps humdrum is well-served, and it falls to a site like fourscoreandmore to serve corpora in other formats? The cost-benefit calculation for extending the provision at fourscoreandmore is a function of at least:

• How visible the respective ‘platforms’ are already and how much additional visibility would integration (re-directs) at fourscoreandmore provide.

• The difficulty of automatic website-building in these cases. Considerations here include the stability of the collection and the existing provision of structured metadata.

• The overall benefits of consolidation. Users seeking score PDFs know to start at IMSLP to give themselves the best chance of finding what they seek; users seeking digitally encoded scores arguably need something comparable.

4.3 Knowledge Graphs and Authority Files at Wikidata and Elsewhere

Practically, when it comes to the topic of data sharing and coordination outlined above, much will depend on the sharing of structured metadata. Clearly it would be best practice to have recognised standards for every aspect of the musical data engaged everywhere. At minimum, this should cover the creators (composers and lyricists) and works (and relations between them, e.g., with songs grouped in collections). Better still would be coverage of additional elements such as editions (discussed above), ambiguous and/or mis-attribution (of creators and editors), secondary data (e.g., analyses), and more. Unfortunately, this data does not currently exist at the level of detail required to cover each work that features in our corpora. Moreover, that coverage is especially patchy when it comes to the historically marginalised composers. For instance, IMSLP is probably the most complete, widely used source of metadata for classical, symbolic music and there is an IMSLP source for each work in each OpenScore corpus (as described above). Yet, even IMSLP provides structured ID only as far as editions (i.e., a specific version of a whole score), but not an individual movement. There are also other interoperability challenges with IMSLP’s limited API.

In so far as this metadata exists anywhere, Wikidata is not currently the leading proponent. And while sites like Musicbrainz have done a very impressive job of mapping the terrain of this data, the primary focus on recorded music makes for an imperfect match here.³⁴ DDEX likewise serves to encode individuals’ roles in musical items for the music business purposes of claiming and distributing rights.³⁵ Wikidata is promising, and growing, but currently in the foothills of this mountainous effort relative to those other providers’ efforts. As mentioned above, when we began the OpenScore lieder corpus we found it practical to engage Wikidata up to the level of the composer: some were present already, and we undertook to add a few that weren’t. Doing this at the scale of individual songs was far outside what is practical for the project. The Wikidata coverage has since improved, but overall, that practical position remains. There is considerable work to be done in enhancing the data provision at Wikidata for its own sake, either from scratch, or (more likely) by triangulating between existing sources. A dedicated project could aim to programmatically enhance Wikidata’s coverage from the provision at IMSLP, Musicbrainz and elsewhere. Clearly that is another project, substantial in itself, and peripheral enough to the primary challenges here to be out of scope. Moreover, while ‘triangulating’ implies three sources, there are many more, and even a preliminary look at these sources shows that they are not mutually consistent. Promising and creative projects for navigating this space include accessing the many existing structured catalogues via natural language queries (‘chat’) and LLMs, as demonstrated by the LinkedMusic project (Fujinaga, PI).³⁶ This could be useful for coordination of that data.