Audio Developer Diary – Episode 7 – What? Don’t you do that?
Today a little detour through some of the “stuff” that needs to get done with every release. Here I’m going to talk (carefully) about clients who engage me to build products for them, and the assumptions some clients make or some of the things they either are not aware of, or that get forgotten.
So I build plug-ins for myself and for other people, and it’s pretty easy to get caught up in the thrill of the new piece of software that makes the noises you’ve always dreamed of. But if there’s only one thing potential customers should take away from this post it’s this:
A cool piece of audio software alone, is NOT a product.
There’s a whole range of additional processes, tools, and services that need to be in place or need to get done, often these can’t get done by your coder (or at very least shouldn’t get done by them). Let look at a few:
Codesigning and Notarization. So these days (and especially on the MacOS platform) there’s a bunch of hoops that the operating system or DAW supplier will require the plug-in development team to jump through. All of this is to validate that the software that is being shipped is valid and secure, and not full of nasty malware and virus’. So this is quite a reasonable thing to require, but it involves the owner of the plug-in to validate the software in a bunch of different ways – and this often includes setting up developer accounts with these people (like AVID for ProTools/AAX work and Apple for anything on the Mac) . These accounts have passwords and are used to validate software, so you don’t want to be handing out these passwords to anyone. Perhaps you can get your coder(me) to do these steps but in the end its a bad security idea and most coders (me) are very reluctant to do this for you.
Installers. End-users expect to have a one click install process so these need building for each of your target platforms (e.g. MacOS, Windows, Linux etc.). There are lots of software options to help out with this process, but as your installer runs as a stand alone piece of code it too needs to go through codesigning and notarization above. So it gets convoluted (on the Mac) very quickly.
Support. This one’s a biggie. Not because of how important it is – and its VERY important – but understanding who does what, and what they will need in order to do it. Lets divide Support into the three classic IT industry types:
Level 1 Support: – Some one who helps end users with their web-based access to your products and services, it might be about resetting their forgotten password, or dealing with problems they are having navigating thru your e-commerce platform, or helping them trace where their order is up to. Note here how this has nearly nothing to do with any single product.
Level 2 Support: – Someone who helps with end users difficulties with a given product – it might be getting the installer to run properly on their operating system, making sure they’ve put the plug-in in a folder their DAW will recognise, or getting the plug-in to do something they think it should do. Again note here none of this is because “the plug-in is broken”, though end-users often report it that way. It’s that the end user hasn’t read the manual(and really these days who does?), or hasn’t followed the instructions in their DAW, or assumes the software will do something it was never designed to do. It’s easy to identify “Level 2 issues” – once everyone understands what they should and shouldn’t be doing then the software works as advertised, there is no need for any change to the code itself.
Level 3 Support: – Someone who makes changes to the code in a product because that code is broken. Software comes with bugs, and they break out into the wild and they need fixing – that’s this role. Note this is where the software fails in exactly the same way for everyone who has the software and is running it in exactly the same way, or for a suitably large percentage of the user-base.
The coder should ONLY do Level 3 Support. In an ideal world the coder should never talk to the end user – just a person from Level 2 Support who has verified that the bug is real. Honestly I’m a coder – and I know a lot of them, mostly you shouldn’t let us anywhere near the paying public….
So someone, different someones, is going to do Level 1, 2, and 3 Support, and in order to do it correctly they are each going to need to have systems configured for all the possible end-user set ups. So as a *minimum* they will need computers running each of the operating systems you intend to provide software for (e.g. MacOS, Windows, Linux etc.). Often you may need different versions of those operating systems too. There’s more. Level 2 and 3 support are going to need a very wide range of DAW software too(e.g. ProTools, Live, Reaper, Cubase, Studio One etc. etc. the list can get very long) .
Often clients expect or assume that I will be doing all the things I’ve mentioned here (or a very large part of them), and I’m not. I *could* do all of it but it would turn prohibitively expensive for them very very quickly, so at some point in every potential-client conversation I say that I’m not doing these things and why (basically for security and cost reasons) , but much of it seems so far away and so abstract that many potential clients either ignore it or assume its fixable later – which it is, *IF* you remember you are doing it not me. Which is a project management issue, but don’t get me started on that topic. Otherwise there’s a sentence that gets spoken in every client-developer relationship at some point that goes like this:
“What? Don’t you do that?”……