Linux in Government: CORE.GOV

by Tom Adelstein

One never can know enough about government and technology. So much fragmentation exists within the playing field that even if you win a significant contract with one department, you cannot expect it to fly through an entire agency. Another demoralizing facet to working with government is vendor pressures exerted by proxy by agency heads.

In a recent article, I wrote about the Emergency Response Network System and how it has worked for over three years in the Department of Homeland Security. Currently, this LAMP program has cost the government approximately 10% of what a comparably componentized proprietary system would have cost. It also works.

Yet, elements within DHS have attempted to push Microsoft into the process. Although the special interest groups have yet to succeed, they have not given up. Microsoft has proceeded, from the outside, to create a .Net solution that the company hopes can convince DHS is a better solution.

Microsoft also has rolled out its Regional Automated Information Network (RAIN) in King County, Washington. In case you don't know, both Seattle and Redmond are located within King County. Additionally, King County has circulated a request for information (RFI) to have vendors perform tests to prove Linux and other open-source software can out-perform Microsoft. The vendors must perform these tests by setting up labs at their own expense. Do you wonder if King County then will rule out open source because no one responded to its request?

The Government's Attempt to Neutralize Vendor Influence

When the US Government creates a software application, it becomes part of the public domain. In reality, however, few such programs ever see the light of day. In spite of Office of Management and Budget (OMB) Memorandum M-04-08, which stresses avoiding duplication of agency activities, few agencies release or even announce their software developments.

On July 1, 2004, Karen S. Evans and Robert A. Burton of OMB issued M-04-16, reminding agencies of regulations related to the acquisition of software. Keep in mind, this memo came from the Administrator, IT and E-Gov and the Associate Administrator, Office of Federal Procurement Policy, and it went to all senior executives and chief information officers within the federal government. Furthermore, as part of the following documentation indicates, OMB circulars also apply to state and local government units receiving federal financial assistance:

This memorandum reminds agencies of policies and procedures covering acquisition of software to support agency operations. The Office of Management and Budget (OMB) Circulars A-11 and A-130 and the Federal Acquisition Regulation (FAR) guide agency information technology (IT) investment decisions. These policies are intentionally technology and vendor neutral, and to the maximum extent practicable, agency implementation should be similarly neutral. As this guidance states, all agency IT investment decisions, including software, must be made consistent with the agency's enterprise architecture and the Federal Enterprise Architecture. Additionally, agencies must consider the total cost of ownership including lifecycle maintenance costs, the costs associated with risk issues, including security and privacy of data, and the costs of ensuring security of the IT system itself. Furthermore, software acquisitions must comply with OMB Memorandum M-04-08, Maximizing Use of SmartBuy and Avoiding Duplication of Agency Activities with the President's 24 E-Gov Initiatives [pdf] (February 25, 2004), and where required, be coordinated with the SmartBuy program.

This reminder applies to acquisitions of all software, whether it is proprietary or open-source software.

CORE.GOV Shines Light on Dark Places

Founded in March of 2004, CORE.GOV resides on CollabNet and uses the SourceCast tool to, according to the site, "Integrate applications for software development, knowledge management and project communication. Control access through a Web-based project workspace with a centralized, role-based permissions model. Enables secure and cost-effective development across multiple agencies."

CORE.GOV stands for component organization and registration environment. It gives government agencies a place to put technology on-line for sharing. It also provides a software map so people can search for shared software that meets an agency's needs or to find code fragments and libraries for agencies to meet development requirements. Agencies, state and local governments can participate and recommend components for inclusion in the CORE.GOV repository. Vendors, however, aren't allowed.

The CORE.GOV Web site states that "CORE.GOV grew out of the Federal Enterprise Architecture (FEA) Project Management Office, the goal of which is to support cross-agency collaboration, transformation and government-wide improvement. CORE.GOV offers an environment where such collaboration takes place seamlessly and easily." Members of CORE.GOV include the Air Force, Navy and NOAA; the US Dept. of State; NASA; the US Dept. of Defense; and numerous state and local government units. On its Index of Mature Components, which is quite large, the administrators state:

Over time, CORE.GOV will become a networked community of component developers and re-users, and will offer numerous components of various types and complexities, including business components, e-forms and technical components. Using the CollabNet SourceCast tool, CORE.GOV's robust collaborative environment can organize and map components in a variety of ways to make them easy to identify, discuss and develop.

Please check this index in the coming weeks and months for the latest information regarding components and component projects.

If you are interested in a component or project listed here and would like to learn know more about it or join a project, please e-mail the contact person listed.

Will CORE.GOV Succeed?

Chances seem good that CORE.GOV eventually will prosper. The main challenges to its immediate success lie in the lack of technical knowledge within agencies themselves. Decision makers and influencers do not yet understand open-source software and, especially, Linux.

If you are a government decision maker about software and look around for a single source of information or any sort of reference, you will discover that no one has produced even a guide to open-source software. This makes agency heads, procurement specialists and other decision makers easy prey for the tens of thousands of government contractors and vendors who have access to government decision makers' pagers, cell phones and e-mail.

What criteria do the decision makers use in choosing a vendor? Personal relationships are the primary factor. Lobbying and relationship-building efforts produce a sense of confidence in a vendor. Recently, a group of agency administrators from Washington DC enjoyed the accommodations in Redmond while attending a three-day seminar on some Microsoft solution.

Government agencies need to become familiar with the key elements of open-source software and obtain at least a minimal understanding of:

Client Components


  • Mozilla

  • Evolution

  • The GIMP


  • OpenLDAP

  • OpenAdapter

  • Apache AXIS

  • Hibernate

  • OpenJMS


  • Linux

  • FreeBSD

  • Globus/OGSA

Management Tools

  • OpenSource Java Management Extensions (JMX)

  • Management Consoles for JMX

  • Concurrent Versions Systems

Server Components

  • Apache

  • JBoss

  • Samba

  • Sendmail

Then, with this understanding, an effort such as CORE.GOV can become relevant.

Vision, Purpose and Goals

CORE.GOV, like other government projects, has to create a new acronym to keep up the trend of confusion among bureaucracies. The project says it offers business components, e-forms and other technical components. Here's more information from the Web site:

What is a component?

The Architecture and Infrastructure Committee (AIC) Component Subcommittee has defined a component as "a self-contained business process or service with predetermined functionality that may be exposed through a business or technology interface." [From Architecture and Infrastructure Committee Components Subcommittee, FY 2003 Work Plan, Version 1.1.]

In SourceCast, components sometimes are referred to as "artifacts".

What are CORE.GOV's goals?

  • To improve interagency collaboration on component-based development.

  • To improve efficiency of development of component-based applications.

  • To support e-Gov initiatives.

  • To be user-friendly, efficient and effective.

  • To promote stakeholder participation.

  • To support OMB mandates for FEA development.

  • To refine and manage the component lifecycle process.

What are CORE.GOV's capabilities?

  • Allows for rapid discovery and assembly of technology and service components.

  • Accessible over a secure extranet where users have varying levels of access.

  • Provides components that have been tested, approved and certified for reuse and enhancement.

  • Enables approved users to easily find, evaluate, share and download components.

  • Enables collaborations with others on component development.

  • Allows users to enhance downloaded components to meet their specific needs.

  • Provides a user-friendly Internet interface for searching for and finding a wide variety of business process and technical components.

  • Leverages tools and saves money.

  • Provides an easy-to-use cataloguing system (e.g.,

  • Consolidated entry point.

As you can see from the above information, CORE.GOV has devised a model to help governments achieve the goals of cutting costs and providing high levels of technological innovation. One would have to agree that these are worthy goals using the open-source model of development.

In little over six months, the CORE.GOV project has delivered impressive results. We hope to revisit the effort once the team has had a year of experience.

Load Disqus comments

Firstwave Cloud