For years, it was a back-office passion for a select few. But government interest in open source software (OSS) took a decidedly large leap forward in 2004 when the city of Munich, Germany, announced it was switching 14,000 desktops to the Linux operating system. Soon after in the United States, the public sector was startled to hear that Massachusetts adopted a new policy requiring state agencies to pursue open standards options (originally open source) for new applications.

Since then, the public sector has acknowledged that OSS is no longer a geeky, technological sideshow, but "an architectural element that has attracted a critical mass of institutional users, forcing attendant changes in the software industry," according to the Center for Digital Government. Yet as with any well known celebrity, that seemingly sudden rise to fame belies years of hard work nobody notices. OSS paid its dues and is now reaping the rewards -- Novell bought SUSE Linux; IBM is embracing the Linux penguin; and Red Hat has pried server market share from mainstream vendors.

The private sector saw the writing on the wall, wholeheartedly adopting open source software and blending the once-rogue code into mission-critical areas. The public sector isn't that far behind, though certain issues must be dealt with.

Is OSS still just something to be tinkered with on a few isolated servers? Is government ready to open its closed, proprietary systems and applications to community-built software? Is the government culture that's so used to working with proprietary solutions ready for this new environment? Is OSS no longer just a tool for early adopters, but a viable domain of software for government to run enterprise systems?

Primary Advantage

The U.S. Department of Labor (DOL) is one agency that believes OSS is ready for prime time. In April 2004, the DOL became the first Cabinet-level federal agency to release a software product under the general public license (GPL). The product, Workforce Connections, is the first tool licensed by a Cabinet agency to any organization in the public and private sectors for use at no charge.

The DOL's Workforce Connections is a set of Web-based tools used to create, acquire, share and control content in real time. It's based on ZOPE, an open source application server for building content management systems, intranets, portals and custom applications.

With Workforce Connections, an organization can build and maintain traditional Web sites, online courses or presentations, "community of practice" Web sites, online coaches and knowledge repositories.

"I've currently got 21 DOL agencies managing more than 123 Web sites, online learning courses or communities of practice within Workforce Connections, and that's just the DOL," said Will Peratino of the DOL's Office of the Assistant Secretary for Policy. He evaluates new and emerging technologies and whether they can be integrated into the workplace. "We have 13 other federal agencies and DoD [Department of Defense] agencies using the tools in similar capacities. I think we're real serious about it."

Though Peratino succeeded at telling federal agencies that OSS is stable and useful, he said he faced two challenges -- educating agencies on what OSS can do, and tackling legal hurdles to a government agency holding a license on a product.

The biggest educational hurdle was convincing people that it's possible to run multiple types of applications in a single environment, because a product's functionality is usually stovepiped by vendors within an industry.

"Everyone thinks, 'If I want to do online learning, I have to buy a learning management system.' 'If I want to do content authoring, I have to buy an authoring tool.' 'If I want to have a community of practice, I have to buy community-of-practice software,'" he explained. "The reality is, we can work in one environment now and at least address four of our previously separate functional, stovepiped operational environments. That's a big advantage."

The primary advantage is reducing months of time and effort to just days, he said, since content is no longer managed with proprietary tools that, in effect, package that content in a proprietary wrapper. Developing a content management application in an OSS environment requires no proprietary tools.

"From a configuration management standpoint, you save an immense amount of time, effort and dollars," he said. "From a program execution perspective, we've got some stats [showing that] OSHA used to take six to nine months to create a three- to five-hour online course. It used to cost them up to $30,000 per instructional hour of finished content. We have their own subject matter expert now creating the courses online -- no programming required -- at less than $5,000 per hour, and they're building courses in weeks."

Acceptance by Chaos

To some, adopting and using OSS is a natural fit for governments as agencies explore collaborating on application development. It's not that interagency collaboration is new, but that OSS more closely mirrors the very nature of government itself -- a sometimes messy form of consensus.

Collaboration by committee is the usual approach, said Andy Stein, IT director for the city of Newport News, Va., and the problem is that approach is hidebound. Collaboration built around the OSS model -- a community-based, distributed responsibility for the constant refinement of a set of tools, such as ZOPE -- will require a new mindset in government.

"That is, to me, the iterative and evolutionary model I feel is most significant for government to understand and embrace," Stein said. "This is the most significant difference between what is possible now -- should we adopt an OSS, iterative and evolutionary methodology -- versus the older methodology that relies on more traditional, structured meetings."

The old way required groups wanting to collaborate to at least agree on specific requirements or a certain design upfront, and nothing could get done unless everybody agreed to agree.

"That whole process was extremely cumbersome and slow," he said. "We can learn from the OSS methodology that it's a converse. It's very fast. It's one group building enhancements on top of enhancements built by other groups through the OSS methods."

The success of OSS springs from that build-on-other-builds mentality, he said, because a particular application or set of tools like ZOPE is constantly being refreshed by far-flung groups of developers who look for bugs, fix them and release a new version after the fixes have been tested.

"In government, we can mimic the same model," Stein said, though he acknowledged a certain government reticence to take the OSS plunge. "I've been working for about two years trying to understand that hesitance. Most of my peers are very interested and intrigued by the model. Some of the hesitation comes from the belief that, 'We tried collaboration in the past and it didn't work. Why should it work now?'"

