Working Group

[John Clingan]

Today on the MicroProfile Live Hangout (recording, minutes) we discussed the need for creating a working group in order to close a gap in IP flow. To this end, we currently have two separate Working Group proposals. To be very brief, the MicroProfile Working Group Proposal outlines a standalone MicroProfile working group, whereas the Cloud Native for Java Working Group Proposal outlines a working group with a single steering committee that encompasses MicroProfile, Jakarta EE, and potentially additional future cloud native projects. There are some additional sub-topics that will need to be discussed that are required to form the working group, such as budget and a specification process.

These proposals are outlines that are intended to generate a lot of discussion, perhaps stimulating the creation of additional proposals. The result of this process should be a final proposal that will then be transformed into a formal working group definition.

The time frame, just to put a fungible marker in the ground, is to have discussion finalized by the end of February and an agreed-upon working group definition by the end of March.

Before commenting on the proposals themselves, please read each proposal in its entirety.  Three ... two ... one ... go!

[Amelia Eiras]

Thank you John for sending the formal update of what could come next Community call follow-up via minutes and video directly to the forum and tweet!

Can we add to the MP calendar the agreed Feb 28th "soft deadline" as an event to take care of?  It matters to set ourselves a reachable timeframe that is traceable beyond this email. :)

 

Second, I recommend that from Jan to Feb, each Community hangout dedicates at least 10 to 15mins for topic to be discussed. 

Further, I recommend that the work and feedback be focus more into the PR itself instead of prioritizing this thread for collaboration/looping feedback that can add debt tracking needs to be cut if at all possible.  

Lastly, as stated during the call, starting this week and for at least 1/week the MP media channels will push this  thread along side the PR proposals until Feb 28th. 

Happy Holidays to everyone, 

[John Clingan]

On Tuesday, December 10, 2019 at 3:21:17 PM UTC-8, Amelia Eiras wrote:

Thank you John for sending the formal update of what could come next Community call follow-up via minutes and video directly to the forum and tweet!

Can we add to the MP calendar the agreed Feb 28th "soft deadline" as an event to take care of?  It matters to set ourselves a reachable timeframe that is traceable beyond this email. :)

Good idea.

 

 

Second, I recommend that from Jan to Feb, each Community hangout dedicates at least 10 to 15mins for topic to be discussed. 

Another good idea. You're on a roll!

 

Further, I recommend that the work and feedback be focus more into the PR itself instead of prioritizing this thread for collaboration/looping feedback that can add debt tracking needs to be cut if at all possible.  

We can forward folks to the issue.

 

Lastly, as stated during the call, starting this week and for at least 1/week the MP media channels will push this  thread along side the PR proposals until Feb 28th. 

Ack.

[Mark Little]

Hey John, is there an easy way to compare and contrast the two options?

Mark.

--
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/89b86cc5-1b2a-4944-b2dd-876e1ff777e0%40googlegroups.com.

---
Mark Little
mli...@redhat.com

JBoss, by Red Hat
Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)

[Kevin Sutter]

No, Mark, we don't have anything like that yet.  Feel free to produce a compare and contrast document to aid with the review.  :-)  Seriously, something like that.  Or, a pro and con table would be good.  It's just a matter of finding the time to do it.  If anybody on this thread has the cycles to produce something like that, please submit a PR.  Thanks!

-- Kevin

On Wednesday, December 11, 2019 at 7:01:07 AM UTC-6, Mark Little wrote:

Hey John, is there an easy way to compare and contrast the two options?

Mark.

On 11 Dec 2019, at 00:11, John Clingan <jcli...@redhat.com> wrote:

On Tuesday, December 10, 2019 at 3:21:17 PM UTC-8, Amelia Eiras wrote:

Thank you John for sending the formal update of what could come next Community call follow-up via minutes and video directly to the forum and tweet!

Can we add to the MP calendar the agreed Feb 28th "soft deadline" as an event to take care of?  It matters to set ourselves a reachable timeframe that is traceable beyond this email. :)

Good idea.

 

 

Second, I recommend that from Jan to Feb, each Community hangout dedicates at least 10 to 15mins for topic to be discussed. 

Another good idea. You're on a roll!

 

Further, I recommend that the work and feedback be focus more into the PR itself instead of prioritizing this thread for collaboration/looping feedback that can add debt tracking needs to be cut if at all possible.  

We can forward folks to the issue.

 

Lastly, as stated during the call, starting this week and for at least 1/week the MP media channels will push this  thread along side the PR proposals until Feb 28th. 

Ack.

 

Happy Holidays to everyone, 

On Tuesday, December 10, 2019 at 2:58:51 PM UTC-8, John Clingan wrote:

Today on the MicroProfile Live Hangout (recording, minutes) we discussed the need for creating a working group in order to close a gap in IP flow. To this end, we currently have two separate Working Group proposals. To be very brief, the MicroProfile Working Group Proposal outlines a standalone MicroProfile working group, whereas the Cloud Native for Java Working Group Proposal outlines a working group with a single steering committee that encompasses MicroProfile, Jakarta EE, and potentially additional future cloud native projects. There are some additional sub-topics that will need to be discussed that are required to form the working group, such as budget and a specification process.

These proposals are outlines that are intended to generate a lot of discussion, perhaps stimulating the creation of additional proposals. The result of this process should be a final proposal that will then be transformed into a formal working group definition.

The time frame, just to put a fungible marker in the ground, is to have discussion finalized by the end of February and an agreed-upon working group definition by the end of March.

Before commenting on the proposals themselves, please read each proposal in its entirety.  Three ... two ... one ... go!

--
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+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/89b86cc5-1b2a-4944-b2dd-876e1ff777e0%40googlegroups.com.

[Mark Little]

OK well I think a pros and cons review is necessary for everyone to understand what is being proposed.

Mark.

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/653160d3-237a-4a76-9bd7-b8a4f57c1571%40googlegroups.com.

[John Clingan]

We felt it was better for the community to  create pro/con to not have us weigh one over the other. Like Kevin, I think the broader community creating one and hashing out what is a  pro and what is a con would be awesome. EDIT: Well, not early on. We have our thoughts that will be part of the discussion.

[Mark Little]

ok makes sense.

On 12 Dec 2019, at 16:43, John Clingan <jcli...@redhat.com> wrote:

We felt it was better for the community to  create pro/con to not have us weigh one over the other. Like Kevin, I think the broader community creating one and hashing out what is a  pro and what is a con would be awesome.

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/0070c540-80d3-4ad6-80f9-6f51a5b4e589%40googlegroups.com.

[Amelia Eiras]

+1 on everyone helping create the contrasts on the 2 proposals as they are consumed, efficient and effective consumption with scalability that minimizes "wondering" or assuming stuff. 

 Important Reminder:  additional proposals via PRs are MOST welcomed.  No leads, just own it if you see it enhancing what currently is. You, mine, our vision of the MP_WG is not a delegated task. :)

MP_WG media push is ready for everyone here to help push further via your media channels.  As stated on the git issue, the reminder will run automatically run from today, to every Tuesday and Saturday until the end of Feb, the current soft deadline. 

Happy wknd MicroProfilers, 

ok makes sense.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/0070c540-80d3-4ad6-80f9-6f51a5b4e589%40googlegroups.com.

[Scott Stark]

I have created an initial version of a pro/con comparison document:

https://github.com/eclipse/microprofile-sandbox/pull/74

[Amelia Eiras]

reviewed, impressive Scott. 

I won't merge the PR as it requires more viewers. :) you ROCK!

Amelia Eiras 

twitter.com/ameliaeiras

Tribe: http://tomitribe.com      https://tribestream.io   

OSS:  http://microprofile.io     https://jakarta.ee

--
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/zwFhZec8MGA/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/d1f3d29f-47b8-477e-9504-467a9bcb637d%40googlegroups.com.

[Emily Jiang]

I was in the middle of producing a cons/pros, but Scott raced ahead of me. In doing this exercise, I have the following questions:

MPWG - MicroProfile Working Group

CNWG- Cloud Native Working Group

1. In MPWG, can Jakarta EE specs adopt MP Specs?

2. In MPWG, judging by "Adhere to the MicroProfile Specification Process, which is based on the Eclipse Foundation Specification Process", am I right to assume the MPWG might be very similar to Jakarta WG except the WG voting.

3. In CNWG, can Jakarta EE specs adopt MP Specs while MP Specs don't need to make any namespace changes?

4. In CNWG, will the spec committee and steering committee be expanded to add additional seats for MP communities?

5. In either MPWG or CNWG, no technical changes are required for any of the specifications, e.g. namespace updates etc. Please confirm.

Thanks

Emily

[Scott Stark]

On Monday, December 16, 2019 at 9:54:05 AM UTC-6, Emily Jiang wrote:

I was in the middle of producing a cons/pros, but Scott raced ahead of me. In doing this exercise, I have the following questions:

MPWG - MicroProfile Working Group

CNWG- Cloud Native Working Group

1. In MPWG, can Jakarta EE specs adopt MP Specs?

This would have to be a change in the Jakarta working group and spec process. It would not be a given if there was a single working group under CN4J either. Regardless of whether there are two or one working groups, a topic for discussion in Jakarta is how Jakarta consumes MP specs. Up to this point it has been an unavailable discussion due to the IP mismatch.

 

2. In MPWG, judging by "Adhere to the MicroProfile Specification Process, which is based on the Eclipse Foundation Specification Process", am I right to assume the MPWG might be very similar to Jakarta WG except the WG voting.

The MPSP that a few have been sketching out differs from the EFSP/JESP by flattening the structural hierarchy, having a single specification project, reducing requirements around TCK compatibility claims and logo usage, and trying to simplify voting with lazy consensus votes where possible. Hopefully we can push out the draft changes for consideration soon.

 

3. In CNWG, can Jakarta EE specs adopt MP Specs while MP Specs don't need to make any namespace changes?

Really the same as 1.

 

4. In CNWG, will the spec committee and steering committee be expanded to add additional seats for MP communities?

That would have to be a discussion in an update to the working group charter relative to the existing Jakarta working group charter. I would think would be some effort to ensuring a balanced makeup, but I'm not sure how that would be achieved since many Jakarta members do have work in MP.

 

5. In either MPWG or CNWG, no technical changes are required for any of the specifications, e.g. namespace updates etc. Please confirm.

There is nothing required other than the current ongoing update from javax to jarkarta for Jakarta EE 9.

[Kevin Sutter]

Just a couple of minor clarifications...

On Monday, December 16, 2019 at 12:00:12 PM UTC-6, Scott Stark wrote:

On Monday, December 16, 2019 at 9:54:05 AM UTC-6, Emily Jiang wrote:

I was in the middle of producing a cons/pros, but Scott raced ahead of me. In doing this exercise, I have the following questions:

MPWG - MicroProfile Working Group

CNWG- Cloud Native Working Group

1. In MPWG, can Jakarta EE specs adopt MP Specs?

This would have to be a change in the Jakarta working group and spec process. It would not be a given if there was a single working group under CN4J either. Regardless of whether there are two or one working groups, a topic for discussion in Jakarta is how Jakarta consumes MP specs. Up to this point it has been an unavailable discussion due to the IP mismatch.

