When you consider becoming an Application Service Provider (ASP), there are quite a few different aspects to consider. You must consider the reliability of your servers, the bandwidth to those servers, monitoring/coverage of those servers, and – most importantly – how to maintain and manage the application. As I've covered before, the variations between codebases and managing those differences becomes a 2n scenario due to the staging and production version for each client. While this is more manageable than a n^2 or a 2^n (God forbid!) scenario, it can still be quite difficult.
Before we could finalize our launch last week, we had to address this problem or else the pricing structure would reflect the increased difficulty. I believe that CaseySoftware has solved the problem. This won't work in every scenario, but it certainly works in ours.
We have a unique instance of dotProject for our customers… for the most part. All database information, files, etc are kept totally and completely segregated from all other customers. During our testing, we found no way for one customer – authorized or not – to access the data of another customer.
To simplify management, we use a model similar to an application-pool which manages the resources separately but simultaneously references the same group of files. Therefore, when dotProject releases an update to the codebase, we manage that one small set of files and all customers see the same update simultaneously.
One of our largest customers manages content for a set of 65 niche-market sites where the core of the sites are identical. The only variations come in terms of content and theming. We believe that this concept can be applied there also.
We believe that it's neither a new concept and nor is it a difficult concept, but it's a powerful concept.