Selling a Patch

Hi!

I’m a TD developer, mainly for theatre and events. Besides my day job, I’m also composing music- my own stuff, but also for television and (rarely) also for film. For this, a lot of composers use touch screens (mostly iPads with TouchOSC) to switch between different articulations, select notes, etc. Since nothing to my liking was available and I didn’t want to use an iPad, I decided to code my own thing in TD. After some time, this thing generated quite some interest in the community (VI-Control as an example). Even so that me and my music making buddy made a video about it:

Our first plan was to re-code this thing in Electron or find a developer for natively developing it for Windows. But the truth is that re-developing it in another programming language is just way too time consuming besides our day jobs. Also, I LOVE developing in TD. So I thought… what if it just stayed within TouchDesigner?

TL;DR: I’m thinking about selling a patch almost standalone, where TD is “only” the framework which it runs in.
I own a TouchDesigner Pro license. The patch runs on the free version of Touch without limitations since there’s no large textures to be rendered. Is it allowed to sell this patch? Now, of course, TD would be an integral part of marketing this thing, from the disclaimer (e.g. a sub-line saying “Made in and for TouchDesigner” or sth like that) right down to instructions for people how to download TD. It IS aimed at people who probably never heard of, let alone used TD.

I’ve never truly understood what the deal is with selling patches- I know that companies sell patches to be used within TD development, “sub patches” if you will. But what about selling a patch like an app? Is there any difference?

I’d love to have clarity on this matter.

Thank you,

Nicholas

3 Likes

Pinging @lucasm

1 Like

Oh boy - I feel you on this journey, I spent years developing GeoPix, started out as a very rough and organic project with out a name, aimed to drive a bunch of leds for my own purposes, and the UI and functionality grew, I generalized, refactored, started thinking about it as a tool and less of a project, began using it for small gigs, then eventually started looking at it as compared to other paid / open source projects, and thinking about the possibility of building a business around it.

Ultimately, I did not succeed in building a sustainable business model around productizing GeoPix as a paid piece of software, there were a lot of factors at play for me, personal life pressures, need of income, and finally big bad Covid which really took the wind out of the sails. I’m happy with how things turned out with GP as an open source project, though it’s not a primary source of income or anything like that.

I’ll try to distill some of the key points from the almost 5 years of GeoPix’s journey. These thoughts are just my observations and opinions, so read around and take with as many grains of salt as you wish :slight_smile:


Audience

You already addressed this, but the main point here is to consider if your audience is TouchDesigner devs OR if they are outside of that, and would look at your application as a general app.

Obviously if you are making things for folks in this community, releasing code is very easy, github repo’s, tox’s, toe’s, etc. version control is no problem, etc.

For the wider world audience, things get more tricky. You want to start considering how best to package up your project into an installer, deploy TD versions, etc. I’ll dive into this later.

Licensing

TD has it’s own license, so if you package up your project and handle TD install automatically, make sure they see TD’s license text in the process. You can install TD silently via command line, and this is nice for automating things for people, but just make sure they are aware of how the TD license works alongside your own, if you have one.

TouchDesigner projects that earn money require a commercial or pro license purchase from the user, so this absolutely needs to be communicated to the end user since TD is not the experience they are getting, it’s a deeper layer of your app.

Speaking of that, if you do have your own license, you’ll want to come up with a strategy for that.

When I started out with licensing for GeoPix, I thought: gee, software piracy almost always ends up happening for software eventually, I need to take this really seriously!

Well, do not under estimate the amount of work and headache you will incur by going down the road of implementing your own licensing. It is very difficult to get right, and / or very costly to hire out.

I tried to build a licensing server/system to mirror Derivative’s licensing model, I figured the user has to be aware of the TD license, I might as well build mine in a similar way so as to not confuse them.

You have to have local key validation/encryption, cloud license code, database, user accounts, web portals, you dip your toes in A LOT. WordPress sites will disappoint, so will any other off the shelf. You will be best off hiring or doing the work your self from the ground up, clean slate. It’ll suck, but don’t waste your time trying to smash together plugins and other products, you will hit web bloat so fast and you’ll end up rebuilding it anyways.


A possibly more sensible solution for starting out, which I wish I had attempted was to not push for maximum security/cloud flexibility of the licenses, and instead just take a simple approach, like local only, no cloud verification keys, or the least secure but easiest is to just embed a table of say 100,000 keys and just assign keys to folks who purchase manually.

