Input on the MicroProfile and CN4J working group proposals

[Paul Buck]

What follows is input on the pros and cons to both the MicroProfile working proposal (MPWG) and the Cloud Native for Java working (CN4J) group group proposal. This commentary is as of discussions on the mailing list and GitHub as around January 9th.

MPWG

Pros for MPWG from GitHub Document - GitHub pull #74

• Flatter governing structure as steering committee, marketing committee and specification committees share the same membership.
  
  This seems of modest value given that many of the same vendors, contributors, and developers are involved in both Jakarta EE and MicroProfile.
  
  

• Addresses IP gap in existing MP development
  
  This is not a pro, since this is true of both proposals.
  
  

• Provides complete autonomy of how MP evolves as governing structure is not part of a non-MP specific working group
  
  This seems of modest value given that the same set of vendors are involved in both Jakarta EE and MicroProfile, and that MicroProfile is based on a number of Jakarta EE specifications.
  
  

• Provides a lower barrier to entry in terms of both cost and process for the MP technology

But increases the overall cost of contributing to the many common elements of cloud native Java technologies since most companies and individual committers are active in both MicroProfile and Jakarta. Having a single participation agreement and a shared set of participants will make collaboration and sharing completely seamless across many related technologies. Also we expect CN4J will have a zero-cost option for individual committers.

• Continues a model that has produced multiple independent implementations of novel technologies over a number of years
  
  The model can continue as part of CN4J, the only change required is adoption of the EFSP  which is happening regardless of which working group path is chosen. Release cadence and planning are totally up to the MicroProfile community as they are today.
  
  

• Allows for large companies to sponsor specification development at a zero cost entry point
  
  This assumes that the MPWG approach will have zero fees, which is an invalid assumption. Nor is it clear why allowing “large companies to sponsor specification development at a zero cost” is an advantage.
  
  

• Less restrictive use of compatibility and logo usage
  
  This is not a valid pro, as under the CN4J approach MicroProfile would have its own specification process and compatibility requirements. The assumption should be that the EFSP-based MicroProfile Spec Process (MPSP) would be identical under either working group structure.

Pros for MPWG from the MicroProfile mailing list 

• MPWG will have relaxed TCK compatibility claims requirements and relaxed voting rules (not clear how)
  
  This is not a valid pro, as under the CN4J approach MicroProfile would have its own specification process and compatibility requirements.
  
  

• Will address the IP and keep "if it ain't broke don't fix it" approach
  
  This is not a valid pro, as under the CN4J approach MicroProfile would have its own specification process and compatibility requirements.
  
  

• There is no need for EF personnel to be allocated to work on MP
  
  Eclipse Foundation staff are focused on areas that have been identified as priorities by the members of working groups. Assuming the stated goals for MP do not require staff, then no additional staff would be engaged.  
  
  

• Addresses the immediate need is for MicroProfile to resolve it's IP gap, and will allow to stay "light" on process as it can be and still be a WG. Any discussion on combining Jakarta and MicroProfile working groups is better suited to when MicroProfile has one
  
  This is not a valid pro, as under the CN4J approach MicroProfile would have its own specification process and compatibility requirements. MicroProfile must adopt the EFSP. The assumption should be that the EFSP-based MicroProfile Spec Process (MPSP) would be identical under either working group structure.
  
  

• Going with 1 WG and later find it wasn’t right for MP or even Jakarta EE, splitting them up again may be a nightmare that no one really wants to tackle. However, starting by spinning up a MP WG which runs in parallel with the Jakarta WG and running the two together in a collaborative manner for the next year or so (we do need to define that relationship) doesn’t commit us to continuing in that mode forever if we subsequently obtain further data which allows for a more informed choice, e.g., we decide that having a single WG encompassing both efforts is the right approach.
  
  None of us can foretell the future. It is equally possible that running two working groups in parallel will become an obvious waste of time and effort by everyone involved. Similarly, the conjecture that splitting the CN4J WG in two would “be a nightmare” is simply FUD. Under the CN4J WG proposal, MP will have its own Specification Committee and Marketing Committee, with its own voting and participation rules. Translating that into separate working groups if it becomes necessary seems trivial.
  

Cons for MPWG from GitHub Document - GitHub pull #74

• Duplicate working group participation agreements need to be signed

• May have duplicate fees depending on the membership level if both MPWG and CN4J/Jakarta are joined

• Tends to not commit to longer term backwards compatibility
  
  This is not a valid con, as under the CN4J approach MicroProfile would have its own specification process and compatibility requirements. If MicroProfile wishes to continue its approach of not guaranteeing backwards compatibility, then that is equally supported in either scenario.
  

Cons for MPWG from the MicroProfile mailing list

• building working group walls between the initiatives within the Eclipse Foundation is pointless and will lead to relentless politics, endless committee meetings, continual confusion about what was discussed and raised where and ultimately will confuse the market. 

• Eclipse Microprofile project leadership is purely IBM (or wholly owned subsidiaries of IBM) this does not feel healthy to the Payara team and moving to a broader PMC would help with that perception. 

• Jakarta EE with one release has not proven itself, more releases are needed to prove the process. Any delays of future releases could impact MicroProfile
  
  This is not a valid con, as under the CN4J approach MicroProfile would have its own specification process and release cadence. There is no reason to assume that there would be any differences between the two approaches with respect to the release dependencies between MicroProfile and Jakarta EE.
  

CN4J WG

Pros for CN4J form GitHub Document - GitHub pull #74

• Allows for parties interested in both MPWG and CN4J/Jakarta to sign one working group participation agreement

