Discussion for Moving Quarkus to a Foundation

[maxandersen]

Earlier, we blogged about Quarkus moving to a foundation - give it a read, add a reaction and comment - using this discussion to share more detailed thoughts/interest in this discussion.

[jbonofre]

I'm commenting here using my personal view (not wearing my ASF director hat).
First, thanks for this blog and considering joining a foundation. Imho, it would be a great move for Quarkus, and bring a lot of value.

I would list the benefits to join a foundation should provide:

1. Open governance, community driven
2. Transparency & Vendor neutrality
3. Branding
4. Additional values (like releases, security management, etc) according to future requirements (I'm thinking about CRA)

On the other, foundation may have constraints as well.

Now, talking about the Apache Software Foundation (of course 😄 ), if you want to evaluate this option, I would be more than happy to help there.
I just want to clarify some questions (I know you may have):

1. The classic way to propose a project to ASF is to go via the incubator. During the incubation period, with the help of the mentors, you will prepare the project and community to graduation as TLP (license check, namesearch check, releases, etc). However, with a project as mature as Quarkus, with a lot of contributors with ASF experience, already using the Apache 2.0 license, it's possible to directly go to TLP. It can be discussed, but it's an option.
2. Some "rules" at ASF are not necessary well know. For instance, the release voting period is an advice, not a requirement (the requirement is to have 3 binding votes). It means that for exceptional reasons, you can do a release super quickly as soon as you have the 3 binding votes. On the same topic, it's not really possible to veto a release (if you have the three binding votes, the release can pass).

Anyway, if you want to chat about that, always available for you 😄

[jbonofre]

It depends if the dependencies are used or shipped.
If you ship Cat-X dependencies, it's problematic indeed (see https://www.apache.org/legal/resolved.html).

Are we talking on Quarkus and Quarkiverse or just Quarkus here ?

Just a reminder, the minimum distribution you have to release at Apache is the source distribution. The binary distributions are for convenience.

[gsmet]

So we won't include these dependencies in a release bundle as we only include the Quarkus artifacts but... we ship jars that non-optionally rely on them.

For instance, the quarkus-hibernate-orm extension is optional, it's a Core extension, you can run Quarkus without it, but it's part of what we ship as the Quarkus Core and it depends on Hibernate ORM which is LGPL through a non-optional dependency at the quarkus-hibernate-orm extension level.

[jbonofre]

Yes, that's a challenge. We have the same challenges in Apache Camel (including camel-quarkus) and the components. Basically, either we distribute the components with Cat-A/B dependencies, or we ask the user to add the required dependencies on its own.

[maxandersen]

Yes, so this challenge of foundations having varying limits on which licenses can be used when is a challenge - and not unique to Apache; though Apache is (as I currently understand it) in the "stricter" end of the scale.

This is what the "Provide flexibility in using Open Source Initiative (OSI)-approved Open Source licences for the Quarkus platform, its extensions and its dependencies." is about - since one of the powers of Quarkus is that the platform is easy to use and if all users have to manually add dependencies we fail on that part.

This issue occurs no matter if we talk Quarkus core or parts or all of Quarkiverse.

"Just a reminder, the minimum distribution you have to release at Apache is the source distribution. The binary distributions are for convenience" - not sure how that helps here ? the dependency to non-ASL licenses exist in both cases afaics?

[jbonofre]

I got the point and you are right. Going to a foundation has pros and cons (and differ depending of the foundation).

Quarkus is a great framework and ecosystem for the users, thanks for all extensions and how it's easy to start with. I'm a Quarkus user (and a bit contributor as well 😄 ) and it's clearly a huge advantage.

I think one concern (not for me, but for Quarkus users/customers) is that the governance is from a single vendor. It means that if the vendor decides to change the direction of the project and even the license of the project (we have several examples like this recently), he can totally do that.

The huge advantage of ASF housed project is that users have the guarantee the project is vendor neutral, open governed and sustainable long term. This depends of the foundation (some foundations have different model). Using my user hat, I would not be super confortable to promote Quarkus in a company without a clear view on this (if Quarkus goes to a foundation governed by one or two vendors, it won't help much imho). Just my $0.1 😄

[oleg-nenashev]

I guess the top candidates would be the Apache Software Foundation and the CommonHaus at the moment, given how the projects consolidate there.

I really like ASF but its governance and release voting model is probably a little bit dated, and it might be difficult to align it with the Quarkiverse governance model. When we were looking for a new home for Jenkins, It seemed to be difficult to align our governance model with the ASF one. So, CommonHaus seems to be the easiest one in terms of the migration if you need an entity to handle the trademark and other common resources. ASF would be more significant from the PR at the moment thanks to its multi-decade history. As @jbonofre mentioned, some of the perceived "standards" in the ASF (e.g. release voting) are rather advised and not mandatory, so the ASF may work IMHO.

Of course, there are many other Java foundations one could consider, and also one of the Linux Foundation foundations. Personally I would advise against the latter, because many things hinge on corporate membership there in the charter, including voting rights for normal board member positions, and committee memberships. Not all members of the Java ecosystem are currently the members of the Linux Foundation, and it implies additional membership costs and goes against values of many ASF folks who rather focus on individual membership not tied to the company affiliation.

I would also advise against starting a new foundation when there are existing umbrella ones, because it is a serious overhead to maintain it, and it is also difficult to build a vendor neutral foundation in the ecosystem like Quarkus where Red Hat would be dominant in terms of the contributions and investment.

[jbonofre]

I'm not sure I got the points/constraint with ASF governance (I don't see a lot of blockers, but I might be wrong).

About CommonHaus, it's a good option. If I may, I would just suggest to evaluate:

• enforcement for vendor neutrality and open governance
• preparing for CRA etc (regulation)
• sustainable foundation and branding

[oleg-nenashev]

I also do not see blockers. Some adjustments and opt-outs from common practices might be needed though. I will see whether I could dig up our ASF evaluation in Jenkins document from the pre-CDF times (~2017) and from the Hudson=>Jenkins renaming times (2012). At that point there were no blockers either, but some points from there might be useful to review.

enforcement for vendor neutrality and open governance

There is no enforcement at the moment. Oppositely, each project decides separately: "We want projects to succeed on their own terms"

I like this approach of leaving the full power to the communities, but it implies that Quarkus sets up their own governance while moving to this foundation. Good thing to do, happy top contribute

preparing for CRA etc (regulation)

All binary distribution vendors are still on fire about that. My recommendation for any new project would be to rely on external distribution infra. Maven Central or GitHub Packages count as external though, at least to some extent.

sustainable foundation and branding

Obviously, it is a risk for CommonHaus that is yet to establish beyond basics. And it will be definitely a subject for the sustainability concern for the next several years, even if bigger projects like Spring or Jenkins join.

[wjglerum]

This is good to hear Max! Thanks for sharing, being open about this and good to hear Red Hat itself is also behind this proposal.

I think https://www.commonhaus.org would be a pretty nice place for Quarkus. No strict rules as mentioned above by other options, so Quarkus can still continue the quick pace we all love and got used too!

[wjglerum]

And looks like a pretty neat place next to Hibernate and Jackson :D

[arjantijms]

Wouldn't the Eclipse Foundation be an option to consider?

It's the home of Jakarta EE and MicroProfile afterall.

[maxandersen]

I’m sorry, @rmannibucau, but it seems you are focusing on one out of the many facets discussed.

Our intention with the blog post and this ongoing discussion is not to present a decision set in stone but rather to explore and understand the best path forward for Quarkus. We value input from the community to ensure that we make a well-informed decision that benefits Quarkus the most.

Would you prefer I just answered “Yes - that sounds like an awesome reason” to all the suggestions on why a specific foundation would be the best choice? If I did that, there would be no discussion, and I, for one, would not learn anything.

[rmannibucau]

You see it open whereas your comment was closing part of the discussion. I'm just highlighting that if some options are closed - which I hope so otherwise it was too early to speak about anything if you follow the reasoning - then these doors should just be explicitly closed IMHO to avoid people to loose time.
There are clearly options discussed which don't match much most of the thread so would be great to list options and list the ones which are no more options to reduce the list to some small set IMHO.

[maxandersen]

I did not close it - I highlighted a concern.

The blog listed the general criteria we are looking for - I hope we can get them all or close to at least.
But if this was an easy choice and there was a clear single choice this would all just be easy and done.

I'm hoping the blog opens up the conversation and explore ways we can adjust but also where foundations can help or inform that challenge XYZ is possible to work through and how.

Most definitely interested in hearing from Quarkus contributors what would work for them.

[blekione]

To give an example - Quarkus launched with lots of features and innovations five years ago, one of them its ability to target native image - to such an extent that many still believe Quarkus is only relevant for native image usage.

I don't want to go too much off-topic, but wasn't this a message sent to the community, that Quarkus is a "new supercharged framework" with fast startup time? At least I've seen a lot of focus on this one.

I also understand that you gave it as an example only and want to make the best decision for the project. I hope and believe you will make one.

[maxandersen]

@blekione - correct. For sure we talked about startup time; for both java and native image. For sure we talked alot about it. We since then changed the weight we put on it because we could see how it created the perception that native image was a requirement. Which is why we know perception is quite a tricky thing to deal with.

[d135-1r43]

It might be interesting to take a look into Kogito (KIE group) currently migrating to ASF. There are plenty of processes to be adapted and met, and many things are unclear. We as the Quarkus community could learn from their impediments and take them into consideration when choosing the right foundation. Here are the relevant weekly meeting protocols: https://github.com/apache/incubator-kie-issues/discussions

[jbonofre]

I don't know Kogito in details but what I heard is:

1. I'm not sure everyone here know the processes/rules (for instance, vote)
2. Each project is autonomous at Apache (governed by the PMC), so everything doesn't necessary apply from a project to another
3. The ASF (the foundation) is not a "static foundation". We are happy to learn and chat with everyone to improve our processes (for instance, we are discussing about board report, new projects process, etc)

So fully agree with you to get feedback from Kogito, and also see how this can help the ASF to improve.

[hantsy]

I miss Jboss.org

[rmannibucau]

My 2cts would be to just take back the blog post and see what fits:

1. Not sure how it is different from github, here a foundation will not help drastically
2. the multi-vendor point is the key point IMHO - rest can be done on github - and even a pre-requisite at Apache (ASF) so it can be some homework to do upfront before seeing which foundation to go to (Eclipse or commonhaus will just keep it like it is in terms of governance and vendoring)
3. Licensing (all other criteria are not constraints IMHO): Apache can be a bit of issue but some move to ASFv2 started in quarkus transitive stack so it can work, no issue with others which are more open on that aspect

Overall my point is that a foundation will not help most of the target listed on the post since they all let the projects be managed by project, what it can bring is some resources - but being OSS you can already get a lot free on github and common friends - so I think it can need some refinement of the goals before moving anything no?

[jbonofre]

We have recent example of vendor github open source licensed projects that changed the license. There's no open governance here. Customers don't want non foundation projects because there's no guarantee the project will be sustainable long terms.

Furthermore, the CRA will require to be open source steward which is the role of foundations.

So foundations are today more important than before (not the technical aspect but the governance aspect).

[rmannibucau]

I can envision/agree with that - even if foundation don't prevent the project to be abandonned and work to continue with another license (there are numerous examples) - but it is not in the goals of the blog post I think so not sure it is the point.

[maxandersen]

Hi Romain,

It’s implicitly mentioned in the post that to enable multi-vendor support, we need to ensure Quarkus remains open in both action and governance. This includes preventing any single company from changing licenses or trademarks overnight. While closed projects aren’t in Red Hat’s nature, some people and companies seek that additional guarantee.

Regarding your comment about the foundation being no different than GitHub, I respectfully disagree. We are already on GitHub and enjoy many of the benefits it offers, such as contributions and discussions. We will always stay on GitHub as long as it provides that. However, a foundation offers additional advantages that GitHub alone cannot provide. Specifically, it can increase adoption, as some Fortune 500 companies require a foundation for assurance. Moreover, for some developers, being part of a foundation helps in convincing peers or management to explore a technology.

While multi-vendor support varies across foundations, any foundation are non-profit organizations that offer essential legal and economic protections, which GitHub does not provide.

On the topic of licenses, we could potentially navigate the requirements of any foundation. However, we must choose our battles wisely. Spending extensive time and resources to meet certain constraints, as opposed to focusing on developing great open-source technology, is a significant consideration. Hence why it is highlighted there.

As you and others mentioned in this thread, getting it all right takes time, which is why I see no point in considering taking the blog back. This conversation we are having publicly, and also privately, is essential for us to move forward and grow.

And as such, Thank you for your feedback. It’s important to us as we continue to refine our goals and make the best decision for Quarkus.

[rmannibucau]

Hi @maxandersen ,

Yes and no, the key point there is to get diversity before moving otherwise it will be pointless - we have ton of examples at apache for ex.
So discussing the foundation is not the point but discussing how to structure the project and who will be involved (first question when doing paperwork in serious foundations) are more important right now IMHO.

[maxandersen]

@rmannibucau yes, so did see there was a Step 1: More Open Governance and a Step 2: Moving to a Foundation in the blog, right?

AFAICS the blog is explicitly stating what you suggest should be done.

[brunoborges]

A lot has been said about Apache Software Foundation.

I'll just say that I wish we had more modern and fresh application frameworks under the Apache brand and umbrella. So yes, I'd love to see Apache Quarkus becoming a thing.

[jkschneider]

The way I see it, Commonhaus would be an amazing place to start that shows first that there is a rock solid commitment to true open source in perpetuity (because of the requirement that the trademark itself transfers to the foundation + its succession planning motive). Governance can come later... doesn't have to be at the same time.

A project that initially starts in Commonhaus (easy move) could later go through Apache incubation (harder move) when it is decided that governance stricture is also desirable for its community.

I think a phased approach reduces the risk of no action being taken at all.

[hantsy]

There are several Redhat/JBoss open-source projects that have become orphans now, for example, Arquillian.org has not been so active for years. Apache DeltaSpike(JBoss Seam3 successor) is also stopped to update. A lot of JBoss projects have disappeared.

I hope there is a foundation that can handle the work, centralize these Java/JakartaEE related projects, and focus on Jakarta EE development productivity, Quarkus is a good Jakarta EE runtime alternative compared to the traditional application servers.

Commonhaus is relatedly new, I think it is a good place to do the right things. In my opinion, a new community could avoid a tedious rule list to obey.

[JoeMurray]

I'm active in CiviCRM, a 20 year old open source project that is actively considering becoming a project of a foundation. Thanks for sharing your criteria for selecting a foundation. Commonhaus.org is new to me and something we'll consider.

FYI, some other options we're looking at include the Software Freedom Foundation, the Software in the Public Interest and the Linux Foundation. LF's CNCF would have to make an exception to let us in as we are AGPLv3, so we're not keen. The Eclipse Foundation is being considered but they are very bureaucratic and it might not be a good culture fit. They recently told us we would need to participate as individuals or change our for profit incorporation if we want to participate in the open regulatory governance project re CRA. :(

[maxandersen]

Glad you liked the info!

And yes its an interesting area to explore and compare all the various options.

AGPLv3 will be a challenge for all the major business focused/friendly foundations (apache, eclipse, cncf etc.); but not for CommonHaus and the others you mention as they recognize any OSI approved license afaik.

Might be too tricky to discuss here but curious what the issue is with individual participation vs profit incorporation - if you are aiming for project to move to a foundation; why would you want/need the for profit incorporation to stay controlling participant? I.e. I would expect this to be issue with any of the foundations that it would need (some level of) individual membership?

[wlfgang]

I am a huge fan of Quarkus. As a small-time vendor, the one issue that prevents me from fully embracing it is that the project is currently under the control of a single entity. The problem is, if I invest in building a product leveraging it, how do I know the license is not going to change in the future? And maybe what I've built is no longer commercially viable.

I am just curious- how would Quarkus joining a foundation change the calculus here? Would it matter which foundation the project enters? Maybe the move is just the first step toward vendor neutrality, where such a license change becomes less likely?

[maxandersen]

Good question @wlfgang - my perspective on what a foundation does is less about what license is being used but more about where the trademark is controlled. With a company it is the company that owns the trademark; when a project moves to a foundation - or more specifically a non-profit organization then that trademark/ip associated with it can no longer move to a for-profit organization.

And since trademark can't move to for profit there is very little incentive to go change to a license that somehow limits who can use the software.

Hope that makes sense?