Development Roadmap for Django Music Publisher

Django Music Publisher has a narrow focus. It covers the needs of most writers who are also original publishers of their own musical works, regardless if they are the only author or not. It also covers the needs of some original publishers who publish multiple writers. And there is no plan to change the focus.

We currently plan only one major release with several major features, which will be described below. But before we discuss changes, let us mention things that will not change.

Some things never change

Original Publisher(s)

Django Music Publisher originally supported just one publisher per installation. This was extended for the US. A set of up to three publishers in different PROs in the US can be used, with one of them being the “main” one. (In the US, there are three major performing rights organization, ASCAP, BMI, and SESAC. They have additional limitations, such as that if a writer is an ASCAP affiliate, then an original publisher for this writer cannot be BMI or SESAC affiliate. As a result, most US publishers who are publishing multiple writers, have different entities affiliated with each of the PROs.)

No data on other publishers (publishers for non-controlled writers) can be entered.

Administration, Co-Publishing and Sub-Publishing

Django Music Publisher only supports one original publisher per controlled writer and does not take data on administrators or sub-publishers, nor any territory-related data. None of it is on the roadmap for Django Music Publisher.

Writer and publisher shares

Django Music Publisher only supports one model, in which writers maintain 50% of performing rights, while the other 50% and 100% of mechanical and synchronization rights are transferred to the original publishers. The only information needed is the writers’ relative shares, all share data is calculated based on that. If you are from the US, then we need to use a different language to explain this. Writers keep and directly collect writer share for performing rights, everything else is owned by original publishers. Nothing else is on the roadmap.

And some things do change

Variable Fees

Original publishers often keep only a part of their income, forwarding the other part to the writers. Django Music Publisher is being extended with statement processing. Currently, only the fee can be set, and in the next release, some statement processing will be added.

Imports and exports

We will add import functionality in the next release. There will be only a single format, the very JSON that is used for external CWR generation. The external service will provide conversion from several formats.

Same will apply to exports, the external service will convert the data to CWR versions 2.1, 2.2 and 3.0, EBR and several other formats.

Per writer access

The publisher will be able to give direct read-only access to writers, who will then be able to view registrations and statements related to their works.

CWR 3.0 and beyond

The data structure of Django Music Publisher has been tightly coupled with the data structure in CWR 2.1, so it could be used for complete imports and exports. The only exceptions have been related to “general agreements”.

CWR 3.0 is going to be released soon, but it may take a while until most of the societies will be ready for it. The optimistic announcements about Q2 of 2019 being the deadline are simply unrealistic. Anyway, in one of the 2019 releases, we will be expanding the data structure.

Simplified deployment

The largest reason why publishers do not even try Django Music Publisher lies in the fact that deployment is too complicated for a non-techie. This will change dramatically.