• Addresses IP gap in existing MP development
  
  This is not a valid pro, as under both approaches MicroProfile will adopt a variant of the EFSP.
  
  

• Tends to focus on stability and backwards compatibility
  
  This is not a valid pro, as under the CN4J approach MicroProfile would have its own specification process and compatibility requirements. If MicroProfile wishes to continue its approach of not guaranteeing backwards compatibility, then that is equally supported in either scenario.
  
  

• Has restrictions on how compatibility and branding are claimed (both Pro/Con)
  
  This is not a valid pro, as under the CN4J approach MicroProfile would have its own specification process and compatibility requirements. 

Pros for CN4J from the microprofile mailing list

• Share the same budget and no extra fees

• MicroProfile can set up committees as they were on their own, and act as separate entity

• MicroProfile projects and Jakarta EE projects have far more attributes in common than differences, and we should leverage this commonality in the way we structure our collaboration via Working Groups, and in the way we present ourselves to the community and the marketplace.

• Single WG governing the evolution of these projects, it could help in aligning and unifying Jakarta EE, MicroProfile and possibly future Cloud Native projects. This could make the relation better understandable for their end users.
  

Cons for CN4J from GitHub Document - GitHub pull #74

• Currently has a higher entry cost and overall overhead to run

• Currently has no zero entry participation model for larger companies to sponsor specification development
  
  This is not a valid con, as this has now been resolved by the Jakarta EE working group.
  
  

• Introduces a conflict of interest between evolution and support of enterprise customers and their previous investment in Java EE with a shared steering committee

The charter for CN4J will be derived from the Jakarta EE charter and will clearly state that the CN4J steering committee has the responsibility of shared stewardship of both Jakarta EE and MicroProfile communities. The steering committee is not involved with the day to day working of the communities including release cadence.

• Has more process around separate steering, specification and marketing committees
  
  The Eclipse Foundation’s position is that two entirely separate working groups is clearly more process than having one working group.
  
  

• Has restrictions on how compatibility and branding are claimed (both Pro/Con)
  
  This is not a valid con, as under the CN4J approach MicroProfile would have its own specification process and compatibility requirements.
  
  

• Has baggage to overcome due to legal requirements to move Java EE to Jakarta
  
  This is not a valid con, as under the CN4J approach MicroProfile would have its own specification process and compatibility requirements.
  
  

• Has still not proven that the process is capable of delivering novel content to end users
  
  This is not a valid con, as under the CN4J approach MicroProfile would have its own specification process, compatibility requirements, and release cadence.
  
  

• Utilizing an existing Jakarta WG is definitely an easier path forward from a time, resource, and dollars perspective.  Due to the huge overlap in participants, I think the existing Jakarta WG could be ready for MP usage with a "flip of the switch".
  
  Well said.
  

Cons for CN4J from the MicroProfile mailing list

• Jakarta EE being new and will potentially slow down MP
  
  This is not a valid con, as under the CN4J approach MicroProfile would have its own specification process, compatibility requirements, and release cadence.
  
  

• shared working group charter, steering group, and pmc, it is not clear that one can create sufficiently independent specification processes and committees.
  
  This is not a valid con, the charter and steering group will be set up to ensure independent specification process, compatibility requirements and release cadence. In addition, the PMC for MicroProfile does not have to be limited to the existing EE4J PMC. It could be split up into a separate, focused PMC if necessary.
  
  

• no ability to collapse the steering committees and specification committees into a single group
  
  Actually, if it was desirable to collapse theSteering Committee and Specification Committees into one, that could be included in the charter revisions.
  
  

• MP and Jakarta together will not break down barriers and make it easier to collaborate
  
  That is false. Having a single participation agreement and a shared set of participants will make collaboration and sharing completely seamless.
  
  

• The requirements around claiming compatibility and logo usage are too restrictive. The TCK is a common testsuite. There needs to be a $0 mechanism to claim compatibility AND use some level of project logo
  
  This is not a valid con, as under the CN4J approach MicroProfile would have its own specification process and compatibility requirements. It is not clear that the Eclipse Foundation would approve of such a $0 mechanism regardless of which structure for the working group is selected.
  
  

• ... we can NOT ensure in CN4J that MP and Jakarta are separate entities and separate processes will be maintained in the future. With a common steering committee, it will continue to influence the tighter integration of the two projects over time. For example, the steering committee has influence over releases and release processes. I can see the potential of the steering committee exerting influence for MicroProfile release date alignment with the (currently unknown) Jakarta release cadence, etc. It will also influence (possibly mandate) how project alignment occurs between the two.
  
  This is FUD. First of all, under the EFSP it is the Specification Committee, not the Steering Committee that drives the creation, adoption, and revisions to the spec process used by a working group. In this context that means that the MP Spec Committee within the CN4J WG would control any revisions to its spec process. Secondly and similarly, it is the Spec Committee that controls and approves the Release Plans and therefore any decisions about the release cadence. Thirdly, if additional assurances are required they could be drafted into the new working group charter for the CN4J WG.
  
  

• ... the idea behind the CN4J WG is to open it up to potentially other cloud native projects in the future. This means unknown projects in the future will also have influence over MicroProfile (and Jakarta).
  
  That is a feature, not a bug. What is this “influence” that you are so afraid of? MicroProfile already builds on top of a number of Jakarta EE specifications, and is already supported by almost exactly the same set of vendors. The ability to collaborate and share across projects is the very essence of open source community behavior. 

[John Clingan]

Kinda long for the time I have, so I'll address a few.

On Monday, January 13, 2020 at 6:00:33 AM UTC-8, Paul Buck wrote:

What follows is input on the pros and cons to both the MicroProfile working proposal (MPWG) and the Cloud Native for Java working (CN4J) group group proposal. This commentary is as of discussions on the mailing list and GitHub as around January 9th.

MPWG

Pros for MPWG from GitHub Document - GitHub pull #74

• Flatter governing structure as steering committee, marketing committee and specification committees share the same membership.
  
  This seems of modest value given that many of the same vendors, contributors, and developers are involved in both Jakarta EE and MicroProfile.

Not modest for some of those that that have worked on the MicroProfile for 4 years. In fact, this is partially what has made MicroProfile so successful. We make decisions and act on them quickly when necessary. We think that, by combining the spec committee (with a lazy consensus approach) and steering committee - via shared membership under a single working group - will let us do that.

 

• 
  
  

• Addresses IP gap in existing MP development
  
  This is not a pro, since this is true of both proposals.

It's a pro in that it is really the only issue that MicroProfile needs to be resolve and that has required this working group discussion in the first place.

 

• 
  
  

• Provides complete autonomy of how MP evolves as governing structure is not part of a non-MP specific working group
  
  This seems of modest value given that the same set of vendors are involved in both Jakarta EE and MicroProfile, and that MicroProfile is based on a number of Jakarta EE specifications.

Again, not modest for some of those involved in MicroProfile on a daily basis, it is by-and-large the most critical point. Some do like the different approaches for the different projects, and MicroProfile having its own steering committee lets it set its own priorities and better define its own future that maintains that differentiation. While vendor neutrality was one of the reasons why the Eclipse Foundation was chosen to host MicroProfile in the first place, so was project independence.

 

• 
  
  

• Provides a lower barrier to entry in terms of both cost and process for the MP technology

But increases the overall cost of contributing to the many common elements of cloud native Java technologies since most companies and individual committers are active in both MicroProfile and Jakarta. Having a single participation agreement and a shared set of participants will make collaboration and sharing completely seamless across many related technologies. Also we expect CN4J will have a zero-cost option for individual committers

• Continues a model that has produced multiple independent implementations of novel technologies over a number of years

• 
  
  The model can continue as part of CN4J, the only change required is adoption of the EFSP  which is happening regardless of which working group path is chosen. Release cadence and planning are totally up to the MicroProfile community as they are today.

This is a point of disagreement.  These are really two different projects today, and could be 2+N different projects tomorrow. I have real concerns that this will actually happen. Everyone goes in with the good intentions, and then the real world gets in the way. As CN4J grows with additional projects, additional WG membership, the focus on MicroProfile within the steering committee will become increasingly diluted. Some who join CN4J because of one of these additional projects may have no interest in MicroProfile, yet will have influence over MicroProfile via the shared steering committee.

