ETSI SR 003 382 V2.1.1 (2016-02)

SPECIAL REPORT
Cloud Standards Coordination Phase 2;
Cloud Computing Standards and Open Source;
Optimizing the relationship between standards and
Open Source in Cloud Computing

2 ETSI SR 003 382 V2.1.1 (2016-02)

Reference
DSR/NTECH-00031
Keywords
Cloud, Cloud computing, Open Source Software
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2016.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI SR 003 382 V2.1.1 (2016-02)
Contents
Intellectual Property Rights . 6
Foreword . 6
Modal verbs terminology . 6
Introduction . 6
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 9
4 Standards and Open Source . 10
4.1 Context . 10
4.2 Objectives . 11
4.3 Approach . 11
4.4 Content of the report. 12
5 Standards and Open Source: definitions, objectives and interaction challenges . 12
5.1 Definitions and objectives . 12
5.1.0 Introduction. 12
5.1.1 Standards . 12
5.1.2 Open Source. 13
5.2 Different objectives, different approaches . 14
5.3 Main challenges to an efficient interaction . 15
5.3.1 Technical challenges . 15
5.3.2 Organizational challenges . 16
5.3.3 Intellectual property challenges . 17
6 Standards and Open Source: Interaction scenarios . 18
6.1 An overall view . 18
6.2 The scenarios . 18
6.2.1 An Open Source community implements standards . 18
6.2.1.0 Introduction . 18
6.2.1.1 An Open Source community implements existing standards from a Standards Setting
Organization . 18
6.2.1.2 An Open Source community implements emerging standards from an SSO . 18
6.2.2 An SSO develops an Open Source reference implementation . 19
6.2.3 An SSO develops standards based on the results of an Open Source community . 19
6.2.4 A collaboration ("joint project") is established between a Standard Organization and an Open Source
community . 20
6.3 Current and future situation . 20
7 Better aligning the standards and OSS communities . 20
7.1 Alignment: if and when needed . 20
7.2 Strategies . 20
7.3 Solutions . 21
8 Conclusions and Recommendations . 21
9 Areas for further study . 22
Annex A: Standards Related Organizations Approaches . 23
Annex B: Open Source Communities Approaches . 26
B.1 Open Source Cloud middleware projects . 26
ETSI
4 ETSI SR 003 382 V2.1.1 (2016-02)
B.2 Standards usage summary table . 27
Annex C: Interaction scenarios in practice in Cloud Computing . 29
C.1 Case Studies . 29
C.2 Sharing specifications: NFV and OPNFV . 29
C.2.1 Introduction . 29
C.2.2 The actors . 29
C.2.3 Working together: opportunities, issues . 30
C.3 Open Source and Standards: OpenStack . 31
C.3.1 Introduction . 31
C.3.2 The actors . 31
C.3.3 Support of standards . 32
C.4 Distributed Management Task Force (DMTF). 32
C.4.1 DMTF Standards . 32
C.4.2 DMTF standards and OpenStack . 32
Annex D: Change History . 34
History . 35

ETSI
5 ETSI SR 003 382 V2.1.1 (2016-02)
List of figures/list of tables
Table A.1: Strategies of SSOs towards Open Source communities . 23
Table B.1: Strategies of Open Source organizations towards SSOs . 26
Table B.2: Open source products adherence to standards . 28
Table C.1: OpenStack services in support of OpenStack architecture . 31

