Towards a Stronger OpenNebula Community

Hello everyone!

By now, all of you must be already aware of the fact—announced earlier today by our Executive Director—that starting from OpenNebula 5.12 “Firework” we’ll be releasing both a Community Edition and an Enterprise Edition. Allow me to review some of the details to give you some perspective on how these changes may impact the OpenNebula Community .

The Community Edition will be a full-featured version of OpenNebula released under Apache License 2.0. The Enterprise Edition, on the other hand, will incorporate additional bug fixes developed by OpenNebula Systems and software patches with minor enhancements, along with enterprise tools to simplify upgrades and maintenance of OpenNebula clouds in production environments.

While we make OpenNebula open source, the packages of the Enterprise Edition and the enterprise tools that it contains will not be distributed under Apache License 2.0 but rather under commercial license terms only to those corporate users with an active OpenNebula Subscription. For more details about the OpenNebula Subscription, please visit our new FAQ section.

As part of the review we’ve recently undertook of the OpenNebula Subscription—the mechanism we have for ensuring the sustainability of the project—the migrators will only be made available for customers with an active OpenNebula Subscription and for users with non-commercial deployments or significant contributions to the OpenNebula Community.

Another change is that our GitHub repository with packaging tools has now become private—as it used to be in older versions of OpenNebula—but the source packages for publicly released versions remain available in the download repositories for easy rebuilds and customizations. Apart from that, the current process of contributing to OpenNebula via GitHub remains completely unchanged, so the new Enterprise Edition brings no disruption at all to the usual way of reporting bugs, requesting new features, contributing to the source code, or creating a new add-on.

I hope my message will help to clarify some of the changes that are taking place these days, which are ultimately intended not only to ensure the long-tern sustainability of the project, but also to strengthen the OpenNebula Community and our shared objective: to build the best open source Cloud Management Platform in the known universe! :rocket: Of course, if you have any questions, or you feel that any of these changes interferes with your contributions to the OpenNebula Community, please don’t hesitate to contact me.

Cheers!

Alberto.

Hi @amarti on github you said:

I think I am active member of the community, but problem is that I use this code to represent the opennebula docker images in kube-opennebula project:

So question is: if I’ll get access to the pacakges repository, can I continue using it to build opennebula docker images and provide them to everyone for free, or should I switch to use another method for compiling OpenNebula from the source code?

Thank you!

1 Like

Same question as kvaps, I was using the packages repository to build RPMS for CentOS, perhaps Fedora and CentOS Cloud SIG in a distant future, for any tagged version from the “one” repository.

1 Like

Honestly it was already a bit of a bad solution to force people to build their own packages for certain hotfixes.
Taking that self packaging route away and also keeping bugfixes and patches from CE users however brings this to a whole other level.

Off to OpenStack it is!

I am also not convinced of this strategy. Don’t you think that the unavailability of the migrators will lead to a fragmented user base? Without an easy upgrade path, people will stick with the OpenNebula version they initially installed, even if it e.g. contains security vulnerabilities. And when they follow the open source idea and develop customizations and improvements, they will do it for the OpenNebula version they are using, not the most actual one on GitHub, which they cannot upgrade to. I don’t see how that will strengthen the community.

Furthermore, I think you should clarify what separates a significant contribution to the community from an insignificant one. How high is the threshold to get access to the migrators?

What is the path for community edition to migrate from 5.10 to 5.12? Does it mean that I can no longer upgrade unless I pay for enterprise version? At that rate community edition stops making sense.

Thank you all for sharing your questions and opinions about the new scenario that we’ll be putting in place after the release of OpenNebula 5.12 “Firework”. Here you have some clarifications on the two topics that seem to generate more interest/confusion:

Access to the packages repo on GitHub:

From now on, for each Major, Minor and Maintenance release of the Community Edition we’ll be providing the traditional set of official binary/source packages for the main distributions. Still, those members of the community interested in creating public packages of the CE for other distros, or with specific open source projects that require access to the packages template repo, are very welcome to request access. For everyone else, we’ll probably have to evaluate on an individual basis. After the release of “Firework” we’ll set up an on-line procedure for this, but if any of you have, for whatever reason, an urgent need to access the packages repo, please send me a private message to community-manager@opennebula.io explaining your situation and I’ll be happy to assist you.

Access to the migrators:

As I mentioned in my original post, migrators for upgrading from one stable release to another will only be available in principle for corporate users with an active OpenNebula Subscription and access to the Enterprise Edition. This is one of the features we believe customers deserve as part of their commitment to the sustainability of the project. While projects like OpenStack are financed by large vendors that create their own commercial distributions to compete against each other, we rely solely on the financial support we receive from customers. Organizations with non-commercial deployments can always request free access to the migrators, but we expect companies with production environments to play a much more active role from now on in supporting the project. They can do that either financially (purchasing an OpenNebula Subscription) or by making some significant contribution to the community (which we’ll also have to evaluate on an individual basis), such as sharing their improvements under an open source license… In sum, we don’t expect these changes to lead to more fragmentation, but rather to more constructive commitment :slight_smile:

Thank you Alberto, it’s indeed more clear now.

So since I only run non-commercial deployments, I will have access to migrators, and also to hotfix packages ? Before we had no choice to build our own hotfix packages, so this is an improvement. If I get you correctly.

Glad to know my message was helpful :slight_smile: If you think your particular use of OpenNebula qualifies as a “non-commercial deployment”, you’ll be able to request the migrators for the CE through a specific on-line form after the release of v.5.12, yes. As for the hotfix releases, we’ve renamed them as “maintenance releases”, and those for the CE will be publicly available: https://github.com/OpenNebula/one/wiki/Release-Policy

