Don't believe analyst firms' reports or vendors' measurements of the total cost of ownership (TCO) and return on investment (ROI) of Linux and open source. Businesses that do their own measurements will get a true picture of the cost savings associated with open source software (OSS), according to Russell Pavlicek, who led a workshop on the topic at the LinuxWorld Conference & Exposition in San Francisco last week.
"Most ROI and TCO measurement methodologies and analyst studies have been created for or by vendors and are aimed at proving their points," said Pavlicek, senior Linux architect at Cassatt Corp., an automation software vendor in San Jose, Calif., and former Linux evangelist for Compaq Computer Corp. "In the Linux field particularly, find out who paid for the study, and you'll get unsurprising results without exception."
Pavlicek's views on why most ROI and TCO reports are wrong, how OSS cuts costs and how to run independent ROI and TCO measurements are discussed in this article, based on his workshop and a one-on-one interview with SearchEnterpriseLinux.com at LinuxWorld.
Freedom, a term associated with Linux and open source, translates to cost savings and control for business users. When evaluating products, comparing licenses and costs per person is necessary, but that alone isn't enough, Pavlicek said. Control needs to show up on your spreadsheet, because controlling software makes an IT infrastructure work more effectively and increases a company's profitability.
Control equals precision of implementation and the ability to run your business as you want it, not the way your software allows you to run it. "Stop being satisfied with software that does 85% of what you want," Pavlicek said. "Take control and get 99.9%."
Historically, controlling software has brought higher costs, like in the 1980s when custom software was commonly used. By 1995, commercial off-the-shelf software brought lower costs, but less control. Generally, people had to make their business processes fit the capabilities of the software. Today, Pavlicek said, open source offers the control of customizing software, as well as low costs for acquisition, upgrades and maintenance.
Open source software tends to be modular because open source developers realize their creations will probably be used to create other products. As a result, they write software with easily usable components, pieces that can be interchanged, Pavlicek said.
"Modular software generates true industry standards that enable the use of interchangeable components in one solution," Pavlicek said.
Modularity enables easier migrations, too. Moving off Unix often requires scrapping the operating system, applications and hardware.
"With open source, you don't have to throw out everything," Pavlicek said. "Open source is not tied to a single hardware platform and is not so tightly bundled that you can't replace pieces of it easily. Also, multiple vendors have access to the same source code so vendors can be replaced."
Don't believe reports that jack up the costs of porting proprietary applications, Pavlicek warned.
Quick fixes, easier deployments
"I don't know how many times, I've seen a proprietary software project stopped and even scrapped completely because a bug appeared, and vendors didn't fix it quickly," said Pavlicek, who added that finding a bug in production software can stop a company in its tracks, too.
With open source software, users don't have to wait for vendors to fix bugs. Once a bug is spotted, users can fix it themselves and/or notify a community of developers who will work on it quickly.
Quick fixes of OSS bugs and vulnerabilities also increase the security of the software, Pavlicek said. With open source, as opposed to proprietary software, it's far more likely that security vulnerabilities will be caught before there are intrusions and quickly fixed if an intrusion occurs.
"Don't blame yourself or your users for security breaches," he said. "It's the vendor's fault because the product's security sucks. With open source, you have a hand in making software security not suck."
Also, developers work on enhancements for each open source product. Users can submit your enhancements, too, and others will work to improve them.
"Open source allows you to fix bugs and get enhancements and changes in code before deployment," Pavlicek said. "As a result, you have clean deployments of a polished product, and that reduces cost."
Reduced license maintenance burdens
Pavlicek explained that OSS was not audited by the Business Software Alliance (BSA), an anti-pirating watchdog group that has often acted on behalf of Microsoft. In one celebrated case, BSA and Microsoft required the City of Virginia Beach, Va., to produce an inventory and proof of purchase for every Microsoft product being used. The city couldn't find all of its documents and had to pay Microsoft a settlement of $129,000.
"It cost the city $81,000 in staff time trying to comply," Pavlicek said. "But with open source, you don't have to spend time chasing pieces of paper."
Easier upgrades, less fear of obsolescence
Typically, upgrading a proprietary application often requires upgrading the operating system and hardware it runs on, too.
"Open source doesn't play that game," Pavlicek said. "After you deploy open source software, you are no longer at the mercy of the vendor's roadmap."
OSS also eliminates fear of obsolescence and dependence on vendor viability and survival. "Even when a commercial open source software vendor fails, the code remains," Pavlicek said. For example, the commercial OSS company Eazel failed, but its product Nautilus still lives on and is maintained. By comparison, "who is still using WordStar?"
"With OSS, discontinued products are no longer cause for alarm," Pavlicek said. "Because the code is available on OSS, you will be able to get yesterday's data. What is your WordStar data going to be worth in five years? Can you really trust undocumented file formats for decades?"
Create your own ROI measurements
If you are comparing an OSS product with a proprietary software product, there's no reason not to use the proprietary vendors' numbers. Add your own numbers and make a comparison, Pavlicek suggested, but don't use their methodologies. Don't just copy the vendor's spreadsheet and fill in the blanks. "Vendor's ROI and TCO methodologies have holes or give more weight to issues that play in their favor and trivialize others that don't play in their favor," he said.
When creating a custom ROI testing methodology, measure the cost of acquisition, migration and training, maintenance and day-to-day costs, including downtime.
When measuring the cost of migrating to that application or distribution, include the technical migration cost of re-implementing apps on Linux. "Don't believe some proprietary vendors' claims that this is a continual cost," Pavlicek said. "It's a one-time bump."
Remember that staying on your current platform will require migration to a new version, and that means paying the related costs, too. Measure those costs, and compare them to the cost of migrating to OSS.
Make sure you cover absolutely everything in your checklist. Include measurements of any process or product and services process that might be unique to your company or the system itself.
"Don't omit anything," Pavlicek said. "One of the biggest mistakes I see in custom methodologies is omissions of data that make the results unrealistic and incorrect."
By all means, don't omit all of the cost benefits of control, Pavlicek concluded.
"Open source gives you high levels of control at low levels of cost," he said. "There are concrete cost benefits of building software that serves 99.9% of your company's needs."