Proprietary Software to Open Source - Migration Approach
Nov. 18, 2005 05:33 AM
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.
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]
- 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
- Make your product intuitive, easier to download, deploy and manage: Count on operational excellence, instant gratification and not on proprietary lock-in
- 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
- Blue Wash: Scan for IP issues (patent, copyright and license infringements), there are tools like BlackDuck and Palamida which offers code scanning services
- 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.
is the founder and CTO of SpikeSource, Inc.
Comments on this weblog
1 to 2 of 2
The real reason behind going open source
1 to 2 of 2
Return to weblogs.oreilly.com.
Weblog authors are solely responsible for the content
and accuracy of their weblogs, including opinions they
express, and O'Reilly Media, Inc., disclaims any and
all liabililty for that content, its accuracy, and
opinions it may contain.
This work is licensed under a
Creative Commons License.