This is the first ever guest post on my blog. In it, my esteemed co-author of “PCI Compliance”, Branden Williams, analyzes the use of open source software for various projects.
Here is more information about Branden and his awesome blog:
- Site: BrandenWilliams.com
- Blog: BrandenWilliams.com/blog (RSS)
- Twitter: @BrandenWilliams
"Free" or Commercial—YOU DECIDE!
Open source software that is freely available for download and use is one of the greatest things about our technical community. The fact that at any given time I have a massive library of software available at my fingertips to accomplish any number of software tasks is nothing short of amazing! Then you tell me that if there is something I want to add to the software, I just jump in and do it? WOW!
Don’t let the rest of this post fool you, I am 100% pro open-source. In fact, I released more than one open source project over the years (though nothing recently of note). Open source has a place in research and the commercial world alike.
But can you just assume that open source software is FREE software?
One of the biggest misconceptions that I see in our industry is open source software is free. Freely downloadable, 0pen source software is by no means free—remember you need smart ladies and gentlemen like yourselves to install, configure, and support it. That aside, there is absolutely no reason why open source software should not be used to meet security or compliance requirements.
Before settling on a particular solution (commercial or open source), security professionals should do a full cost analysis including some risk-based elements. I know security people avoid doing this because we trust our guts more than we trust business tools, and it can be very time consuming. When you have to put out fires on an hourly basis, fiddling with a spreadsheet just doesn’t seem like a good use of your time.
Know this: going through the exercise will pay off in spades by showing the team when and where open source is strategic.
Before considering an open source software package, check with your legal team to see if your company has a position on any of the plethora of open source licenses under which software is typically licensed. For example, I work with a customer that strictly forbids GPLv2 software from being used (due to the requirements to contribute code improvements back to the larger community), but permits software licensed under the BSD license. Get a legal opinion from your legal counsel before your business comes to depend on a piece of software.
Once you have the green light on a set of licenses and find a software package that meets your requirements, it’s time to do your cost analysis. Open source software that is freely downloadable does have a cost greater than zero, yet that cost is often left out of the comparison (or incomplete) between commercial and open source software packages. Here are some things to consider:
- Do you have to acquire equipment for this software to run? Be sure to include network infrastructure to support it.
- How much of your time is required to keep it up to date? Estimate it, then use your salary plus bonus, and add anywhere from 15-25% for a benefit load. This will get you in the ballpark.
- Do you need to hire a staff to keep it up to date? Use the same calc above.
- Will someone else in your company have to support it? Same calc as above.
- Will you need a second tier support contract from the open source group to handle advanced support issues?
The base formula should look something like this:
Total Cost = (Total Man-Days * Estimated Daily Salary Costs) + Initial Hardware Cost + Hardware Upgrade Cost + Annual Support Contract.
Whereby:
- Total Man Days = the TOTAL number of man-days you will spend per year. If maintaining this software will take 10% of your time, then that would be 192 hours (based on a 1920 hours/year) or 24 days. If you have multiple staff classes, you will need to do the math in the parenthesis multiple times with the correct corresponding day rates and man-day effort.
- Estimated Daily Salary Costs = Your fully loaded daily rate. If someone made 70K/yr plus a 15K bonus, that’s 85K/yr target compensation, plus a 20% benefit load = 102K/year, divide that by 240 days per year and you get around 425/day. This and the previous would get you a support cost of 10K.
- Initial Hardware Cost = The capital you must spend to get hardware to support your project.
- Hardware Upgrade Cost = Your current hardware is probably on a 3 or 5 year lifecycle. Estimate costs of replacement and divide by the normal lifecycle to get an annualized cost.
- Annual Support Contract = The annual cost of second tier support from the group that writes the software.
NOW you have something to compare to your commercial-off-the-shelf vendor’s estimate. In more cases than some of us want to admit, freely downloadable, open source software can be more expensive than commercial software. That doesn’t mean you shouldn’t use it, or that it always negatively impacts your business. On the contrary, this exercise will help you document all of the costs and risks associated with deploying the package.
Besides, on a personal note… if it goes down at 4am on a Sunday, isn’t it nicer to scream at someone’s face and then go back to bed? :-)
==
Enjoy the guest post – feel free to check out my guest post at Branden’s blog too.
