software
- Since I’m currently on my fast home Internet, that download will probably last about 20 seconds.
- I have a fast SSD, so the “Extracting files” step might be 6 seconds long.
- “Copying files into place” will run at about the same speed, for another 8 second.
- My shiny new CPU can chew through 100 CPU units in 10 seconds.
Little Snitch 6 came out yesterday with many quality of life improvements.
It’s always the first app I install on a new Mac. New versions are no-brainer upgrades for me. I still wish it had a way to sync rulesets between Macs so that I don’t have to train each one independently.
Smart progress bars
Progress bars suck at predicting how long things will take. I’ll tell you what I want (what I really really want): a system-wide resource that receives a description of what the progress bar will be measuring and uses it to make an informed estimate the entire process’s duration. For example, suppose that an application installer will do several things in series, one after another. Perhaps an explanation of that process could be written in a machine-readable format like this:
vendor: Foo Corp
name: My Cool App installer
stages:
- Downloading files:
- resource: internet
size: 1000 # Number of MB to download
- Extracting files:
- resource: disk_read
size: 1000 # Size of the downloaded archive file, in MB
- resource: disk_write
size: 2000 # Size of the extracted archive file, in MB
- Copying files into place:
- resource: disk_read
size: 2000 # Now we read the extracted files...
- resource: disk_write
size: 2000 # and copy them elsewhere.
- Configuring:
- resource: cpu
size: 100 # Expected CPU time in some standard-ish unit
Because I’ve used the progress bar resource before, it knows about how long each of those things might take:
Ta-da! The whole installation should run about 44 seconds. When the installer runs, instead of updating the progress bar manually like
update_progress_bar(percent=23)
it would tell the resource how far it had gotten in its work with a series of updates like
update_progress_bar('Downloading files', internet=283)
...
update_progress_bar('Copying files into place', disk_read=500)
update_progress_bar('Copying files into place', disk_write=500)
...
update_progress_bar('Configuring', cpu=30)
The app itself would not be responsible for knowing how what percent along it is. How could it? It knows nothing about my system! Furthermore, statistical modeling could lead to more accurate predictions with observations like “Foo Corp always underestimates how many CPU units something will take compared to every other vendor so add 42% to their CPU numbers” or “Bar, Inc.’s website downloads are always slow, so cap the Internet speed at 7MB/s for them.” Hardware vendors could ship preconfigured numbers for new systems based on their disk and CPU speeds where the system can make decent estimates right out of the box. But once a new system is deployed, it gathers observations about its real performance to make better predictions that evolve as it’s used.
We should be able to do a much better job at better job of guessing how long it’s going to take to install an app. This solution needs to exist.
App subscriptions must offer value
Software authors are increasingly switching to subscription models to make their work “sustainable”. Too often they’re forgetting to make a value proposition that helps their customers. Here’s a hint: if you have to write a Medium post explaining why I should support your new business model, you’re doing it wrong.
I understand why authors can’t afford to write an app and then offer free upgrades for the following decade. That’s a great way to cut off the income supply that keeps new development happening. Neither authors nor their customers want that! Creators want to be compensated for their time and users want up-to-date software with competitive features. Buying an application one time shouldn’t come with the expectation that I should get all the newest work for free, forever.
The alternative is not that purchasers are an endless font of cash and goodwill, though. A recent trend is for annual app subscriptions to cost roughly the same as buying a copy of the app each year. In the real world, no one does this and it’s not sustainable. If you want to move to a subscription model, your price has to make sense as a value proposition by itself. Customers don’t care about pretty words and guilt trips in long blog posts. They want a good deal from their own perspective.
From a customer’s point of view, the math is simple: your target annual fee is the previous price divided by the number of years I would have expected to keep a paid copy before upgrading. For instance, if your upgrades used to cost $40, and you released new paid major versions every two years, I can be convinced to subscribe at a rate of $20 per year. Anything beyond that is a price increase, and that increase must be justified exactly as if you were selling me a new copy instead of a monthly rental. That is, you can’t tack on “…and now with cloud sync!”, or “…for teams!”, or pack it with other features I won’t care about and expect that I’ll happily pay twice the old price.
1Password did this right: although their new “1Password Families” service costs more than their old software licenses, it offers lots of features that genuinely make it more useful. Smile Software did this wrong: their new annual TextExpander subscription service costs about the same as their previous one-time software licenses, but all of the new features were geared to a workflow that could not have been less attractive to me if they’d tried. They were asking me to pay a lot more and get nothing of value to me in return.
In summary, you want to make money. I want you to run a profitable business so that you’ll continue to make the software I enjoy. But you have to remember that while your app is your labor of love, for me it’s just a tool I use for work or play and it’s not my life’s ambition. It’s the one among several competitors that had the best value proposition. If that ever changes, I’ll re-evaluate and move on to one of the others. I’m frustrated that this is 101-level business class stuff, and we shouldn’t need to keep learning this lesson anew.
Fun With Software Licenses
Did you know that you’re probably not allowed to make backups of your computer? It’s true, if you believe in the legal fiction known as “End User License Agreements” (or EULAs), which are those annoyingly long contracts where you have to click “I Agree” before you’re allowed to install some program or another.
For example, here’s a snippet of the Adobe Integrated Runtime (AIR) End User License Agreement:
2.3 Backup Copy. You may make one backup copy of the Software, provided your backup copy is not installed or used on any computer.
Nice, huh? If you install this software, its EULA forbids you from making more than one backup copy. This is a deal-breaker for business which keep multiple backup archives from days, weeks, and months past. According to this agreement, you could hypothetically alter your corporate storage system to ignore each of the files that would be installed, but realistically no one would ever even attempt this.
This is just one more reason to be grateful that EULAs are almost universally believed to be legally unenforcable. However, unless you’re willing to tell a jury that you don’t think you’re bound by such an agreement, remember that every piece of software with a similar license is a potential time bomb. Theoretically, you could be sued just for having it, even if you probably wouldn’t be found liable.
Fans of commercial software often talk about the “impracticality” of Free or Open Source Software, but the alternatives are starting to look a lot worse.