One of the biggest hindrances to offshoring CMS projects is the product license costs. If a project can have an offshore component, one of the ways to do it is to setup an offshore development environment (I will talk about different options for offshoring in a bigger article that I’m currently working on). That means setting up a CMS instance, database instance and probably an application server/portal server locally. This also means that the client has to provide CMS licenses for the SI to setup the software at offshore. However, many CMS licenses are based on per CPU or per box or per user model and this becomes a huge additional cost for the client. Sometimes, there are restrictions built into the licensing model because of which the clients find it difficult to transfer their existing licenses abroad. For a three month project, if they have to buy additional licenses of products that cost as much as $ 50 K per CPU, the total cost becomes prohibitive.
So what do we do? We end up executing the project completely onsite even if it was a perfect candidate for offshoring. There are delays and compromises to quality because you often do not get a person who is an excellent resource, who’s got good skills in that particular product, has a ready visa and can fly immediately. These issues would not have been there if we’d executed the project offshore.
I think the big CMS vendors should emulate what some of the application server vendors are doing and that is to start providing development licenses free if you have bought licenses for production. This will not only make it easier to offshore projects, it will also popularize the products.
Very interesting post indeed – I will link to this on my blog.
I know that Oracle does not charge for development licences but FileNet for example does. The entire pricing structure of the main ECM players is horrendously complex and really needs looking at again.
I wondered if this makes a case for the likes of Nuxeo or Fuego (the two Open Source ECM options) when considering offshoring?
Thanks Alan.
Yes I agree that pricing structure is very complex. For example, Interwoven used to charge a base server cost (per CPU) and then a cost per user and per power user!!
This is when i sometimes think how important standards can be. In the portal/J2EE world, things are slightly better. If a client uses IBM but follows J2EE and JSR 168 for example, we can atleast *theoritically* build all the functionality using an open source product like JBoss and then deploy it to IBM. No need of buying dev licenses!!
/a
Most vendors have a partner program which would enable use of licenses for development use. I know these vary from a few hunder dollars (e.g. IBM) up to tens of thousands of dollars (e.g. Documentum). But still, this would be something your company should be able to afford to invest in to service multiple clients? Of course, the exact terms of each program might work/not work for you.