Proprietary Software to Open Source - Migration Approach
 | ||
 | Email weblog link | |
 | Discuss | |
 | Blog this |
Murugan Pal
Nov. 18, 2005 05:33 AM
Permalink
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:
- 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.
Murugan Pal is the founder and CTO of SpikeSource, Inc.
Showing messages 1 through 2 of 2.
-
open communication
2005-12-29 17:49:58 ctcbmw [Reply | View]
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.
-
The real reason behind going open source
2005-11-21 07:58:57 Condamoor [Reply | View]
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.
| Showing messages 1 through 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.
