| Re: [cn4j-alliance] [External] : Perspectives on technical relationship |
Tl/Dr; Red Hat is opposed to this suggestion for several reasons, not the least of which is that it contradicts one of the fundamental ideas agreed to in the CN4J messaging statement.
Reasons for opposing this approach:
There are fundamental organizational, operational and funding differences between the working groups
MicroProfile has a flattened governance structure to help it deliver more quickly
It is our belief that MicroProfile is more transparent, with all meetings recorded and publicly available
There is a fundamental difference in the fee structures and forcing MP into Jakarta would entail a huge jump in cost to achieve the same level of participation
Red Hat’s intent is to help minimize the overhead introduced by the EFSP/working group to behave as much as possible like the former open source project
There is a fundamental difference on the patent license type, and the recent vote indicated there is no clear majority opinion on this in the Jakarta working group.
It does not introduce any time savings as you are simply replacing the MicroProfile state with an incubation state. You still have to argue over when a specification is ready to migrate and you have to exclude non-incubation specifications from introducing dependencies on incubation specifications. There is a benefit to having separate namespaces for APIs in different states of development.
Jakarta EE is yet to prove itself as a vehicle which can deliver stable technologies, let alone be a safe home for fast moving innovation. To date all that has been delivered are repackaging of Java EE 8. Six to 7 years of no functional Java EE progress means Jakarta will have difficulty reinventing itself as a lightweight cloud native platform versus more mature and adopted cloud-native runtimes like Spring and Node.js.
There seems to be a more restrictive view towards compatibility requirements in Jakarta than MP. Recent internal steering committee discussions would seem to indicate that some Jakarta members would like to go so far as preventing non fully compatible implementations.
MP formed as a community with no barriers to entry that leveraged key annotation oriented specifications from EE to build micro service/cloud native focused specifications. While perhaps contested, our view has always been that MP supports 'based on' implementations of its specifications as well as 'based on' Jakarta dependencies as there should be no requirement for transitive compatibility requirements. There are members in MP that would be alienated with a fold of MP into Jakarta without a new sub-working group structure, the introduction of which brings us back to a Jakarta/MP structure.
Whilst MP utilises some Jakarta EE specifications, there are MP implementations that don't require Jakarta EE compatible implementations under the covers, so that's another change we'd be pushing on them with a merge. Further, there are MP based implementations that have no ability to reasonably implement full specifications because it breaks their usecase; bridges into cloud serverless environments is one example.
This continued rehashing of an agreed on working groups structure will ultimately lead to a fracture of Jakarta/MP into two disconnected groups with duplicated APIs ala the Hudson/Jenkins debacle.
Below is my personal opinion.
It's hard to separate two standardization efforts in the same area. This separation is artificial, doesn't bring advantages to any of the parties and doesn't make sense in general. Instead of separation we should join these two efforts together. It will save us a lot of time which we can use more productively.
- Move MicroProfile project under Jakarta keeping all committers. Use it as an incubator for new and fast evolving specifications.
- Use Jakarta specification process. It's well established and proven to work.
- Move all MicroProfile specs to jakarta namespace. It's the most painful step. But MP 5.0 is going to adopt jakartified versions of Jakarta EE specifications anyway. If this change is done at the same time the pain will be significantly reduced.
- Keep MicroProfile brand.
- Keep MicroProfile platform.
Thanks,
Dmitry
-----Original Message-----
From: cn4j-alliance <cn4j-alliance-bounces@xxxxxxxxxxx> On Behalf Of David Blevins
Sent: Wednesday, August 11, 2021 12:43 AM
To: cn4j-alliance@xxxxxxxxxxx
Subject: [External] : [cn4j-alliance] Perspectives on technical relationship
I thought it might be useful for each of us to write our perspective on how we see the two projects align technically in principle.
The high-level Tomitribe perspective is basically:
- We see Jakarta EE as the brand behind which we can offer more stability to customers. We see MicroProfile as the brand behind which we can address parts of the market that are volatile.
- We've deliberately not created anything in MicroProfile that would compete with Java EE (now Jakarta EE). All specs are complimentary. We'd like to see this "no duplication" and "no competing" principle last and be bi-directional.
- We are happy to see specifications move from MicroProfile to Jakarta as needed. The Jakarta version of the spec would be under `jakarta`. The MicroProfile version would cease to be developed, but could still be shipped as frozen for a period of time.
None of the above should be confused with innovation. We don't see that innovation stops on a spec, regardless of where it is in its lifecycle.
It's really more about volatility of emerging sections of our industry where things are created and obsoleted quickly. By definition you can't create a stable spec on something that is itself unstable. In the past we did all of this under one brand and that has its own set of disadvantages and risks.
--
David Blevins
https://urldefense.com/v3/__http://twitter.com/dblevins__;!!ACWV5N9M2RV99hQ!dayf82s4XlHJVRZp60Mom9XUFS9G7UwRVYyLdgKnGEoQlKUP8TNGmaDQjBSoZthnUNtQ$
https://urldefense.com/v3/__http://www.tomitribe.com__;!!ACWV5N9M2RV99hQ!dayf82s4XlHJVRZp60Mom9XUFS9G7UwRVYyLdgKnGEoQlKUP8TNGmaDQjBSoZtTms9Sn$
_______________________________________________
cn4j-alliance mailing list
cn4j-alliance@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://urldefense.com/v3/__https://dev.eclipse.org/mailman/listinfo/cn4j-alliance__;!!ACWV5N9M2RV99hQ!dayf82s4XlHJVRZp60Mom9XUFS9G7UwRVYyLdgKnGEoQlKUP8TNGmaDQjBSoZsm3WyWw$
_______________________________________________
cn4j-alliance mailing list
cn4j-alliance@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cn4j-alliance