Why are there so few working administration sofware solutions for music publishers?

If I had asked people what they wanted, they would have said faster horses.

This quote is, probably falsely, attributed to Henry Ford. However, it does raise an interesting dilemma. On one side are the potential customers, with their needs, wishes, expectations and concerns. On the other is the technology, both existing and potential.

Customers usually know what they don’t want. Regardless if it is slow transportation or typing the same metadata over and over again, that is the only thing that an engineer can believe. While wishes, expectations and concerns may give some guidance, they usually are misleading.

So, what does “faster horses” translate to in music publishing? For a generation used to a criminally slow software everyone used for decades, it means making a much faster clone with many new features. For a new generation of creatives, it means a great user experience. For people used in dealing with metadata in Excel, it means better templates. But all of that is really just “faster horses”. And obviously one can not have a fast system with redundant data (implied by spreadsheets) with great user experience.

I am actually extremely conservative when it comes to tech. I truly believe in programs that do one thing well, and that output from one can be the input into another, the first two principles of Unix philosophy. And just about any device made in this decade runs on some Unix-like OS. Smartphones, cameras, dishwashers, cars, just about anything without a Windows logo on it, proving that it has some merit.

Metadata Exchange Formats

Lack of free and pragmatic and universally usable metadata exchange formats has been sustaining the monopoly in administration software for music publishers. Let me explain what free and pragmatic mean in this context. Free means that one can use the format without any limitations. Applying for a licence is a huge limitation in this context. Pragmatic means that it is part of the contemporary programming practices, e.g. understandable to contemporary developers. Universally usable means that it can be processed fast regardless of the use case.

This is where music publishing has been failing. DDEX is definitely not free, and not universally usable (no normalized data format can be). CWR is free, but outdated by three decades at least, and therefore not pragmatic. Both CWR (and related formats) and DDEX are formats that do one thing. But that is not the same thing as programs that do one thing. Formats that do one thing are just electronic versions of bureaucratic forms.

There are some initiatives out there that claim to be working on new formats, and some of them are smart enough not to use blockchain and smart contracts for it. But I have not seen any workable open source solution yet that uses any of them. Nor any institutional receiver or a service that accepts them.

I did take all the projects I worked on in the last year and came up with a JSON-based format. While it is far from perfect, it does fulfil these requirements. If you are interested, have a look at Django Music Publisher. It is a free, open source solution, though only for original publishers, so no territory-related data is available. But it can be converted into MWN (DDEX) and CWR, including the upcoming versions 3.x. I still have to do some refining before I finalize and document it.

Seamless Integration

If we did have such formats, then we would be able to exchange data among existing solutions and integrate them in ways that would be seamless for end users. This is one of the reasons why I released Django Music Publisher as open source. So companies that would naturally provide an interface for adding and or extending publishing metadata can do it in a simple way. They can just use the code or simply translate it into the programming language they use. Or integrate at the database level. Or…

But this brings us to the first principle. Software should be modular and each module should do one thing well. Django Music Publisher’s one thing is the management of metadata required for registrations of musical works. I am still wondering if extending it to include registrations of recordings would not be pushing it too far.

However, when it comes to processing royalty statements, something that I have started working on, it goes into a separate app. The interface will provide seamless integration, but the functionality is only loosely coupled. Although the registration of recordings is still on paper, it will be able to handle royalty statements on the performing side as well. It really comes down to defining interfaces well.

I truly believe that things will change in the next couple of years and various services will integrate my code or a similar one. And if they need more, then they will use API services for data processing.

There will be only a few new solutions, but existing services in music industry will integrate vertically.