Open-source myth busters

Don’t let common misconceptions about freely distributed software derail your IT strategies

Depending on whom you talk to, open-source software is a welcome replacement for expensive commercial software or an out-of-control threat to information technology departments and data security. Some organizations embrace freely distributed programs with a near-religious zeal, but others avoid any code that lacks liability if a problem arises. No wonder government chief information officers struggle to find open source’s proper niche in their IT operations.Fortunately, as open-source technologies mature and gain mainstream acceptance, many prevailing but incorrect assumptions about their pros and cons are dissolving. And with those new insights come more effective policies for adopting open source and acquiring it with the same controls as commercial software. Or as Ben Berry, CIO at Oregon’s Department of Transportation (ODOT), said, “Instead of bringing it in through the back door, we’re bringing it in through the front door.” Open-source acquisition costs are lower than for commercial software, but support and maintenance contracts can diminish the advantages over time. Instead, public-sector IT managers and consultants expect data center consolidation initiatives will drive expanded use of Linux and open-source middleware in the next year. For example, 58 percent of federal IT executives say they are more likely to consider moving to open source as they consolidate their data centers, according to a recent survey by the Federal Open Source Alliance, a consortium of companies that sell and support open source.An open-source operating system such as Linux can benefit those projects by helping IT managers move applications from mainframes and proprietary servers to less expensive hardware running chips from Intel and Advanced Micro Devices. Those CPUs don’t sacrifice performance for economy if agencies use them in banks of compact blade servers or adopt  virtualization techniques, said Paul Smith, general manager and vice president of government operations at Red Hat, a Linux vendor. CIOs may also save on training costs. “Linux can run on your desktops, your server farms or mainframes,” said Morris Segal, a consultant at L.A. Systems, an IT consulting and systems integration firm. “Instead of having your Windows guy or your Unix guy, one person understands the [operating system] and applies this expertise to the different platforms.” Even agencies with extensive general-purpose open-source implementations can balk at using the technology in mission-critical applications. For example, although Navy CIO Robert Carey named open source a key component of the Defense Department’s strategy for achieving data interoperability across its applications, he also voiced concerns about the appropriateness of open source’s collaborative requirements in certain circumstances. Some public licenses require programmers to share alterations that lead to fundamental source-code modifications, a stipulation intended to distribute bug fixes and innovations. “If we’re working on command-and-control software, for example, this would make us think twice before using open source,” Carey said. “If the application is life and death, we have to keep a close hold on the code.”Despite the availability of the mature OpenOffice software suite (www.openoffice.org), which consultants such as Segal compare favorably to the market-dominant Microsoft Office, public-sector agencies will be slow to switch. Existing enterprise license agreements with Microsoft and users’ resistance to change are the primary factors, Berry said. “The cost of switching is pretty high because of all the internal knowledge that we’ve already acquired for the [Microsoft] software now on our desktops,” Berry said. “Also, our customers would say, ‘Why are we switching if it’s not broken?’ If the payoff is not great, then we ought to be working on something that has a higher priority.”  Carey cited similar reasons for sticking with Microsoft Office. But, he added, “we’ll be looking at all options” as the Navy’s Next Generation Enterprise Network modernization initiative proceeds.Nevertheless, IT managers see potential long-term problems in maintaining public information in proprietary file formats, such as Microsoft’s .doc format. Microsoft also supports standards-based file formats. The use of proprietary formats forces people to use commercial software to view public data and leaves the information potentially vulnerable to the support decisions of a vendor. Open source offers the alternative Open Document format supported by the Organization for the Advancement of Structured Information Standards and the International Organization for Standardization. “I believe the international standards groups and the vendors need to work out” file format concerns, said Andy Stein, director of IT for Newport News, Va. “What we users need is a single universal format…and investment protection.”  Some industry estimates place the amount of open-source code in typical commercial applications at 30 percent to 50 percent of the total code base. That could include distributions of the Eclipse open-source development platform by IBM and others in addition to commercial enterprise resource planning applications that use an open-source software module for compressing and decompressing data called zlib. “For IT managers, this means there’s undocumented code that is now sitting behind your firewall, and you don’t know about it,” said Mark Tolliver, chief executive officer at Palamida, which sells tools for identifying open-source code embedded in larger applications. “If you are running applications that contain sensitive data, you want to ensure that there is no potential weakness in your applications that would allow someone remote access to that application.”Others warn that because agencies don’t know what code is embedded in their commercial or custom third-party applications, they won’t be able to update the programs or apply security patches. Tolliver advised IT managers to require vendors to list all embedded open-source products before buying software. Companies unable to do so may not be appropriate software suppliers, he said. Vendors who can document open-source contributions and the related licenses should be responsible for updates and patching under the requirements of their software licenses, he added.Agencies need to guard against open-source sprawl created by the technology’s easy availabilit y. Berry said he was surprised when a recent internal software audit identified more than 5,000 open-source applications in ODOT’s production and test environments. Those numbers raised management and legal concerns, Berry said. “A member of the technical staff might just hit OK to the license agreement without ever having read the agreement.”  Berry said he will organize representatives from various agencies early this year to sort through the dozens of open-source licenses that apply to Oregon’s IT operations and create policies for downloading software. Ultimately, he said, he wants each agency to be accountable for any software it acquires. “We can’t afford to just have software showing up that has intellectual property licensing without CIOs knowing about it.” Hewlett-Packard, which distributes Linux and other open-source technologies to the public sector, established a review board of IT and legal representatives to monitor embedded open-source code in its operations. “This is the model we use to evaluate open source, whether we are putting it into our product or reusing it internally,” said Erik Lillestolen, government program manager of HP’s open-source and Linux organization. “Our recommendation is that, as organizations become aware that they are using open source, they should do something similar to help them understand what sort of impact they may experience in their organizations,” he added.

