Outline Oss Strategy

Outline Oss Strategy

NATO UNCLASSIFIED

Enclosure 1

AC/322(SC/1)N(2007)0011

AC/322(SC/4)N(2007)0014

AC/322(SC/5)N(2007)0016

STRATEGY

FOR THE USE OF

OPEN SOURCE SOFTWARE (OSS)

IN NATO SYSTEMS

(07JULY 2007)

NATO UNCLASSIFIED

(1)

NATO UNCLASSIFIED

TABLE OF CONTENTS

REFERENCE DOCUMENTS

EXECUTIVE SUMMARY

  1. INTRODUCTION
  2. Background
  3. Need for OSS Strategy
  4. Open Source Software (OSS)
  5. OSS versus Proprietary Software
  6. OSS Usage Model
  7. TARGET GROUPS
  8. System Acquisition Managers
  9. Budget Managers
  10. Policy Makers
  11. SCOPE
  12. PURPOSE
  13. OBJECTIVES FOR USING OSS
  14. Objectives
  15. Conditions for meeting Objectives
  16. KEY AREAS AND CRITERIA
  17. Architectures and Standards
  18. Migration and Integration
  19. Management, Support and Maintenance
  20. Repository and Licensing
  21. Security
  22. Training
  23. Funding
  24. Distribution
  25. Total Cost of ownership
  26. WAY AHEAD
  27. Short Term (1-2 years)
  28. Medium Term (3-4 years)
  29. GOVERNANCE
  30. Approval Authority of Strategy
  31. Execution Authorities of Strategy

REFERENCE DOCUMENTS

(a)NATO Software Management Guidance, EAPC(NC3-B)D(2003)007, 2 October 2003

(b)NATO C3 System Architecture Framework, AC/322-D(2004)002(INV), dated 7January 2004

(c)NATO C3 Technical Architecture (NC3TA), EAPC(AC/322-SC/5)N(2006)0021, dated 12April 2006

(d)NATO Interoperability Standards and Profiles (NISP)EAPC(AC/322-SC/1-WG/4)N(2007)0001, dated 5April 2007

(e)NATO CIS Configuration Management Policy and Directive, AC/322-D(2006)0052, dated 28 August 2006

(f)Security Implications of Using Open Source Software (OSS) in NATO, AC/322(SC/4)WP(2004)0012, 7July 2004

(f)INFOSEC Technical and Implementation directive for computer and Local Area Network (LAN) Security, AC/322-D/0048, 29April 2002

NATO UNCLASSIFIED

(1)

NATO UNCLASSIFIED

EXECUTIVE SUMMARY

The Military Budget Committee (MBC)requested the NATO C3 Board (NC3B) to conduct a study into non-proprietary software solutions such as Open Source Software (OSS) for use in NATO systems. These other solutions could be considered as alternatives to single source enterprise agreements when screening budgets for IT-systems. In response to the MBC study request, the NC3B tasked the former Information Systems Sub-Committee to develop a strategy for the use of OSS and other software for NATO funded systems.

An explicit strategy on the use of OSS within NATO is required to ensure that NATO exploits the benefits that OSS can offer in a systematic and balanced way when selecting software for NATO systems. The target group of this strategy is NATO system managers (including acquisition managers), budget managers and policy makers.

OSS has initiated a fundamental change in the software infrastructure marketplace. The model of the OSS market is based upon the concept of users getting ‘free’ software and paying for ‘value added’ services where required. The potential application of OSS in NATO covers a wide spectrum, ranging from its use as a commodity, provided and supported by commercial providers, to NATO’s active involvement and leadership in developing, supporting and distributing Open Source code.

The purpose of this strategy is to enable a structured approach to the adoption of OSS in NATO systems through the identification of key areas, with their associated criteria, required for the objective selection of OSS or proprietary software to meet specific user requirements. The objectives for using OSS are:

  • Less dependency on single vendors and proprietary technology,
  • Cost reduction, and
  • Improvement of interoperability of systems through the use of Open Standards.

