Friday, June 26, 2009

How to make money from Open source ?

Getting started
Visit the well-known open source code repositories such or Search to find projects which are thematically related to the kind of product you want to build. Next, start drilling down into the contestants. There may be only a handful or there may be dozens. Use your heuristic filtering sunglasses to help you whittle these down to two or three selections: Do they do the core of what you want? Are they written in programming languages you know? Are the projects active? Are they available under a licence which is commensurate with what you are trying to achieve?

Next, download the project which appears to have the most overlap with your intended product. Scope the code, audit it for quality, comments, structure and evenness. If it passes muster, you read through the documentation to determine if there's a section to jumpstart new developers into the complexities of the code base. Most of the good open source software projects have this, which is what enables them to become good open source projects.

Now, start making some mods, for example stylesheet changes, logo changes, form changes etc. You want to get a feel for how much time and effort would be involved to get up to speed with this code, and how much effort would be involved in adding any missing functionality your putative product may need, which this open source project lacks.

It's now up to you to determine if indeed utilising this codebase will get you to your intended destination faster than if you started from scratch. Bear in mind a few things however; many widely-used open source projects have seen successive iterations of quality and security feedback, loopsÃ, Code being fixed and enhanced and security exploits being patched. If you start your project from scratch, it may be years before you reach a similar maturity level. Factor this cost in to your decision process too.

Do the right thing by the existing project community; make contact, alerting them to the fact that you intend to build a commercial application upon their codebase, but that you will comply with the licence they have stipulated for the project. Contact with the open source developer community isn't mandatory, just common courtesy.

Package it
Packaging your solution in a form downloadable via the Internet for no cost provides a friction-free manner for distributing your application, allowing you to establish your product's credentials and market presence. You can also provide a packaged version which includes printed manuals and CDs. This is for all those sites that do not like to use freely downloaded software off the Internet, but prefer a real, physical product. Price varies, as it's essentially a service charge. Say $100 to $500. You could also consider building an appliance solution, constituted of preinstalled operating system, database, application server and your application on top. Price: $2k to $10k depending on the level of bundled support. With all your product options, price them in the market sweet spot, to maximise attention and gain as many quick sales as you can.

Marketing your offering
What does it take for your product to get noticed? Obviously, by using open source attributes when marketing your product: Market the fact that you give your customers the complete source code to the system; market the fact that the code does not have a use-by date or sunset clause. If you and your business collectively fall under a bus, your customers can continue to use and have third parties provide ongoing support. Leverage the fact that local business and government consumers are risk averse, and that you, unlike a group of coders in Iceland or Brazil who produced the original codebase, can indemnify your customers using your professional and product liability insurance; market the fact that you are local or regional and can provide same time zone business support.

By commercial support, I mean commercial support. Charge the customers $200 per hour for it, but make sure you deliver the goods. You should also play the perpetual code escrow card. Many potential customers of vertical business applications need to be guaranteed that they will not be left stranded when deploying a new line of business system.

This is one of the main reasons encountered when Australian firms have trouble competing against larger international players. The argument goes that buyers are unsure of smaller Australian firms' business longevity and worry about code escrow. Ensuring that potential customers have full access to the source code is a great way of nullifying this competitive disadvantage.

In short, open sourcing saves you many of the marketing and sales costs necessary in taking your application globally. If your product is good, and there is a global market for it, you have a far greater chance of reaching that market through open sourcing.

Achieving the same marketing reach using traditional means, would cost millionsââ,¬"money that few Australian developers have. News of good quality open source projects travels fast.

Paying the bills
But how do you make money? First up, support revenue. As soon as you can, establish mailing lists and discussion forums so that users of your software can help other users. This takes the load off your team. You will need to kickstart this community by providing technical support freely at first. Once momentum has been reached, provide no more free support. Instead, offer various paid support options, with credit card payments: per incident, quarterly and yearly. For business-grade vertical applications, this could be hundreds of dollars per incident or thousands of dollars per quarter.

Next up, provide installation, customisation and enhancement services. This is where the real money is. Show the market you are a serious commercial open source player. Whilst your code is indeed open source, and your users could extend it themselves, most businesses do not have the time nor the inclination to undertake this kind of activity; it's not their core business. Firms will instead turn to you.

Additionally, no one should know the code as well as you, and your time to build for extensions and any integration work will far exceed others' value delivery. All you need to do is capture just a small percentage of all those users who pulled down a free download and you can generate some real revenue with customisation work. And because any such resultant work can be open source too, you can slowly build upon the functionality of your product, thus attracting more users.

Finally, you can make money by re-licencing. Just because you licence your software under an open source licence, doesn't mean you can't also licence it under non-open source terms as well. For various tactical reasons, the best open source licence to use for this purpose is the General Public Licence (GPL). This approach works especially well for libraries and for products which you could classify as 'engines', such as computing engines (scientific and engineering), database or transactional engines. By using the GPL, anyone who links to your engine or library and plans to redistribute that combination as a total product must also licence their own IP under the GPL.

Many potential customers would prefer not to do this, which gives you the opportunity to sell them a version of your product which is not based on an open source licence. Are there issues with open source licences when reusing the code of others? Specifically, aren't we in trouble if we reuse open source code in our own projects? In most circumstances, no. Most developers in Australia are building bespoke software, which is not for redistribution beyond the client purchasing the service.

This model is compatible with all open source licences. If you or your client wants to redistribute modified binaries of GPL licenced products, you must also supply the source code to your modifications under the GPL.

If you use any of the BSD-like licences (Apache, MIT etc.) only attribution is needed within your derived modified binaries. You do not need to make available the source code to your modifications.

For the full text visit

courtesy :,339028271,339191343,00.htm

No comments: