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 a commercial product/service. 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 registration at societies (CMOs, PROs, MROs, etc.). While this is natural, as I have been very verbose about this, only in a handful of cases was this their first concern, or a place where they started. Although from the purely technical perspective, this is where one would want to start, it is the business that drives the development. So, oversimplified, the question was how to build foundations for a building that already has several floors.
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 one could do but start over. While I can come to such a conclusion very fast, the potential clients would not accept my arguments and would keep tinkering. Some came back after about six months, often with depleted budgets that were insufficient in the first place.
Let me cover the technical reasons why the database that holds the 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.
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 issues, many impossible to predict. It is a Pandora’s box, and hope does not cut it. Some, however, can be predicted by any good developer, and some only by a developer experienced in this particular domain.
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, however, does mean evacuating the building for a while, usually at least for several days. (The weekend is rarely enough!)
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. Then it is not just about making the foundations stronger and extending them downwards, but replacing the structure across many floors. And this is, by far, the most common case I have been encountering. And to do this, the building has to be evacuated for a considerable time.
Also, in this case, the experience is really critical, no matter how good the developers are, as music rights are a complicated environment, 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 either about the 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 of the software must at some point test it, then all of them need to be re-educated. Often, for a while, the data has to be managed both in the old and in the new system. This is hard if the software is used only in-house and nearly impossible when it is used by paying clients.
This is where the misconception of small steps comes in. Technically, they may be possible, but they are rarely socially sustainable. One has to make a clear cut. People get far too nervous if things are changing all the time. Adding new features is hard enough, but changing existing one should only be done rarely. In big leaps.