Skip to content

How to Participate in Add_on Development

Alberto P. Marti edited this page May 23, 2020 · 11 revisions

How to Make an OpenNebula Add-on

  1. Check the Existing List of Add-ons. Before starting the development of a new Add-on, have a look at our list of Add-ons and review our GitHub repo. Maybe you find something interesting and decide to invest your time and efforts in co-leading or contributing to an existing Add-on...

  2. Requirements for New Add-ons. The basic requirements are:

  • A codebase tested in the OpenNebula version you claim to support
  • Documentation to install and use the Add-on with OpenNebula
  • An active development and support
  • A potential user community
  • Apache License version 2.0

We applaud the following design and development principles in contributions:

  • Collaborative open source software development
  • High quality software
  • Implementation of standards
  • Security as a mandatory feature
  1. Share your Plans with the Community. If you want to start a new Add-on, you should bring it up for discussion on the Community Forum. Other developers may have suggestions, and this ensures that the new Add-on is aligned with the roadmap and other features being developed. It is important for everyone involved to make sure that you are not doing redundant work. It's always a good idea to ask on the Forum if there's someone else planning to start the same Add-on, just in case!

  2. Identify an Add-on Leader. Add-ons leaders are responsible for coordinating the development of the Add-ons and committing contributions on behalf of other developers.

  3. Licensing. OpenNebula requires contributions to be released under the Apache License version 2.0 and to include appropriate licensing information at the header when uploaded to our GitHub repo. This submission method makes all contributions immediately available to all Community members under the Apache License version 2.0.

  4. Group Infrastructure Set-up. A new repository "Addon-[Name]" will be created in our GitHub repo. Add-on Leaders will be granted Commit access to the new repository. This new repository will have an Apache LICENSE file and a README file with the following sections:

  • Description: What is the Add-on about
  • Development: Identify how to contribute and how support requests and issues will be managed
  • Authors: Identify leaders and developers by email
  • Compatibility: Tested OpenNebula versions
  • Features: Summary of main functionalities
  • Limitations: Known limitations (if any)
  • Requirements: Hardware/software requirements for usage
  • Installation: How to install the Add-on
  • Configuration: How to configure and tune the Add-on
  • Usage: How to use the Add-on
  • References: External references to project site, etc.
  • License: Apache License version 2.0
  • Other: You are free to add more sections. You can have a look at one of the existing README files for inspiration.

Regarding Development, it is highly recommendable to use GitHub issue tracking system and wiki to manage the project.

  1. Make the Add-on Public. Once the leadership is identified and the Add-on infrastructure is ready, we will list the new Add-on on the Add-On Catalog.

  2. Announce the New Add-on. To help you attract new developers and users, we will help you announce the incipient Add-on through our Community Forum, social networks and blog. If you want to use the OpenNebula logo as part of the promotion of the new Add-on, please contact


How to Run an OpenNebula Add-on

  1. Support for the Add-on. Unless otherwise stated, Add-ons are supported by the OpenNebula Community.

  2. Maintain the Add-on. Add-ons are maintained by their leaders. Typically they are also the main developers of the Add-on. Only leaders have Commit access (Push & Pull) to the Add-on repository. Contributions from other developers are submitted by Pull Request on GitHub.

  3. Build Community. Attract users and developers to your project (we can help with this too).

  4. Keep Compatibility. Add-ons do not necessarily have to follow the OpenNebula release cycle, but it is very important to test their compatibility with upcoming versions of OpenNebula. Once a new Beta version of OpenNebula is announced, leaders will have 10 days to test compatibility and release a new version of the Add-on.

  5. Promote your Work. You can use our Community Forum to discuss the development, as well as our blog and your own social media profiles to announce new versions and enhancements (just remember to used the #opennebula hashtag).


How to Contribute to Add-on Development

The Development section in the README file of the Add-on specifies how development is being managed. Typically, the GitHub issues system is used for issue tracking.

The leaders of the project are the only members with Commit privileges. To contribute to an Add-on with bug patches or new features, you can use the GitHub Pull Request model to the Add-on public GitHub repo:

  • Fork it
  • Create a branch (git checkout -b my_markup)
  • Commit your changes (git commit -am 鈥淢y changes鈥)
  • Push to the branch (git push origin my_markup)
  • Create a Pull Request to this repository from your new branch

Coordination is performed through the Community Forum. It is assumed that code and documentation are contributed under Apache License version 2.0.

Don't hesitate to contact the leader of an Add-on if you are interested in co-leading its development.


Are Add-ons part of the OpenNebula distribution?

Add-ons sometimes, but by all means not always, end up being incorporated into OpenNebula. New Add-ons have to go through an incubation phase and the Quality Assurance process defined for the project before they can become part of the OpenNebula distribution. Prior to escalation to the OpenNebula distribution, the Add-on needs to show that:

  • It perfectly fits within the OpenNebula project
  • Its features are highly demanded by the Community
  • It has been developed to be thoroughly tested with the Quality Assurance process of the project
  • The developers allocate resources for the maintenance and support of the new component to ensure long-term stability to its development
  • The developers must have signed their work.