Just to be clear.  As it stands today with our current MP processes, Jakarta EE can not reference or embed any of the MP specifications.  A minimum requirement to allow this to happen is for MP to adopt a derivative of the EFSP.  And, a requirement of the EFSP is to be part of a Working Group.  So, once MP becomes part of a Working Group via any of the proposals, then that opens the door for the next level of discussions between Jakarta EE and MicroProfile.

 

2. In MPWG, judging by "Adhere to the MicroProfile Specification Process, which is based on the Eclipse Foundation Specification Process", am I right to assume the MPWG might be very similar to Jakarta WG except the WG voting.

The MPSP that a few have been sketching out differs from the EFSP/JESP by flattening the structural hierarchy, having a single specification project, reducing requirements around TCK compatibility claims and logo usage, and trying to simplify voting with lazy consensus votes where possible. Hopefully we can push out the draft changes for consideration soon.

The single specification project is not unique to the MPWG proposal.  This could also apply to the CN4J WG proposal.  The other differences listed are valid.

 

3. In CNWG, can Jakarta EE specs adopt MP Specs while MP Specs don't need to make any namespace changes?

Really the same as 1.

 

4. In CNWG, will the spec committee and steering committee be expanded to add additional seats for MP communities?

That would have to be a discussion in an update to the working group charter relative to the existing Jakarta working group charter. I would think would be some effort to ensuring a balanced makeup, but I'm not sure how that would be achieved since many Jakarta members do have work in MP.

I think there are positives with both WG proposals.  And, regardless of which way is eventually chosen, I hope that we will evaluate the other proposal in detail to possible incorporate some of the ideas.  For example, the idea of lazy consensus voting in the MPWG proposal should be considered for the CN4J WG proposal.  Maybe expanding the voting membership is another idea that should be considered.

[Steve Millidge]

Having read the proposals and not been involved in drafting them. As the leader of an organisation that is involved heavily in both initiatives from the beginning I am in favour of a single Cloud Native for Java Working Group and don't see the point of the bureaucracy involved in two working groups. Both technologies are complimentary to each other, involve to a large extent the same organisations and people and are both beneficial to the same group of end users. My view is that 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. 

Steve 

[Emily Jiang]

Thank you Scott and Kevin for your response! First of all, it is good to have a working group, so that we can cover IP issus and work towards the next level of integration between Jakarta and MicroProfile (mainly focusing on getting MP available to Jakarta EE specifications).

4. In CNWG, will the spec committee and steering committee be expanded to add additional seats for MP communities?

That would have to be a discussion in an update to the working group charter relative to the existing Jakarta working group charter. I would think would be some effort to ensuring a balanced makeup, but I'm not sure how that would be achieved since many Jakarta members do have work in MP.

I think there are positives with both WG proposals.  And, regardless of which way is eventually chosen, I hope that we will evaluate the other proposal in detail to possible incorporate some of the ideas.  For example, the idea of lazy consensus voting in the MPWG proposal should be considered for the CN4J WG proposal.  Maybe expanding the voting membership is another idea that should be considered.

I would like to explore a bit more on this area. I think this is a real differentiator or the comprimise area. If we settle on CN4J WG proposal, is it possible to set up two spec committees: Jakarta Spec Comittee and MicroProfile Spec Comittee. Is this something acceptable?

Thanks

Emily

[Ivar Grimstad]

On Tuesday, December 17, 2019 at 3:26:35 PM UTC+1, Emily Jiang wrote:

Thank you Scott and Kevin for your response! First of all, it is good to have a working group, so that we can cover IP issus and work towards the next level of integration between Jakarta and MicroProfile (mainly focusing on getting MP available to Jakarta EE specifications).

4. In CNWG, will the spec committee and steering committee be expanded to add additional seats for MP communities?

That would have to be a discussion in an update to the working group charter relative to the existing Jakarta working group charter. I would think would be some effort to ensuring a balanced makeup, but I'm not sure how that would be achieved since many Jakarta members do have work in MP.

I think there are positives with both WG proposals.  And, regardless of which way is eventually chosen, I hope that we will evaluate the other proposal in detail to possible incorporate some of the ideas.  For example, the idea of lazy consensus voting in the MPWG proposal should be considered for the CN4J WG proposal.  Maybe expanding the voting membership is another idea that should be considered.

I would like to explore a bit more on this area. I think this is a real differentiator or the comprimise area. If we settle on CN4J WG proposal, is it possible to set up two spec committees: Jakarta Spec Comittee and MicroProfile Spec Comittee. Is this something acceptable?

Yes, this is part of the proposal. Independent specification processes with independent specification committees.

Bullet three in the Background section:

"Both Jakarta EE and MicroProfile will be moved under the governance of CN4J as separate, peer brands. Each would be supported by having their own separate specification processes, specification committees, branding guidelines, and marketing committees - all under the guidance of a shared steering committee, and a common membership."

https://github.com/eclipse/microprofile-sandbox/blob/master/proposals/working-group/cloud-native-for-java-working-group/cloud-native-for-java-working-group-proposal.adoc#background

Ivar

[Emily Jiang]

Thank you Ivar for the info! I read this proposal last week and obviously forgot some key parts:o. I think one important message is that CN4J is just to set up a Working Group structure not combining working groups.

I reread the proposals again and leans towards CN4J. For me, CN4J makes a lot of senses for Microprofile community. I summarised some key points as follows.

For CN4J,

1. MicroProfile and Jakarta EE are peers and they are separate. I don't see any negative influence being imposed at all. The worry of Jakarta EE being new and potential slowing down MP is not true because they are separate entities.

2. MicroProfile can set up committees as they were on their own. I don't see any difference between the MP Committees under CN4J or having their own one under MPSP. Please comment if you think differently.

3. Share the same budget and no extra fees. At the moment, Eclipse Foundation promotes both MicroProfile and Jakarta EE. Sometimes conference attendees confused with the relatipshios between them. With CN4J, a better consolidated plan for future conferences or sponsorship can be set up.

I have not figured out what other advantages MPSP can bring except more process work and more funding. Again, please comment.

IIUC, I will join Steve to vote for CN4J.

Thanks

Emily

[Scott Stark]

With a shared working group charter, steering group, and pmc, it is not clear that one can create sufficiently independent specification processes and committees. The MPWG charter touches on topics such as relaxed TCK compatibility claims requirements, more freedom with the compatibility and project logo, lower cost to entry for MP only implementors, and relaxed voting rules. None of this is supported by the shared working group proposal. 

In addition, there is no ability to collapse the steering committees and specification committees into a single group with the shared working group.

[Scott Stark]

This increases the cost for implementations that are only interested in MP. I disagree that the shared proposal does not introduce risk to slowing down MP. The MP committees and associated rules would not have complete autonomy, and it is not clear the spec committees and process could be made as close as possible to the current MP process because of shared steering committee and pmc. The confusion around EE and MP does not magically disappear with a shared working group. That relationship needs to be defined and a technology exchange defined regardless of whether there is one or two working groups.

[Scott Stark]

Red Hat views the double work as necessary and essential due to the fact that the purposes are different. There is duplication of specification committees and projects is required regardless of which working group proposal is chosen. There are many more implementations of parts of MP then there are EE implementations, so we don't agree that to a large extent the same organizations are involved. We have different customers using MP and EE in different ways and with different support requirements and expectations. The only way we see EE clarifying the relationship between MP and EE is to define an evolution path to bring MP specifications into EE profiles by promoting them to EE specification projects with a focus on the compatibility and stability requirements that EE customers have come to expect.

[Emily Jiang]

In addition, there is no ability to collapse the steering committees and specification committees into a single group with the shared working group.

From my understanding, two sub groups are kind of indenpendent. There is one shared steering committtee. Obviously we will need to add more seats for MP. As for other spec committees, I don't think it makes sense to merge though.

With a shared working group charter, steering group, and pmc, it is not clear that one can create sufficiently independent specification processes and committees. The MPWG charter touches on topics such as relaxed TCK compatibility claims requirements, more freedom with the compatibility and project logo, lower cost to entry for MP only implementors, and relaxed voting rules. None of this is supported by the shared working group proposal.

Maybe a further clarification on what power steering committee hold should be documented.

Thanks

Emily

[Steve Millidge]

Scott,

I don't see in the MPWG proposal where is states the things you mention below;

Where does it say;

• relaxed TCK compatibility claim requirements
• more freedom to use project logo
• lower cost to entry
• relaxed voting rules
  

Steve

[Steve Millidge]

What increases the cost? There has no budget been proposed for the proposed MP working group and there is no reason to assume the fees would be less. If you implement both then the cost MAY be higher as you will have two sets of dues to pay. Essentially we have no idea on cost based on the two proposals. 

[John Clingan]

On Monday, December 16, 2019 at 2:13:01 PM UTC-8, Kevin Sutter wrote:

Just a couple of minor clarifications...

On Monday, December 16, 2019 at 12:00:12 PM UTC-6, Scott Stark wrote:

On Monday, December 16, 2019 at 9:54:05 AM UTC-6, Emily Jiang wrote:

I was in the middle of producing a cons/pros, but Scott raced ahead of me. In doing this exercise, I have the following questions:

MPWG - MicroProfile Working Group

CNWG- Cloud Native Working Group

1. In MPWG, can Jakarta EE specs adopt MP Specs?

This would have to be a change in the Jakarta working group and spec process. It would not be a given if there was a single working group under CN4J either. Regardless of whether there are two or one working groups, a topic for discussion in Jakarta is how Jakarta consumes MP specs. Up to this point it has been an unavailable discussion due to the IP mismatch.

Just to be clear.  As it stands today with our current MP processes, Jakarta EE can not reference or embed any of the MP specifications.  A minimum requirement to allow this to happen is for MP to adopt a derivative of the EFSP.  And, a requirement of the EFSP is to be part of a Working Group.  So, once MP becomes part of a Working Group via any of the proposals, then that opens the door for the next level of discussions between Jakarta EE and MicroProfile.

Basically, both working group proposals close the IP gap, although as Kevin states it is up to the Jakarta EE as to  how it wants to consume the MicroProfile specifications.

 

2. In MPWG, judging by "Adhere to the MicroProfile Specification Process, which is based on the Eclipse Foundation Specification Process", am I right to assume the MPWG might be very similar to Jakarta WG except the WG voting.

The MPSP that a few have been sketching out differs from the EFSP/JESP by flattening the structural hierarchy, having a single specification project, reducing requirements around TCK compatibility claims and logo usage, and trying to simplify voting with lazy consensus votes where possible. Hopefully we can push out the draft changes for consideration soon.

The single specification project is not unique to the MPWG proposal.  This could also apply to the CN4J WG proposal.  The other differences listed are valid.

The MPWG proposal tries to maintain, as much as is possible, the current way MicroProfile operates.

 

 

3. In CNWG, can Jakarta EE specs adopt MP Specs while MP Specs don't need to make any namespace changes?

Really the same as 1.

To be clear, however, MicroProfile will likely need to adopt the new Jakarta EE namespace for the Java EE/Jakarta specifications it includes - CDI, JAX-RS, JSON-P, JSON-B, (Common Annotations and Security too).

 

 

