One of the first requests I received since releasing Backup Pro a year ago last June was for a developer license (1 price/unlimited installations). Truth be told, I was adamantly against it. At the time I thought it was a just silly idea and I’d lose money in the long term for sure. But, due in no small part to the persuasiveness of the ExpressionEngine community, I obviously came around and released Backup Pro Developer last October. Now that it’s been a year, and I’ve been able to see things first hand, I’m going to be making some changes and I wanted to go over the details and my thought process when deciding if they were right for me.



TLDR: I’m going to no longer offer developer licenses on my add-ons starting today and below is why. Anywho…



When I was first asked to release a developer license of Backup Pro, back in, I think, August 2011, I really didn’t like the idea. It just seemed short sighted; a trade of short term gains over long term stability. It seemed to me that, at the time, the ExpressionEngine market just wasn’t large enough to support the model. Too few available customers to offset the potential interest. Basically, the number of new, and available, customers wasn’t growing fast enough to replace those potential sales lost through repeat purchases (yes, I may make more today, but I’m going to make less tomorrow). Not a good strategy for longevity. Nope; no way was I going to do developer licenses thankyouverymuch.



But then I made a colossal blunder; I started to think about piracy. And I realized our piracy prevention options do not exist. Within the ExpressionEngine add-on market there’s a great deal of trust between the developers and the customers.

I can think of no add-on that uses code obfuscation like Zend Encoder or IonCube to prevent manipulation of anything.

(Thanks to John Baxter I’ve learned that Membrr does require IonCube for, I’m sure, some super important reason that’s great for their customers! </sarc>) There are no add-ons that employ any digital rights management (DRM) whatsoever. I can think of none that do any verification of license keys. More, I know of only a single add-on that even validates the structure and format of a license key. Hell, quite a few add-ons don’t even have license keys. We trust and respect the customer as an unspoken rule (unspoken until now I guess…).



Code obfuscation is an abomination of an idea. A black hole of despair for any customer that is, in my experience, forced on developers by business pretenders who want to look useful. There is no good reason to do this and pretty much all add-on developers get this. Preventing perusal, extension, and/or modification of the underlying code is contrary and even anathema to every add-on developer I know; in fact, the exact opposite ethos of ExpressionEngine itself. Plus, it’s ridiculously easy to reverse any encoding so It just makes no sense from a prevention or technical standpoint.



Were we to employ DRM within our add-ons, we would be repeating the mistakes of, well, pretty much the entire entertainment industry, and almost all of the existing commercial software industry. Industries that have spent billions of dollars to effectively treat all customers as criminals. I’m sure we’ve all seen or experienced firsthand the frustration DRM can cause on legitimate use so please, for the love of God, let us never employ DRM within the ExpressionEngine add-on market.



Even simple license key verification isn’t done. And, again, this is a good thing. Even though license verification isn’t, at the core, similar to DRM, it does present a couple issues for customers similar to DRM. For one thing, verification is traditionally done using a remote service that requires constant and responsive up time. If the remote service isn’t running at 100% performance and efficiency, 100% of the time, it can lead to a degraded user experience for the customer in certain circumstances. To do properly, to avoid this type of situation, just isn’t something to be taken lightly. Thankfully, I know of no one who does this and I’m glad for it (outside of add-ons where a remote service is the core of their functionality of course).



So, to me, it all comes down to trust. We’re trusting our customers and, in theory, treating them with respect. We’re trusting that the customer isn’t going to ignore our license agreements. We’re trusting that they won’t do the easiest thing in the world, and just copy/paste our add-on between sites. We’re trusting that customers won’t download our add-ons from those pirate sites that pop up from time to time. And we’re trusting our customers to not use one of the myriad of Dropboxes that are out there that contain our add-ons (yes, we know they exist and mostly don’t care). For this, we add-on developer treat our customers with respect and not cripple or cause degraded experiences when using our add-ons and/or, for most, when asking for support.



And this is how it should be.



But I’m a cynical sumbitch’. While I agree that we shouldn’t do anything to hurt user experience or treat our customers as criminals I just couldn’t get past the idea of trusting customers 100% (not you who are reading this though; you’re cool). As much as I like to think of myself as a forward thinking developer who doesn’t care about piracy the truth is that it does concern me; just not enough to take it out on the customer. I mean, let’s be honest; It’s not exactly a simple process to purchase add-ons when compared to the ease and use of piracy. Seriously people, copy/paste for crying out loud…



Once I realized that is when I started to seriously consider developer licenses. Why not take it off the table? What if, for a moment, the ease and convenience of piracy was taken off the table? It seemed possible to make things easy on customers and still profit. I mean, you’ll never stop deliberate piracy, best leave that alone, but the unintentional kind? Sure, why not make it a non issue?



And by “unintentional piracy” I mean the type of activity where a customer wouldn’t pay for a license is essentially an accident. An oversight. For example, the customer does some prelim prototyping, they grab a copy of the add-on from an old site to test on (fully intending to buy a license if things move forward), and then things progress and they forget. With the way that I personally work, this seemed highly likely. As I said, I just want to code, and I do lots of prototyping. I try to remember to make things right, now more than ever, but paying for a license has slipped my mind from time to time. Me, not being a unique snowflake, it makes sense that others would work in a similar fashion.



There’s also the whole, “Start a project before assets have been payed for” method of development that happens from time to time. Personally, not a big fan, but, yeah sure, whatever, it does happen occasionally. Let’s not pretend it doesn’t. Point though is that once things get underway it’d be an easy and forgivable oversight to forget to pay for the add-ons. It’s not like they’re intentionally trying to be a dick; just that, again, the convenience of copy/paste is pretty great.



Plus, it seems pretty obvious that developer licenses are, overall, a good thing for customers and it is important to be good to your customers. Not that they’re not without their problems but, by and large, it’s a tough argument to make that developer licenses aren’t good for customers. Right?



Outside of the obvious cost savings (1 price for unlimited is tough to beat from a consumer standpoint), they make licensing a breeze. No longer does a customer even have to think about researching an alternative product, purchasing that product, learning about that product or maintaining any add-on licenses. Having personally dealt with this, to me, it sucks. I want to spend my days with my head in code, so anything that distracts me from that goal just bums me right the fuck out. Plus, there are only 24 hours in a day and us web developers are some busy people. One less thing is a good thing.



Another, and likely most important, is that when a customer purchases and add-on developer license they’ve made their choice. This stuff’s hard, and developer licenses allow customers to put their trust in 1 company for 1 or more aspects of their site. When a customer purchases a developer license of a product, that customer is effectively saying that they trust that one product to handle that aspect of all their client sites. It also means that the customer knows the product well enough for that level of trust; they’ve figured things out and know the little peccadilloes of a given product and they still love it. It’s no wonder that customers of developer licenses require far less support than your average customer.



The only, and relatively small, complicated part of the equation is what to do when a client leaves a development shop that has a developer license. How do updates and upgrades happen for the client? For me, I admit, the solution is pretty crappy; hit me up with the developer license key for the product, the devot:ee account name of the client, and I’ll gift the account a license so they can stay updated. Not exactly an ideal solution but it’s easiest on everyone else I think…

But, are developer licenses good for add-on developers? With a few exceptions, and definitely depending on the circumstances, not so much, in my opinion. Don’t get me wrong, there are definite upsides, and depending on a developers long term goals, they can even be a good thing. But if I knew a year ago what I know now, I probably would have passed on the whole idea.

First though, in certain circumstances developer licenses can be good for the developer. Absolutely. If a developer is doing add-on work as a side gig, with no expectation or plan to go full time, they can be a nice and easy way to randomly increase revenue in chunks rather than organically over time. Developer licenses are real good at doing that. If you’re ok with having income that fluctuates heavily month to month, I think you’ll find developer versions of your product to be a nice addition.

Another school of thought is that it really does depend on the add-on. An add-on like Backup Pro, that required hundreds of hours to perfect, and over a hundred hours in support, does not. It’s sort of embarrassing in hindsight, but yeah, an add-on that requires this level of investment should never have been sold with a developer license. Were it an add-on that was simply developed and released at 1.0 or grew slowly and  required little to no further time investments, now that would make a little more sense for a developer license.

Had I not released EE Syntax as GPL, now THAT would be a prime candidate add-on for a developer license. That was a nice and simple add-on that never really got past the 1.0 stage of it’s life.

But, by and large, and for me specifically, developer licenses don’t really make much sense. Backup Pro, Automat:ee, and Securit:ee are all really complicated products that require serious time investment. Yes, even now. Frankly, if that time can’t be financed it’s no longer worth investing in those products, and I should retire them. It’s just bad business and this is the writing on the wall from the above chart.

Now, don’t get me wrong, I love those peaks; there are very few things that a dramatic increase in revenue can stymie. It’s the valley’s that are a problem. In order for me to do ExpressionEngine add-on development as my primary source of income (which is my goal with mithra62), things have to stabilize and/or grow quite a bit. Growth in ExpressionEngine add-on customers is slow coming so the choice is pretty much made for me.

In the above graph (which, BTW, is taken from CT Admin and illustrates the progress of Backup Pro since the initial 1.0 release), note the increase at October 2011. That’s when I first released Backup Pro Developer. As you can see, things definitely spiked upward after the Developer version was released and then took a distinct dive on a month where no developer licenses were purchased (April 2012). Then up again, then down. Again. It’s become inconsistent. It makes much more sense to focus on building a consistent revenue stream especially though because it’s crazy important that revenue is able to be anticipated.

So we have one of those moments where something that’s good for the customer is actually bad for this developer. Which is my long and detailed way of saying that, unfortunately, I’m going to no longer have available the developer licenses for any of my ExpressionEngine add-ons starting sometime soon. (There are some logistics to be worked out first but I will make an announcement.)

Now, if you’ve already purchased a developer license of one of my add-ons, don’t worry. Nothing is going to change for you. You’ll still be able to download the add-ons and never have to purchase a new license or anything like that. This only applies to any customers looking to purchase a new developer license. 

I know this may come as a shock to a lot of customers, that I would be against developer licenses now, but I really do think the market isn’t large enough to sustain them just yet. Maybe, in the future, I’ll revisit things and come to a different conclusion, but, for now, developer licenses are just not worth it.