Concept for
That Green Thing
Music Publishing Software

/media/_versions/images/tgtwriter_full.png

Editing a writer in That Green Thing

Since the first incarnation of That Green Thing, the basic concept has not changed. Take Django Music Publisher, change primary color from red to green, add support for multiple original publishers and administrators. Do it fast.

And, most importantly, keep it simple, stupid!

The same must apply to the reincarnated project!

Take Django Music Publisher…

It turned out it was not that simple.

Manuscript Shares

One of the revolutionary ideas I had for years was to have a single share field. It was implemented in Django Music Publisher since the initial release in 2018.

The original incarnation of That Green Thing used the same model. But, I decided to go with feedback from alpha users and potential clients, and replace it completely with 6 share fields (performance, mechanical and sync for both writer and publisher).

Generating CWR

Django Music Publisher supports CWR versions 2.1, 2.2, 3.0 and 3.1. The last two are not yet in use anywhere. So, I decided not to include them in That Green Thing. But, I wanted to make sure that I can do it easily.

With support for administrators and sub-publishers, territorial CMO affiliations and several minor features, the code that generates CWR in Django Music Publisher was largely useless for That Green Thing. It had to be refactored. Which is just a posh term for “rewritten”.

Add support for…

Other publishers

Another of the revolutionary ideas I have had for years is to ignore information about other publishers. It makes everything needlessly complicated, and sometimes very ambiguous. I decided to allow it in That Green Thing, as muchas I hated the fact at that point in time.

But, this allowed me to add support for sub-publishing. Which is my next topic.

Administrators and sub-publishers

/media/_versions/images/plans_large.png

Plans in That Green Thing are based on features for various publisher roles

That Green Thing has four tiers. But, that was not in the initial plan, actually. It was one tier, one price.

Having multiple tiers often requires a lot of coding, unrelated to creating actual features if done right. In most projects, it actually makes development of future features more complicated. And that goes against “doing it fast” and “keep it simple”.

As I was rewriting the code for CWR generation, I realized I could just squeeze in support for sub-publishers. With some limitations, so that it still fits “fast” and “simple”. I gave in and decided to have two plans.

One of the things I learned from marketing research and my alpha testers is that there are publishers who don’t administer, but do sub-publish. Can administration be seen as an add-on, like sub-publishing? Sure! (And it took only several lines of code.)

So, basic tier and two independent add-ons, that makes four tiers in the end:

  • Basic
  • Administration = Basic + administration add-on
  • Sub-publishing = Basic + sub-publishing add-on
  • Full = Basic + both add-ons

Tier “Administration” is exactly what I originally planned with one tier, one price.

Do it fast

Six weeks from the moment I decided to resurrect the project till the release. This included alpha and beta testing, deployment and maintenance automation, data migration from DMP instances, import of data from (some) CMOs, as well as documentation and a dozen of videos. And this is just the technical side, the business side saw as much work, at least.

Not bad.

Keep it simple, stupid!

Absolutely!

next