| [jakarta.ee-wg] Cloud Native for Java Umbrella Working Group Proposal |
Dear MicroProfile and Jakarta EE communities,
I hope that everyone is safe and healthy in these difficult
times.
My apologies for the cross-post, but for this topic we do need to
hear the views of both (overlapping) groups.
Some months ago we kicked off a discussion on the MicroProfile
list about the right path forward for MP as it transitions to a
working group. At the moment there are two main proposals on the
table: (a) create a completely independent working group, or (b)
find a way to work more closely with the Jakarta EE, while
maintaining independent brands and specification processes. Many
good points were raised during the discussions one of them being a
suggestion for an "umbrella working group" that allows for greater
autonomy.
As the main author of the (b) proposal, we would like to withdraw
it and replace it with a
new proposal[1] for an umbrella working group that will be
initially made up of MicroProfile and Jakarta EE. I have pasted
the text of the proposal below for your convenience. But to keep
cross-posting to a minimum, it may be better to comment directly
on the document.
[1] https://docs.google.com/document/d/1pV2n0iZkgdaIOaaZMZuTmSPDyjVKZBS5gg7Y1-P_RHU/edit?usp=sharing
We look forward to the discussions!
Mike Milinkovich
Executive Director | Eclipse Foundation, Inc.
mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx
@mmilinkov
+1.613.220.3223 (m)
There have been a number of discussions recently about an alternate solution to how Jakarta EE and MicroProfile can be aligned: namely, the notion of an “umbrella working group”. This document attempts to describe how such a solution would work under existing Eclipse Foundation policies and procedures.
Working Group (“WG”): as defined elsewhere, a collection of member committers and companies who share an interest in a particular domain, where that domain is defined by the open source projects (including specification projects) within the scope of the working group. Working Groups are intended to complement the activities of open source projects with activities such as marketing, branding, specification development, and developer advocacy. Working Groups are required to implement the Eclipse Foundation Specification Process, so any initiative intended to create specifications will require the formation of a Working Group.
Umbrella Working Group (“UWG”): a working group whose domain of interest is defined by two or more constituent working groups.
Participation Fees: annual dues paid to a WG or UWG by an Eclipse Foundation Member company to participate in the activities of those groups. Note that in all cases it will be possible for an individual to participate in the activities of a WG or a UWG with no fees. However, in some instances an employer consent may be required. It is our suggestion that the initial fees for the UWG be the same as the existing fee structure for Jarkarta EE. In other words, there would be no additional costs to our members under this proposal.
Sponsorship: monies paid on an ad hoc basis to support the activities of a particular WG or UWG. Sponsors (i.e. the companies doing a Sponsorship) do not have to be members of the Eclipse Foundation or any of the working groups.
We would like to suggest that the following principles be adhered to by the Cloud Native for Java Umbrella Working Group:
Minimize Bureaucracy: It is important to keep the amount of paperwork that needs to be done by participants to an absolute minimum. This is not only for the benefit of the participants. The Eclipse Foundation itself is a small, resource constrained organization. Each time another agreement must be signed, or an invoice must be sent this is an additional burden on our operations.
Freedom of Movement: It must be possible for participants in the UWG to participate in all of the constituent WGs and their related projects with minimal (preferably zero) additional effort.
Frictionless Intellectual Property: It must be possible for the assets of the WGs and their related projects to be shared within the UWG. Among other benefits, this allows for straightforward sharing, consumption and potential refactoring of the work product of working groups, specification projects, and (potentially) specifications as future circumstances require.
Although it is not, strictly speaking, a principle it should be noted that one of our goals is to establish an organization that is easier for companies to join, particularly enterprise consumers of these technologies. Having more members not only provides additional resources supporting these initiatives, it also demonstrates industry momentum and the long-term sustainability of the technologies.
We would propose the creation of a Cloud Native for Java Working Group (“CN4J” or “CN4J WG”) as an Umbrella Working Group, initially comprised of the Jakarta EE Working Group and the (to be formed) MicroProfile Working Group.
In general, we envisage an umbrella working group that is made up of other working groups. Member companies join the umbrella by signing a single participation agreement and paying a single fee. They can then participate in any of the constituent working groups by simply stating their intention to do so (e.g. just send an email to the working group mailing list). Member companies may not join constituent WGs without joining the Umbrella Working Group.
The UWG decides the budget allocations of participation fees collected. Budgets for the UWG and its constituent WGs will be done for each calendar year (additional details below). Any entity (whether an Eclipse Foundation member or non-member) that wants to earmark funds for a particular WG can do so by sponsoring the WG directly.
Each WG will have control over its own charter, committees, processes, and activities. The UWG may put resources into an overall marketing message or activities, but it does not direct or control the activities within its constituent WGs.
Each WG will have the freedom to leave the UWG and form their own independent working group, provided that they decide to do so no later than July 1st of each year. This is to allow the necessary time to re-work the respective charters, and prepare budgets for the following year. Such decisions would be made by a super-majority vote of the WG Steering Committee.
The Cloud Native for Java Working Group would have the following roles and responsibilities:
Establishes a Steering Committee to manage the overall Cloud Native for Java initiative.
Create and manage the evolution of its WG charter as per the Eclipse Foundation Working Group Process, including any other committees deemed necessary for the vendor-neutral operation of the UWG.
The Steering Committee will establish participation fees for various levels of membership in the UWG.
The Steering Committee would determine the budget, including allocations to each constituent WG. Each WG can make budget allocation requests.
The Steering Committee will decide via a super-majority what Eclipse Foundation WGs are within its purview. (Note that the constituent WGs will have to accept this, and state so in their own charters.)
The holder of the single Working Group Participation Agreement to be executed by all participants in the UWG and its constituent WGs.
In general we would expect that any Eclipse Foundation staff supporting these activities would be in the UWG budget, rather than in constituent WG budgets.
The constituent working groups (e.g. Jakarta EE and MicroProfile) would have the following roles and responsibilities:
Establish a Steering Committee to manage its operations.
Create and manage the evolution of its WG charter as per the Eclipse Foundation Working Group Process, including any other committees deemed necessary for the vendor-neutral operation of the WG.
Create, approve, and manage an annual budget. The funds used by the WG would be based on allocations from the UWG, plus any sponsorships directed to that WG.
The Steering Committee will decide via a super-majority what Eclipse Foundation open source projects (including specification projects) are within its purview.
Create and manage any branding programs necessary.
Note that each WG would not be permitted to have participation fees, since that would imply a separate participation agreement which conflicts with the minimize bureaucracy principle.
Recognize the contributions of participants and sponsors.
Membership in each WG is done by simply having a signatory to the UWG Participation Agreement send an email to the WG list indicating their desire to participate. Note that this requires that the WG charter state that its members must already be members of the UWG. They could optionally have some sort of mapping of membership classes. For example, with additional requirements such as contributions or committed development resources, a Participant Member of the UWG could be a Strategic Member of a constituent WG.