The following key areas to be considered for selection of OSS are addressed in the strategy, with their associated criteria:

  • Architectures and standards,
  • Migration and Integration,
  • Management, Support and Maintenance,
  • Repository and Licensing,
  • Security,
  • Training,
  • Funding,
  • Distribution, and
  • Total Cost of Ownership.

The strategy provides the following recommended way ahead for the short term (1-2 years):

(a)Use of OSS and Proprietary Software: NATO project and program offices are to consider OSS and proprietary solutions equally for IT procurements for NATO systems, based on value for money and fit for purpose principles by applying the criteria in this strategy.

(b)OSS Pilot projects: In order to fully exploit the benefits of OSS in NATO programs, program managers should establish feasibility studies and pilot projects to study and test the viability of the OSS approach in their respective programs.

(c)Open Standards: Adherence to the use of Open Standards in OSS for the exchange of information in a mixed environment of proprietary software systems and OSS based systems should be mandatory for NATO systems.

(d)INFOSEC Operational Procedures: Operational security guidance , developed under the lead of Information Assurance Sub-Committee, concerning the INFOSEC aspects of deploying, operating and managing OSS are the same as in proprietary software and shall be followed.

(e)Legal Aspects of OSS Licenses: NATO legal authorities should investigate the legal aspects of OSS licensing and provide clear guidelines concerning the use of different OSS license types in NATO systems.

The strategy provides the recommended way ahead for the longer term (3-4 years) as follows:

(a)Implementation plan for the use of OSS in NATO: Based on NATO and nations experience, results of feasibility studies and pilot projects, the possibility of expanding the deployment of OSS components should be investigated for the longer-term, including its consideration as the default exploitation route for NATO funded software where practical and cost-effective.

(b)Open Standards strategy: The NOSWG should develop a strategy to encourage cooperation between users of Open Standards and OSS and help ensure the use of common Open Standards within OSS.

NATO UNCLASSIFIED

(1)

NATO UNCLASSIFIED

  1. INTRODUCTION
  2. Background

1.1.1In October 2002, the Military Budget Committee (MBC)voiced concerns over the software license agreements acquired via Select and Enterprise agreements under sole source procurement rules. It requested the NATO C3 Board (NC3B) to conduct a study of other software solutions such as the use of Open Source Software (OSS) to report in time for the post-2005 selection process. The NC3B tasked its former Information Systems Sub-Committee (ISSC) to develop a NATO strategy for the use of OSS to allow software alternatives for NATO funded systems. This document is intended to meet this requirement.

1.2Need for OSS Strategy

1.2.1OSS is already in significant use in a growing number of NATO systems, both large and small. However, in order to ensure that NATO fully exploits the benefits of such use, it is necessary to adopt a more systematic and balanced approach to the selection of software for NATO systems. An explicit strategy on the use of OSS within NATO is required to ensure consideration of OSS for NATO systems based upon an objective assessment of relevant selection criteria.

1.3Open Source Software (OSS)

1.3.1OSS is software whose source code is developed, tested and enhanced in an open exchange of information environment, often through the voluntary efforts of business and academic software experts. It is usually made freely available without a license fee under an open software development process to prevent it being subsequently redistributed under a more restricted license. This innovative approach of OSS has had a significant impact upon the software infrastructure marketplace.

1.4OSS versus Proprietary Software

1.4.1OSS is characterised by the openness of code and the absence of a single controlling entity. In contrast, the workings of proprietary software are usually kept hidden, protected under the terms of the license the owner of the software has laid down.

1.4.2In switching from proprietary software to OSS direct savings can be made in license payments. On the other hand, there will be increased costs for services such as software management, training and building up expertise among system managers. The model of the OSS market is based upon the concept of users getting ‘free’ software and paying for ‘value added’ services, where required.

1.4.3The principal question is: to what extent can and should OSS supplement or replace proprietary software? OSS offers opportunities to provide product diversity in the acquisition of NATO systems, which will reduce the costs and risks of being wholly dependent upon a single software supplier. In addition, OSS is based on Open Standards, which makes it independent of proprietary solutions and relatively easy to replace or to integrate with other Open Standards based products. However, other factors must also be considered, such as the cost of change and the overhead of having to maintain both OSS and proprietary software simultaneously.