4. In CNWG, will the spec committee and steering committee be expanded to add additional seats for MP communities?

That would have to be a discussion in an update to the working group charter relative to the existing Jakarta working group charter. I would think would be some effort to ensuring a balanced makeup, but I'm not sure how that would be achieved since many Jakarta members do have work in MP.

I think there are positives with both WG proposals.  And, regardless of which way is eventually chosen, I hope that we will evaluate the other proposal in detail to possible incorporate some of the ideas.  For example, the idea of lazy consensus voting in the MPWG proposal should be considered for the CN4J WG proposal.  Maybe expanding the voting membership is another idea that should be considered.

 

 

5. In either MPWG or CNWG, no technical changes are required for any of the specifications, e.g. namespace updates etc. Please confirm.

There is nothing required other than the current ongoing update from javax to jarkarta for Jakarta EE 9.

+1, which I covered above.

[Steve Millidge]

On the point of the PMC, that is completely independent of the Working Group discussion. Moving to a PMC where MP can create more projects makes complete sense to me. To run the whole MP initiative under one project at the Eclipse Foundation has always seemed cumbersome to me. Also currently the 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. 

On Tuesday, 17 December 2019 18:57:02 UTC, Scott Stark wrote:

[John Clingan]

On Tuesday, December 17, 2019 at 7:07:07 AM UTC-8, Emily Jiang wrote:

Thank you Ivar for the info! I read this proposal last week and obviously forgot some key parts:o. I think one important message is that CN4J is just to set up a Working Group structure not combining working groups.

I reread the proposals again and leans towards CN4J. For me, CN4J makes a lot of senses for Microprofile community. I summarised some key points as follows.

For CN4J,

1. MicroProfile and Jakarta EE are peers and they are separate. I don't see any negative influence being imposed at all. The worry of Jakarta EE being new and potential slowing down MP is not true because they are separate entities.

They are not entirely separate entities. They would share a common steering committee. This would mean that CN4J working group members that join due to interest in a subset of CN4J projects (currently either MicroProfile or Jakarta EE) would have influence over all projects under CN4J.

 

2. MicroProfile can set up committees as they were on their own. I don't see any difference between the MP Committees under CN4J or having their own one under MPSP. Please comment if you think differently.

3. Share the same budget and no extra fees. At the moment, Eclipse Foundation promotes both MicroProfile and Jakarta EE. Sometimes conference attendees confused with the relationships between them. With CN4J, a better consolidated plan for future conferences or sponsorship can be set up.

The CN4J proposal assumes separate budgets and separate marketing committees. The intent is to allow MicroProfile more independence in how it markets MicroProfile, evangelizes, invests, etc.

I have not figured out what other advantages MPSP can bring except more process work and more funding. Again, please comment.

I know you've commented, but for others, please see the pros/cons discussion in github.

[John Clingan]

Bingo. The MPWG proposal wants to maintain the current approach as much as possible with as much independence and control over its destiny as possible while fulfilling IP obligations. Ditto on alignment.

[David Blevins]

My own perception is that John and Kevin act primarily as individuals and work actively to ensure they are facilitators, not decision makers.  Enablers, not leaders.

Further that we as a community overall do an outstanding job at making sure everyone feels like they truly can participate, even including giving release responsibility to people who are not even committers yet (Edwin) and doing completely community lead marketing efforts like the MicroProfile Whitepaper (Lars).

Where I sit on the concerns spectrum is a little closer to "don't fix what isn't broken."   The legal issue is very broken -- there is no debate.   But beyond that I lean on being very nervous to change too much that we risk breaking what I perceive as working very well.

-- 

David Blevins

http://twitter.com/dblevins
http://www.tomitribe.com

310-633-3852

--
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/a14133f2-cb54-4909-aa9f-ded27b1fe6e1%40googlegroups.com.

[Emily Jiang]

Well, I don't see how MPSP tries to maintain the current approach or why CN4J cannot stay as similar as to the current approach as far as the spec committee is concerned. The proposal on MPSP also comes with different committees. I don't see how it is lightweight and how to stay with the current approach. I think it might make more sense to spell out how the committees operate under MPSP.

My 2 cents.

Emily

[Mark Little]

Agreed. To date I believe John and Kevin have worked together well to achieve something which puts the community first and any specific vendor second.

I want to take this opportunity to give my perspective. I've been consistent from the start in that MP has evolved quickly and innovated well without a detailed specification process in place. It has built upon good open source principles from the outset. Yes we have some IP issues to address and yes the WG approach is the only way to do this within the Eclipse Foundation. Therefore, we have to adopt a WG. However, I agree with David that the old engineering adage of "if it ain't broke don't fix it" should be foremost in our minds here be because I don't want MP and the community to take a step or two backwards. It's that time for another quote, this time Einstein "make it as simple as possible but no simpler."

I've also stated several times that I put correctness above money here. What I mean by that is that if it is better to have to working groups instead of one then that's my preference even if it means Red Hat pays two sets of dues. I also have a concern about moving MP into JEE under a single WG before the latter has found it's feet. We have one release out of the door and the next one for Jakarta is likely to be later in 2020; anyone who believes that will be easy or require no further changes to process as we learn more about what we are doing is living in their own reality. And that entire learning experience could delay the release, could require more chances, and could have an impact on MP which is itself going to have to go through some changes when adopting the WG concept. Even if we agreed to have a single WG I'd argue for that to be delayed initially for the above reasons.

As Scott said, before we think about merging MP with JEE somehow, whether in WG or elsewhere, we have to clearly defined their relationship. That isn't going to be defined magically by either proposal and so far both communities have managed to sidestep that debate, or at least coming to a conclusion. Now is the time to do it.

One final point: anyone who believes that putting MP and Jakarta together will somehow break down barriers and make it easier to collaborate is being silly, to say the least. Barriers are not erected by foundations or working groups. Look at how well Apache CXF works with other efforts not in the ASF. Look at how well Eclipse Vert.x works with Quarkus, which isn't in a foundation. Barriers are erected by individuals and communities. And that's who has to break them down too.

Mark.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/5B94C5EE-8C89-43A2-89F8-23E8AFD5E43B%40tomitribe.com.

[Steve Millidge]

I understand your points Mark but this is not about moving MP under Jakarta EE it is about whether to have 2 WG organisations at the Eclipse Foundation or one. The only real pro I have seen for having 2 working groups is to maintain the current autonomy of the MP project however I do not see that as something inherent in the proposal of having two separate working groups.

Surely we can have a single broader Cloud Native Java Working Group that encompasses diverse projects and initiatives focussed on server side Java that doesn't create a whole duplication of bureaucracy. 

Imagine in the future a new organisation, unfamiliar with the history and politics of the 2WGs decision, comes along to the EF and wants to create a new "Distributed Compute Fabric" or whatever standard at the Eclipse Foundation. With two working groups which one does it choose? Is the initiative "microservice based architectures" focussed or is it  "server-side and cloud-native applications" focussed? The charter distinction between the two is arbitrary to an outsider. I'm sure the argument will be choose which one you like the spec process/governance of but to somebody who knows nothing I bet the differences from the EFSP and in governance will be subtle and non-obvious. 2WG IMHO is the wrong solution for effective governance of the technologies over the next 2-5 years.

Finally I think working groups at the EF should have distinct non-overlapping purposes to bring clarity to the market. A microservices WG and a server side java WG in my view do not have the necessary level of distinction. That's why as a founding an active member of MP I support the single WG proposal. 

Steve

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

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/a14133f2-cb54-4909-aa9f-ded27b1fe6e1%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 microprofile+unsubscribe@googlegroups.com.

[Mark Little]

Steve, it doesn't matter whether it's MP moving to the JEE WG or both moving to a new WG structure, I believe my points still hold true. And particularly the one about defining the relationship we want to exist between MP and Jakarta - without that it really seems like putting the proverbial cart before the horse to worry about WG structures.

Mark.

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/a14133f2-cb54-4909-aa9f-ded27b1fe6e1%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 microprofile...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/5B94C5EE-8C89-43A2-89F8-23E8AFD5E43B%40tomitribe.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 microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/de166045-a469-48d8-8c23-553c0e959a34%40googlegroups.com.

[Steve Millidge]

So now I am confused. If it is cart before horse why have we been asked to review the proposals?

[Scott Stark]

I'm assuming that the current CN4J working groups fees are inherited from the current Jakarta working group fee structure. I have included a candidate cost proposal in the current PR:

https://github.com/eclipse/microprofile-sandbox/pull/74

[Mark Little]

We need to define a WG to fix the IP issue which you know about. We've dodged resolving the relationship and now we need to do that. I'm saying we should do that before finalizing the WG issue but it doesn't have to be months before!

On Wed, Dec 18, 2019, 13:47 Steve Millidge <l33t...@gmail.com> wrote:

So now I am confused. If it is cart before horse why have we been asked to review the proposals?

--
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/f949211b-5fa6-4979-a11a-94446b420d14%40googlegroups.com.

[Mark Little]

Let me be more explicit in case it's still confusing: I believe Kevin and John have suggested making a decision on WG by end of February. That's over two months from now and should be plenty of time to resolve the relationship and WG if people are motivated.

Mark.

[Scott Stark]

I'm going to address several comments that have come up in this thread. 

First, the reason for introducing the discussion of working groups is that this is the current mechanism available to specification projects run at Eclipse to manage the IP gap between open source development licenses and the wider scope of IP commitments required by specifications to allow downstream usage of the IP for ANY implementation. A working group has a participation agreement that expands the commitment of IP to include the essential patents necessary for any implementation of the specifications produced by the working group.

MicroProfile has operated without such an IP capture. The most straight line solution to this is to introduce a MicroProfile working group and minimizes the disruption to the current development model in use.

It has been brought up that an umbrella type of working group that addresses all server side Java concerns would be a better manifestation that MicroProfile could join to close the IP gap. Hence, we have two proposal outlines, neither of which goes into sufficient detail to address the questions that are being raised.

The point of introducing incomplete working group proposals was to see where the community was aligning. I would say this has lead to good discussion, but it is clear that the proposals are not adequate for preparing a vote one direction or the other.

What I am gathering from the discussion is that there is a desire for an environment where server side Java specifications have a venue for aligning commonalities. What is also clear is that a given specification subject area be allowed to define the details of how participants make use of TCKs, logos, participation voting rights and fee structures.

So, we could step back try to define a new cloud native Java working group that accomplishes these goals. The problems I see with this are:

1. This will take time and possibly incur legal fees that are not bound to any exisitng working group budget.

2. It is unclear how the goals of specification subprojects autonomy and a single participation agreement can be aligned. The complexity of managing shared budget allocation, voting rules at the shared committee levels, and even the restriction of IP commitments seem at odds here.

If someone wants to expand the CN4J proposal to take a stab at these issue, I am happy to give my feedback.

[Kevin Sutter]

Scott,

PR #74 is getting real cumbersome...  And, due to the many open issues and questions related to that PR, how about if you create a separate PR for the proposed cost structure?  It would be easier to accept and process that.  Did you want to keep it as a separate .adoc or merge it with the current MPWG proposal?  Either way works, but if you keep it separate, then maybe we need a link from the MPWG doc to this proposed cost structure?

