Current Eclipse MicroProfile governance

Eclipse MicroProfile, first and foremost, is an Eclipse project and it, therefore, follows Eclipse processes. This includes committer approvals, project releases, intellectual property safeguarding, license review processes, and more. However, the Eclipse Foundation is flexible enough for projects such as MicroProfile to offer some additional lightweight processes for multiple specifications to move forward in parallel with ways to communicate across and align specifications.

One of these lightweight processes is the Eclipse MicroProfile bi-weekly Hangout meeting/call (whose meeting URL is https://eclipse.zoom.us/j/949859967, and whose recordings can be found on the Eclipse MicroProfile YouTube channel at https://www.youtube.com/channel/UC_Uqc8MYFDoCItFIGheMD_w), which is open to anybody in the community and serves as a forum where topics brought up by attendees are discussed and decisions are made, from sub-project statuses and release contents to release dates and sub-project creation approvals. It should be noted that MicroProfile is not a standards organization, although it can seem that way. MicroProfile was created by the community for the community, and it moves at the speed that the community determines as it innovates in its different sub-projects. MicroProfile defines specifications that encourage multiple implementations, much like a standards organization. However, MicroProfile truly operates as a fast-evolving open source project whose source code is specifications.

The main means of community communication, discussion, and debate is the Eclipse MicroProfile Google Group (https://groups.google.com/forum/#!forum/microprofile). You can use your favorite web browser to read, post, answer, or start forum messages for any MicroProfile-related topic in the Google Group. You can also use the Group's email to start new forum messages. Anybody can start new forum threads to discuss topics, such as potential new functionality to be added to MicroProfile. After the community discusses a new idea at length in the forum and/or the MicroProfile Hangout call, and it's been determined that it is worth furthering the debate, the community decides to create a working group for this new idea, and a lead or a group of leads, who are usually subject-matter experts in the topic at hand, are designated to serve as its facilitators.

One important aspect to note is that the lead or leads of a working group (or sub-project for that matter) do not single-handedly shape or determine the evolution of a specification or what capabilities are included or not. They do not have the power of veto or a final say in the decisions made with respect to their specification. By their sharing of ideas, expertise, past experiences, analysis of existing technologies, and best practices, the working group will come up with their best proposal possible. In addition, all unresolved issues need to be discussed by the community and brought up in the bi-weekly Hangout meeting/call for further debate, if needed. Through discussion, collaboration, and feedback from the community, many points of view are analyzed, allowing the best option or options to bubble up to the top. The working group will establish a recurring weekly or bi-weekly meeting, which is entered in the MicroProfile Google Calendar (https://calendar.google.com/calendar/embed?src=gbnbc373ga40n0tvbl88nkc3r4%40group.calendar.google.com). This contains information of all MicroProfile Hangout calls, MicroProfile sub-project calls, and MicroProfile release dates.

While anybody can attend these meetings, there's usually a core number of people that serve as the subject-matter experts who participate in these calls. After a few meetings, the working group decides whether or not the new functionality should be brought up to the MicroProfile Hangout call to discuss its proposal to become a MicroProfile sub-project.

At the MicroProfile Hangout call, a sub-project proposal may be rejected or accepted. It should be said that by the time the sub-project proposal is brought to the MicroProfile Hangout call, most of the discussion of whether or not it should move forward will have taken place already, so the decision taken at the call should really be of no surprise to the sub-project working group. The rejection of a sub-project does not mean that it does not fulfill a specific developmental need, but rather an affirmation that its goals are not a good match to advance the MicroProfile specification, whose goal is the optimization of Enterprise Java for a microservices architecture.

For example, if a sub-project proposal addresses a need that is unrelated to microservices, then the chances are that the sub-project proposal will not move forward as a MicroProfile sub-project. The acceptance of a sub-project means that it effectively addresses a need that enriches the specification toward its goal of optimizing Enterprise Java for a microservices architecture. It is at this moment that a sub-project becomes an official MicroProfile API. Once the sub-project becomes a MicroProfile API, then a determination is made as to whether it should be a standalone sub-project outside the umbrella or a sub-project included in the umbrella MicroProfile releases. A high-level flowchart of this process is as follows: