Backup Pro Blog Archive
Today, I'm following the lead set out by Solspace and Exp:resso (among others) and releasing a bunch of goodies onto GitHub. I love the idea of making things easier and fun for users and developers and GitHub is a great place to do that.
First, all mithra62 add-ons that have language packs now have those language packs available on GitHub. This includes Backup Pro, Backup Pro(ish), CT Admin, Export It, Automat:ee, Securit:ee, and Flag Master. If you have any translations for those add-ons please do a pull request to make them available to the community. Oh, and all translators will receive a free license for the add-on they've translated once it's been officially merged with the repository so get on that multilingual EE people.
Next, with the exception of Backup Pro(ish), I've put the "free" add-ons onto GitHub. Right now, this includes EE Syntax and Meetup though any new free add-ons will be on GitHub as well. The only exception will be add-ons, like Backup Pro(ish), that are loss leaders and released to build awareness in another product. It just doesn't make sense to release add-ons like those on GitHub.
Hit me up if you have any questions or concerns.
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.
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.
I've been using Backup Pro on a personal MSM site of mine that has 4 sites in it and it runs flawlessly. After installing there are a few settings to input and then it will just work. You need to set your file backup location, i.e. what you want backed up and Backup Pro auto fills that in for you, but you can change it if needed. I did not need to change this setting. Then you will need to set your storage location which is also filled in, I changed mine to store backups above root.The next two settings set the maximum number of backup files and databases you want. There is also a prune option and an ability to set exclude paths so that not everything in your site is backed up.
Be sure to read the full review.
Today's release of Backup Pro to 1.8.6 adds numerous improvements and bug fixes. It's a pretty big update.
First, now you can set custom date formatting to your archive display to keep things inline with your localization preferences. The mechanism uses the same formatting as ExpressionEngine date formatting so it should be easy to pick up.
To make things a little easier to understand when it comes to the Auto Threshold, Backup Pro now includes some human readable defaults. For example, instead of having a text input that you put the maximum space available to store your backups, you can now choose from a list or enter in a custom value.
It's also now possible to keep your remotely stored files within sane limits. Remote files now mirror the stored archives so if something is deleted locally it's also removed from remote.
Today I released updates of 2 add-ons: Backup Pro and CT Admin. Both releases are purely for fixing bugs so unless you're being affected by anything weird you probably won't have to worry about updating till the next time.
CT Admin gets updated to 1.4.2 in order to remove some lazy hard coding and some sanity checks to accommodate some of CartThrob's latest updates. Backup Pro gets updated to 1.8.5 and just gets a fix for some progress bar issues.
Backup Pro 1.8.4 is a standard release including both small new features and a couple bug fixes.
First, there's now Maximum Backup Limits available to keep the number of backups stored on the local file system in check. The limits for both file and database backups are independant so you can allow for different limits for each. Any time the limit is reached the oldest backups are removed first to make way for newer backups. Note that this works in conjunction with the Auto Prune so both options are available.
Like all my recent updates this also includes override config option for the settings to help make deplyment easier. Take a look at the docs for more information about how to implement config overrides.
Lastly, there's a fix for the backup progress page on fast backups outpacing the JS. It turns out that on really fast servers the backups were completing before the Ajax would load, causing the progress bar to get a little fussy. Not a problem any more
Hit up Devot:ee to download the update.
Forgot to include another bug fix with the last release of Backup Pro yesterday. Woops...
This release fixes an issue where filter_var() is being used.
Hit up Devot:ee to download the update.
This is a bug fix release for Backup Pro that resolves an issue with certain FTP servers and how directories are handled.
Hit up Devot:ee to download the update.Octave 2 GmbH was kind enough to put together a German Language pack for Backup Pro 1.8.1 and he's offering it for free to the community! Big thanks to Werner for that. It's stuff like this that makes developing ExpressionEngine add-ons such a treat.
This is a quick release of Backup Pro to 1.8.1 to add UK Rackspace cloud storage and Help Tab support for quick linking to the documentation.
Hit up Devot:ee to download the update.
The details are pretty simple: purchasing a developer license entitles the owner to install Backup Pro on an unlimited number of servers and an unlimited number of their clients sites. It's a clear win for developers who want to take care of their clients but feel that the continued expense of purchasing repeated licenses can be overwhelming at times.
As usual, there's also the free access to updates for the life of the version so staying up to date won't be a concern at all.
I have the best customers. Seriously. The. Best. Customers.
Not only do my customers give me money and love in exchange for my products but they actually <em>invest</em> in my products above and beyond just buying a license. Case in point; the 1.8 release of Backup Pro
I had always anticipated adding Rackspace Cloud sync to Backup Pro as a nice complement to the already popular FTP and Amazon S3 sync. It's such an obvious feature it's surprising no other backup add-on for ExpressionEngine had adopted it yet. But, it was a ways off in the schedule. And then a customer, who really wanted it, decided to up the ante and offer what's called a bounty to get it done ASAP. Blew my mind that someone would offer to pay for me to improve my product. Very cool paradigm!
So, 1.8 includes Rackspace Cloud storage support. But, it doesn't stop there. Below is a complete list of updates and features to Backup Pro:
1. Rackspace cloud storage
2. ExpressionEngine hooks
3. Interface updates
4. Complete Windows Server and IIS support
5. Various edge bug fixes include openbase_dir work arounds.
All in all, a very complete update and one I'm quite proud of. Be sure to update your installations to take advantage