1.5OSS Usage Model

1.5.1The potential application of OSS in NATO covers a wide spectrum, ranging from its use as an out-of-the-box commodity provided and supported by commercial providers, to NATO’s active involvement and leadership in developing, supporting and distributing OSS code.

1.5.2The gradations of OSS usage in NATO are as follows:

(a)Using unchanged common available OSS packages obtained from a commercial provider responsible for packaging, distribution, support, training, etc.

(b)Using a commercial provider to adjust OSS to meet specific NATO purposes, for example by changing configuration settings and files and supplying additional integrating OSS packages to provide a NATO OSS desktop suite.

(c)Using OSS from approved sources without commercial support. In this case, NATO would be responsible for obtaining OSS source code from the OSS community (for example by downloading from the Internet) and compiling, packaging, configuring, distributing and supporting the product internally.

(d)Using and modifying OSS, typically by changing source code, to provide functionality to meet NATO specific needs. In such circumstances, NATO Organisations might contribute to the OSS community through participation in the improvement of the OSS published baseline by proposing improvements, requiring critical updates, etc.

(e)Using OSS to create new applications. In this case, NATO would develop, publish, and sponsor OSS and share it with the OSS community in order to solicit feedback and contributions to improve its functionally and quality. Use of such software would be open to the entire OSS community.

1.5.3The type of OSS usage will largely determine the way in which the life-cycle of a particular system component is managed and hence its impact on the “Total Cost of Ownership” of the OSS component.

  1. TARGET GROUPS
  2. System Acquisition Managers

This strategy is primarily aimed at those responsible for NATO systems acquisition, offering guidance in software selection during the planning, design and maintenance phases of new projects and when updating existing systems.

2.1.2Budget Managers

This strategy is also aimed at the NATO budget managers, in support of the screening of software choices on a value for money principle within NATO projects.

2.1.3Policy Makers

This strategy is also aimed at alerting NATO policy and decision makers to the potential benefits of OSS when setting other strategies for ensuring interoperable systems.

  1. SCOPE

This strategy shall be used for the planning of all new and updates to existing NATO systems which require the acquisition or development of software.

  1. PURPOSE

The purpose of this strategy is to enable a structured approach to the adoption of OSS in NATO, by identifying key areas and criteria against which the selection of OSS to meet NATO requirements can be objectively determined.

  1. OBJECTIVES FOR USING OSS

5.1Objectives

The overall objectives of using OSS are as follows:

5.1.1Less dependency on Single Vendors and Proprietary Technology

NATO software selection procedures shall seek to remove or to minimize reliance on ‘vendor lock-in’ to proprietary products and services. OSS can provide for a significant reduction of vendor dependency and can increase flexibility of choice. Because the source code is freely available, any suitable company can be selected to integrate, update or maintain the software.

5.1.2Cost reduction

Every effort shall be made to select a software solution that reduces total cost of ownership for a system and gives value for money to NATO. This may be an OSS solution, a proprietary one, or a mixture of both. Decisions shall be made on the basis of the key areas and associated criteria provided in this strategy.

5.1.3Improvement of interoperability of systems

In order to ensure interoperability among NATO systems and between NATO and national systems, products that support open standards shall be used to the maximum extent possible in all future NATO System acquisition and developments.

5.2Conditions for meeting Objectives

The following conditions must be met in order to achieve the above objectives:

5.2.1Retain or improve quality of Software

The quality of software must be assured. Experiences with OSS in large civilian projects demonstrate that it can be reliable and stable. The availability of the software source code enables regular software quality checks which help ensure that software quality can be retained and improved.

5.2.2Retain or improve security

Security must be maintained. Studies in the civilian and military domain demonstrate that properly configured and patched OSS can be as secure as proprietary software and as immune against malicious software attacks. Appropriate security checks should be conducted to retain or improve the required level of security.

5.2.3Retain or improve usability of systems

Existing system facilities must be maintained. When introducing new OSS components to a system, it essential that existing levels of usability are retained and disruption of users kept to a minimum.

