ONLamp.com    
 Published on ONLamp.com (http://www.onlamp.com/)
 See this if you're having trouble printing code examples


Big Scary Daemons

The Price Quote of Freedom

11/01/2001

Last time, we looked at the basics of selling a BSD-based system in your company. This time, I'll discuss using a price quote to back your proposal.

Many of us think of a price quote as something a vendor uses to tell you how much money he demands in exchange for a CD, a flimsy box, and a thin booklet translated from the original Sanskrit by a native Urdu speaker. These price quotes don't reflect the actual cost of the product, however. A person responsible for computer systems can use complete price quotes to make a decision. Price quotes can help solidify an argument before you even start talking to anyone.

Realize that this process might very well show that your preferred solution isn't cost-effective. In that case, seriously evaluate why you prefer that solution. Remember, your respectability and credibility is your only currency in selling solutions inside your company. Skewing your results will only cost you in the long run. If you cannot objectively quantify why your preferred solution is cost-effective, perhaps you should choose another solution.

First, list your desired functions. Suppose you need a firewall. You might require stateful packet filtering, Web caching, content inspection, and intrusion detection. Some Google searches will quickly give you a list of reputable products that have these functions. In this case, your list might include Firewall-1 or Gauntlet, RealSecure, or Network Flight Recorder, and BSD with IPFilter, Squid, and Snort.

Software cost is the easy part. Call up your local software vendor or the manufacturer and get a quote. Be sure to ask about the cost of updates to the software! Software updates can be a major portion of the cost. Many vendors will only provide them if you purchase a support contract. Be sure to ask the term of the agreement. Will you receive updates forever, or just for one year? If so, ask for a price on subsequent years.

Then you have hardware. One of free software's greatest advantages is its ability to run on obsolete hardware. You probably have a system in the back that would easily handle the load. Before you do this, think about why that system is on that shelf gathering dust. Did it have undiagnosed problems? They might be caused by hardware issues. If nothing else, you'll probably want a new hard drive that hasn't been run for months straight. How about the network cards? A surprising number of "high-end" systems have cheap network cards. For a network server you probably want some nice 3Com XL or Intel EtherExpress Ethernet adapters. If the motherboard has scorch marks, just start over.

Comment on this articleAnyone have any success stories to share?
Post your comments

Also in Big Scary Daemons:

Running Commercial Linux Software on FreeBSD

Building Detailed Network Reports with Netflow

Visualizing Network Traffic with Netflow and FlowScan

All software comes with recommended minimums of hardware and operating system. Check software reviews and see if those recommendations are realistic. If the reviews recommend buying additional hardware, keep the review to document why you recommend this hardware.

Now that you know what sort of hardware you need, get a price on the operating system. Be sure to include the cost of upgrades! While Microsoft offers free patches, many vendors don't. In any event, you'll want to include the cost of upgrades to newer versions of the core OS.

The above is the easy part of a price quote. You then need to add the cost of your time.

Your time might seem cheap to you, but it isn't to your employer. He is paying you because your presence provides a certain dollar benefit. This is very different from (and much higher than) your salary; most of you reading this column require a desk, heat, light, air conditioning, sick days, health insurance, and so on. If you work in a stuffy, dark room without a desk or a chair, your employer is still paying for the floor space where you huddle and cough. Even if you're in an infrastructure position where you support the sales staff, your presence is part of his cost of doing business. He should have a good idea of what your time is worth per hour. Once you have a good quote for the rest of the material, ask your manager.

In many multi-tier organizations your manager will not know the hourly dollar value of your services. A reasonable guess is that your time is worth 2.5 times what you make in an hour. As your salary goes up this multiplier drops, but it's a good starting point.

Your free solution will take more time than the commercial one, unless you've completed an identical project before and already know every step in the process. Then comes the most difficult estimate of all: How much time will it take you to complete each project? The only way to estimate this is to break the job up into subcomponents. Here's a sample list of time estimates for installing a FreeBSD/IPFilter/Squid/Snort system.

assemble hardware:4 hours
document installation requirements:4 hours
install and patch operating system:2 hours
configure system to support software:4 hours
configure IPFilter:4 hours
configure Squid:8 hours
configure Snort:4 hours
document IPFilter install:4 hours
document Squid install:4 hours
document Snort install:4 hours
test:8 hours
deploy in production:4 hours
total:54 hours

If my time was worth $50 an hour, I'd be asking for $2,700 in staff time to complete this. That's a significant investment. Add up the numbers for the other products on your list and see what you get.

Some of these times might seem high to you, while others are low. I always document time to gather hardware on the high end, for example. While you might only spend 15 minutes unpacking the freshly shipped server and lugging the empty carton to the trash, more often than not, you'll find yourself spending an hour looking for the PS/2 serial adapter that you recently saw in one of the drawers on the left side of one of the hardware rooms. How often do things go smoothly? As a general rule, I allow 2 hours for a "trivial" task.

Here, I allowed 4 hours apiece for Snort and IPFilter. I know these pieces of software very well, and can probably churn out suitable rules and exclusions in 30 minutes, tops. What if something goes wrong, however? Both of these packages are continually updated, and it's quite possible that I'll stumble across some new behavior that completely blows away my configuration. On the other hand, I don't know Squid as well. I'm allowing twice as much time to configure Squid. I wouldn't be too surprised if Squid soaked up some of the time I allocate to Snort and IPFilter, but I've tried to allocate enough time so that this doesn't happen. My goal is to be accurate, but error on the high side.

Related Reading

The Cathedral and the BazaarThe Cathedral and the Bazaar
Eric S. Raymond
Table of Contents
Index
Sample Chapter
Full Description
Read Online -- Safari

Some of these tasks might not be applicable to your environment. Perhaps you don't exhaustively test your systems, or you don't provide documentation. (If you don't document, you should; I'll talk about that some other time.) Also, times vary with your familiarity with the software.

Add up all your pieces, and you have a set of complete price quotes for your project. Which costs less?

Now that you have information, it's easy to create a list of the benefits of each package. Remember, the average manager doesn't consider "open sores" a benefit, and "free" is a suspicious word. Get benchmarks, if you can find them. Compare the benchmarks to your needs. Perhaps Gauntlet can handle 40,000 Web requests a second, and perhaps Squid levels off at 20,000. (These numbers are pulled out of thin air, and do not reflect reality in any way, shape, or form.) Compare these limitations to your needs. If you have 100 users, the chances of you hitting that 20,000 requests/second limit are nonexistent.

This honest appraisal can also help tell your manager exactly what it is they're buying. When you're later asked about some feature, you have documentation to show what you do and do not support. This can also be used as a "contract" between you and management. Worst case, a detailed, realistic price quote will enhance your image with your manager and within your company.

Michael W. Lucas


Read more Big Scary Daemons columns.

Return to the BSD DevCenter.

Copyright © 2009 O'Reilly Media, Inc.