The key to why collaboration based on the OSS model will work now, he said, is that OSS addresses collaboration by communities that are loosely connected to each other, citing the millions of members of OSS repositories that don't belong to one organization or go about their development work in one way.

"It's geographically dispersed, and they're not centrally coordinated," he said. "They're almost chaotic, and in that sense, this is very similar to local governments and state governments. We are not centrally coordinated. There's nobody at the federal and state level that sets direction for localities. There's nobody at the federal level that sets direction for the states. I'm not even sure how much direction is being set by the federal government for federal agencies because there's a significant amount of overlap right now, and a redundancy of work in federal agencies."

Add to this the diverse bodies of programmers across government -- who also do their own thing in their own way according to their own agencies' business process needs and service offerings -- and it mirrors the OSS community development model, he said.

"If you were to put all the programming resources from government together into one virtual community, it would start approaching the size of the OSS community," he said. "This is a tremendously large staff of programmers that, should we learn how to collaborate, we could use to significantly reduce our cost of software development."

OSS in the Core

It's been a long road, but OSS has finally achieved an aura of legitimacy, paving the way for government agencies to pursue higher levels of OSS integration into their software environments.

A big boost toward that legitimacy came from the U.S. Office of Management and Budget on July 1, 2004. The agency released its Software Acquisition Memo officially recognizing OSS as a viable option for civilian agencies of the federal government, said Peter Gallagher, president of Development InfoStructure (Devis), a consulting firm specializing in the government market, giving agencies the green light to treat OSS packages like commercial off-the-shelf packages.

"It's clear the large systems integrators are now getting more involved and interested as the government takes more notice of open source, all of which packages together to create that envelope of legitimacy and improve the support options and alternatives," Gallagher said.

Devis worked with Peratino and the DOL on creating Workforce Connections, and Gallagher serves as an at-large advisory member of the Government Open Source Advisory Committee, put together by the Center of Open Source and Government.

In part, OSS has moved from fringe applications to core business functions because more enterprises now trust its stability.

"We're now competing on contracts that are core business, and we're proposing OSS alternatives for things like the database," Gallagher said. "The government is giving us full points for technology based on the fact that we can point out that other people are using these products.

"That's what it's taken -- having enough case studies to show that, yes, this technology does work, it's been in use and the products are stable," he continued. "Apache's [an open source Web server] history, for example, guarantees it's as good as something else. Until you have some of those examples out there, the government doesn't want to be first. I still don't believe OSS is seen as the solution for some mission-critical tasks, but that's probably appropriate. OSS isn't the best thing in all situations. It isn't always the best of breed."

Gallagher said his company deals with federal agencies, like the General Services Administration, increasingly defining their needs in terms of services, and those agencies make it clear they don't care what technology is behind the service.

"If we can run it on OSS and keep our total cost to those agencies down on that service then, of course, we're in a better position when we bid," he said, citing the emergence of Web services as a significant motivation to move toward OSS. "That's where Web services come in. They mask, in effect, the technology behind the Web service, in which case, as a vendor, I can do it more cheaply with OSS. If I can do it securely, that gives me a competitive advantage."

A Matter of Formality

At the end of June 2004, a band of state and local governments created the Government Open Code Collaborative (GOCC) to encourage sharing computer code developed for and by government entities. The GOCC launched with a diverse range of state and local governments.

State members included Massachusetts' Information Technology Division; the Rhode Island Secretary of State's Office; Pennsylvania's Office for Information Technology; the CIO Section of the Utah governor's office; Kansas' Secretary of State's Office; Kansas' Treasurer's Office; Missouri's Secretary of State's Office; and West Virginia's Auditor's Office.

Local government was represented by Gloucester, Mass.; Worcester, Mass.; and Newport News, Va.

Since then, the Texas Department of Information Resources and the Albany County, N.Y., Airport Authority joined the GOCC. The GOCC's Web site houses a code repository accessible by members that have signed the GOCC agreement for code deposit and withdrawal. Government entities that have not signed the agreement can access some parts of the Web site as "observers." Code deposited in the repository is meant to be shared within the public sector. It's hoped the repository will support collaboration among government entities in the areas of software development, best practices and potential solutions to government business problems.

Members and observers share the burden of creating and maintaining the GOCC's Web site: The New York State Attorney General's Office maintains a GOCC discussion group; the Rhode Island Secretary of State's Office is developing applications for the GOCC repository; the University of Rhode Island hosts the repository; Massachusetts' Information Technology Division is developing the GOCC Agreement and related legal framework, and facilitating meetings while providing the hardware for the GOCC repository; and Massachusetts Institute of Technology and Harvard University offer academic support, guidance and code donation.

Keeping the GOCC going will likely be a challenge. Organizers said the GOCC will be entirely independent and not affiliated with any professional or private-sector entity, and it will not accept financial or in-kind assistance from private-sector companies. Add to this stance the fat-free budgets under which state and local governments now operate, and it's clear the GOCC will be forced to function on a shoestring budget. Despite these challenges, it's apparent that OSS and efforts -- such as GOCC -- to sustain it in the public sector will survive for no other reason than that government badly needs OSS.

"The cost of government is not sustainable in its present form," said Massachusetts' CIO Peter Quinn at the close of his presentation on OSS at a National Association of State Chief Information Officers meeting. "Open source is one avenue of a multifaceted pincer strategy to create meaningful sustainability of IT with a very different cost structure in government."

Shane Peterson  |  Associate Editor