Thanks!

Kevin

[Scott Stark]

The fee proposal has been moved to this PR:

https://github.com/eclipse/microprofile-sandbox/pull/76

[Kevin Sutter]

Merged (but post-merge, I found a couple of minor items that should be cleaned up -- communicated via the PR #76 comments).  thanks!

[Amelia Eiras]

Kevin and all, 

Below is the copy/paste msg from PR #74

@kwsutter thanks for merging this PR yet I don't see it in the https://github.com/eclipse/microprofile-sandbox/tree/master/proposals/working-group

I recommend that the comparison (s) be added directly on that main document.
Further, MP media pushes 2 reminders for week until the end of Feb to that main doc... using that, please lets keep the this and future PRs within the main doc as they are easy to find and consume. :) Thanks for the follow up clarification.

[Bill Shannon]

We've been following this conversation and reviewing these proposals within Oracle and we definitely agree with the points Steve is making.  I'll post a more complete response to these proposals shortly.

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/a14133f2-cb54-4909-aa9f-ded27b1fe6e1%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.

[Bill Shannon]

Oracle prefers the Cloud Native for Java Working Group proposal.
Let me explain why I think this is the best choice for the
community and for our users and customers.  These reasons
reflect my own experience with Java EE and Jakarta EE, my
experience with other standardization efforts, and input
from my colleagues at Oracle.

My impression is that the MicroProfile project at Eclipse was
partially a reaction to Oracle's failure to move Java EE forward
in a timely manner, and the limitations of the JCP to allow others
to fully participate in the leadership of Java EE.  Oracle recognized
many of these issues and agreed that, while the Java EE standard
was a benefit to us all, a new approach would help us more fully
realize that benefit.

After discussion with Java EE licensees and users, Oracle agreed
that the best way to resolve these issues was to move Java EE
development to the Eclipse Foundation and take advantage of the
lessons learned while doing MicroProfile development at Eclipse.
The MicroProfile project has shown that an enterprise Java standard
can be developed in an open source environment in a timely manner
using a vendor neutral process driven by collaboration between both
vendors and users.  All of these are attributes that everyone wants
for the Java EE standard, and moving to Eclipse while abandoning
all of the JCP rules was the best way to achieve this.  This allowed
us to "start over" and create EE4J and Jakarta EE as just what we
wanted, with as few constraints as possible.  The Cloud Native for
Java Working Group proposal further recognizes that Jakarta EE has
successfully addressed many of the issues that caused the separation
between Java EE and MicroProfile.  In fact, the Jakarta EE and
MicroProfile efforts now have more common attributes than differences.


Let's look at the key attributes that are claimed as distinguishing
features of the MicroProfile project and ask ourselves whether we want
these features to apply to the Jakarta EE project as well...

- Shipping works-in-progress to gather live user feedback

    Yes, we're definitely doing that in Jakarta EE and want to
    continue doing that.  The Jakarta EE 9 release plan proposes
    having a "release candidate" release of Jakarta EE 9 for exactly
    this purpose.  Meanwhile, some projects are already updating
    their APIs and implementations and getting experience with
    these changes.  There are no impediments to shipping work
    in progress and gathering feedback to guide future development.

- De-emphasizing backwards compatibility

    Jakarta EE 9 introduces a huge backwards incompatibility by
    moving all the classes out of the javax namespace and into
    the jakarta namespace.  All existing vendors are likely to
    include some level of backwards compatibility support in
    their products, but by not including this as a requirement
    we reduce the cost for new vendors to enter the market.  This
    was easily agreed to by all participants.

    As products mature and the needs of customers change, there
    will be pressure to allow APIs to evolve in ways that break
    backwards compatibility.  Even the core Java SE platform
    has defined a process to mark items as deprecated and remove
    them from the platform.  Given the rate of change in the
    industry, we're clearly going to need the ability to do
    likewise for Jakarta EE, thus breaking backwards compatibility
    but in a way that will not surprise customers.

    Similarly, the core Java SE platform has recognized the need
    to introduce new features that are "not quite done yet".
    Jakarta EE will also need a way to introduce "incubating"
    APIs for which there are no backwards compatibility promises.

- Keeping processes deliberately light, avoiding overhead and more

    We're constantly looking for ways to reduce overhead in the
    processes we're introducing for Jakarta EE.  Many of the
    MicroProfile community members have been involved in the
    design of the Jakarta EE processes, helping to ensure that
    the processes contain only what we need and no more.  And
    as we learn by using these processes we will continue to
    update them.  Unlike the JCP, there are no significant
    barriers to updating our processes.

- Low or zero bar to enter the community in perception and process

    Just moving to the Eclipse Foundation has significantly reduced
    the actual and perceived barrier to participate in our projects,
    and the results for Jakarta EE 8 and 9 show that we've been
    successful.  Downloads require no sign-in, projects use well
    understood and widely used open source licenses, mailing
    lists are open to all, anyone can file an issue.  Contributions
    are subject to the same rules as all Eclipse projects,
    requiring only a minimal check to ensure intellectual property
    rights are maintained.

- Bottom up community decision making

    Decisions for Jakarta EE are made by the community, acting
    within and through the various projects and committees
    that the community has established.  In some cases the
    community has decided that there needs to be a common set
    of values, techniques, etc. across all our projects, in
    order to provide a better result for our customers.  And
    still we've tried to retain as much flexibility as possible
    so that individual members of the community and individual
    projects within the community have the freedom to deliver
    innovative solutions as demanded by our customers and market
    needs.


It's very clear that the attributes that are important for the
MicroProfile projects are also attributes that are important for
Jakarta EE.  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.  Combining these projects will reduce overhead
and barriers to entry for community members to participate in and
across these projects, and will increase collaboration.   Conversely,
keeping these projects separate will increase overhead and raise
the barrier to entry for community participation, even though the
key drivers for separation in the past are no longer relevant.
Enabling collaboration across the work of all of these projects
will inevitably result in better software, and a better technical
result for our users and customers.  That's what we should focus
on - better collaboration, better software, and better for our users
and customers.   That's why I favor the Cloud Native for Java Working
Group Proposal.

[Edwin Derks]

Hi all,

I have learned a lot about how things work internally at Eclipse from the topic at hand. As a relative newcomer to this community, it provides a lot of insights in what's important for the people and organisations involved. I would like to share my thoughts from a contributor and end-user perspective, since I'm not involved in Jakarta EE and MicroProfile as an organisation (or even a committer), although I hope that I'm not flying in sideways in the awesome discussion that has been going on.

1. End users of Jakarta EE and MicroProfile use either of both projects for building enterprise software. Me as a contributor that actively follows the evolution of these projects, knows why these projects are separated and why they can't "just merge". This continuous to time and again cost me effort to explain this situation to developers that aren't involved. Don't get me wrong, I do it with love and pleasure. The point that I want to make is: if we have a 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. From this perspective, I like the idea of the CN4J WG initiative.

2. I'm currently involved in both Jakarta EE and MicroProfile as an individual contributor, having joined two separate communities tat have their own way of working. I appreciate the voice I can have, and trust that is put in me to support or drive MP releases in the near future, and see where this goes. What's important here, is that a lot of people I have contact with, are involved in both Jakarta EE and MicroProfile. This results in a lot being discussed that regards both projects, especially since they complement each other. Therefore, I feel that a single WG governing the direction of both projects could lead to the projects better aligned on all areas, in order to decrease overhead and provide a more clear and transparent platform for the end users. So again, I feel the CN4J WG could be beneficial here in my opinion.

Please share your thoughts if necessary.

Kind regards,

Edwin Derks

--

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/7c4997af-5f82-42c5-a854-dc0e77b9b288%40googlegroups.com.

[Emily Jiang]

Thank you Edwin for sharing your insightful thoughts from the end user point of view! Very much apprecated! I also encourage others to speak up. MicroProfile is a truely open community. All of the views shoud be taken into consideration.

Emily

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

[Kevin Sutter]

Very nice write-up, Edwin!  Thanks for the insights.  Hearing from more end-users and/or customers would be excellent!

-- Kevin

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

[Scott Stark]

So from this I take additional simplifications to the current Jakarta EE process are desired. Let me point out the current issues in the Jakarta EE process I see as unworkable as a baseline for MicroProfile specifications. 

1. The WG membership fee structure is simply too high. Someone should be able to participate in a few specifications in a CN4J effort without a large cost. The value of paying for top tier sponsorship needs to be unrelated to

open source specification development. OASIS has put forth a sponsorship model that presents a much lower bar to bootstrapping a specification development effort. There has to be a layered model that goes from $0 to X.

If vendors don't see value in X that is a problem with the specification effort itself.

2. 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. Again,

paying for some higher tier compatibility claim needs to be a value add that vendors see the value of.

3. The role of a steering committee in the context of an arbitrarily wide topic like cloud native Java can only be one of an advisor. It should not have any ability to veto subproject specification votes. If there is any voting

rights at this level, a makeup that ensures fair representation amongst subprojects becomes a logistic problem.

Another general issue with shared committees and associated funds is how to allocate votes and money to appropriately represent the subprojects. As more subprojects are added, this becomes increasingly difficult.

Let me point out that all of this is outside of the scope of addressing the original reason why a working group was needed for MP. If there is a problem with MP continuing to

operate without dealing with the specification IP gap, a standalone working group solves that problem while a CN4J effort is explored. Another is to simply introduce or reuse the consent agreement like the one Paul Buck

mentioned on the steering committee list and introduce a formal MPSP process, something that is required regardless.

[Steve Millidge]

Hi Scott,

On point 1 the Jakarta EE WG membership fees for Participant member level are roughly similar to the ones you proposed for the MP WG and cheaper at the lower level with a $0 for < 10 employees. Why do you see these as too high?

Steve

[Steve Millidge]

On point 2 I think the participant member fees are fair to gain logo usage. We have to remember that the Eclipse Foundation is a not for profit organisation without a huge budget. Given the logo is a trademark of the EF I don't think it is unreasonable to expect commercial organisations, that wish to ship product, with a compatibility logo to join at the Participant member level, license the logo and pay a fee to support the foundation and its efforts. Currently in the Jakarta EE WG the fees are tiered based on organisation size and start at $0 for small organisations. 

Payara is a small startup company and we are not requesting $0 fees.

Steve

On Friday, 20 December 2019 15:38:38 UTC, Scott Stark wrote:

[Scott Stark]

It has to do with the how the various fee levels define the participants ability to participate in committees. The base level in the MP proposal would at least equivalent to the Enterprise level in the EE WG scheme. So if the Participant member level did have the ability to participate in all committees, that would be a fine base fee structure.

[Scott Stark]

And I will challenge what the break even cost to run a specification is. For example, there are no CI runs that run massive TCKs under MP, and the project repos are hosted on GitHub. Without a supported CI this would be managed like every other open source project and CIs would be hosted elsewhere using community support.

It is a secondary consideration to increase fees to support efforts like marketing and dedicated community members. That should not infect the baseline for a community that wants the minimal uplift from open source to open source based standards.

[Steve Millidge]

