Proprietary Software to Open Source - Migration Approach

by Murugan Pal

As more and more IT and ISV executives understand the power and promise of open source, proprietary software companies are starting to adopt the open source model. I quoted this phenomena as 'Opening Up - Who, When, What' in one of my presentations in May 2004. Since then, Ingres, Open Solaris, and many other commercial products have been open sourced. Recent announcements on Google's Free Urchin (free software, not open) and Sun's PostgreSQL support stress the importance of ‘Software Delivered As A Service (SAAS)’. Larry Augustin's editorial describes why open source model is better very well.

Just in the last week, 3 proprietary software companies informally discussed with me on how to open source their products. I suggested the following migration approach and thought would share the same for wider community consumption.

Pricing Model:

Commercial and Proprietary software vendors charge one time License (L) and annual Maintenance/Updates (U) plus Support (S) fees. Remember, in open source model - you 'may' not be able to charge for newer versions ('Upgrades') as that restricts customers and violate the open source adoption model. Typically, the maintenance and support costs are 18 - 22% of license cost. When you migrate to open source or SAAS model the L becomes zero as the software itself is free. Customers prefer at least two third cost savings on a 5 year TCO before making a software migration.

Hence, you may want to price your Updates & Subscription as a nominal annual subscription matching to 12% of your typical license costs derived from: [( L+L*5*20/100)*1/3*1/5 - mapped per year on a 5 year TCO of L+U&S after two third cost savings]

Migration Steps:
  1. Decide on the business model and licensing type: Caveats include how your business model will be perceived by community, licensing type impacts your prospective customers, and competition exploits your open sourced offering

  2. Make your product intuitive, easier to download, deploy and manage: Count on operational excellence, instant gratification and not on proprietary lock-in

  3. Conduct Technology Audit and do code walk through with architects and senior developers: If there are suggested improvements, either you can improve the code or document it for community to improve/enhance

  4. Blue Wash: Scan for IP issues (patent, copyright and license infringements), there are tools like BlackDuck and Palamida which offers code scanning services

  5. Community Involvement and Enablement: Have an action plan for how community can benefit from the offering. The community of developers or users or administrators must have key take-away after visiting your community site. This is important as open sourcing a product without a plan to help foster a community does not help.


2 Comments

Condamoor
2005-11-21 07:58:57
The real reason behind going open source
While the modalities to convert from a closed to an Open source license maybe well understood, one wonders at the intent of closed source companies to open up. Will they follow the spirit of the Open Source without any conflict of interest? Are they embracing Open Source only to suffocate? Will the community trust them enough to support and adopt their products? It will be interesting to see how Gluecode, InnoDB etc. fare over time now that they have big corporate support.
ctcbmw
2005-12-29 17:49:58
open communication
One thing I would add is the development model around the open source project. The development should be open communication, not just open source, otherwise, itís more like free software.