Extending the Music Publisher Software
In the last year, I have been in contact with several companies and individuals who have been working on their own software for music publishers - either just for themselves or creating commercial products and services. They ranged from just thinking about it to having many clients. In this article, I will discuss the most common issues that came up in our conversations.
Most of them contacted me in regard to registrations of musical works. Only in a handful of cases, was this their first concern. Or a place where they started. From a purely technical perspective, this is where one would want to start. But it is the business that drives the development.
The second misconception they often had was that this can be done in small steps. They needed to keep the building in use while raising it up to build foundations. The third was that they already had almost all the metadata needed for registrations. There are some foundations, they are just not quite strong enough.
Many of my tools were built to help in this process, as well as Gord Dimitrieff’s PHP library for CWR. In some cases, I made custom tools, as the general ones were not appropriate. But in many cases, there was really nothing to do but start over. While I can come to such a conclusion very fast, a potential client rarely accepts my arguments keeps tinkering.
Let me cover the technical reasons why a database that holds metadata for musical works must be at the core of any comprehensive software for music publishers.
It is really simple. In a database, some entries have references to other entries. It is natural for a recording to reference composition and for a composition to reference composers and lyricists. It is natural because there must be a composition before there is a recording and a composer before there is a composition. It would be unnatural for references to point the other way. (“Natural” means in accordance with the nature of data and database.)
To be clear, some of these references can be empty (null), and in this way, the structure can be extended towards foundations, with actual data added later, as it becomes available. But by doing this, one is exposed to a variety of potential issues. Some can be predicted by any good developer, some only by a developer experienced in this particular domain. Most are impossible to predict. It is a Pandora’s box, and hope does not cut it.
The only way to avoid most of them is to allow a null reference temporarily, add all the missing data, and then disallow it, making this data required in further entries. This means stopping the process for a considerable time, often weeks.
Bad data structure
While this is never a simple task, things get much more complicated if there is some data in a badly designed structure. And this is the most common case I have been encountering.
In this case, the experience is really critical, no matter how good the developers are. Music metadata is a complicated domain with poorly documented processes and formats.
The real problem is really not in the technical domain. The software can be installed in a different location, data can be copied and developers can work there, and once they are done … well, no, it can not just be copied back. It is not about data entered in the meantime, this can be solved with relatively simple scripts, with some minor exceptions.
It is the social structure that needs to be rebuilt as well. The actual users must be re-educated. For a considerable time, data has to be managed both in the old and in the new system. Twice the usual job plus time for education. This is hard if software is used in-house and nearly impossible when used by paying clients.
This is where the misconception of small steps comes in. Technically, small steps may be possible, but they are rarely socially sustainable. It is extremely stressfull if things are changing all the time. Adding new features is hard enough, but changing existing ones should only be done rarely. In big leaps.