5.2.4Assess life-cycle costs

A full assessment of life-cycle costs is necessary. Before selecting OSS for a NATO system, it must be demonstrated that support will be available and that the use of OSS will provide additional value over the projected life-cycle, taking into account all new system and infrastructure support costs.

  1. KEY AREAS AND CRITERIA
  2. Architectures and standards
  3. A well-structured architecture is essential for a modern, complex information system whatever software it is based upon. Open standards provide flexibility in adopting new or replacement OSS and proprietary software components from different sources. However, integrating large numbers of small components from different sources can become complex. It is, therefore, necessary to balance the level of software integration complexity caused by granular component modularity and the level of flexibility and openness to ensure and maintain a manageable level of architectural and support complexity.

In order to achieve a stable open standards and OSS-based architecture, the principles and guidelines below should be applied by system managers in selecting and integrating these components.

6.1.2Principle 1: Adopt Open Standards and Technologies

(a)Only adopt products adhering to open standards and an open architecture.

(b)Follow mandatory open standards in the NATO Interoperability Standards and Profiles (NISP).

(c)Ensure long-term readability of data. OSS Office Tools can read/write most current COTS document formats successfully, but digital durability of information can only be assured through the adoption of open standards-based document exchange, groupware, email, media, database storage and file system formats.

6.1.3Principle 2: Select OSS Products Carefully

(a)Only adopt OSS products with a proven track record – (e.g. have external community support and market share, or have been certified for use in other NATO projects);

(b)Ensure that representative pilot projects have been undertaken to provide extensive “proof of concept” before undertaking major architectural changes;

(c)Ensure that all security and technical issues have been fully investigated before adoption;

(d)Ensure that selection of OSS products is undertaken using objective criteria;

(e)Consider the use of experienced OSS System Integration Contractors to reduce and manage the risk of malfunction or lack of functionality.

6.1.4Principle 3: Control and Manage Integration Complexity

(a)Re-engineer application systems using modules with open APIs in order to ease integration and allow more re-use of components;

(b)Before commitment to any change, ensure that the support required for a complex mix of OSS components linked through open standard interfaces is properly understood and considered against that required for less highly integrated alternative OSS or proprietary systems;

(c)Ensure that the Systems’ Target Architecture addresses in sufficient detail the Technical and Software Configurations (ref. (a) and (b)) that define the different software components, their underlying standards and interfaces;

(d)Select components that closely match user requirements or that are customisable to add or remove required or surplus functionality;

(e)Plan to allow the use on servers of both OSS and proprietary software, in order to facilitate smooth transition;

(f)Leave existing applications which cannot be readily ported to a new OSS platform to continue to run in their legacy environment. Concentrate on linking them with the rest of the new architecture and plan to replace them when the existing platform is renewed;

(g)Consider the use of application virtualisation on servers while running thin clients. Although introducing a risk of single point of failure, it offers improved management control, scalability and economies in the resources needed for software and hardware configuration management.

6.2Migration and Integration

6.2.1Full or partial migration of an architecture based on proprietary software to one based on OSS requires extensive planning efforts. For a large-scale migration exercise, (as opposed to extension of the existing infrastructure with a single OSS component or system) an outline migration roadmap should be prepared that addresses as a minimum the following aspects:

(a)Migration principles;

(b)The migration scenario or approach; and

(c)Specific integration issues to be addressed.

6.2.2Migration Principles

In a complex CIS enterprise environment such as the NATO CIS infrastructure the following two high-level principles are advised as a starting point for a migration roadmap:

(a)Assume a heterogeneous environment comprising components from multiple sources, both OSS and proprietary software based. Most (complex) large-sized NATO systems can be so described and there are no indications that emerging OSS technologies are likely to change this architectural reality;

(b)The migration roadmap should be based on progressive migration and integration of OSS components (no BIG BANG approach).

6.2.3Migration scenario:

A step-wise approach should be followed that addresses the risk and impact of migrating from non-OSS components. A migration roadmap focused on migrating to a full OSS environment (bearing in mind the first migration principle) should include the following steps: