In the world of business, where there is risk, there is always an opportunity. Opportunists take calculated risks to gain higher profit where others are too faint-hearted even to try. This article is about such an opportunity.
FOSS Phobia
If you work for a small to medium scale (may be even large) enterprise software vendor you probably have experienced the disease known as FOSS phobia. This condition causes irrational behavior on the part of management when the company’s software requires third party software components to perform effectively and those components are available through a choice of commercial closed source offerings as well as free and open source software (FOSS) projects.
FOSS-phobic management fails to even consider this choice rationally and decides in favor of commercial closed source offerings. This is because the primary pathogen in this case, the marketing guy from the closed source component, provider is offering a support contract that a free and open source software project cannot match. He also plants this idea of a need of a support contract deep into the manager’s mind so that he’ll decide against free & open source software at any given opportunity, effectively making him a victim of FOSS phobia. Common sense criteria such as licensing, performance, quality of software and stability won’t even come in to consideration after that.
The idea of this article here is not to promote the definite use of free and open source software at any such given opportunity, But rather to emphasize the point of conducting a proper risk vs. gain analysis of choosing either option on a case by case basis.
Rationale
First let’s consider the primary selling point from that marketing guy for their closed source software component, the expensive but comprehensive support contract. Why would you require support in the first place? Firstly this is to gain initial know how on configurations, setup and tuning for the component. Secondly support will be required in order to diagnose and fix a production fault or a malfunction with the given software component. You don’t have to think too much in order to understand the huge incentive the third party software component provider has, in order to make his software seem more complex and hard to learn as possible. This is particularly true of markets where there are only few dominant vendors (less competition) for the same component. Good examples for these kinds of vendors can be found in the enterprise database and application server markets.
Naturally this abuse of power is one of the reasons why the FOSS movement came into being in the first place. FOSS projects do not have an agenda to sell you software, but they do care about gaining popularity among users so that the project can thrive. Therefore you can bet on it that the more popular and successful a FOSS project is, the easier it would be to learn, configure and adapt it for your own requirements and you’ll face also less issues while on production. You’d also observe that the more popular FOSS components have a great supportive community of followers as well as companies that are willing to provide support for it if needed. But I stress again that this is not enough reason to make a general case for using FOSS software components or otherwise.
So how would you go about evaluating a commercial software component vs. a FOSS component to be used with your company’s own software? As I mentioned earlier this would have to be done on a case by case basis. Following are some general rules of thumb for evaluation of FOSS components to be used with your software.
- Make sure the license is not infectious – Some FOSS licenses oblige you to open source your own code once you integrate the FOSS component into your code. More popular non-infectious FOSS licenses are Apache license, Eclipse public license and MIT license.
- Check if the software component satisfies your requirements (functionality, performance etc.).
- Make sure there’s enough documentation online even for the core parts of the code that you might never even touch in the beginning.
- Get an understanding of how active their forums are, in terms of number of questions asked/answered as well as how active the core developers are in participating in the conversations. Higher the activity the better for you in finding answers for common problems as well as problems specific to you.
- Check if there’s commercial support available if you were to require some assistance in the future.
- If multiple FOSS components are available, compare/contrast between them using above criteria to select the better one.
- Finally compare/contrast with the available commercial closed source alternatives, if you can afford it. Author’s personal experience is that FOSS components that filter through above rules of thumb beat commercial alternatives by a mile most of the time, even without considering the cost savings in using FOSS components.
Imagine you made the choice to go with the FOSS component even when there is a risk that you yourself might have to provide support for the component in the future without help from the original authors. You might even be using that component in one of the most mission-critical parts of your software. But this might result in some huge opportunities for your company to profit from in the future.
Opportunity
First opportunity presents itself when the software developers of your company become familiar with that external FOSS component. This might result in better tuning of your software as well as that external component to suit your needs, making your software perform better in the future. This might also result in you being able to provide better support for your clients as well. Also you’ll not be constrained by an external party not to do any changes to the components as the business requirements change. A good example of this can be found in how Google’s Android operating system is used by different software and hardware vendors. Some like Amazon have even managed to fork and customize it according their needs in their Kindle Fire product, revealing a great opportunity for profit.
Another way you stand to gain by your risky investment is when your company requires some vertical integration or diversification. With your software developers becoming experts on those FOSS components you use as support for your software instead of treating them as black boxes, you’ll be in a nice position to sell support for those components as well, profiting in turn from other peoples FOSS phobia. Or you may even be able to build a complete product over it, extracting a profit from that as well. If you look closely you can see this happening all over the enterprise software field right now. Some of the companies that do that already include RedHat with JBoss software and OpenStack, Mulesoft with Tcat application server, Pivotal with Hadoop and Liferay with their Portal solution and many more.
Conclusion
I hope this article has convinced you of the potential gain of adapting and integrating FOSS components into your own software. Though you take a bit of risk in using some of the stuff without any support contracts, it’d still be better in the long run than spending money on support contracts that may end up being a burden to you as well as your clients.
More importantly if you do find a FOSS project useful in some way please make sure you do contribute back to it in whichever way you can as well.
Vimukthi, Welcome to TechWire!