A level playing field

As agencies turn to open-source software, some struggle with whether to treat it the same way they do commercial off-the-shelf (COTS) products. The confusion comes from customary definitions that identity COTS as code developed and supported by a single vendor.

“In that respect open source is not COTS,” said Andy Stein, director of information technology for Newport News, Va.

The distinction is important because traditional procurement practices that use requests for proposals to start the process make it difficult for agencies to acquire open-source solutions, even if they offer attractive alternatives to commercial packages, Stein said.

“The typical RFP process caters to the traditional COTS vendors, which have a marketing organization to respond to bids,” Stein said. “Open source does not operate that way.”

To eliminate confusion in his service, Navy Chief Information Officer Robert Carey circulated a letter last summer stating that misconceptions about open-source software hinder the service’s ability to realize the benefits of the technology and prevent it from receiving equal consideration during the software acquisition process.

“We were treating it with kid gloves,” Carey said in an interview. Instead, he asked the Navy to treat open source as COTS when it conforms to the spirit of the Navy’s definition of commercial software. For example, even though open source isn’t commercial, it must be copyrighted and licensed under an agreement that separates it from freeware and public-domain software, according to Navy rules.

The Defense Department isn’t the only organization struggling with that dilemma. The Oregon Department of Transportation (ODOT) is working to make open-source software competitive in procurement processes.

Open-source software typically falls in the state’s special category for products costing less than $5,000, for which agencies don’t need to ask for bids before acquiring the software.

However, ODOT CIO Ben Berry said the RFP process is biased in favor of software companies with staff members available to respond to the requests.

“Open-source entities are not out looking for RFPs,” Berry said. “There is a disadvantage to CIOs who may want to use open source, but they can’t get open-source entities to apply to these RFPs. The best thing we could do is make an even playing field where we don’t discriminate between the two sets of code.”

Help in overcoming that bias often comes from systems integrators that respond to RFPs and use open source in their solutions, Berry said.

“But that’s only a recent development,” Berry said. “I also want to make sure that our RFPs don’t have language in them that asks, ‘How many instances have you deployed this software with X number of like agencies?’ That sets up [open source] for failure because it’s still pretty new.”

— Alan Joch









Myth #1: Savings derived from avoiding licensing fees are the biggest business driver for open-source software.
Reality: Not entirely.









Myth #2: The success of open-source operating systems and Web servers proves open source is
suitable for every program agencies might run.
Reality: False.





Myth #3: Desktop office applications will be the next hot area for ope n-source technology.
Reality: Not in the immediate future.











Myth #4: Clear distinctions exist between open-source and commercial software.
Reality: False.









Myth #5: When it comes to in-house development, CIOs can manage open-source software with the same strategies they use for commercial software.
Reality: False.













Joch (ajoch@worldpath.com) is a business and technology writer based in New England.

NEXT STORY: SEC could demand transparency