Participant members can be elected to the committees in the same way as Enterprise members. If it is the number of seats allocated, currently 1 for Participant and 2 for Enterprise, then I'm sure the seat allocations could be tweaked. 

[Steve Millidge]

So an employee of a $3B+ revenue for profit organisation is suggesting that a $6M revenue not for profit organisation is charging too much to run the process and infrastructure ;-).

There's some irony their somewhere :-)

[Scott Stark]

Yes, and I think we know what we are talking about.

The base open source specification process needs to be viewed as an extension of open source development. It has become the De Facto development model because the cost to entry is the developer cost to do so. Anything more is an impediment to adoption. If we are designing a specification process that does not allow a specification community to be built for nothing more than the community horsepower, we are designing a process that will be replaced by one that does.

[Ian Robinson]

First of all, I think its been really helpful that Kevin, John, David, and Scott created the proposal for a separate MicroProfile WG so we could have that as a concrete option to consider. I know it took a great deal of effort to define a WG proposal that could work for the MicroProfile Community and still adhere to the general guidelines and principles of an Eclipse Working Group.

But, after reviewing both proposals, I much prefer the single CN4J WG proposal and for several reasons.

First, it's been well-stated that MicroProfile has to become a member of some Working Group in order to close the gap on the IP requirements for Specification development.  We already have an established "Enterprise Java" Working Group called Jakarta EE.  Renaming this existing Working Group to something like the proposed "Cloud Native for Java" Working Group and then establishing the two communities (Jakarta EE and MicroProfile) as peers would be the easiest path forward.  We could then devote our time and resources on establishing an appropriate derivative of the EFSP specific to MicroProfile -- instead of defining a new Working Group, defining a Charter, establishing new fees, determining membership levels, etc.  We already have that in place for the Jakarta EE Working Group, let's just reuse what we already have.

Second, and this feeds off the first item...  The Jakarta EE Working Group (or CN4J WG) is defined for Enterprise Edition (EE).  The mission statement for MicroProfile states "Optimizing Enterprise Java for a Microservices Architecture".  A combined Working Group seems like the natural choice to further enhance both brands. Others have already made this point and it seems crazy to me that we'd want new contributors to have to think about which WG to join or join both. Better to have one WG with a single vision but discrete EFSP derivations and committees to accommodate the needs of the two (significantly overlapping) communities.

Finally, as a follow-up to one of Scott's recent posts...  Some of the ideas outlined in the separate MP WG proposal have merit and should be considered as input for the CN4J WG proposal (for example, the use of respective logos, voting rights, etc).  So, even if we do decide to go with the CN4J WG proposal, there should be some tweaks based on the input from the separate MP WG discussions. 

-- Ian

[Mark Little]

I'm on vacation and trying to stay away from this but need to jump in ...

In case it's not obvious I agree with Scott. In order for me to support a single WG at this stage I'd need to see:

- a clear definition of the relationship between MP and JEE. I know I'll sound like a broken record but until someone points me at something both communities agree with I'm going to keep pushing it.

- the tweaks to a single WG definition that address the concerns Scott, John, Kevin, David and others have raised.

Mark.

Sent from my iPhone

--
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/f2b7c4cb-0257-4340-b9c7-66a31b9fba9b%40googlegroups.com.

[Steve Millidge]

Scott,

You seem to be arguing for a zero cost entry fee for commercial organisations to protect the participation of the little guy. However I am the little guy and I am arguing for scaled fees. This may seem paradoxical but let me tell you how I see it as the little guy paying fees which are a much greater % of our turnover than yours and therefore relatively more painful.

This single biggest cost for any organisation in tech is people. When you use the word "community horsepower" I think you mean a bunch of committers who predominantly are paid to work on Microprofile by their respective organisations. If as you suggest we don't pay Eclipse Foundation, through fees, to host and manage our processes and CI infrastructure then this work still needs doing and so this will fall to "community horsepower". 

This has two effects;

1) We either have to go out and find a bunch of independent volunteers to pick up the work  that EF would do, which isn't fair on these people.

2) We all as WG members have to pick up the slack and add more people to carry out these tasks.

The burden of (2) falls more heavily on the little guy than the multi-billion pound turnover organisation to whom the "developer cost" of a few more people is negligible in the scale of things. So let's say the little company can't add 2,3,4 more full time workers onto the project as they can't afford the "developer cost" but the Multi-billion pound organisations can. As all these people are "the community" without the rules and processes the EF fees create then the small guy's voice is in danger of being drowned out. The "community" of committers essentially becomes a couple of companies as they employ the majority. These companies can then just drive what they want, as they run the infrastructure and all work for the same 1 or 2 companies.

In my view paying fees to support the EF working group staff to manage the processes and infrastructure brings neutrality to the picture which is exactly the purpose of the EF and the WG.

Absolutely we need zero cost entrypoints for individuals and non-commercial entities to participate but the WG needs adequate funding.

Now you could argue, why should the big corporate subsidise the participation of the little guy through large scaled fees to the EF and this is absolutely a valid argument but it is not the protect the little guy participation argument you are using. You'd have to look at whether you want an independent standard to answer that question.

I hope you can see why I like scaled fees and I am happy to pay them as one of the small organisations in the EF and in MP.

Steve

[Amelia Eiras]

MPWG doesn't propose a $0USD budget, it proposes that whatever the budget, it is fully managed by its working group. 

Currently, there are 4 PRs under the sandbox dealing with this conversation, let's bring attention that under the MPWG any budget will provide 100% transparency. That budget won't be used to grow EF employment as it has done in the Jakarta project. 

MPWG proposal aims at continuing to enable the MP Contributors own & be responsible for how  time = value is spent in the project.  

The proposal enables each contributor to choose to earn and protect via actions the project itself. 

MP has no "managers", it has facilitators -- each one of us who show up and via actions push the project forward, those of us who make "new" interested individuals stand beside us and not behind us. Everyone matters. 

 

https://github.com/eclipse/microprofile-sandbox/pulls [open PRs] 

In my mind, anything that chooses to lack budget transparency to a thriving community in OSS, e.g. percentages budget distribution, is leading itself and those involved to a TOTAL lack of ownership to the Ecosystem that its meant to protect. Further, it is quickly choosing to drop adjusting and taking proactively valuable feedback. 

Where there is much to protect, especially employees who are hired to work in OSS & are meant to enhance an ecosystem, what goes first: the employer who hires that person vs. the ecosystem and the reason that job was created first. 

The "perfecting excuses" and protecting what doesn't work but yet is allowed to exists is made by humans neutral positionings. 

MicroProfile has proven its capacity to sustain diverse strengths in its community.  Anything that will make those strengths be lesser or take away the work currently successfully being accomplished by this community is anything but a  weak-mode and must be called as such by anyone who is watching this conversation. 

If you, me, us are not asking those questions, then START NOW! 

Ask:

WHY> then 

What>then

How

Let's tackle the proposals via PR and  hopefully create new ones as we discover a road forward! 

Happy wknd everyone, 

Amelia Eiras 

twitter.com/ameliaeiras

Tribe: http://tomitribe.com      https://tribestream.io   

OSS:  http://microprofile.io     https://jakarta.ee

--
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/zwFhZec8MGA/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/84384a18-5014-4b84-8b02-0475a34d7d63%40googlegroups.com.

[Scott Stark]

I'm arguing a zero cost because that is what MP runs with today. I don't see how introduction of the WG introduces any new cost over how MP is run today, and in general, upgrading any open source development project to an open source specifications project. All the WG adds is a higher level agreement between IP stakeholders to expand the scope of IP commitments.

There is no need for EF personal to be allocated to a specification process. In general they contribute no developers and no IP, so why should that be a staple of every WG? Jakarta is a special case that decided a shared marketing group and EF representatives were needed. However, Jakarta should not be viewed a the canonical specification WG.

[Amelia Eiras]

First, a very healthy 2020 to the + 1180 individuals in this forum! :) 

+1 Scott on specially this: 

• Jakarta should not be viewed a the canonical specification WG.   The Jakarta Project must not be viewed as the core "how to"  on needed processes for other projects under the EF.

NOW, about budget-- it would be nice for the future MP WG to have a small budget that fluctuates without much hustle & that is fair across dedicated for MPswag.  SWAG git skeleton issue  is already in place and ready to be tackled when time permits.

Currently, each active partner distributes MPswag,  covering JUGs, speakers & the many wonderful independent MicroProfilers who are DOERS. 

A lighter betterment on MPswag ought to be considered in 2020 to make that process scalable, smoother & across all continents. Aiming at lowering shipping costs,  expectations on how to ask & how etc ought to make easier.  I have heard plenty of time individual Microprofilers, who want to sponsor a few MPSwag for JUGs, speakers, events yet it is not as light of a process yet. :) 

I believe in good ideas that lower debt and make things better and scalable. Such a mentality is found in MP, our responsible actions mark each responsible doer. 

MicroProfile is not about Vendors owning the sole weight in time or budget but about each MicroProfiler being able to do so.

It has works beautifully for the past 3 years, fixing IP wouldn't interfere with what works today yet while we are working on it, setting up a small MPswag to execute & welcome sponsorships without pressure ought to be considered. 

 

Cheers, 

Amelia Eiras 

twitter.com/ameliaeiras

Tribe: http://tomitribe.com      https://tribestream.io   

OSS:  http://microprofile.io     https://jakarta.ee

--
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/zwFhZec8MGA/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/9cb6fc64-f9e5-48e4-96f8-2f5ed1486bba%40googlegroups.com.

[John Clingan]

+1 to Scott’s point that the primary reason MicroProfile needs a working group is to close the IP gap, not to manage MicroProfile marketing. Had IP not been an issue, we wouldn’t be talking about marketing $ at all (nor a WG). We’d be operating as successfully as we have been over the last 3+ years. In fact, a marketing committee is not required for a WG, so we could potentially continue operating marketing outside the WG as we currently do. I’m not necessarily advocating that because I grok it makes it difficult for some vendors, but it does make the point.

Personally, I'd like to keep operating as closely to the way MicroProfile has been operating because, IMHO, it has been extremely successful.

--

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.

[Amelia Eiras]

HUGE +1 John! :) 

Amelia Eiras 

twitter.com/ameliaeiras

Tribe: http://tomitribe.com      https://tribestream.io   

OSS:  http://microprofile.io     https://jakarta.ee

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/zwFhZec8MGA/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/09DCCECF-721D-4EE1-A7FF-2D63F55E4D69%40redhat.com.

[Ken Finnigan]

After thinking on this before and after the holiday break, several different concerns are converging into this decision when they don't need to.

While I agree that long term MicroProfile and Jakarta need to work out how they can work together, that's not the immediate issue that a Working Group for MicroProfile needs to address.

The immediate need is for MicroProfile to resolve it's IP gap, only then can meaningful discussion be held on how MicroProfile and Jakarta can work together.

To that end, in an effort to resolve the IP gap quickly and move forward, my preference is for a MicroProfile WG that is as "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. Even better would be for such a discussion to occur once each working group has been operating long enough to have a better idea about what processes work and what needs to change, otherwise we're prematurely optimizing for a single WG without either group knowing what works and what doesn't.

Ken

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAJ0g8j5OSjmJoG-t31t-LAE_hj9-fuXXxHQ-tPsxtfbMFmXEjA%40mail.gmail.com.

