As Open Source enters the mainstream and the buzz rises to deafening levels all software producers are going to ask themselves "Should I Open Source?". For these people the answer lies in the business value of open source, rather than the philosophical reward. This article presents the factors to consider when making a decision about opening up your product. The ideas were compiled from talks and discussions with industry experts at the O'Reilly Open Source Convention.
The key questions, problems and advantages to be considered when making a decision are given below. You will quickly notice that the majority relate to your ability to build and support a community of developers and users.
You know your company and product better than anyone. Use the high level descriptions below to determine which points require fine level attention in your case.
Using an open source project as the basis of your product is similar to providing a free demo or making the first month of service free. These methods are very effective because upgrade selling is cheaper than new sales. In fact, it may even be a benefit to lose those customers who don't really want to pay for the product, since they are often the ones placing the heaviest burden on technical support.
A large user base adds value to your product, even though they might not be paying you directly. Lots of users results in bugs being discovered more quickly. Best of all, users of free software will tend to be more forgiving of problems, or even fix them for you! The end result is a very stable product for your paying customers and enhanced reputation for your company.
All the buzz and hype surrounding Open Source makes just the act of opening your products good business. Compared to past technology trends, the Open Source buzz-word is readily accessible to everyone. Which is easier, changing your software license, or rewriting your entire product range in Java? By jumping on the band-wagon, there is an opportunity to leverage the fast-paced and reliable reputation of open source projects for your product.
Buzz and hype are self-perpetuating. Each product and company that embraces open source adds to the general noise. Adding your product benefits the movement, which in turn increases the benefits of adding your product in the first place. The same benefits arise from contributing to open source projects, even if they are not related to your business.
In emerging markets like Linux, the benefit of growing the overall market for a product outweighs the benefits of competing for market share. That's why the Linux distributors are playing nice with one another at this stage. As a product reaches saturation the fight for market share begins in earnest. Here open source can be used to undermine your competitors. Free, open source products can make certain technologies a commodity. If you have a slight technological edge over your competitors, make their products almost worthless by giving away that level of functionality. You then simply sell your technological edge as a value added product.
Placing your product at the center of the open source movement in your field carries significant advantages. Closed API's are of no benefit to free software since it is already completely open. The result is that open source projects tend to be the leaders in creating and complying to standards.
Good open source projects spend a lot of time and effort encouraging community involvement, attracting the people with ideas for improvements and features. Listen to these ideas, they will bring you new sources of revenue through the product evolving in ways you didn't expect.
Open source is a very powerful way to stimulate development. If the project is trailing the technological leaders then those products can act as a virtual specification or roadmap for development. Only now is Linux moving out of this emulation mode. Once that roadmap runs out, the passion of the community for the project kicks in. Good businesses spend a lot of time and money trying to get in touch with and listen to their customers. Open source projects take this a step further getting the end users involved in the actual development of the product, even if it's only in the form of testing, feedback and contributing ideas. That's very different to providing support or customer response surveys. Rather than waiting to see what they get or be asked what they want, users become proactive.
Developing code for open source projects encourages good programming practices. When many geographically isolated people with limited time are working together it is very important to write modular code. The interfaces between these modules need to be well defined and strictly followed. That way, I can work on my module (even completely change the way it functions internally) without affecting the operation of the whole program. Small modules are necessary to allow developers to do effective work in short bursts. This was made very clear by the problems with the Mozilla project. Strong progress is being made and the community is growing now that the main code base has been simplified and separated into managable modules.
Also affecting developers is the conscious thought that anyone can read their code. That makes the inner workings almost as important as the external functionality. The desire to impress peers with the elegance of your code is strong. The result is code that is clear, well though out and has been reviewed multiple times.
Many eyes make all bugs shallow. Jeff Dutky argues that "Debugging is parallelizable" because "although debugging requires debuggers to communicate with some coordinating developer, it doesn't require significant coordination between debuggers. Thus it doesn't fall prey to the same quadratic complexity and management costs that make adding developers problematic." Quoted from Eric Raymond's The Cathedral and the Bazaar.
An open source project can be an excellent way to attract new recruits, which is very difficult in the current technical labour market. These recruits may already have an intimate knowledge of your product through contributions to the project. Best of all, you have a chance to evaluate their suitability in a real work situation by observing their contributions to the project and interaction with the community.
High salaries and abundant work opportunities gives developers the luxury to be more fussy when choosing an employer. The type of work and nature of the company become very important factors in that decision. A lot of developers are attracted by the prospect of working for an open source company.
Using your existing development team to work on an open source project also holds a number of benefits. People who write code in their spare time are usually extremely dedicated and often excellent programmers. Exposing and including your developers in that community will give them strong opportunities to learn from gurus.
Open source projects give your employees the chance to give something back to the community, gain reputation and interact with other developers. For a lot of developers these are strong motivating factors when at work.
The first obvious example is lost revenue through giving your product away. In some cases, this may be abated by selling services or through upgrade selling to a much larger user base. The revenue from specialist products may just be too high to give them away.
In fact, some people question if open source is a viable model for all types of software. Is there a large enough community of developers who are interested in your particular niche to make open source beneficial? Are the problems and code too difficult for anyone but the most devoted to understand? I personally believe that open source can be of benefit to any product since the benefits to the software owner are great, even if the development community is small. In these examples of specialist products customers will usually have a large time and money investment in the use of that software. Under a proprietary model, if the vendor collapses the customers are left in the cold with a system they cannot update. Open source, if nothing else provides the peace of mind that you can always pay someone to work on the code that you do have, even if the vendor shuts down. Although the learning curve may be steep, it may be cheaper than installing and training for a completely new system.
The most difficult, demanding and important aspect of an open source project is the community around it. Any company using open source must be ready to build, nurture, support and listen to this community. The community may try to move in ways that you didn't expect, or that don't suit your business model. As a strong and respected element in the community you have a large influence over these directions, but in the end the community is free to do as it likes.
Supporting a community through interaction and opening your technology for all to see is extremely difficult. It is not a transition that all companies or developers are ready and able to make. Clear communication and an open nature are vital for success. Working habits and methods for developers will need to be changed. People at all levels now need to explain their decisions to a community of users and developers every step of the way.
Open development requires strong, open and scalable software engineering techniques. Methods for accepting and rejecting patches, reporting bugs and so on need to be clear and well maintained. This involves substantial administration work and careful documentation of changes by your internal developers.
It can be very difficult to find a successful business niche within open source projects that have a massive user base. Different users will have a wide variety of needs from the same project, your job is to find the common thread.
Perhaps worst of all, is the absense of a financial perspective in the Open Source model. Free software grew out of anti-proprietary sentiment. Open source adapted the free software ideas to make it more palatable to the business community. Open source is a way of working and running your company, it is not a business model. It may bring value to your product, but turning that extra quality into financial gain is still a difficult question.