As the prior version of “packages” code is Apache licensed, could we continue with a community fork of that code?
The whole limited-access thing isn’t clear to me. I’m also interested in creating Docker containers but I don’t know where we stand now. Would prefer a clear and consistent licensing scheme and source availability across our code-base.

1 Like

I am a bit confused about the ‘migrators’ part. Does this for instance mean we cannot run onedb upgrade to do the database migrations?

Hello.

I’m a little bit concerned by this opencore switch.

We distribute OpenNebula in turn-key solution for french schools and all
this make me think that we couldn’t distribute OpenNebula anymore. Our
Ubuntu derivative is publicly available and we need the migrators for
our users but they are not libre anymore.

I’m sad that you are in a situation where you need to make that choice
but this seems to us that it’s the end of this wonderful story :frowning:

Regards.

That’s how I understand it. Why else would they delete all existing migration scripts from the GitHub repo?

Dennis Felsch via OpenNebula Community opennebula@discoursemail.com
writes:

That’s how I understand it. Why else they would delete all existing migration scripts from the GitHub repo?

So, it seems I understood correctly.

This will make OpenNebula out of the list of recommended software for
the french government[1].

Footnotes:
[1] in french https://sill.etalab.gouv.fr/fr/software?id=107

1 Like

Hi @howels, and welcome to the Community Forum.

For the OpenNebula Community Edition, there has been no change in terms of licensing. The Apache License 2.0 applies to the source code, packages, and package sources of Major/Minor/Maintenance releases of OpenNebula CE. For more details, please visit: https://github.com/OpenNebula/one/wiki/Release-Policy

What is now for internal use only⁠—as it used to be not that long ago⁠—is the GitHub repo where the OpenNebula Team stores the package templates. Still, if you have any special needs for creating those Docker images, just send me a PM and I’ll see how we can help :slight_smile:

Hi Daniel!

That sounds quite “non-commercial” to me, so the easiest thing to do in your case would be simply to submit this on-line form asking for the migrators, and one of my colleagues will review the application once OpenNebula 5.12 is out, and contact you: https://opennebula.io/get-migration/

As for the “opencore switch”, don’t worry because the Community Edition is a full-featured version of OpenNebula, released under Apache License 2.0. What the Enterprise Edition brings along are additional bug fixes developed by OpenNebula Systems and software patches with minor enhancements. At the end of each maintenance cycle, we contribute those additions back to the Community Edition, so that EE and CE are in sync for each new Major/Minor release :wink:

Hi @roedie,

If you think your case qualifies as a “non-commercial deployment”, please submit this on-line form once OpenNebula 5.12 is out: https://opennebula.io/get-migration/

Companies with commercial deployments in a production environment (i.e. that somehow make money with OpenNebula), and with no significant contributions to the Community, are expected to support the project at least financially by purchasing an OpenNebula Subscription.

Of course, as the OpenNebula Community Edition is released under Apache License 2.0, anyone can always keep using an specific version of OpenNebula CE for as long as they want, with no restrictions apart from those defined by the license itself.

Gosh, I thought I asked a simple Yes/No question, turns out that’s not the case… But, when I feed this text through my BS filter it gives 98% certainty on ‘No’.

So, to get this straight. No, you cannot upgrade Opennebula CE unless:

  1. You reverse engineer the upgrade process yourself
  2. Fit is some special rules
  3. Have a subscription, in which case you can run Enterprise!

I can remember being at the tech days at Bit in Ede and Opennebula conf in Berlin where you guys where all ‘Opensource and Free Software is the way to go!’. That spirit sure died somewhere.

I do understand you need to make money, but somehow the way it is brought, with a lot of text and fuzz, annoys me.

Alberto P. Martí via OpenNebula Community opennebula@discoursemail.com
writes:

Hello.

That sounds quite “non-commercial” to me, so the easiest thing to do
in your case would be simply to submit this on-line form asking for
the migrators
, and one of my colleagues will review the application
once OpenNebula 5.12 is out, and contact you:
https://opennebula.io/get-migration/

Sorry, I was not very clear: if we get the migrators, we will package
them in our Ubuntu derivatives and they will be publicly available to
everyone in our Git repositories and Deb packages repository.

As for the “opencore switch”, don’t worry because the Community Edition is a full-featured version of OpenNebula, released under Apache License 2.0. What the Enterprise Edition brings along are additional bug fixes developed by OpenNebula Systems and software patches with minor enhancements. At the end of each maintenance cycle, we contribute those additions back to the Community Edition, so that EE and CE are in sync for each new Major/Minor release :wink:

I read the release-policy and I’m glad that the community edition is
full-featured.

So, if I understand correctly the release cycle diagram:

  • Major release X.0 is releases at the same time for community
    and commercial editions

  • Minor release X.Y is released at the same time for community and
    commercial editions

  • Maintenance release of community edition X.Y.0.Z is released just
    before commercial edition X.Y.Z+1 is released.

Am I right?

Regards.

Hi Daniel,

Maintenance releases for the CE and the EE follow independent schedules (we’ll modify our wiki to reflect this a bit better), but yes, apart from that detail, all the rest regarding Major/Minor releases is correct.

Hi @roedie,

I’m sorry you feel that way, and apologies for not being able to provide a binary answer to your original question. We’ve tried to ensure that these measures have a minimum impact on users with non-commercial deployments, so that’s why there are a number of exceptions that apply to some specific cases.

As for our commitment to Free (as in free speech) and Open Source Software, I would like to confirm that it remains intact, and that’s why the new OpenNebula CE will be a full-featured version of OpenNebula, released under Apache License 2.0. But, as you probably know, producing high-quality open source sofware is not free (as in free beer), so it seems just fair to expect those organizations with commercial deployments that benefit from the work we do as an open source community, to somehow support the project in an active, constructive and sustainable way—a bit like this, I guess…