How can we make the brave decision to create a project entirely or substantially using Open Source Software (OSS)? In this article I take a look at a few ways in how we can justify the use of OSS for our projects and the criteria we can use to make the right selection
The Open Source Software Conundrum
Risk vs. Reward
So you’ve got a brand new Greenfield project and a budget and you’re raring to ago. You know you will be judged not only for delivering your project on time but also keeping a tight hold of your budget.
“So I know,” says the inner IT muse, “I shall brave the wilds of the Open Source menagerie and reap the rewards by being lauded by my peers and score with the bean-counters by using free software!”
You may be on to something there, the rewards for going the OSS route is that it is practically license free (a fact that your CFO will like), is admired and supported by many including your peers, and in many cases have huge and active user communities. But before you go down this path you need to also consider carefully the risks.
One risk of using OSS is that many open source projects are developed by a community that work in their spare time. It stands to reason therefore that they may have limited time to fix bugs that may well be a showstopper to the progress of your project. The OSS you choose for your project may also fail in time or be orphaned, due to a myriad different reasons that are entirely out of your control. OSS typically has a steeper learning curve, requiring more skilled resources working on your project that in turn raises the question of opportunity and hiring costs that need to be considered. Unlike their professional brethren, OSS may not have the required community help you need provided in a timely manner and this can lead to costly project timeline overruns. OSS also often do not always have the best documentation and this can again lead to project time lost. All these are serious and important considerations that cannot be dismissed lightly.
An Open Source Strategy
So do we give up on an Open Source strategy and move to an expensive and often bloated software solution with the substantial costs? Sometimes this is necessary and there is nothing wrong with that approach if it makes sense in your case. What I propose here, however, is a simple selection strategy you can use to decide if Open Source is the way to go for your project.
The assumptions I make here are that you are not dealing with some intractable legacy issue and that you have more or less a Greenfield project to work on.
1. Examine your Resources
This should always be your starting point once you have an approximate idea about the kinds of software you will need for your project (e.g., Operating System to host apps, Coding platform). Even in a Greenfield type project you would first need to examine who you can bring in on the project and what they will cost. By costs I don’t simply mean salaries though that will indeed be a major part of your OPEX budget but also opportunity costs. What else can or should they be working on based on the over-arching initiatives of the business? So in looking at your resources first work these priorities out and then assuming you have a team you can assemble have a good understanding of what their skill sets are. Do an analysis on their expertise on the key software you plan to introduce. Running on Linux? Fine, how good is your Sys-admin team on not just Linux but the flavour or Linux you are considering using? Plan to utilize a MySQL cluster? Does your DBA have any experience in the MySQL cluster engine or will he or she have to pick it up?
Having to learn new things is one of the joys of being in IT so it is certainly no showstopper but you will have to factor the time in for your project, and sometimes this can be a considerable factor.
Sometimes in doing your analyses on your available resources you may realize that going down the open source is not your best solution. In that case be always pragmatic and go with the strengths of your team.
2. Choosing the OSS
Ok so you’ve done your resources analysis and you’ve picked or are about to hire your team. At this point you should have some idea about the software you want to use for the project. However typically you will have a range of software that you can use for each part of the piece and will need to drill down. For example, your team has a Linux expert so you can go in that direction but what flavour of Linux (of the many dozen distributions and flavours out there)? For example, does it need to be ready for enterprise use? How exactly do you select the OSS for you? Personally I have found the following criteria handy for the given situation I am in. I choose my OSS based on the following criteria, and I typically require the answer be a ‘Yes’ in all 3 of the criteria listed below:
A.) Are there companies of the size I am working in or larger using this software for professional projects?
If the answer to this question is yes it gives me some assurance that others before me have beat this part and succeeded. A lot of IT decision making and strategy is based on an assurance of future success and it helps to know that someone else has done so – albeit for what could be a very different project with different resources etc. – but it can be, and more importantly has been done. If you need further assurance than simply call or email the project manager or CTO/CIO of the company in question. I find that colleagues are only too happy to share their hard won knowledge if approached politely and can have extremely valuable insight for your project ahead.
B.) Is there a large and active user base and community both using and supporting this software?
If the answer is yes it increases my confidence level in the success of this project. It means that there is every chance that this project is not going to end soon and that should I have questions that need to be answered they will get answered in a timely fashion.
C.) Is there a Professional Services package you could purchase for the software in question?
More often than not, an IT decision maker will choose a professional proprietary software vendor on the strength of its support program. This makes sense as it’s his or her job on the line when things fail and having someone else to turn to (or pass the blame to!) in a timely fashion, seems like a smart move. However all joking aside, OSS that have a Professional Services package only makes sense. The risk of not being able to get answers when you need it and the time wasted in finding an alternate solution late in the project is too costly by far. You can mitigate this by paying for the appropriate level of support you need.
Conclusions
When I choose an OSS I tend to make sure that all 3 of these criteria are met as a minimum and that the Resource question also makes sense for your given situation. In making this fairly simple analysis you can improve the odds of success in selecting the right OSS for your next project.