This section describes, and provides pointers to, the various aspects involved in code contribution to the ONOS project.  If you have questions about any of this, please ask on the onos-dev mailing list or chat with us on Slack.

Getting Started

Finding Tasks to Work On

Bug Bounties

Bug bounties are issues that are important to resolve for an upcoming release, but the core team doesn't have bandwidth to address right now.  Once you've become familiar with the ONOS code submission process, we would love if you assigned yourself one of the bounty bugs.  To thank people, we will be sending ONOS swag out to community members who complete a bounty bug.  Check out the bug bounties on Jira.

Backlog Issues

The ONOS project actively maintains a list of backlog issues that are used when planning future sprints.  You are welcome to look at the backlog of the ONOS Scrum Board to find an issue there that looks interesting to work on. 

Submitting New Features and Enhancements

Developers are encouraged to build on ONOS and, as much as possible, to contribute their enhancements back to its code base. The ONOS team strives to provide the right balance between enabling and encouraging innovation and creativity, but at the same time maintaining the coherency of ONOS architecture and the code. To that effect, we welcome partners and contributors to follow the process outlined below:

Clearly for bug fixes and small enhancements, the above process can be significantly abbreviated. However, for larger feature contributions, following this process will greatly increase the chances of success and should make for a smooth experience overall. We look forward to your contributions and to see what exciting ideas and solutions you can build with ONOS!

Coding Processes and Guidelines

To maintain a level of manageability in the codebase, the project maintains a set of coding and testing processes and guidelines.

Licensing and Contributor Agreement

 Any code contributed to ONOS source must be released under the Apache 2.0 license, i.e. the licensing information must appear in the header of contributed files. The IDE setup section describes how to configure the IDE to automatically add the licensing information for two IDEs, Eclipse and IntelliJ.

 In addition, code submitters must agree to the project Contributor License Agreement (CLA), based on that of the Apache Software Foundation. 

Coding style

Please read through our Coding Style Guidelines documentation.  Note that many IDEs may be configured to take care of the formatting aspects of the coding style. 

Unit tests

Unit tests are a fundamental part of ensuring the stability of ONOS. Any new classes or system components should be accompanied by unit tests. For existing code, any changes that do not alter functionality should pass existing tests; however, existing tests should also be modified to reflect any changes that alter the behavior of a class or interface. Existing tests should not be disabled when new functionality is added, unless the tests are obsolete.

All available unit tests are run as part of a full build process. Contributions should pass all tests and build successfully before being submitted.

Minimum code coverage via unit tests is 70%, but the goal is 80%+. More details can be found in the Unit Test Guidelines documentation.

Code submission

The process of submitting code and amending changesets using the git Gerrit plugin is described in the Sample Gerrit Workflow documentation. As a general rule, please submit early and often, but avoid stacking submissions on top of each other and avoid artificially fragmenting changesets; stacked reviews should not exceed 4.

Code Review

The ONOS project uses Gerrit for code review. Once submitted, a changeset is inspected by ONOS committers. The reviewers of a submitted patch, or changeset, depend on several criteria. For example, the reviewers for modifications to the existing codebase will likely include current maintainers of the particular subsystems that the changeset affects. Reviewers of new additions, e.g. applications, subsystems, and providers, will depend on where and how the new changeset will affect the existing codebase, as well as who, if any, has provided guidance during the development process of the changeset. 


The primary mode for feedback is via email. This includes notifications about changeset acceptance and rejection, as well as reviewer comments that should be addressed. Therefore, it is important to 1) be subscribed to the project, and 2) have email notifications configured in user settings. Git/Gerrit Setup addresses the configuration of Gerrit.  

For a changeset to be accepted, it must receive one review with a +2 (not to be confused with two reviews of +1). A changeset given a -2 will not be accepted.  

More information on Gerrit may be found in the Gerrit Code Review - A Quick Introduction documentation.

Previous : Submitting a new feature proposal

Next : Sample Gerrit Workflow