ETSI
6 ETSI SR 003 382 V2.1.1 (2016-02)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Special Report (SR) has been produced by ETSI Technical Committee Network Technologies (NTECH).
The present document is approved by the NTECH Technical Committee and for publication on the Cloud Standards
Coordination website (http://csc.etsi.org).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Introduction
Cloud Computing is increasingly used as the platform for ICT infrastructure provisioning, application/systems
development and end user support of a wide range of core services and applications for businesses and organizations.
Cloud Computing is drastically changing the way ICT is delivered and used. However, many challenges remain to be
tackled. Concerns such as security, vendor lock-in, interoperability and accessibility, service level agreements more
oriented towards users are examples of issues that need to be addressed.
In February 2015, the Cloud Standards Coordination Phase 2 (CSC-2) was launched by ETSI to address issues left open
after the initial Cloud Standards Coordination Phase 1 (CSC-1) work was completed at the end of 2013, with a
particular focus on the point of view of the Cloud Computing users (e.g. SMEs, Administrations).
The present report investigates the relationship and the interactions between standardization and Open Source based
software and solutions in Cloud Computing. This question was not addressed in Cloud Standards Coordination Phase 1
(see [i.1]). In the meantime, Cloud Computing has emerged as one of the domains of Information and Communication
Technology where Open Source development plays a very important role and changes significantly the status quo and,
amongst other, the traditional approach to standardization.

ETSI
7 ETSI SR 003 382 V2.1.1 (2016-02)
1 Scope
The present report presents the results of the analysis of the relationship between Standards and Open Source in the
context of Cloud Computing.
In February 2015, the Cloud Standards Coordination Phase 2 (CSC-2) was launched by ETSI to address issues left open
after the Cloud Standards Coordination Phase 1 (CSC-1) work was completed at the end of 2013. Cloud Standards
Coordination Phase 2 is investigating some specific aspects of the Cloud Computing standardization landscape, in
particular from the point of view of the Cloud Computing users (e.g. SMEs, Administrations). It will also generate a
new snapshot regarding the state of standards and investigate the interaction and relation between standardization and
Open Source based software and solutions.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
Not applicable.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] Cloud Standards Coordination, Final Report, November 2013.
NOTE: See http://csc.etsi.org/resources/CSC-Phase-1/CSC-Deliverable-008-Final_Report-V1_0.pdf.
[i.2] Regulation (EU) No 1025/2012 of the European Parliament and of the Council, on European
standardization, 25 October 2012.
NOTE: See http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32012R1025.
[i.3] Implementing FRAND standards in Open Source: Business as usual or mission impossible?,
European Commission, November 2012.
NOTE: See http://ec.europa.eu/DocsRoom/documents/15601.
[i.4] Open requirements for standards, Open Source Initiative.
NOTE: See http://opensource.org/osr.
ETSI
8 ETSI SR 003 382 V2.1.1 (2016-02)
[i.5] ETSI SR 002 960 (V1.0.1): "Working in ETSI within an OSS context: Guidance and
recommendations, including usage of OSS within ETSI Secretariat, adoption/usage of elements of
OSS in the elaboration of ETSI Standards and adoption of ETSI Standards within the OSS
communities".
[i.6] Comparison of free and open-source software licenses, Wikipedia.
NOTE: See https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses.
[i.7] Top 20 Open Source licenses, Black Duck.
NOTE: See https://www.blackducksoftware.com/resources/data/top-20-open-source-licenses.
[i.8] The architecture of Open Source Applications, A. Brown & G. Brown, The AOSA editors.
[i.9] The OPNFV Release 1 'Arno'.
NOTE: See https://www.opnfv.org/sites/opnfv/files/opnfv_arno_overview_diagram.jpg.
[i.10] ISO/IEC Guide 2:2004: "Standardization and related activities - General vocabulary".
[i.11] OpenStack Application Programming Interface (API).
NOTE: See http://developer.openstack.org/api-ref.html.
[i.12] UK Government Open Standards Principles.
NOTE: See https://www.gov.uk/government/publications/open-standards-principles/open-standards-principles.
[i.13] "Compatibility Of The Licensing Of Embedded Patents With Open Source Licensing Terms", Iain
G. Mitchell QC, Stephen Mason.
NOTE: See http://www.ifosslr.org/ifosslr/article/view/57.
[i.14] ISO/IEC Draft 19941: "Cloud Computing - Interoperability and Portability".
[i.15] "Open Standards and Open Source: Enabling Interoperability", F. Almeida, J. Oliveira, J. Crux.
NOTE: See: http://airccse.org/journal/ijsea/papers/0111ijsea01.pdf.
[i.16] ETSI GS NFV 002: "Network Functions Virtualisation (NFV); Architectural Framework".
[i.17] ETSI GS NFV 001: "Network Functions Virtualisation (NFV); Use Cases".
[i.18] ISO/IEC 17203: "Information technology - Open Virtualization Format (OVF) specification".
[i.19] ISO/IEC 19831: "Cloud Infrastructure Management Interface (CIMI) Model and RESTful HTTP-
based Protocol - An Interface for Managing Cloud Infrastructure".
[i.20] DMTF DSP0243: "Open Virtualization Format Specification".
[i.21] DMTF DSP0262: "Cloud Auditing Data Federation (CADF) - Data Format and Interface
Definitions Specification".
[i.22] DMTF DSP0263: "Cloud Infrastructure Management Interface (CIMI) Model and RESTful
HTTP-based Protocol".
[i.23] DMTF DSP2038: "Cloud Audit Data Federation - OpenStack Profile (CADF-OpenStack)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
Open Source license: copyright license for Open Source software
ETSI
9 ETSI SR 003 382 V2.1.1 (2016-02)
Open Source Software (OSS): computer software that is available in source code form
NOTE: The source code and certain other rights normally reserved for copyright holders are provided under an
open-source license that permits users to study, change, improve and at times also to distribute the
software.
source code: any collection of computer instructions written using some human-readable computer language, usually as
text
standard: output from an SSO
NOTE: For the sake of simplicity, the meanings of "standard" and "specification" are not differentiated in the
present report, unlike in the other CSC-2 reports.
Standards Setting Organization (SSO): any entity whose primary activities are developing, coordinating,
promulgating, revising, amending, reissuing, interpreting or otherwise maintaining standards that address the interests
of a wide base of users outside the standards development organization
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
3GPP Third Generation Partnership Project
API Application Programming Interface
ATIS Alliance for Telecommunications Industry Solutions
CC Cloud Computing
CCSL Cloud Certification Schemes List
CDMI Cloud Data Management Interface
CIMI Cloud Infrastructure Management Interface
CSA Cloud Security Alliance
CSC Cloud Standards Coordination
CSC-1 Cloud Standards Coordination Phase 1
CSC-2 Cloud Standards Coordination Phase 2
CSI Cloud Storage Initiative
CSMIC Cloud Services Measurement Initiative Consortium
DMTF Distributed Management Task Force
EC European Commission
ENISA European Union Agency for Network and Information Security
EPO European Patent Office
FRAND Fair, Reasonable And Non Discriminatory
GS Group Specification
HP Here we should take away the reference to HP in Clause B2 Table 2 Eucalyptus (see below)
IaaS Infrastructure as a Service
ICT Information and Communications Technology
IEC International Electrotechnical Commission
IETF Internet Engineering Task Force
IP Intellectual Property
IP Internet Protocol
ISG Industry Specification Group (an ETSI structure for open membership projects)
ISO International Organization for Standardization
IT Information Technology
ITU International Telecommunication Union
ITU-T ITU Telecommunication Standardization Sector
JSON JavaScript Object Notation
JTC Joint Technical Committee
KVM Kernel-based Virtual Machine
NFV Network Function Virtualization
NFVI NFV Infrastructure
NFVO NFV Orchestrator
NIST National Institute of Science and Technology
OASIS Advancing Open Standards for the Information Society
OCCI Open Cloud Computing Interface
OCF Open Certification Framework
ETSI
10 ETSI SR 003 382 V2.1.1 (2016-02)
ODCA Open Data Center Alliance
OGF Open Grid Forum
OMA Open Mobile Alliance
ONF Open Networking Foundation
OPNFV Open Platform for NFV
OSS Open Source Software
OVA Open Virtual Appliance
OVF Open Virtualization Format
PaaS Platform as a Service
SaaS Software as a Service
SDN Software Defined Network
SDO Standards Developing Organisation
SIIF Standard for Intercloud Interoperability and Federation
SLA Service Level Agreement
SME Small or Medium Enterprise
SMI Service Measurement Index
SNIA Storage Networking Industry Association
SSO Standards Setting Organization
STF Specialist Task Force (an ETSI structure for internal projects)
TMF TeleManagement Forum
UCD Unified Cloud Disk
VIM NVF Virtualised Infrastructure Management

