OMM


OMM stands for Open-source Maturity Model. It is the model in use at OW2 for assessing the maturity of open-source projects in terms of quality and trustworthiness. This page describes the current status of the model and presents some extensions that are under consideration by the OW2 Technology Council for possible OMM updates. 

OMM status

  • The current OMM sections and criteria are available at OMM.
  • Each OW2 project that has reached the mature level has an OMM form that can be accessed from its dashboard.

Extensions under review

Cloud deployment

This section aims at assessing the maturity level of a project in terms of cloud deployment readiness. It includes special quality requirements that have to be met in order to ensure that a project delivers deployable assets (binaries, images, templates) within a cloud marketplace such as AppHub.

Cloud deployment readiness and workflow

IDName and objectiveControls
DEP-1.1Does the project provide cloud templates or images that are ready for deployment?
  • The project shall provide templates or virtual images in one or several cloud deployment platforms, such as AppHub
  • The project shall make sure that the templates or images contain installation instructions and release notes
DEP-1.2Does the project provide deployable templates / images versions that are aligned with the project's releases?
  • Projects shall provide several versions of the deployable asset following the project release cycle (whether binaries or templates/images)
  • Projects shall make sure that the release notes in one or several cloud deployment platforms such as AppHub log the improvements and differences between versions.
DEP-1.3Does the project define a procedure for managing the deployable templates / images (e.g. as part of the configuration / release management)
  • The project shall appoint a person in charge of producing and exposing the deployable templates / images in one or several cloud deployment platforms such as AppHub
  • The project shall document the release of the deployable templates / images (internal documentation, or on the project website)

Cloud deployment testing

DEP-2.1Does the project provide evidence that the deployable assets function correctly?
  • The project shall make sure that there is a description available associated to the project asset, that explains how to test whether the deployed asset works correctly
  • The project shall provide an automated test suite on deployable assets.

Architecture

Architectural controls are related to two interrelated issues:

  1. Software architecture has to be of sufficient modularity to enable reuse and maintainability (design time), and
  2. Software architecture can be separated into functional components that can be integrated in a service oriented manner (run-time).

Design patterns

IDName and objectiveControls
ARCH-1.1Design patterns - The project shall ensure that code structure follows well accepted design patterns
  • The project shall ensure that the software architecture follows well accepted
  • The set of design patterns used by the project shall be documented

Components

IDName and objectiveControls
ARCH-2.1Components - The project shall ensure that assets are structures into functional components
  • Availability of components: Projects shall ensure that software is structured into components that can be used as stand-alone functional blocks
  • Component exposition: The source code shall be structured and documented in a way that allows external users and integrators to access components in a stand-alone manner
  • Technology: Projects shall use component/container technologies such as CORBA or OSGi Medium to implement the controls listed above

Interfaces

IDName and objectiveControls
ARCH-3.1Defined interfaces - Projects shall ensure that component interfaces are clearly defined and documented
  • Definition: Interfaces between components shall be clearly defined, including permitted exchange data classes, exchange mechanisms, containers, and control messages. If relevant, the order of messages shall be defined. Error conditions shall be defined.
  • Documentation: The asset documentation shall contain a description of the issues listed above, preferable using a formalized language (such as UML).
ARCH-3.2Standardized interfaces - Projects shall ensure that component interfaces are clearly defined and documented
  • Standardized protocols and data formats - Whenever possible, projects shall enforce the use of standardizes protocols and data formats to define component interfaces.

Cloud service enablement

IDName and objectiveControls
ARCH-4.1Component can be used in PaaS or SaaS mode - Components can be used as cloud services, either by a platform-as-a-service type exposure, or directly as application type service
  • PaaS/SaaS exposure - Components can be deployed and used as cloud services
  • Open standards - Components are based on open standards (such as CIMI, CDMI, OCCI, etc.)
  • Cloud interoperability and portability - Components are interoperable or provide data portability to other cloud services, either vertically (e.g., to a set of infrastructure services), or horizontally (i.e., to provide or use support from other services running in the same cloud environment).

Other extensions

Relations