None of these are great solutions either, but they allow you to maintain focus on what matters… which takes me to my next point.

Feature-creep and multitasking overload

One mistake I made was biting off more than I could chew, consistently, over time. GeoPix turned into a massive piece of software. One I could handle if it was truly the only thing I was focusing on, but too much when I factored in licensing, web development, marketing, copy writing, technical documentation, tutorials, etc. That’s more like the job of 2, maybe 3 people, and it just meant I was going to work more slowly across all fronts.

I should add that I tested out making this my full time job for a couple years - and it was still too much. If you’re rocking a full time or part time job and doing this on the side, be extra mindful of how much you put on your plate.

Often times we start thinking of all the cool things our software can also do when Touch is your back end, but if you know what your sole value providing feature or set of features is, spend a LOT of time on that, polishing, optimizing, making it fast and fun and enjoyable to use before thinking of new things to add.

Engaging with your audience is wonderful but also will take time. If you have a small audience and release a beta, you’ll be able to keep up with feature requests, bugs etc. If you have been showing off a product/project to a growing larger audience, you will be hit with a wave of interest, bugs, requests, and it will almost literally knock you on your back if you’re not expecting it. That’s not a bad thing, just something to plan for if you have a significant audience already.

Honestly from your description it sounds like you’re building a really focused and precise tool in terms of use and features, and that will work in your favor big time. Try and get to the point where you are seeing success before letting the project, and feature requests expand the scope.

Packaging up the software

There’s lots of ways forward, I won’t get too technical, but it’s absolutely possible to automate your entire install so the user doesn’t have to think about TD as a separate thing from your app.

You can package the TD installer into something like Advanced Installer(paid) or Inno Setup(open source), you can package install scripts that reach out to derivative servers and download the installer from there. Though I’m personally a fan of installer packages that contain all you need.

Or more simply, you can break the process down into two steps. 1) install TD, 2) download your app installer.

If you launch your project in TD, it by default starts in TouchDesigner itself, which will require at minimum a non-commercial license, and thus a derivative account on behalf of the user downloading your software. This is work they have to manually do. Sometimes signing up scares users away, other times it does not.

Alternatively you can automate the launching of your Toe with the TD installed TouchPlayer executable, which does not require a license, and can run a toe non commercially straight up. This would be the most elegant automatic solution for your end users.

Of course there is always the TD splash screen, they won’t see your own software until it loads. but TD loads really fast now adays if your patch isn’t too heavy, and plus it’s nice to show the user the bad ass ecosystem that makes the software they are using possible :slight_smile: .

How involved you want your users to be in the process is up to you, you can start simple, and just make the 3 step guide for setup very readable and easy to follow. Then package it up more intelligently later.

It can easily take several weeks to a month to really get a fully automated build process and install process put together. You’ll want ways to reset your software to “default” before saving/building, a way to integrate change logs maybe, things like that. Be sure to have this process in place before you start releasing builds, so you can easily address and push fixes quickly as stuff rolls in from new users.

Software Auto Update

This is not as necessary, but personally recommended. If you’re promoting the eventual release of software to people and you have some momentum going there, after the first version drops and the user’s open it a few times, it’s nice to have a little icon turn on, or button that links to the download page at least, so they can be reminded of development updates, fixes, etc. with out having to remember to go to your site again.

I wouldn’t say this has a huge impact in user retention, but it’s a nice mechanic to have in day 1 if you can, to keep users up to date. You definitely should have something like this eventually though.

Paid Product vs. Open Source

This is probably the heaviest choice / fork in the road you’ll have to make, if you haven’t already.

There are two ways generally you can earn money. Paid product, and open source. Besides the fact that both can generate you spendable money, I observed some fairly significant differences in terms of approach.

I ended up trying the product route first, then eventually open sourced as a plan b. If you know what you want to try, you can make more efficient use of your time though, so here’s some of my pros and cons.

Product Pros & Cons

You don’t necessarily have to focus as much energy on online momentum, presence, etc., though that’s not to say you don’t need it. You definitely do. You also will want to have a polished professional web presence for your product. Guides, Downloads, Home page, etc.

If your product fixes a big problem no one else fixes, or makes peoples lives easier in a way no one else does, and you can demonstrate that clearly people will be willing to pay. Even more so if your tool fits into other peoples pre existing workflows with out requiring a huge learning curve.

