Page tree
Skip to end of metadata
Go to start of metadata

This page is intended to provide guidance to new members for stepping up in the OPEN-O community.


OPEN-O is a vibrant community gathering the top players in the Information Technology arena. OPEN-O is using modern technologies to become agnostic to historic expensive hardware and is leveraging Open Source community as well as Agile practices to enable software-defined networking (SDN) and network function virtualization (NFV) operations.

OPEN-O is a place where anyone is welcomed to join and participate. OPEN-O values transparency, collaboration, responsiveness and effectiveness.

How to onboard a new Developer?

  1. Before anything else, create a Linux Foundation Account (also called LFID) this is your passport for any contribution within OPEN-O Community.
  2. Intellectual Property Right: be sensitive to what Intellectual Property Right mean!
  3. Be a good community citizen follow our: Community Code of Conduct
  4. Contribute in OPEN-O wiki
  5. Get started
    1. Join the mailing list and sign up on Slack for real time chat
    2. Participate on the calls: OPEN-O community holds every week 3 main meetings: Technical Steering Community Meeting, Architecture Review Community Meeting and Integration Meeting. Logistics.
    3. Observe/ask questions first, then dive in
    4. Some obvious places to start – bug fixes documentation, testing. Look at the Jira tickets and pick one
  6. Project best practices
    1. Identify your developer's TSC Charter Project Roles (Section 8) role up front: The OPEN-O Community is pretty large. They are Contributors, Committers and Project Team Lead covering multiple Approved projects which are then broken down in to multiple sub-projects. As you are just joining the OPEN-O community, most probably you will have a contributor role.
    2. OPEN-O is embracing Agile practices and provide a set of Development Practices to start with.
    3. Do your work in the Linux Foundation tool chain:
      1. Identify backlog in Jira
      2. Identify a Sprint
      3. Work and commit code to Gerrit
      4. Committers – target reviews in <24 hours (need at least one +2)
      5. Build and test in Jenkins and Nexus
      6. Identify bugs in Jira
    4. Even if you’re sitting next to someone, communicate in public forums (wikiSlack, mailing list, etc.). Private conversations don’t scale.

Who can contribute to OPEN-O?

Anyone willing to help the OPEN-O community can join as a Contributor. A standard meritocracy model allows Contributor to become Committers who will be the decision makers on design, code, packaging, and patches for their project. The TSC Charter describes these roles (section 8) in details.

How to contribute in OPEN-O Wiki?

The OPEN-O community is based on collaborative efforts. In other words, it is unlikely you will make something right the first time, and OPEN-O community understands and respects that with collaborative efforts we will make it right. This is again related to the OPEN-O values.

So when it comes to editing in the wiki, go ahead and don't worry about making your article perfect the first time through. Don't hesitate to add content you think is useful and don't hesitate to make edits where you think you can help. There's always somebody to fix anything that breaks.

To help you out in collaborating in its wiki, OPEN-O is providing some guidelines.

As its name says, this is a Wiki; please avoid uploading Word, Excel, PPT, and PDF documents. These are not easy to maintain, there is no history and we never know what is the latest version.

A good way to start, is to write a bit about yourself in your User page. We don't need your resume (LinkedIn do it very well). Just provide your name, location, time zone, which project you are in and how we can get in touch with you. Example. To edit your User page, once you are logged in the wiki, just click your name, then select Profile and go ahead, "Edit your Profile"

The Technical Steering Committee

The TSC (Technical Steering Committee) is the Committee chartered to make technical and release planning decisions for the community.

TSC's operations are governed by TSC Charter and TSC Policies.

All TSC meeting minutes are logged in a single place.

Tools: the basics

OPEN-O Community is relying heavily on Linux Foundation who is providing state of the art whole Open Source tool chain.
So to get things moving, it may sounds obvious but any new members should start his journey by getting a Linux Foundation Account, also called LFID.
In OPEN-O, LFID is your free pass to login and contribute in the tool chain.


This is the place where things happen. As a developer you will find access to API, Architecture diagrams, Notes, Discussions and much more.


That is where OPEN-O community describes the stories and the tasks they are developing.

To Get Started on Jira


 Gerrit concatenates Git and Code Review in one place. This is the central place when it comes to code.

To Get Started Use Onboarding.



No need to indicate that every Commit triggers a Build and an Automated test in Jenkins.

To Get Started on Jenkins Use Onboarding.

To understand Continuous Integration Practices


Well known place to store the artifacts.

To get Started on Nexus


To document OPEN-O RESTful API microservice architecture.

Mailing List

Mailman is THE OPEN-O mailing list to convey information within the community.

To Get Started Use Onboarding.


Real-Time messaging.

Sign Up on Slack.

To Get Started Use Onboarding.


Conference bridge: OPEN-O is using Zoom No phone needed, just Internet. Unless you organize meeting you do not need an account.


 Sonarqube to continuously monitor Unit Test code coverage and perform static code analysis.



Meetings: OPEN-O community holds every week 3 main meetings: Technical Steering Community Meeting, Architecture Review Community Meeting, and Integration Meeting. Logistics.

Need Support?

  1. Problem to get started with LFID or any of the tools:
  2. Real time, on your way general question for the OPEN-O community. Use Slack
  3. Deeper questions, need to share your thoughts or discuss a topic use the openo-discuss mailings list

Whole chain

OPEN-O uses a simultaneous delivery model, meaning that all contributing projects have to follow the cadence and intermediate milestones.
OPEN-O release cadence is 6 months. Consult OPEN-O calendar for details.

Furthermore, for its naming convention, OPEN-O releases follows the sun and planets of the solar system.

Lifecycle, Templates, Guidelines

OPEN-O has fully documented its Project and Release lifecycle along with supporting templates

Recommended Development Practices

Guideline to write good commit messages

To make you comfortable collaborating in the OPEN-O wiki, here are a few guidelines

Intellectual Property

OPEN-O Members agree that all new inbound code contributions to OPEN-O shall be made under the Apache License, Version 2.0 (available at

FYI, all contributions shall be accompanied by a Developer Certificate of Origin sign-off ( Don't worry this is automatically integrated within Gerrit.

To become familiar with how Free and Open Source Software is implemented within OPEN-O.

Refer to Intellectual Property section in Development Practices to make it concrete in your project.

Furthermore, Linux Foundation is using FOSS to scan all the OPEN-O code to ensure license compliance.

How things work?

Contributions within an Open Source Community are not done for the sake of doing something. Contributions support a Business need, either it is a simple bug fix or a complete new set of functionalities.

The Business needs can be proposed by anyone to the OPEN-O Technical Steering Committee for discussions, reviews and approval (proposal and examples are available).

Once that fist step is passed (Release Kick-Off), the assigned resources can dive deeper and proposed a concrete Release Plan (Release Planning template) along with Use Cases, User Stories, Functionalities.

Now, all the Linux Foundation tools chain come in place. In OPEN-O, to support our value of transparency, everything we do is traceable. From Use Cases in wiki, to requirements (under the form of Stories grouped in Epics, and Tasks) in Jira, code commit in Gerrit (linked to Jira during commit) that triggers a Jenkins Build, and ultimately to repositories in Nexus.

Need to dive deeper?

Congrats. You are on the right track to contribute.
Here is a link you may find useful to dive deeper with coding.

Note: feel free to edit and improve these pages