[Amelia Eiras]

You have my +1 Ken! :) 

Amelia Eiras 

twitter.com/ameliaeiras

Tribe: http://tomitribe.com      https://tribestream.io   

OSS:  http://microprofile.io     https://jakarta.ee

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe5bDwxV3CxV8e%3DP4evigvj_T4A_rFDwOncwMMPAvYQ4%2BQ%40mail.gmail.com.

[Emily Jiang]

I'm arguing a zero cost because that is what MP runs with today. I don't see how introduction of the WG introduces any new cost over how MP is run today, and in general, upgrading any open source development project to an open source specifications project. All the WG adds is a higher level agreement between IP stakeholders to expand the scope of IP commitments.

There is no need for EF personal to be allocated to a specification process. In general they contribute no developers and no IP, so why should that be a staple of every WG? Jakarta is a special case that decided a shared marketing group and EF representatives were needed. However, Jakarta should not be viewed a the canonical specification WG.

It is better to bring these questions to Eclipse Foundation. IIRC, any WG under Eclipse will have associated $.

 

I think one thing is clear: there should be a WG due to IP issues.

Setting up a WG is not trivial. Since MicroProfile and Jarkarta are complimentry to each other. I think operating them under one roof is reasonable. I know there are concerns that Jakarta process might potentially influcence or impact MP process. Can't we ensure in CN4J that MP and Jakarta are separate entities and separate process will be maintained?

+1 on Ian's comments! I think it is better to work on CN4J to address the concerns instead of starting from scratch with unnecessary $ waste. Besides, some community members (see Edwin's notes) also favour CN4J.

Thanks

Emily

[John Clingan]

"Can't we ensure in CN4J that MP and Jakarta are separate entities and separate process will be maintained?"

IMHO, no. The CN4J will share a common steering committee, which IMHO will continue to influence the tighter integration  of the two projects over time (meaning MicroProfile moves more towards to Jakarta processes). 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. There will be CN4J steering committee members who have no stake in MicroProfile whatsoever (join for Jakarta EE participation) influencing these decisions. I don't think think this is nefarious in any way, it's just the natural consequence of a single committee. Keeping decisions as close to the project as possible is a good thing, IMHO.

Second, although it is not in the CN4J WG proposal, 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).

IMHO, it gets back to solving the real problem (fixing the MicroProfile IP gap) and maintaining what has driven the success MicroProfile has achieved in such a short period of time.

[Scott Stark]

On Tuesday, January 7, 2020 at 5:13:05 AM UTC-6, Emily Jiang wrote:

I'm arguing a zero cost because that is what MP runs with today. I don't see how introduction of the WG introduces any new cost over how MP is run today, and in general, upgrading any open source development project to an open source specifications project. All the WG adds is a higher level agreement between IP stakeholders to expand the scope of IP commitments.

There is no need for EF personal to be allocated to a specification process. In general they contribute no developers and no IP, so why should that be a staple of every WG? Jakarta is a special case that decided a shared marketing group and EF representatives were needed. However, Jakarta should not be viewed a the canonical specification WG.

It is better to bring these questions to Eclipse Foundation. IIRC, any WG under Eclipse will have associated $.

 

We are the EF as far as defining a WG is concerned. There is nothing in the base working group documents from the EF that I can find that establishes any minimum funding requirement for WGs: 

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

If you browse through the charter of the existing working groups:

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

Many are running under a $0 fee or have a $0 participation fee for some level. 

 

I think one thing is clear: there should be a WG due to IP issues.

Setting up a WG is not trivial. Since MicroProfile and Jarkarta are complimentry to each other. I think operating them under one roof is reasonable. I know there are concerns that Jakarta process might potentially influcence or impact MP process. Can't we ensure in CN4J that MP and Jakarta are separate entities and separate process will be maintained?

+1 on Ian's comments! I think it is better to work on CN4J to address the concerns instead of starting from scratch with unnecessary $ waste. Besides, some community members (see Edwin's notes) also favour CN4J.

Thanks

Emily

I agree that one WG should be explored, but it is far from clear that it can work sufficiently for the individual specification  projects. It will certainly take more time and money to form a new version of a common WG for all current and future cloud native Java then it will to create an MP WG, so I will challenge that there is any upfront cost savings. 

[Mark Little]

We have extremely limited data at the moment upon which to base any decision and I worry that we make a bad decision as a result. It seems to me that if we were to go 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.

Mark.

[Kevin Sutter]

Scott,

>  It will certainly take more time and money to form a new version of a common WG for all current and future cloud native Java then it will to create an MP WG, so I will challenge that there is any upfront cost savings.

Really?  I don't buy this.  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".

-- Kevin

[Kevin Sutter]

Mark,

>  We have extremely limited data at the moment upon which to base any decision...

As I read through all of this thread, I am coming to the same conclusion.  Most of the discussion is based on biased interpretation of the proposals -- made by the people who participated on the proposals.  Steve has been very helpful with posting his opinions and positions from one of the "little guys".  And, Steve was not directly involved in the creation of either proposal.  Edwin has also come forward with his views as a user and consumer of MicroProfile.  Thank you!

It sure would be nice to get more of the MicroProfile community involved in this discussion.

-- Kevin

[Amelia Eiras]

+1 Mark 📌

”It seems to me [Mark] that if we were to go 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. ”
(This worries me greatly today)

”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.”

(This mentality is aligned to smart, short term & long term agility & patience)

Sent from my IPhone

[Reza Rahman]

I would be curious whose feedback on this vendors would really value in this context. I think Edwin, Steve and Bill in particular have articulated the broader community view pretty well. I suspect anyone else that is likely to be inclined to weigh in directly will emphasize long term Jakarta EE and MicroProfile alignment and see the single working group proposal as a very small step towards figuring that lingering issue out. I think many of these people have already sufficiently expressed themselves, here and elsewhere.

Reza Rahman
Jakarta EE Ambassador, Author, Speaker, Blogger

--
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/740bf9ec-bdc0-4659-9db7-9c8de1ff67f1%40googlegroups.com.

[Scott Stark]

It is not as we have no agreement on WG fees, a single steering committee, how membership in committees is made up of participants from the subprojects, trademark and logo usage, etc. 

[Ondro Mihályi]

Hi all.

The following may not represent Payara, it's my own honest opinion as a community member.

Reading between the lines, i feel that the decision about one or 2 WGs is really about something else than the arguments presented here. It's more about who and how will collaborate on JakartaEE and MicroProfile. It seems that for Red Hat it's OK to have 2 working groups and continue contributing to both MicroProfile and JakartaEE easily. Some others may not care about one or the other and would only contribute to one of them and 2 WGs would make it easier. But for Payara, Oracle and I also think Tomitribe, contrary to what Amelia wrote, it's very complicated to contribute to both MP and JEE if even now, so having 2 WGs wouldn't really solve much. A single WG would mean less beraucracy for them, fewer meetings and efficiency. For Oracle it may be the only option to contribute to MP. And those that otherwise would care about only MP or JEE would be tempted to contribute to the other project, increasing its quality and relevance.

I recon that we only want to solve the IP issues right now. It may be a good start to create a separate WG and mwrge them later to solve the other issues I described. But having 2 WGs for a long time will be harmful to both MP and JEE, risking that both projects and their communities split and alienate. So the real decision we need to make is whether it's worth the effort and time to do this in 2 steps. Or it's better to kill 2 birds with one stone and put the extra effort into something more productice.

I agree with the concerns presented by Scott, Amelia and others, and arguments against a single WG. I just think they are not as relevant as keeping the enterprise Java community united and strong together. These concerns may be addressed by amending the existing group and I encourage the we evaluate this before we consider establishing a separate MP WG. I see that the community is already split and the risk of making it worse is just too high.

Ondro

[John Clingan]

On Wednesday, January 8, 2020 at 11:57:14 PM UTC-8, Ondro Mihályi wrote:

Hi all.

The following may not represent Payara, it's my own honest opinion as a community member.

Reading between the lines, i feel that the decision about one or 2 WGs is really about something else than the arguments presented here. It's more about who and how will collaborate on JakartaEE and MicroProfile. It seems that for Red Hat it's OK to have 2 working groups and continue contributing to both MicroProfile and JakartaEE easily. Some others may not care about one or the other and would only contribute to one of them and 2 WGs would make it easier. But for Payara, Oracle and I also think Tomitribe, contrary to what Amelia wrote, it's very complicated to contribute to both MP and JEE if even now, so having 2 WGs wouldn't really solve much. A single WG would mean less beraucracy for them, fewer meetings and efficiency. For Oracle it may be the only option to contribute to MP. And those

It would not result in fewer meetings. Separate marketing and spec committees, and spec team meetings even under a single WG. The steering committee meetings and the MicroProfile Live Hangout would both continue regardless of the WG selection.

 

that otherwise would care about only MP or JEE would be tempted to contribute to the other project, increasing its quality and relevance.

I recon that we only want to solve the IP issues right now. It may be a good start to create a separate WG and mwrge them later to solve the other issues I described. But having 2 WGs for a long time will be harmful to both MP and JEE, risking that both projects and their communities split and alienate. So the real decision we need to make is whether it's worth the effort and time to do this in 2 steps. Or it's

I see it the other way. There is more risk in combing them when MicroProfile has been delivering 3 releases per year and Jakarta EE has yet to deliver a feature release. There is still a lot of unknowns in how Jakarta EE will get into a cadence and deliver. I'm confident it will get resolved, but there is still a lot to be done to get there. I prefer to see what new processes come out of that effort before we consider merging the two projects under a single WG.  The folks that built MicroProfile over the last four years did so to make it lightweight and agile as a project.  I think MicroProfile's approach risks being diluted under a single WG as the desire for "optimizing concerns across the two projects" becomes the norm. IMHO, it's too early. 

 

better to kill 2 birds with one stone and put the extra effort into something more productice.

My fear in combing the two is that MicroProfile will become less productive for reasons already stated. I'm trying to keep both birds alive and flying :-)

 

I agree with the concerns presented by Scott, Amelia and others, and arguments against a single WG. I just think they are not as relevant as keeping the enterprise Java community united and strong together. These concerns may be addressed by amending the existing group and I encourage the we evaluate this before we consider establishing a separate MP WG. I see that the community is already split and the risk of making it worse is just too high.

Under the CN4J WG, on a day-to-day basis, the two will still be as separate as they are today with the exception of the steering committee, which is where I have concerns - I'd like to see how Jakarta operates on feature release delivery before considering a single WG.

 

Ondro

[Mark Little]

I’ve said it before and I’ll say it again: it’s not working groups, foundations or multitudes of separate projects that make the Java community united and strong, it’s the people. Taking your argument to the extreme, should we ask the EF and ASF and Github and others to come together under a single foundation because somehow that’s “better”? I think not.

Mark.

[Reza Rahman]

Well said. Like everything in computing this is all about trade-offs.
Where one falls in the spectrum of trade-offs is far more subjective
than we would like to admit.

