Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?
share|improve this question
Just curious, but whats to stop someone from downloading the update from your repository, and then re-publishing it via P2P networks? I would also note that if your going to have your customers add your repositories to their sources.list file, you may want to mention Apt-Pinning for their own security. Otherwise someone could insert a malicious libc to your repo and your customers would automatically update to it. – Jeff Welling Apr 2 '11 at 7:53

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?

share|improve this answer
My plan was to have it be a random selection every month or so and if you were in the external 1 group one period you were except from the group for several periods. – Scott Keck-Warren Aug 3 '11 at 12:48
You might run into issues with that, since it is pretty much unpredictable which user has which upgrade and who needs to be hotfixed. Say you have a bug in external 1 and a user just dropped out of external 1, you need to push the hotfix all the way to external 90. Maybe you could just ask the customers who would like to be an early adopter? – thiton Aug 5 '11 at 8:01

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

share|improve this answer
Thanks for the feedback. In order to reduce the pain to get people to use this my plan is to have the software run in full feature mode for 30 days then require the customer to purchase at least a years worth of updates and support to bring it out of a "crippled" mode. If they choose to stop paying for the product after that time they can and they just won't get the updates or our awesome tech support. :-) – Scott Keck-Warren Mar 28 '11 at 12:09
@TheLQ: I don't see that as a problem: Having access to the repositories is what you're paying for anyway. If you stop paying, you don't get updates that fix security issues and bugs or add features. That seems like a perfectly sane business model to me. – greyfade Jul 26 '11 at 0:39

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.

share|improve this answer

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.

share|improve this answer

If i was to do it I would do it based on IP address. So when they come to download there ip address has to be on the allowed list to connect to that server other wise they cant download. It sucks if they dont have dedicated ip but unlikly from what it sounds like your talking about if its server based if its 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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.