If you can do these things, and your industry tends to involve expensive software (lighting industry is like this, madrix, elm, etc.) than there’s already an expectation for what software will cost. Lighting industry for example is a bit more niche, not a consumer market etc. You need to price accordingly. Don’t overcomplicate pricing and tiers either.

If you’re market is broad, software tends to be lower cost. Be sure you’ll get the number of sales/audience to justify starting at the lower price you think you want.

Also be prepared to offer support. That might be email, or occasional Zooms / video shares to diagnose issues. When people pay for software, especially stuff used in gigs and live environments, they tend to expect at least some kind baseline support. Be careful to protect yourself too though. If you are selling a license that has a year’s worth of maintenance, think of a way to price your time for support into that, because sooner or later your time will become the bottleneck and you may need to hire help.

Lastly, with products and their licenses, consider how you want to cover the cost of future development. If you release your software and sell a bunch of perpetual licenses, you might do very well year 1, but how do you sustain your income fairly over the years?

I personally think Derivative nailed it with this, and I’ve seen it used elsewhere and I really like it for software. You buy a years worth of updates and / or support for a software, and if you are happy with that version at the end, you can never pay another penny and keep using it forever.

If you do really love the software and keep getting value out of development / updates, you’ll be willing to continue paying for the software updates year after year.

The challenge with this model is building your software around it. How do you handle year to year updates? licensing server and payment portal? ( complicated! ) Or some other way? Something to think about.

Open Source Pros & Cons

We all love open source software, but if we stop and think about all the stuff we’ve used that is open source, then filter that down to the stuff we’ve actually supported monetarily, then filter that down to stuff we’ve actually supported on an ongoing/regular basis… It is a very small slice of a very small slice for most of us.

There are MANY positive reasons to open source, but the crucial question is, how do you convince your audience that your open source software is the one out of probably dozens that they should support with actual money?

It’s a tricky question, I don’t think there’s a clear answer that works every time, it requires reading the room so to speak, and understanding your industry, other competing software, and the type of audience you have or are trying to attract.

One observation I’ve seen time and time again, is that really successful Patreon projects tend to have this “superstar” vibe to them. What I mean is that, if you watch that creator’s youtube videos, or scroll through their project’s other social media areas, there is just this community excitement around it. High regard, it’s almost like a sports team and their fans. It’s a bad analogy because I don’t even follow sports, but hopefully it makes some sense.

If your project has that kind of momentum and engagement, you’ll probably do really well, because then supporting your project is less about paying for a thing you use, and more about rooting for your favorite team.

There’s also certainly a critical velocity on Patreon. Once projects get enough patrons/funds, people notice that enough other people are supporting it and are more interested in joining that.

Other things about open source, people tend to be much more forgiving of issues and bugs, even more proactive in reporting them. Support tends to self generate if you have a discord or slack or fb group where the community can chat with each other.

You tend to not need as fancy of a website or web presence either. You can operate entirely on GitHub for example with a great wiki and releases through the releases page.

Also users tend to be more forgiving or open to getting software installed themselves, to get the project working, vs the fully automated / packaged up nature of productizing.

Lastly and most importantly, with open source you do not need to deal with licensing if you are truly making it free. This means an entirely expensive and time / bug / support consuming part of development is not necessary at all.

There are many many pros to open source that are practical advantages to you, as well as the obvious good feeling of putting back out into the community. The big bad scary in all of this is whether or not you can achieve critical velocity and make enough recurring money from voluntary support. Many many open source projects unfortunately fail in this way.


Conclusion

I think I’ve written enough :upside_down_face: Basically my TLDR here is this:

Open Source is simpler, but riskier, maybe also more exciting though. Productizing is more complex, some less glamourous parts to it, but probably more likely to be profitable if you can manage the extra moving parts (website, licensing, etc) and know what your value point is.

It’s possible to package up your software to be fully automated startup and even install of TD. It takes some work to get there, but it’s possible.

Be mindful of feature-creep and multi tasking too much. You are probably your own worst enemy here.

Licensing is complicated, especially when you factor in your own + derivatives. If the end user is making cash moneys, they need to buy a Derivative license. This is the one part you can’t automate, they have to go to derivative.ca and buy that license, and activate it to their machine, etc.

I hope this helps! Good luck, and hopefully some others can chime in with their experiences in this regard as well.

16 Likes

Amazing write-up.

1 Like