My personal belief in these sorts of situations is to trust the wisdom
of the crowd, make a leap of faith and work gradually towards a desired
end goal. I think an outcome that is more likely to result in a strong
and united community for open standards in enterprise Java is a well
worthy end goal. That's what we once had with Java EE and I think if we
really look back it had served most of us pretty well for a very long
time despite latter day leadership hiccups at Oracle and financial
hiccups at Sun.

Reza Rahman
Jakarta EE Ambassador, Author, Speaker, Blogger

[Scott Stark]

On Thursday, January 9, 2020 at 1:57:14 AM UTC-6, Ondro Mihályi wrote:

Hi all.

The following may not represent Payara, it's my own honest opinion as a community member.

Reading between the lines, i feel that the decision about one or 2 WGs is really about something else than the arguments presented here. It's more about who and how will collaborate on JakartaEE and MicroProfile. It seems that for Red Hat it's OK to have 2 working groups and continue contributing to both MicroProfile and JakartaEE easily. Some others may not care about one or the other and would only contribute to one of them and 2 WGs would make it easier. But for Payara, Oracle and I also think Tomitribe, contrary to what Amelia wrote, it's very complicated to contribute to both MP and JEE if even now, so having 2 WGs wouldn't really solve much. A single WG would mean less beraucracy for them, fewer meetings and efficiency. For Oracle it may be the only option to contribute to MP. And those that otherwise would care about only MP or JEE would be tempted to contribute to the other project, increasing its quality and relevance.

The bulk of the work should be at the specification project level, and no structure changes that working on EE and MP requires more effort. As John has said, the only efficiency introduce by a single WG is that there would be one steering committee. 

 

I recon that we only want to solve the IP issues right now. It may be a good start to create a separate WG and mwrge them later to solve the other issues I described. But having 2 WGs for a long time will be harmful to both MP and JEE, risking that both projects and their communities split and alienate. So the real decision we need to make is whether it's worth the effort and time to do this in 2 steps. Or it's better to kill 2 birds with one stone and put the extra effort into something more productice.

First of all, the possibility of a fracture in MP and EE exists regardless of the structure due to the differing points of view on what cloud native means as well as a need to support existing EE customers. The latter being a concern of only existing EE vendors. The effort to resolve any perceived discontinuity in my view has nothing to do with a WG structure. The would need to be a mechanism defined for how MP specs are used by EE. The only thing stopping this conversation from happening now is participation by some due to IP concerns. While a single WG addresses the IP issue, it opens up several issues that no one has addressed. A single WG seems like an O(N^2) solution, if not NP, to the IP issue when an O(N) solution exists in the form of separate WGs.

 

I agree with the concerns presented by Scott, Amelia and others, and arguments against a single WG. I just think they are not as relevant as keeping the enterprise Java community united and strong together. These concerns may be addressed by amending the existing group and I encourage the we evaluate this before we consider establishing a separate MP WG. I see that the community is already split and the risk of making it worse is just too high.

 A proponent of the single WG approach needs to put forward some possible ways to resolve the concerns I and others have raised.

The strongest statement being made for a single working group is a desire to have a view of consistency across cloud native oriented specifications. This could also be addressed by introducing a notion of an umbrella working group the deals with cross cutting concerns among a collection of WGs. The focus of such an umbrella WG could be things that architectural consistency, fee structure for participation in multiple WGs, higher level branding, etc.

If you look at the existing WGs:

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

There are already multiple WGs that touch on cloud native Java including:

Cloud Development Tools (https://www.eclipse.org/org/workinggroups/eclipse_cloud_development_charter.php)

Internet of Things (https://www.eclipse.org/org/workinggroups/iotwg_charter.php)

Tangle EE, just proposed, (https://accounts.eclipse.org/mailing-list/tangle.ee-wg)

[Amelia Eiras]

Hola Ondro :) , it is nice to read from you beautiful MicroProfilers!

I read to understand. I became curious when you mentioned Tomitribe on your follow-up above.  Where in this thread or in any other instance has I or Tomitribe stated agreement to combining MP with Jkta?  

Thank you for a follow up that enables clearing the erroneous assumption you have mentioned above wonderful Ondro.  

Today, the main reason this thread and Proposals for a WG for MP conversation exists is to fix the MP IP gaps. The focus ought not to be to push combining the MP & Jkta into 1 single WG.  Keeping both projects flying independently as nicely John puts it is also my preference for the reasons stated in the many exchanges already. 

 

Dias/Noches MicroProfilers, 

Disclosure: It is January 9th and this thread has 79 posts written by 16 authors:

For any of you who might choose to become the 17 + individual wearing your MicroProfiler hats and those already here, when participating please let's REMEMBER TO:

• USE: "I" statements 
• SHARE/ANSWER: What do I care about?
• AVOID statements like: "we" or "universal" statements that generalize stuff
• Owning our words and judgements as our own is necessary to avoid blurring others' points of view

Amelia Eiras 

twitter.com/ameliaeiras

Tribe: http://tomitribe.com      https://tribestream.io   

OSS:  http://microprofile.io     https://jakarta.ee

--
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/zwFhZec8MGA/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/4d601c6e-9cad-4c69-930f-a30e61037061%40googlegroups.com.

[Werner Keil]

So "CN4J" would replace "EE4J" as a Top level project?

Looking at a recently proposed "Edge Native" WG https://www.eclipse.org/org/workinggroups/eclipse_edge_charter.php which covers many areas already in scope of the IoT WG, there would be a similar overlap and collaboration between the WGs of Jakarta EE and any possible MicroProfile or "Cloud Native" WGs. So they could be separate, I am not fully aware of the fee structures for all members other than the Committer Reps or (non-voting) Guest Members, if all the corporate members are happy to pay sometimes multiple fees for membership in all those, then why not have at least 2, the IoT space even got another proposal for https://www.eclipse.org/org/workinggroups/eclipse_sparkplug_charter.php which is far more restrictive than Edge Native and others, because it doesn't even plan "Guest Members" as of now and you can see from the fee structure, that large multinational companies (all except maybe Tomitribe or Payara are likely to fall into that category) above 1 Bio $ shall pay another 10k (Participant Members) or 20k (Strategic Members) 

The fees to Strategic Jakarta EE WG membership are of course even 10 times higher for the biggest companies above 1 Bio, so can't tell how those "Big Fish" are willing to double that just to keep Jakarta EE and MicroProfile separate? 

If it was "moderate" maybe they are happy to pay that much, but it is clearly more something to ask IBM, Red Hat (which is still separate here AKA also has to pay a separate fee ;-), Oracle or Microsoft, not so much Tomitribe because they "only" should pay 25k $ for the Strategic Membership, but of course if you multiply that by 2 or 3 some of the "sub Billion" companies may also feel the pain ;-)

Werner

To unsubscribe from this group and all its topics, send an email to microp...@googlegroups.com.

[Ondro Mihályi]

Hi Amelia,

I meant nothing personal and I owe an explanation but I won't respond to this topic again here.

I expressed only my opinion and literally wrote "I think" and not that you are any Triber said it. I really think and are seriously afraid that small companies like Payara, Tomitribe and other find it hard to keep pace with both MP and JEE and contribute to both even now. Creating an MP WG doesn't solve it and maybe should not. But having a single WG for both would seriously release some burden. This is solely my opinion, I don't base it on anything anybody has said. I see that while we're arguing about beraucratical topics (they are really not worth 70+ emails), we should rather move on and address how we can improve the progress of both MP and JEE. I we can't agree on a single WG then let's create a separate one and move on. But we should address the problem of splitting effort and the community soon after.

Ondro

[Kevin Sutter]

Werner,

>  So "CN4J" would replace "EE4J" as a Top level project?

No.  There would be no plans to change the top level project.  We had considered changing EE4J once we decided on the Jakarta name and decided against it.  Changing it would just be busy work that doesn't provide any true benefit.

Re:  Fee structures...  You are correct.  IF there are fees associated with a separate WG for MP, then each member that is participating in both Jakarta EE and MicroProfile would have to pay twice.  BUT, the separate WG proposal has outlined a much smaller budget than Jakarta EE and, thus, we're not looking at doubling the fees.  But, there would be some incremental increase.

-- Kevin

-- Kevin

[Kevin Sutter]

Ondro,

>  I see that while we're arguing about beraucratical topics (they are really not worth 70+ emails), we should rather move on and address how we can improve the progress of both MP and JEE.

Big +1

-- Kevin

[Josh Juneau]

Happy New Year everyone!  I believe that everyone on this thread has made valid points.  There is no doubt that the MP has been a great success, and it would be a bad thing if it were somehow hindered by a slower process.  That said, I've read each of the proposals a few times and the CN4J proposal seems to make the most sense to me.  I think it is important to have both MP and Jakarta EE evolve separately, but if they are unified under a single working group then I do believe it will be a good thing for the community.  I feel that the CN4J proposal was written loosely enough to allow the two to evolve separately while combining the working knowledge from both groups to help drive the cloud native initiative forward.

Also, +1 on moving forward to address how we can improve the progress of both MP and Jakarta EE.

[Rudy De Busscher]

From what I understand when there would only be 1 WorkingGroup

- There is only 1 steering committee

- All the rest will remain the same and JakartaEE and MicroProfile would be independent.

Some people fear that by having only 1 WG, MicroProfile could be limited in how it currently works or how it works. I'm in no way an expert in the structure and committees of Eclipse Foundation, so I wonder

- What will no longer be possible for what we do today for MicroProfile when there is only 1 WG?

- What will not be possible to adapt/change in the future about MicroProfile when there is only 1 WG?

For me, having 1 WG will be a strong signal that JakartaEE and MicroProfile pursue a common goal. That there is no competition and will strengthen the collaboration between them. And after all, it is mainly the same group of people behind the two of them.

[John Clingan]

<snip>

The bulk of the work should be at the specification project level, and no structure changes that working on EE and MP requires more effort. As John has said, the only efficiency introduce by a single WG is that there would be one steering committee. 

It's not an efficiency for MicroProfile. It would actually add a meeting for some since the Live Hangout is effectively the equivalent of the steering committee meeting, and the Live Hangout would not go away.

<snip> 

[John Clingan]

IMHO, they won't evolve separately under a single steering committee because, again IMHO, the the very intent of having a single steering committee is to ensure the two don't evolve separately. My two cents.

[Emily Jiang]

Well said, Josh and Rudy!

First of all, it is great to see so many people care about MP community. I think we have one thing in common:

We want to make MP more successful and grow the community!

When comparing CN4J vs. MPWG,

For me, I feel CN4J has demonstrated it is functionable. The steering community is formed and maybe additional seats can be added. The logistics are thought after. Pretty much ready to function. The MP community is well represented in CN4J. I think the current players will not drop as a consequence of moving MP under CN4J.

MPWG: do we know how much money and effort needed to be set up? Before arguing further on this, it will be worthwhile to get confirmation from Eclipse Foundation how much $ is associated. With this info, I think some current MP players might have to rethink their participantion. Are we at the risk of loosing some one? Is this what we need?

For the worries about MP being impacted in a negative way if residing under CN4J, I think this is unlikely as we are all players under CN4J. Why could we make it happen? Can we add some requirement in CN4J to stress the separation bit? I think the structure was designed for Jakarta and MP progress separately since they are separate Spec committee.

Before we discuss the same thing again, I think more concrete data should be gathered such as MPWG fees and the participants on the to-be-setup Steering committee. Otherwise, I fear we are repeating ourself with the old message.

My 2cents.

Emily

[Paul Carter-Brown]

My 2c is that we need more standardisation across JEE and MP. If one working group helps achieve that then I'm all for it.

My hope would be that MP is a subset of full JEE just like Tomcat can implement the servlet spec and be a lightweight web server, so could Quarkus implement just MP and be a lightweight rest service container. But there should be nothing stopping me deploying my Quarkus app into A full JEE app server like Weblogic.

If we look at MP as it stands and take a simple example like @Timed as part of the metrics api, then what will JEE use when they come up with a spec to add metrics to methods on a SSB. Will the JEE specs now reuse MP packages and specs? Or will my EJB that has jax-rs services on it have to import @Timed from a ejb package or a microprofile package and know that they are different and configured in different places and act in a similar way but only by coincidence...

This confusion is already happening in my mind and will get worse. Look at Payara and TomEE which are both JEE and Microprofile compatible... how will they maintain this if we have 2 different working groups under which a metrics spec is being defined. Will we have long discussions on stackoverflow explaining why our metrics for rest services are working in TomEE but no stats are coming through on calls to message driven beans cause they are 2 different things configured in 2 different ways...

IMHO the only way the TomEE and Payara teams are coping is cause JEE has not been releasing similar specs and cause the teams all come from JEE. We are thus relying on the historical fact that MP and JEE are linked as a protection against complete confusion. But as years roll on and if we have working groups encouraging competition between MP and JEE then all will be lost and end users like me will have to pick one or the other and know that trying to use both at the same time would be like trying to mix spring and JEE in single app.

In short... have 1 working group and if it's too slow for the MP guys then address that as a standalone issue and find ways to allow for subsets of the JEE specs like those part of MP to have faster cadence than others.

Paul

[Scott Stark]

It is the fee structure for CN4J that needs to be spelled out. My concern is that larger companies only wishing to participate in MP are going to be faced with large participation fees.

I certainly don't see how anything can be viewed as functional without the specifics of operation as that is what the WG is all about.

[Scott Stark]

The only model for the steering committee that currently exists is the Jakarta EE WG charter:

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

The Steering Committee section lists 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?

It is pointless to say that EE and MP specs will operate independently and that there will also be alignment. Alignment must be defined.

[John Clingan]

The reverse is also true. There are runtimes that have no intent on being a Java EE appserver, so you can't hard code Java EE behavior into any MicroProfile spec. The specs can be written, as they have been in Java EE and in MicroProfile, to behave a certain way when running in a Java EE runtime and outside of it. 

What you are suggesting is out of scope of either proposal and is, in fact, what scares the heck out of me as a MicroProfile co-founder :-) I personally do not want a tight binding between Jakarta EE and MicroProfile, but I absolutely want a loose coupling. I want MicroProfile specs to be used by Jakarta EE going forward (WildFly is supporting MicroProfile), but I do not want them to be subject to Jakarta EE (a-la Quarkus). This is what really worries me about a shared steering committee.