Speaking of good intentions, while I am putting up a strong defense of a standalone working group (because I truly believe it is what's best for MicroProfile), if the vote is for CN4J, then I'll work as hard to make MicroProfile successful within the CN4J as I have in making MicroProfile successful thus far. However, the independence and focus that MicroProfile has been operating under since it was founded is what has driven it to the success that it has become.

 

• 
  
  

• Allows for large companies to sponsor specification development at a zero cost entry point
  
  This assumes that the MPWG approach will have zero fees, which is an invalid assumption. Nor is it clear why allowing “large companies to sponsor specification development at a zero cost” is an advantage.
  
  

• Less restrictive use of compatibility and logo usage
  
  This is not a valid pro, as under the CN4J approach MicroProfile would have its own specification process and compatibility requirements. The assumption should be that the EFSP-based MicroProfile Spec Process (MPSP) would be identical under either working group structure.

Pros for MPWG from the MicroProfile mailing list 

• MPWG will have relaxed TCK compatibility claims requirements and relaxed voting rules (not clear how)
  
  This is not a valid pro, as under the CN4J approach MicroProfile would have its own specification process and compatibility requirements.
  
  

• Will address the IP and keep "if it ain't broke don't fix it" approach
  
  This is not a valid pro, as under the CN4J approach MicroProfile would have its own specification process and compatibility requirements.  

• 
  
  

• There is no need for EF personnel to be allocated to work on MP
  
  Eclipse Foundation staff are focused on areas that have been identified as priorities by the members of working groups. Assuming the stated goals for MP do not require staff, then no additional staff would be engaged.  

The EF has been critical in getting MicroProfile off the ground. Hats off to Wayne and the rest of the EF staff! However, in the context of the shared steering committee, "no additional" != "none". Under a separate  WG, it would be "none".

 

• 
  
  

• Addresses the immediate need is for MicroProfile to resolve it's IP gap, and will allow to stay "light" on process as it can be and still be a WG. Any discussion on combining Jakarta and MicroProfile working groups is better suited to when MicroProfile has one
  
  This is not a valid pro, as under the CN4J approach MicroProfile would have its own specification process and compatibility requirements. MicroProfile must adopt the EFSP. The assumption should be that the EFSP-based MicroProfile Spec Process (MPSP) would be identical under either working group structure.
  
  

• Going with 1 WG and later find it wasn’t right for MP or even Jakarta EE, splitting them up again may be a nightmare that no one really wants to tackle. However, starting by spinning up a MP WG which runs in parallel with the Jakarta WG and running the two together in a collaborative manner for the next year or so (we do need to define that relationship) doesn’t commit us to continuing in that mode forever if we subsequently obtain further data which allows for a more informed choice, e.g., we decide that having a single WG encompassing both efforts is the right approach.
  
  None of us can foretell the future. It is equally possible that running two working groups in parallel will become an obvious waste of time and effort by everyone involved. Similarly, the conjecture that splitting the CN4J WG in two would “be a nightmare” is simply FUD. Under the CN4J WG proposal, MP will have its own Specification Committee and Marketing Committee, with its own voting and participation rules. Translating that into separate working groups if it becomes necessary seems trivial.

We can't foretell the future, but we can look at the past to get some perspective of the future. The two projects have been operating separately already, and during that time MicroProfile has had six releases, and possibly more depending on when the clock is started. In a few more weeks, it'll be 7 releases.

• 
  

Cons for MPWG from GitHub Document - GitHub pull #74

• Duplicate working group participation agreements need to be signed

• May have duplicate fees depending on the membership level if both MPWG and CN4J/Jakarta are joined

• Tends to not commit to longer term backwards compatibility
  
  This is not a valid con, as under the CN4J approach MicroProfile would have its own specification process and compatibility requirements. If MicroProfile wishes to continue its approach of not guaranteeing backwards compatibility, then that is equally supported in either scenario.

Can the CN4J steering committee override if it conflicts with the needs of Jakarta EE?

BTW, even under separate working groups this would be resolved. However, the process of how it is resolved and what the resolution is may be different.

 

• 
  

Cons for MPWG from the MicroProfile mailing list

• building working group walls between the initiatives within the Eclipse Foundation is pointless and will lead to relentless politics, endless committee meetings, continual confusion about what was discussed and raised where and ultimately will confuse the market. 

• Eclipse Microprofile project leadership is purely IBM (or wholly owned subsidiaries of IBM) this does not feel healthy to the Payara team and moving to a broader PMC would help with that perception. 

• Jakarta EE with one release has not proven itself, more releases are needed to prove the process. Any delays of future releases could impact MicroProfile
  
  This is not a valid con, as under the CN4J approach MicroProfile would have its own specification process and release cadence. There is no reason to assume that there would be any differences between the two approaches with respect to the release dependencies between MicroProfile and Jakarta EE.

Can the steering committee influence this? Even the Jakarta steering committee had to review the Jakarta spec process. What if the CN4J steering committee reviews the MicroProfile spec process and doesn't like it? Can it deny the spec process that the MicroProfile Spec Process committee defines?

[Scott Stark]

On Monday, January 13, 2020 at 8:00:33 AM UTC-6, Paul Buck wrote:

What follows is input on the pros and cons to both the MicroProfile working proposal (MPWG) and the Cloud Native for Java working (CN4J) group group proposal. This commentary is as of discussions on the mailing list and GitHub as around January 9th.

MPWG

Pros for MPWG from GitHub Document - GitHub pull #74

• Flatter governing structure as steering committee, marketing committee and specification committees share the same membership.
  
  This seems of modest value given that many of the same vendors, contributors, and developers are involved in both Jakarta EE and MicroProfile.

That is not a good justification as it assumes there will be no independent expansion in either direction. Many of these same vendors also support truly competing efforts like SpringBoot based applications, so this argument is a non sequitur in my mind.

 

• Addresses IP gap in existing MP development
  
  This is not a pro, since this is true of both proposals.

It is valid as a pro since this was the original statement of why a WG structure was needed. For the vast majority of MP members who have no experience with the EFSP or the Jakarta WG, there is no reason not to be explicit about overlapping pros.

 

• Provides complete autonomy of how MP evolves as governing structure is not part of a non-MP specific working group
  
  This seems of modest value given that the same set of vendors are involved in both Jakarta EE and MicroProfile, and that MicroProfile is based on a number of Jakarta EE specifications.

Again, this make a limiting assumption, and further ignores fundamental issues like WG fees, branding and compatibility claims usage that have not been addressed in the single WG structure. As I have outlined in the other thread, these are fundamental responsibilities of the steering committee.

 

• Provides a lower barrier to entry in terms of both cost and process for the MP technology

But increases the overall cost of contributing to the many common elements of cloud native Java technologies since most companies and individual committers are active in both MicroProfile and Jakarta. Having a single participation agreement and a shared set of participants will make collaboration and sharing completely seamless across many related technologies. Also we expect CN4J will have a zero-cost option for individual committers.

It only increase the cost for those who want to participate in multiple technologies. If you are only interested in a subset of CN4J specifications, and the likelihood of this increases and more specifications are brought into CN4J, the cost barrier to entry will simply preclude users from participating. They will simply be consumers and avoid producing fully certified releases of any subset because the traditional enterprise server cost model does not make sense in the cloud.

• Continues a model that has produced multiple independent implementations of novel technologies over a number of years
  
  The model can continue as part of CN4J, the only change required is adoption of the EFSP  which is happening regardless of which working group path is chosen. Release cadence and planning are totally up to the MicroProfile community as they are today.
  
  

Without the definition of the shared steering committee role, makeup, voting structure and focus, this is an unwarranted statement as the steering committee sits on the path for release approval.

 

• Allows for large companies to sponsor specification development at a zero cost entry point
  
  This assumes that the MPWG approach will have zero fees, which is an invalid assumption. Nor is it clear why allowing “large companies to sponsor specification development at a zero cost” is an advantage.

Why? There is no fundamental coast overhead for signing a second participation agreement. The MP usage of Eclipse infrastructure is no different than any other open source development project, and in fact less due to the fact that implementations are not hosted at Eclipse. The advantage is very clear; company X wants to sponsor adoption of a specification under MP and MP alone. They have no interest in an EE profile runtime. An IDP vendor that is looking for changes in MP-JWT is one trivial example.

 

• Less restrictive use of compatibility and logo usage
  

• This is not a valid pro, as under the CN4J approach MicroProfile would have its own specification process and compatibility requirements. The assumption should be that the EFSP-based MicroProfile Spec Process (MPSP) would be identical under either working group structure.

Again it is the responsibility of the shared steering committee to define branding and compatibility requirements. There is no statement that the CN4J will allow for multiple logos and associated compatibility claims with usage of the logos under different cost terms. 

 

Pros for MPWG from the MicroProfile mailing list 

• MPWG will have relaxed TCK compatibility claims requirements and relaxed voting rules (not clear how)
  
  This is not a valid pro, as under the CN4J approach MicroProfile would have its own specification process and compatibility requirements.

 

• Will address the IP and keep "if it ain't broke don't fix it" approach
  

This is not a valid pro, as under the CN4J approach MicroProfile would have its own specification process and compatibility requirements.

Again, there is no justification to this statement from a definition of the shared steering committee under the CN4J model.

 

• There is no need for EF personnel to be allocated to work on MP
  

• 
  Eclipse Foundation staff are focused on areas that have been identified as priorities by the members of working groups. Assuming the stated goals for MP do not require staff, then no additional staff would be engaged.  

Correct, and hence the question of why the same cost model as any other open source project at Eclipse would not apply to MPWG? There is $0 additional relative to the membership fees participants already cover for open source development at Eclipse.

 

• Addresses the immediate need is for MicroProfile to resolve it's IP gap, and will allow to stay "light" on process as it can be and still be a WG. Any discussion on combining Jakarta and MicroProfile working groups is better suited to when MicroProfile has one
  

This is not a valid pro, as under the CN4J approach MicroProfile would have its own specification process and compatibility requirements. MicroProfile must adopt the EFSP. The assumption should be that the EFSP-based MicroProfile Spec Process (MPSP) would be identical under either working group structure.

 

Not justified via the current CN4J due to the undefined nature of the shared steering committee.

 

• Going with 1 WG and later find it wasn’t right for MP or even Jakarta EE, splitting them up again may be a nightmare that no one really wants to tackle. However, starting by spinning up a MP WG which runs in parallel with the Jakarta WG and running the two together in a collaborative manner for the next year or so (we do need to define that relationship) doesn’t commit us to continuing in that mode forever if we subsequently obtain further data which allows for a more informed choice, e.g., we decide that having a single WG encompassing both efforts is the right approach.
  
  None of us can foretell the future. It is equally possible that running two working groups in parallel will become an obvious waste of time and effort by everyone involved. Similarly, the conjecture that splitting the CN4J WG in two would “be a nightmare” is simply FUD. Under the CN4J WG proposal, MP will have its own Specification Committee and Marketing Committee, with its own voting and participation rules. Translating that into separate working groups if it becomes necessary seems trivial.

I agree that translating into separate working groups is the simplest solution to the current IP issues with MP. Establishing a single WG that satisfies the requirements of EE, MP AND future sets of specifications that may apply to cloud native Java will take a lot of time, and is the nightmare being referenced. Any belief to the contrary by someone who went through the Jakarta EE WG formation is not looking at the history of that effort with honest reflection.

 

• 
  

Cons for MPWG from GitHub Document - GitHub pull #74

• Duplicate working group participation agreements need to be signed

• May have duplicate fees depending on the membership level if both MPWG and CN4J/Jakarta are joined

• Tends to not commit to longer term backwards compatibility
  
  This is not a valid con, as under the CN4J approach MicroProfile would have its own specification process and compatibility requirements. If MicroProfile wishes to continue its approach of not guaranteeing backwards compatibility, then that is equally supported in either scenario.

It is a con of the current MP project from the perspective of the traditional EE enterprise customer where long term compatibility was a feature of the EE platform. It continues to be a con under either WG approach if the current MP focus is able to be maintained under CN4J.

 

• 
  

Cons for MPWG from the MicroProfile mailing list

• building working group walls between the initiatives within the Eclipse Foundation is pointless and will lead to relentless politics, endless committee meetings, continual confusion about what was discussed and raised where and ultimately will confuse the market. 

• Eclipse Microprofile project leadership is purely IBM (or wholly owned subsidiaries of IBM) this does not feel healthy to the Payara team and moving to a broader PMC would help with that perception. 

• Jakarta EE with one release has not proven itself, more releases are needed to prove the process. Any delays of future releases could impact MicroProfile
  
  This is not a valid con, as under the CN4J approach MicroProfile would have its own specification process and release cadence. There is no reason to assume that there would be any differences between the two approaches with respect to the release dependencies between MicroProfile and Jakarta EE.

The same critique regarding the lack of definition around the shared steering committee applies here. It will take far longer to hammer out an agreed on CN4J structure than it will to complete and MPWG which only has to define the MPSP. 

 

CN4J WG

Pros for CN4J form GitHub Document - GitHub pull #74

• Allows for parties interested in both MPWG and CN4J/Jakarta to sign one working group participation agreement

• Addresses IP gap in existing MP development
  
  This is not a valid pro, as under both approaches MicroProfile will adopt a variant of the EFSP.
  
  

 

• Tends to focus on stability and backwards compatibility
  
  This is not a valid pro, as under the CN4J approach MicroProfile would have its own specification process and compatibility requirements. If MicroProfile wishes to continue its approach of not guaranteeing backwards compatibility, then that is equally supported in either scenario.
  
  

 

• Has restrictions on how compatibility and branding are claimed (both Pro/Con)
  
  This is not a valid pro, as under the CN4J approach MicroProfile would have its own specification process and compatibility requirements. 

Pros for CN4J from the microprofile mailing list

• Share the same budget and no extra fees

• MicroProfile can set up committees as they were on their own, and act as separate entity

• MicroProfile projects and Jakarta EE projects have far more attributes in common than differences, and we should leverage this commonality in the way we structure our collaboration via Working Groups, and in the way we present ourselves to the community and the marketplace.

• Single WG governing the evolution of these projects, it could help in aligning and unifying Jakarta EE, MicroProfile and possibly future Cloud Native projects. This could make the relation better understandable for their end users.
  

Cons for CN4J from GitHub Document - GitHub pull #74

• Currently has a higher entry cost and overall overhead to run

• Currently has no zero entry participation model for larger companies to sponsor specification development
  
  This is not a valid con, as this has now been resolved by the Jakarta EE working group.
  
  

• Introduces a conflict of interest between evolution and support of enterprise customers and their previous investment in Java EE with a shared steering committee

The charter for CN4J will be derived from the Jakarta EE charter and will clearly state that the CN4J steering committee has the responsibility of shared stewardship of both Jakarta EE and MicroProfile communities. The steering committee is not involved with the day to day working of the communities including release cadence.

• Has more process around separate steering, specification and marketing committees
  
  The Eclipse Foundation’s position is that two entirely separate working groups is clearly more process than having one working group.

There is clearly less process under the MPWG as all committees collapse into one that uses the current bi-weekly MP community meeting for all committees.

The best the CN4J WG can do is to match this.

 

• 
  

• Has restrictions on how compatibility and branding are claimed (both Pro/Con)
  
  This is not a valid con, as under the CN4J approach MicroProfile would have its own specification process and compatibility requirements.
  
  

• Has baggage to overcome due to legal requirements to move Java EE to Jakarta
  
  This is not a valid con, as under the CN4J approach MicroProfile would have its own specification process and compatibility requirements.
  
  

• Has still not proven that the process is capable of delivering novel content to end users
  
  This is not a valid con, as under the CN4J approach MicroProfile would have its own specification process, compatibility requirements, and release cadence.
  
  

This is a non sequitur comment that does not address the con.

 

• Utilizing an existing Jakarta WG is definitely an easier path forward from a time, resource, and dollars perspective.  Due to the huge overlap in participants, I think the existing Jakarta WG could be ready for MP usage with a "flip of the switch".
  
  Well said.

But unfounded due to the lack of definition in the CN4J.

 

• 
  

Cons for CN4J from the MicroProfile mailing list

• Jakarta EE being new and will potentially slow down MP
  
  This is not a valid con, as under the CN4J approach MicroProfile would have its own specification process, compatibility requirements, and release cadence.

Same critique as before regarding the lack of steering committee definition.

 

• 
  
  

• shared working group charter, steering group, and pmc, it is not clear that one can create sufficiently independent specification processes and committees.
  
  This is not a valid con, the charter and steering group will be set up to ensure independent specification process, compatibility requirements and release cadence. In addition, the PMC for MicroProfile does not have to be limited to the existing EE4J PMC. It could be split up into a separate, focused PMC if necessary.
  
  

This statement cannot be justified with the current level of definition

 

• no ability to collapse the steering committees and specification committees into a single group
  
  Actually, if it was desirable to collapse theSteering Committee and Specification Committees into one, that could be included in the charter revisions.
  
  

Ok, this is the level of detail that is needed to really be able to validate the CN4J

 

• MP and Jakarta together will not break down barriers and make it easier to collaborate
  
  That is false. Having a single participation agreement and a shared set of participants will make collaboration and sharing completely seamless.
  
  

The participation agreement does nothing to further address barriers as it only deals with the expanded IP licensing grants and separate participation agreements achieve the same IP sharing arrangement. A discussion about how MP and EE collaborate simply has not even been bridged due to lack of willingness on some parties to engage in the MP spec process due to IP concerns. The point of the critique is that a single WG in of itself does not change this. What will change this is having interested parties define what technical collaboration means. Requiring this as part of the CN4J charter complicates the development of the charter and pushes out the closing of the MP IP gap.

 

• The requirements around claiming compatibility and logo usage are too restrictive. The TCK is a common testsuite. There needs to be a $0 mechanism to claim compatibility AND use some level of project logo
  
  This is not a valid con, as under the CN4J approach MicroProfile would have its own specification process and compatibility requirements. It is not clear that the Eclipse Foundation would approve of such a $0 mechanism regardless of which structure for the working group is selected.

Which raises two responses. First, acceptance that MP would be able to define its own compatibility and logo usage requirements is unclear due to the lack of definition around the shared steering committee. Second, how the Eclipse Foundation can define minimum cost for project logo usage is based on what existing process structure? It would seem that the Eclipse Foundation is attempting to use open source specification development as a revenue generation model above that already in place for open source development.

 

• 
  

• ... we can NOT ensure in CN4J that MP and Jakarta are separate entities and separate processes will be maintained in the future. With a common steering committee, it will continue to influence the tighter integration of the two projects over time. For example, the steering committee has influence over releases and release processes. I can see the potential of the steering committee exerting influence for MicroProfile release date alignment with the (currently unknown) Jakarta release cadence, etc. It will also influence (possibly mandate) how project alignment occurs between the two.
  
  This is FUD. First of all, under the EFSP it is the Specification Committee, not the Steering Committee that drives the creation, adoption, and revisions to the spec process used by a working group. In this context that means that the MP Spec Committee within the CN4J WG would control any revisions to its spec process. Secondly and similarly, it is the Spec Committee that controls and approves the Release Plans and therefore any decisions about the release cadence. Thirdly, if additional assurances are required they could be drafted into the new working group charter for the CN4J WG.

As I have pointed out, the responsibilities of the steering committee as outlined in the current Jakarta EE WG in The Steering Committee section include the following:

Powers and Duties

Steering Committee members are required to:

• Define and manage the strategy of the working group.
• Define and manage which Eclipse Foundation projects are included within the scope of this working group. This will require acceptance of the specification process by these projects.
• Define and manage a process for projects outside of the Eclipse Foundation to be included in the Jakarta EE platform.
• Define and manage the roadmaps.
• Review and approve this charter.
• Review and approve the participation agreement.
• Review and approve the specification process.
• Review and approve the trademark policy to ensure compatibility of independent implementations of specifications.
• Define the budget and fees for all classes of working group membership each year.
• Invite Guest members to participate in the working group.

So there are several areas that the steering committee has authority over that have conflicts in terms of how MP operates and Jakarta EE operates. While we have many of the same groups participating in both EE and MP, those same groups also have different products and customers that do have competing requirements. The main points of conflict that have not been addressed in the CN4J draft statement include fees and budget, trademark and compatibility policies, and in general, what does alignment between MP and EE mean? There really can't be a meaningful discussion of the pros/cons of the CN4J approach until the duties and operation of the steering committee are defined.

 

• 
  
  

• ... the idea behind the CN4J WG is to open it up to potentially other cloud native projects in the future. This means unknown projects in the future will also have influence over MicroProfile (and Jakarta).
  
  That is a feature, not a bug. What is this “influence” that you are so afraid of? MicroProfile already builds on top of a number of Jakarta EE specifications, and is already supported by almost exactly the same set of vendors. The ability to collaborate and share across projects is the very essence of open source community behavior. 

The influence that is of concern is that as orthogonal specifications are brought into CN4J, the focus dilutes, the budget either increases or becomes diluted relative to original specifications, and the operation and even charter definition become increasingly complicated to deal with fair distribution of limited resources. In short, it is a general critique of utilizing a structure whose baseline technical is the facilitation of IP sharing to attempt to achieve broader community orchestration goals via a process that has not been battle tested.

The continued reference to the same set of vendors is something that should be of concern to you as it implies the functioning of the process relies on equally weighted participation in all subsets of specifications. That is an unhealthy requirement. Participants should be able to come and go freely, contributing when they can with minimal cost and still have significant impact on the specifications and associated user community.

 

[Scott Stark]

Related to the inability to support a $0 fee for usage of compatibility claims and logo usage, I have gone through the base working group process document:

https://www.eclipse.org/org/workinggroups/process.php

and the only contexts in which fees are mentioned are the following:

Working Groups may decide to charge annual fees (“Working Group Fees”). If so, those fees must be defined in the Charter, must clearly describe the fee structure for each level of Participant, and must clearly indicate the Working Group Fees are exclusive of and in addition to the fees for membership in the Eclipse Foundation. The Charter must indicate that the Steering Committee is responsible for establishing and modifying the Working Group Fees.

...

A Working Group may define multiple levels of Participation. These levels can be differentiated by different Working Group Fees, responsibilities, commitment of resources, representation on committees, etc.. These levels of participation must be described in the Charter.

...

Unless decided by the Working Group Steering Committee and stated in the Working Group Charter, there shall be no additional charges or fees for Eclipse Members to be a Participant in a Working Group.

So at a base level, the written stance with respect to Working Group related fees would clearly be that a $0 is the default unless otherwise stated in a Working Group Charter.

On Monday, January 13, 2020 at 8:00:33 AM UTC-6, Paul Buck wrote:

[Paul Buck]

John, Scott,

Thanks for the responses. After reading (and re-reading) your comments... for CN4J many points root back the shared steering committee. I think it would be constructive to propose changes to the Jakarta EE working group charter that evolve it to effectively support both MicroProfile and Jakarta EE. Thoughts?

Regards ... Paul

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/4404a2f8-b2e4-4d38-9ad5-c86d2b7e681b%40googlegroups.com.

[Emily Jiang]

+1 Paul!

I think if we can ensure the CN4J steering committee makes sure Jakarta EE and MP separate and allow them to progress indendpently, it will help.

Thanks

Emily

To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

[John Clingan]

Paul, can you provide more details, I'd like to parse this correctly. Not quite sure I follow because it sounds like this would move further away from an independent MicroProfile.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

[John Clingan]

On Friday, January 17, 2020 at 2:46:16 AM UTC-8, Emily Jiang wrote:

+1 Paul!

I think if we can ensure the CN4J steering committee makes sure Jakarta EE and MP separate and allow them to progress indendpently, it will help.

Emily, you cannot ensure a shared steering committee will make them separate. I've covered this elsewhere. In addition, to Scott's point, there are some fundamental differences that occur at the working group level, like fees.

[Scott Stark]

Before we get into weeds, it seems to be a though there is a lack of
fundamental agreement on:
1. What it means for EE and MP to be aligned technically.
2. Whether those arguing for a single WG are really arguing for a
single set of EE specs.

I would like to get to an understanding of these points before looking
at the mechanics of how a single WG might function because there seem
to be conflicting requirements at this point.

> You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/Zv966Yw0FEs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/6f2403d7-bf31-4f8c-845f-fbf0d0aa41ca%40googlegroups.com.

[Paul Buck]

John,

Let me try again, the charter for a CN4J working group that supported both Jakarta EE and MicroProfile would have a single steering committee with Powers and Duties described in the working group's charter.

What I am wondering is what changes/edits are required to the Jakarta EE working group charter to address the points you and Scott have raised as concerns with having a single steering committee for CN4J that supports MicroProfile and Jakarta EE? Here's a draft CN4J charter as a starting point.

... Paul

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/6f2403d7-bf31-4f8c-845f-fbf0d0aa41ca%40googlegroups.com.

[John Clingan]

Thanks Paul. I’ll read over the weekend.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAEWo7Y5aUOCg6XYgmHk%2BJh5T3zDZTYZF8mJs58uWE51juwiszQ%40mail.gmail.com.

[Scott Stark]

I have made an initial pass through the CN4J charter. I see that there are references to MicroProfile specific committees while I was thinking of, and have added a general notion of a Developer Subgroup for a subset of CN4J specification projects. Do we expect to modify the WG charter every-time a new subset of specifications is added? Say separate bootstrap, native image generation, and kubernetes binding specifications want to be added? That would be three separate updates to the WG charter or could these be separate sub-charters that the CN4J steering committee approves?

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/6f2403d7-bf31-4f8c-845f-fbf0d0aa41ca%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAEWo7Y5aUOCg6XYgmHk%2BJh5T3zDZTYZF8mJs58uWE51juwiszQ%40mail.gmail.com.

[Mark Little]

Paul, thanks for pulling this together.

Mark.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAEWo7Y5aUOCg6XYgmHk%2BJh5T3zDZTYZF8mJs58uWE51juwiszQ%40mail.gmail.com.

[Werner Keil]

Paul,

So is this about MP or CN4J WG or should there really be BOTH?

How an explosion of many different working groups may look like can be seen in the Automotive space:

https://www.eclipse.org/org/workinggroups/explore.php

OpenADX, openGENESIS, OpenHW, openMDM, OpenMobility, openPASS

The annual fees for the biggest companies (>$250 million turnover) are

20k, 30k, 250k, 40k, 0 (during Incubation), 20k

So if a company of a large size (not just Billion Dollar ones like Oracle, Red Hat or IBM) wishes to be an influential member in all of them, it would cost them 360,000 US$ per year and that is only for the WGs.

I'm just a small Individual Committer representative, so myself and maybe a handful others don't really bother about fees and we actively participate wherever we are welcome to, but for larger companies that might sometimes be quit hefty, and especially in the Automotive industry things aren't so rosy any more, so some of these WGs might see a sharp decline in membership over time...? ;-/

Werner

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/6f2403d7-bf31-4f8c-845f-fbf0d0aa41ca%40googlegroups.com.

[Paul Buck]

On Sun, Jan 19, 2020 at 2:39 PM Werner Keil <werne...@gmail.com> wrote:

Paul,

So is this about MP or CN4J WG or should there really be BOTH?

The draft charter is for CN4J, although would have applicability for a MP working group too I expect.

 

How an explosion of many different working groups may look like can be seen in the Automotive space:

https://www.eclipse.org/org/workinggroups/explore.php

OpenADX, openGENESIS, OpenHW, openMDM, OpenMobility, openPASS

The annual fees for the biggest companies (>$250 million turnover) are

20k, 30k, 250k, 40k, 0 (during Incubation), 20k

So if a company of a large size (not just Billion Dollar ones like Oracle, Red Hat or IBM) wishes to be an influential member in all of them, it would cost them 360,000 US$ per year and that is only for the WGs.

I'm just a small Individual Committer representative, so myself and maybe a handful others don't really bother about fees and we actively participate wherever we are welcome to, but for larger companies that might sometimes be quit hefty, and especially in the Automotive industry things aren't so rosy any more, so some of these WGs might see a sharp decline in membership over time...? ;-/

The fees are set by the working group's steering committee to fulfill the objectives they establish in their program plan, considerations like the ones you mention for automotive need to be assessed by the respective steering committees. That includes implications of the same company joining multiple working groups and need for low-cost or no-cost options for membership.

 

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/f54a0053-75b1-47d8-9d2f-89bef9ae2829%40googlegroups.com.

[Mike Milinkovich]

On 2020-01-18 7:34 p.m., Scott Stark wrote:

I have made an initial pass through the CN4J charter. I see that there are references to MicroProfile specific committees while I was thinking of, and have added a general notion of a Developer Subgroup for a subset of CN4J specification projects. Do we expect to modify the WG charter every-time a new subset of specifications is added? Say separate bootstrap, native image generation, and kubernetes binding specifications want to be added? That would be three separate updates to the WG charter or could these be separate sub-charters that the CN4J steering committee approves?

That's a good question.

First off, let me start by saying there is no right answer to the dilemma of whether it is easier to explicitly edit and approve charter revisions to tackle cases like you described, versus creating a general framework that allows a simpler process for adding structure. The former is more explicit effort when these events occur, but the latter can end up being more confusing to read and understand because it is providing an implicit framework rather than stating in clear language what is being added.

That said, I do not think that the triggering event is the addition of a new subset of technical specifications. The triggering event would be the addition of a new brand. So as long as separate bootstrap, native image generation, and kubernetes binding specifications were happy to use either the Jakarta EE or MicroProfile brand, they could fit within the proposed framework. If there were good reasons why such specifications should reside within a new brand, then those conversations would have to happen at that time.

Given that there are already two well regarded brands under discussion, hopefully new specifications would be happy to select one of those for quite some time to come. Given that, I do not think that working group charter edits would be required very often.

--

Mike Milinkovich

Executive Director | Eclipse Foundation, Inc.

mike.mil...@eclipse-foundation.org

@mmilinkov

+1.613.220.3223 (m)