Using an Apt Repository for Paid Software Updates

Question

I'm trying to determine a way to distribute software updates for a hosted/on-site web application that may have weekly and/or monthly updates. I don't want the customers who use the on-site product to have to worry about updating it manually I just want it to download and install automatically ala Google Chrome. I'm planning on providing an OVF file with Ubuntu and the software installed and configured.

My first thought on how to distributed software is to create six Apt repositories/channels (not sure which would be better at this point) that will be accessed through SSH using keys so if a customer doesn't renew their subscription we can disable their account:

1. Beta - Used internally on test data to check the package for major defects.
2. Internal - Used internally on live data to check the package for defects (dog fooding stage).
3. External 1 - Deployed to 1% of our user base (randomly selected) to check for defects.
4. External 9 - Deployed to 9% of our user base (randomly selected) to check for defects.
5. External 90 - Deployed to the remaining 90% of users.
6. Hosted - Deployed to the hosted environment.

It will take a sign off at each stage to move into the next repository in case problems are reported.

My questions to the community are:

1. Has anyone tried something like this before?
2. Can anyone see a downside to this type of a procedure?
3. Is there a better way?

Answer 1

Overall, I love the approach. Piracy issues can't be countered anyway, whether over traditional distribution or automated, and you can avoid the inconvenience of a licensing scheme.

You might get problems with the random selections. Is a customer picked to be an early adopter for the whole duration of your business relationship? If not, how can a downgrade from external 1 to external 9 be realized?

Answer 2

Take a look at the Sparkle framework for OS X, it does a very similar thing to the Chrome update mechanism but provides user feedback so they can skip the update or do it later. I've had applications update on me and change functionality that I needed as was, always best to at least ask the user.

I like the apt idea though, makes sense to do it that way, it's simple and really, really well tested at this point.

Answer 3

If i was to do it I would do it based on IP address. So when they come to download their ip address has to be on the allowed list to connect to that server otherwise they can't download. It sucks if they don't have dedicated ip but unlikely from what it sounds like you're talking about if it's server based if it's for work stations then you may be better off setting them up with there own apt server inhouse and then that downloads a copy via cron job or something over ftp and so on once a week and then there workstations download from there really up to you.

Answer 4

I know of a company that is doing almost exactly what you have described. (Fewer tiers than you have described, and I don't know how they're authenticating.)

The largest problem they had is that some customers block internet access from their appliance. That means those customers are just locked down to the version that they installed. Maybe that's fine. I think they discussed opening up firewall rules with some of those customers. Others just upgraded manually.

Answer 5

This is a good seasoned approach.

Some pitfalls to consider:

• You may not always want to to go 1 percent, 9 percent, 90 percent. Your customers may not be homogenous, meaning you might want to start specialising, say, by region, by device type, etc. in which case a distribution by 1, 9, 90 percent globally no longer makes sense.

• Having a single repository for 90 percent of your users introduces hotspotting - that server will experience the bulk of requests, which means it will be the first to die in the event of a traffic surge, causing an outage for 90 percent of your users. Redundancy helps, of course, but that introduces more expense overall.

• You may have a workflow where certain features are ready for distribution to 90 percent of all users, but a global update will cause features not ready for 90 percent adoption to hit production, introducing botttlenecks in your dev workflow. A fixed distribution will not be able to handle these issues effectively, forcing you to handle this at the application level.

A way to correct for that is by keeping multiple copies of production repos on different servers, place a configurable load balancer in front of it, and then carefully update your production repos incrementally on a rolling basis. In other words, treat all repos as eventually wanting to be the same, but configure traffic so the percentage of users reading from a server is changeable.

The benefit is you can configure distribution of requests at will using your load balancer, you can scale horizontally better (all of your servers can start serving the same repo proportionally if all features are ready for 100 percent adoption), and, depending on how your team's workflow is and your need for region specific updates, you can eventually allow certain features to be available right away without worrying about the other features.

Answer 6

Have you thought about general licensing and phone home type protection for your software?

The issue I see here (without any licensing) is that I can pay for a month, stop, then just keep running on this version. Sure its old, but its free. This loophole will be exploited by at least some people

If you already have licensing, then just have simple unprotected repositories with the software requiring checking the license before running

Answer 7

I don't know enough about your software and/or the nature of your customers, but in many places updates are not installed without being tested. Many companies use a license key that will timeout. Allow them to download the update and initiate manually. Auto updates are convenient, but sometimes users don't like surprises.