As for running Quarkus apps in an appserver, sure, if developers want to limit their APIs usage to those specs, then go for it. I don't mean a negative way! It is a completely valid position and I expect some organization to do that. In fact, some are doing it. It's a Quarkus benefit. However, Quarkus goes beyond MicroProfile specs (vert.x, Hibernate ORM with Panache, reactive, etc,). We look at Quarkus as a way to build APIs, try them out in the real world, and then maybe submit new specs based on them in the future. In other words, Quarkus isn't 100% about compatibility and portability. Quarkus is MP compatible, but we never intend for Quarkus to be Jakarta EE compatible. They target different user bases. I want more platforms like Quarkus out there, btw, and it is great to see others like Piranha pop up and try out different approaches.

The other reason for two working groups is that we don't yet know how quickly Java EE customers will be able to adopt Jakarta EE updates. Traditional Java EE customers put apps into production for a decade. We view MicroProfile in Quarkus as targeting a customer base that wants to move more quickly. Prematurely putting MicroProfile and Jakarta too closely is going to cause friction. We don't know what we don't know about how the industry will consume Jakarta EE. Let's give it time to play out. BTW, I think this duality is good for Java. It enables more innovation, targets a broader user base, but provides a base level of commonality. If Jakarta EE tries to be all things to all people, then it will likely lose out to other platforms. If MicroProfile tries to become all things to all people, then it will also lose out. My 2c.

[Emily Jiang]

Thank you Scott for sharing the power list for Steering committee! It is very helpful.

It is the fee structure for CN4J that needs to be spelled out. My concern is that larger companies only wishing to participate in MP are going to be faced with large participation fees.

 

At the moment, do we know what other large companies wishing to participate in MP are not in Jakarta EE already? Besides for big companies, fee probably might not be an issue.

John, I understood your concern: worrying about MP merging to Jakarta EE. If we can ensure the two communities are separate, it will solve your worry. Can we bring this concern with CN4J and make such requirement/guideline to ensure the communities should operate in parallel? If the answer is no, I think some people might change their mind regarding the WG.

Thanks

Emily

[John Clingan]

Emily, it's more than just merging. That's just one aspect, and I (and others0 have already laid others out above. Also, no one can ensure the two will remain separate. If they merge, only time will tell. It's an inherent risk, especially since Jakarta has yet to get into a cadence of releases and customers consuming those releases. It's a risk not worth taking at the moment, IMHO.

[Roman Prosvetov]

Hi All,

It's certainly will be impossible to stay objective on this topic. But I would try to find the words from the prospective of independent of any brands developer.

1. Unfortunately, I can not be on the same side of such statement as, "We want to make MP more successful and grow the community!".
I really don't want this. As a (still) Java developer I want to make "Java Ecosystem" more successful and be the part of that community.
Today's developer has to face the Trade-offs on each level and live with the consequences of made decisions. So, if Ecosystem doesn't have an intention to simplify this,
the motivation to contribute to such Ecosystem would surely start falling down.

2. The topic being discussed is complex and it's pretty easy to lose a general feeling about the purpose and intention of initiated activities.
From my prospective if it's not specified for Jackarta EE as intention to become MP as it's sub-set and get it maintained at least on the same level as MP is maintained today,
then MP would stay as it is and EE Stack would lose the momentum. If MP doesn't have an intention to become the sub-set of Jackarta EE, then this discussion is over.

So, will MP allow the WG to start adopting it's part and would WG find the way to let MP part be adopted so, that MP would get expected benefits from such adoption?

3. Right now I feel myself as walking in two different shoes. I am still walking, but at some point I definitely would start feeling pain.
And then nobody would prevent me to start wearing something from NodeJS or non-existing Kotlin EE, but on the both legs.

4. Jackarta EE should open the door for next generation of developers. For that these people need to understand, why they should start contributing. If MP stays as it is,
I would not get any interest to contribute into any other solutions.

Kind regards,
Roman

[John Clingan]

On Friday, January 10, 2020 at 10:15:15 AM UTC-8, Roman Prosvetov wrote:

Hi All,

It's certainly will be impossible to stay objective on this topic. But I would try to find the words from the prospective of independent of any brands developer.

1. Unfortunately, I can not be on the same side of such statement as, "We want to make MP more successful and grow the community!".
I really don't want this. As a (still) Java developer I want to make "Java Ecosystem" more successful and be the part of that community.

Per my comment to Paul Carter-Brown, I feel a separate working group is a better recipe for a stronger Java ecosystem.

[Guillermo González de Agüero]

As an end user, I prefer a single working group. MicroProfile was as a separated entity from Java EE because the later was basically blocked and dominated by a single vendor. MP has since advanced and demonstrated it has a lot of value by itself. It's best for Jakarta EE and MP to stay independent, as they are complementary and do not compete. Nobody questions that now. But MP will stay highly coupled to Jakarta EE and having a single WG is a strong message that we are creating *the one* next generation Java enterprise framework.

Creating two WGs would sure have its benefits, but for end users (note: end users = me. I can only guess others will think the same), it'd like someone's not so sure about one of the two projects future, and prefers to keep them separated, so it's easier to leave one behind in case of trouble. I'm not saying that's the case, but going forward with a single WG dissipates all doubts, and protects us from that kind of FUD.

That current Jakarta EE WG would need to be accommodated in order to become the Cloud Native WG and support independent evolution of both projects. It's not about merging Jakarta and MP, but about merging the common infrastructure. I think it's worth the effort.

Regards,

Guillermo González de Agüero

--

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/4322a83d-3e08-4cbe-be80-b11cc0cca198%40googlegroups.com.

[Arjan Tijms]

Hi, 

I'm currently wearing multiple hats, but basically in every capacity I'm mostly in favour of seeing a single Cloud Native for Java Working Group.

As a consultant, currently working on actual applications, I see EE & MP as one toolbox from which I can choose whatever the application I'm working on needs. If I need JWT authentication with an additional identity store and custom bean validation, then I would like everything to work seamlessly together. Technically this already breaks down a little, since JWT Auth is not officially Jakarta EE Security based, although I made sure that in Payara and Piranha it actually is. WildFly and SmallRye also did this, but an application installing an additional identity store and expecting it to be used is unfortunately not portable.

An a vendor of sorts and a lead of Piranha which intends to implement both EE and MP I don't like having to implement multiple code paths for similar or even identical functionality, nor would I like to layer, adapt and maintain multiple APIs doing similar things. For instance, a common thing such as configuration should not be duplicated in both EE and MP. There's should not be multiple @Asychronous annotations doing the same things but in a slightly different way, etc.

As a  member of the Jakarta steering committee I'm not particularly keen on the bureaucracy involved with having multiple committees deciding about things that in practice overlap; all MP implementations have a Jakarta EE core (CDI, Jakarta REST, Jakarta JSON) and in practice pretty much every EE implementation also implements MP.

A few things to remark apart from that:

The posts above mention "inside and outside an app server" a couple of times, but what does that really mean in practice? Aren't we just talking about being dependent on a certain set of APIs? The fact that for instance MP depends on CDI obviously does not make it run inside an app server.

The concern about being tied to Jakarta EE releases are maybe largely ungrounded. Even within Jakarta EE, individual specifications can release revisions independent of a main Jakarta EE release. This has always been the case for Java EE under the JCP as well. Eventually one of the revisions will be part of a Jakarta EE release, but intermediate revisions don't necessarily have to be.

Kind regards,

Arjan Tijms

[Ryan Cuprak]

Hello,
This thread is getting very hard to follow. I would prefer that there would be a single Cloud Native for Java Working Group.

Right now it feels as if enterprise Java development is split - there is the MicroProfile and Jakarta/Java EE. There is overlap between the two as most if not all Jakarta EE containers support MP.

I don’t see how MicroProfile and Jakarta EE can succeed if our efforts are divided. I was at DawsCon over the weekend and informal poll during the closing talk practically the entire room (which was about everyone at the conference. -close to 300 people) raised their hands when asked if they were using SpringBoot. The response in the room had me worried about the future of both MicroProfile and Jakarta EE.

Both MicroProfile and Jakarta EE are too dependent on each other.

-Ryan