VM Virtual Machine
VNF Virtualised Network Function
VNFC VNF Component
W3C World Wide Web Consortium
WS Web Service
4 Standards and Open Source
4.1 Context
The Cloud Standards Coordination project (CSC)
Cloud Standards Coordination Phase 1 (CSC-1) took place in 2013 as a community effort supported by ETSI and
primarily addressed the Cloud Computing standards roadmap. In December 2013 the results were publicly presented in
a workshop organized by the European Commission (EC).
The CSC-1 Final Report [i.1] provides a snapshot on the Cloud Computing standardization landscape at the end of
2013. It is available at: http://csc.etsi.org/resources/CSC-Phase-1/CSC-Deliverable-008-Final_Report-V1_0.pdf.
Cloud Standards Coordination Phase 2
Given the dynamics of the Cloud Computing market and standardization, Cloud Standards Coordination Phase 2
(CSC-2) was launched in February 2015 with, in particular, the main objective of producing an updated version of the
snapshot of the Cloud Computing standardization landscape. CSC-2 aims at better taking into account the needs of
Cloud Computing customers on their Cloud related requirements and priorities. This will help CSC-2 to further assess
the maturity of Cloud Computing standards and evaluate how standards can support the Cloud Computing customers'
priorities.
ETSI
11 ETSI SR 003 382 V2.1.1 (2016-02)
Analyzing the relationship of Standards and Open Source
The question of Open Source has been alluded to in the Cloud Standards Coordination Phase 1 report [i.1], but not
directly addressed:
"Another aspect of the cloud computing environment that is worthy of consideration is the role of the various
Open Source projects 
which are addressing many of the topics discussed in this report. While not formal
standards, the Open Source projects 
are creating tried-and-tested APIs, protocols and environments which
address aspects of interoperability, portability and 
security relating to cloud computing. It is possible that
future specifications and standards may derive from one or more 
of the Open Source projects. Some
examples of positive interaction have already been seen between standards bodies and Open Source projects
that should be encouraged. The role of Open Source projects was not addressed in this report" (see [i.1],
clause 6.1).
The present report addresses some of the points mentioned above, in particular regarding the positive interaction of
Standards Setting Organizations (SSO) and Open Source communities.
4.2 Objectives
The present report will elaborate on the differences and overlaps between Open Source and standardization with the
purpose of outlining areas where, despite these differences, Open Source communities and Standards Setting
Organizations might come together to further add value to the Cloud Computing space.
The main objectives are to:
• Understand the relationship between Open Source and standards and vice-versa via the identification of a
number of interaction scenarios involving Standard Setting Organizations and Open Source communities.
These scenarios are not specific to Cloud Computing. Some of them are already visible and some only
emerging.
• Clarify how these scenarios apply to Cloud Computing.
• Collect information upon the perceived strategies and visible actions of the SSOs regarding Open Source, and
how they match the above scenarios.
• Collect information upon the perceived strategies and interactions of the Open Source projects towards
standardization, especially when the interaction scenario involves one or more of the SSOs relevant in Cloud
Computing.
• Propose recommendations to foster positive interaction, to suggest areas for collaboration between both
communities on ways to support this interaction (e.g. technical frameworks, interoperability, intellectual
property).
4.3 Approach
As it will be outlined a number of times in the remainder of the present report, standardization and Open Source are
serving rather different purposes and have developed different ways to achieve their own goals. Therefore, the
following is not going to be a debate on the respective merits (or lack of) of each approach.
The report is mostly focused on the relationship between standardization and Open Source in Cloud Computing. The
understanding of this relationship may require that some consideration will be made of topics outside this precise scope.
However, this has been limited to the maximum and the report is not addressing the following questions:
• The debate on the different meanings of "open". Different approaches to "openness" are coexisting, in
particular regarding "open standards". The present report will refer to the EU regulation (see [i.2]), as was also
the case for Cloud Standards Coordination Phase 1.
• The debate on the many options for intellectual property licensing. Different approaches are coexisting in
Open Source communities as well as in standardization. Despite its importance, this question has been
considered as outside of the scope of the present report.
• The debate on the respective merits of Open Source licenses. The same remark as above applies.
ETSI
12 ETSI SR 003 382 V2.1.1 (2016-02)
• The contributions of organizations that are not directly involved in standards making or Open Source projects
in Cloud Computing that are outside the scope of the work., even if they are addressing important questions
such as promotion, marketing, etc.
4.4 Content of the report
Clause 5 of the present document is a general analysis of the main differences between standards-making and Open
Source (Software) and the related challenges. Though this analysis is not addressing Cloud Computing specifically, the
remarks made apply also in this context.
Clause 6 is presenting a framework for the analysis of the interactions between standards (and in particular Standards
Setting Organizations) and Open Source (and in particular Open Source organizations or projects). This framework is
not specific to Cloud Computing but may be used in this context. It is used in the following clauses.
Clause 7 outlines some trends and open questions regarding the evolution of SSOs' and Open Source communities'
expectations, strategies and perceived evolutions.
Clause 8 highlights conclusions and recommendations from the analysis done in the present report.
Clause 9 suggests some areas for further work.
Annex A is a compilation of information related to the undertakings of major SSOs in Cloud Computing related to
Open Source.
Annex B is a compilation of information related to the undertakings of major Open Source communities and projects in
Cloud Computing related to standardization.
Annex C introduces several examples of the scenarios outlined in Clause 6 in the context of Cloud Computing.
5 Standards and Open Source: definitions, objectives
and interaction challenges
5.1 Definitions and objectives
5.1.0 Introduction
Clause 5 presents some generic characteristics of standards and Open Source (i.e. non-specific to Cloud Computing)
and how standards and Open Source solutions together can help drive the development and uptake of Cloud Computing.
5.1.1 Standards
Definition
A standard is defined as "a document, established by consensus and approved by a recognized body, that provides, for
common and repeated use, rules, guidelines or characteristics for activities or their results, aimed at the achievement of
the optimum degree of order in a given context" (see [i.10]). This definition is in fact amplified by ETSI's rules for
drafting standards (available via the ETSI Portal).
Standards are typically manifested as specifications that can be used as is or as elements of larger products, solutions or
other standards. A standard can be compared to or said to constitute a reference based on which one can build products
or services that all share the same specifications, and thus are "compatible" at some level. Standards are of various
natures, may apply to different contexts and are not always directly related to an implementation.
A standard may be universal in nature, and is often used internationally and/or independent of a particular industry or
vertical domain. Standards can also be developed to support a particular domain, vertical or industry sector.
Standards tend to be stable over time. Another frequently mentioned characteristic is that a standard should be
technically agnostic/neutral, unless developed in support for a particular technology platform. This allows innovation to
take place in implementations.
ETSI
13 ETSI SR 003 382 V2.1.1 (2016-02)
Standards Setting Organizations
A Standards Setting Organization (SSO) refers to any organization that develops and maintains standards. Some
essential elements of the operation of an SSO (see [i.2], [i.4] or [i.12]) are:
• Transparent and publicly accessible decision-making processes.
• Collaborative consensus building, extensive consultation & review efforts.
• Formal procedures and mature processes.
• Fair access to standards at zero or nominal cost.
• Deliberate selection of future standards through pre studies, study groups or similar preceding any decision to
develop a standard.
• Market support and usage.
Benefits
Whilst success and adoption of individual standards may vary, in general the known benefits that come from relying on
standards are:
• Stability. The more standards are incorporated and used in ICT solutions, the more likely it is that the solution
based on them will be stable over time.
• Focus on the core functionality. As a consequence of using standards, the developers of ICT solutions can
spend the most of their efforts on creating support for the core functionality that is requested by the users.
• Widespread use and Interoperability. Using standards increases the probability of interoperability between
solutions; standards for exchange of information for example are commonly based on specifications that are
built for any technology platform and with support for different underlying technologies in mind.
• Technology/implementation neutrality. In particular, this is a significant factor to support avoidance of lock-in
by allowing multiple implementations from different providers.
• Regulatory/Governmental Policies/Legal aspects. Standards are often used a support for regulation.
5.1.2 Open Source
Definition
Open Source refers to a way to develop solutions collaboratively. Open Source solutions rely on a "community" that is
responsible for the development, provisioning and maintenance of the Open Source solution. Most OSS solutions have
been developed with independence from the underlying environment as a main objective. Initially, Open Source ®
solutions were particularly available on freely available technologies (such as Linux , Apache, Java distributions, etc.)
but are today available also on most commercially available technology platforms.
NOTE 1: "The registered trademark Linux® is used pursuant to a sublicense from LMI, the exclusive licensee of
Linus Torvalds, owner of the mark on a world-wide basis."
NOTE 2: "The Apache Software Foundation owns all Apache-related trademarks, service marks, and graphic
logos."
NOTE 3: "Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks
of their respective owners."
Applied to the development of solutions, Open Source is characterized by the following:
• Decentralized production of source code.
• Collaboration across geographies and organizations.
• Variants, known as "forks", that sometimes are brought back into the originated version of the source code
product or in other cases spun off into another product.
ETSI
14 ETSI SR 003 382 V2.1.1 (2016-02)
• Usage of Open Source licenses (see [i.6] and [i.7]).
Open Source communities
There are many Open Source communities in Cloud Computing. Some of them are listed and analysed in Annex B of
the present document.
Benefits
Whilst success and adoption of individual open source project may vary, in general the known benefits that come with
Open Source are:
• Shared co-development resources enabling collaboration and reducing development cost to each participant.
• Availability of many resources due to the collaborative and community-based nature of Open Source.
• A development model based on recurring and incremental releases and improvement that fits well with
concepts such as "continuous delivery", "team based development" and "agile development".
• Modular and clearly defined products and services with improved flexibility for customization.
• Support to multiple underlying environments as a key factor to avoidance of lock-in.
5.2 Different objectives, different approaches
The Open Source approach is useful to, at least, two categories of stakeholders:
• Developers are benefitting from a carefully elaborated and fine-tuned innovation framework: tools, methods,
governance, recognition, etc. This framework is fully supportive to major requirements from this community:
systematic usage of source code at the centre of the development, support of agile methodologies, extremely
short cycle times, to name a few.
• Some organizations (e.g. enterprises, industry associations, service providers, etc.) have quickly endorsed the
innovation power of Open Source and incorporated it into their strategies. They all share the objective of
creating ecosystems around innovations to rapidly test their value and shorten their time-to-market. The 'open
innovation' based model prevalent as a result of Open Source enables the creation of value-added services on
top of the source code.
The leading force in Open Source is the (source) code: "the code is the proof" (that the idea is sound, that it is
implementable, that its works, etc.). In consequence, Open Source has some specific characteristics that make it
different from standardization:
• The focus of the Open Source work is the development of an independent set of source code that can possibly
be forked into another independent set of source code that will provide a different solution. This approach to
multiple implementations is different than the one in standardization (which is in most case a basic assumption
for the development of standards). But in any case, it should be clear that Open Source communities as well as
SSOs consider multiple implementations as a key aspect of their work and are organized to support them
(e.g. via a wide use of Plugfests).
• Open Source development does not necessarily rely on prior (ex-ante) specifications. In some extreme cases, a
written specification and even documentation are hard to find.
• OSS is concerned with interoperability if and when it is useful and needed, for instance to enforce multi-
vendors support.
On the other hand, the leading force in standards is the specification:
• The work in SSOs assume an ex-ante plurality of implementers and tries to avoid the choice of a given
technology against other possible candidate ones.
• SSOs ensure neutrality vis-à-vis implementations via stable and well-controlled specifications. The major
objective is to guarantee interoperability and in most of the cases to provide the means to verify it (via test
specifications, validation tools, interoperability testing, etc.).
ETSI
15 ETSI SR 003 382 V2.1.1 (2016-02)
• SSOs are guaranteeing the neutrality vis-à-vis technologies through their internal processes, and a permanent
search for consensus (with a result to reduce the concerns related to antitrust).
5.3 Main challenges to an efficient interaction
5.3.1 Technical challenges
Architecture
With the development of more and more complex systems, standards no longer rely only on the definition of protocol to
support interoperability. They are also more and more relying on reference architectures, functional decompositions and
reference points that are slowly evolving over time.
For Open Source products, the situation is comparable: to distribute the work load between various contributing
programmers or code producing communities, a proper architectural and functional decomposition of the software
under development is mandatory for OSS development (see [i.8]).
Incremental releases versus updates
Open Source products are largely evolving incrementally: new features are prototyped, tested and adapted very rapidly.
The stability of the code is a major issue open source projects have to address by implementing proper measures for
release management and versioning. Standards on the other hand are developed once, and then updated (more or less)
regularly, until they become obsolete.
Standard document and source code
Standards Setting Organizations and Open Source communities produce and distribute artifacts that are different in
nature:
• Standards Setting Organizations produce standards that are commonly manifested in documents that specify
requirements, architecture and protocols/APIs of a system or a part of a system. The evolution of a standard is
based on change requests that are examined during periodic reviews and possibly implemented via a change
request in the standard. The coherent development of the standard is supported by tool environments that are
essentially managing document versions associated to a list of revisions. Note that some Standards Setting
Organizations guidelines include the need of having source code implementations of the standard (e.g. W3C,
OGF).
• Open Source communities produce source code, a collection of computer instructions written using some
human-readable programming language, usually as text. This source code evolution is guided by a permanent
flow of change requests that are constantly examined by reviewers and implemented on-the-fly if deemed
accurate. While source code is the main output of Open Source Projects, a solid product documentation
including code documentations, architecture and functional specifications based on requirements collections or
standards, and user and installation guides, is crucial for a successful OSS development. Open Source
communities also often produce documentation associated with the open source code (e.g. architecture, API
textual description).
Interoperability
Interoperability is an important topic to consider for standards and Open Source, though for somewhat different reasons.
In the development of standards, achieving the highest degree of interoperability for any given standard is normally one
of the main objectives (see [i.14] for the work done in ISO/IEC JTC1 SC38 on interoperability and portability). For
Open Source projects, achieving interoperability is also important, but typically only within the technology context of
the Open Source project in question.
For Cloud Computing efforts to be successful when using standards and Open Source, it is subsequently important to
understand, keep track of and address all aspects of interoperability that apply in the Cloud Computing context in
question. The present document will
...