Ever pondered how companies make money from free and open source development projects? Could you open source your code and still make a profit? Con Zymaris puts forward the case. In this easy-to-follow guide, we're going to examine the commercial opportunities for open source software. We'll investigate the different ways of generating revenue from open source software and how to reduce development costs by using open source software in your development life cycle and how to select open source software technologies for building that next knockout product. On top of this we will also investigate how to gain access to national and international markets through using the open source marketing methodology.
Before we get started the first question you are probably asking is; why bother? According to Accenture Australia, using open source software as the basis of your development can cut your development time and budget by 50 percent. The open source testing and debugging methodologies have been shown to greatly reduce product development costs, and using open source software marketing and distribution channels can greatly increase the likelihood that your product reaches the broadest market possible, and levels the playing field with your larger, better- heeled competitors.
The next question many would be asking is; sure, but can you make profit from open source software? Let's get this straight from the start. Open source is commercial software. At no stage do open source licences preclude the commercial exploitation of the software. Open source licences are not anti-commercial, they are anti lock-in. This is good for users and can be used by you for marketing purposes. There have been free and open source vendors selling solutions in this space for over 15 years. Open source is not suddenly going 'commercial'; it always has been.
Services not licences
The open source revenue model is one based on a service revenue stream rather than a licence revenue stream. This fosters competition amongst vendors for any class of software. Most open source software is copyright, but released under licences which allow free re-distribution. It is this attribute which allows for the distinctive economic benefits that open source accrues. And it is this in turn which attracts a number of potential customers to consider using software which is sourced from smaller development houses. Customers who would have otherwise never considered your software.
Let's also take a whirlwind look at the industry side of the open source world. We know there are around two hundred Linux (and BSD etc.) open source platform vendors globally. These are firms which pool together hundreds of applications, placed on top of an open source operating system, marketed through a number of channels and via a number of different business and non-business models. Strong competition is evident in this space.
There are also several thousand open source products, solutions and service vendors, including perhaps 300 in Australia. If you'd like more information, visit
OSIA.
Additionally, almost all major traditional ICT industry vendors now support open source software too. These range from tier- one hardware vendors through to numerous enterprise level ISVs. Many vendors of open source solutions also supply proprietary software. Open source software can be bundled with proprietary software, with no problems. Proprietary software can also be built with open source tools, be linked to many open source libraries and run on open source software.
Open source development and distribution models can increase the visibility of local software development as well as of individual programmers. Australia's market size has often meant that we do not have the potential to acquire sales and revenue momentum from the local market. We are thus at a disadvantage in comparison to US-based suppliers, who hit Australia's shores well-stocked with funding, flushed with success and momentum from their home market. Australians are great at tech smarts, but lousy at marketing. We often don't have the financial and managerial wherewithal to take software technology to the global market. If we can't, then why not let the open source distribution method do it for us?
Indeed, why not use open source to form the basis of our product in the first place, reducing our own efforts? To get the ball rolling, recall the Programmer's Maxim: good coders code, great coders reuse.
Before you write a single line of code, let's see how the open source world can help us by saving time and money. The reuse model is merely an extension to the well-accepted idea that developers will have put together a pretty decent toolbox of code chunks, application frameworks and possibly partially complete application husks. When you're planning a new application, it merely takes rummaging around in this toolbox and pulling out the components which more closely match your requirements.
Open source takes this to the logical conclusion, making the toolboxes of 500,000 other developers available to you.
Getting started
Visit the well-known open source code repositories such
Freshmeat.net or
SourceForge.net. 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.
The proof
How do we know that it is possible for firm to develop a commercially viable support, training and custom extension business model based on open source? We have case studies.
Just consider the following success exemplars: JBoss, MySQL, eZ Publish, ZOPE and Trolltech. Let's drill down a little. MySQL AB in Sweden went from nothing to become a name brand in database technology in the space of seven years: over 4 million deployment sites worldwide, earning US$10 million in annual sales and growing. Similarly adept Australian software technology firms can do the same.
Open sourcing your code is not a panacea, nor is it guaranteed to work in every case, but then again, building and trying to sell closed-source apps carries no guarantee of success either, and the financial investment stakes therein are much, much higher.
As with all matters, you should undertake your own diligence and risk assessment, and decide based on careful consideration. At least with the rise of open source, you now have another path to a successful software business, perhaps one that may be better suited to your team and your strengths. Good luck!
