Eclipse EE.next Working Group on the move
© Shutterstock / Rawpixel.com
The draft of the EE.next Working Group charter is now available for community review. You have at least 30 days to give your comments and feedback on the firstname.lastname@example.org mail list but you are advised to read the FAQ first.
However, you are advised to read the FAQ first.
As Mike Milinkovich, Executive Director of the Eclipse Foundation wrote in a recent blog post, “you can think of this group as the replacement for the Java Community Process for Java EE. It will be the body that the ecosystem can join and participate in at a corporate level. Individuals can also join if they are committers on EE4J projects.”
will also be the place where the new specification process will be created and managed, and where specs will be reviewed and approved.
The community review period will last at least 30 days.
Keep in mind that the name EE.next is still subject to change since the name that will replace “Java EE” has not been selected yet.
EE.next Working Group vision and scope
The EE.next working group will:
- Promote the “EE.next” brand and its value in the marketplace.
- Provide vendor neutral marketing and other services to the EE.next ecosystem.
- Define and manage a specification process to formalize the specifications that are defined within the scope of this working group.
- Define compatibility rules and a compatibility and branding process for implementations of these specifications to ensure application portability.
- Define licensing and intellectual property flows that encourage community participation, protect community members and encourage usage.
- Manage the overall technical and business strategies for EE4J and related projects.
- Establish and drive a funding model that enables this working group and its community to operate on a sustainable basis.
EE.next Working Group FAQ
Who defines and manages technical direction?
The projects manage their technical direction. The PMC may elect to coordinate the activities of multiple projects to facilitate the release of software platforms, for example.
Because the creation of roadmaps and long-term release plans can require market analysis, requirements gathering, and resource commitments from member companies, the working group may sponsor complementary activities to generate these plans. However, ultimately it is up to the projects to agree to implement these plans or roadmaps. The best way for a working group to influence the direction of the open source projects is to ensure that they have adequate resources. This can take the form of developer contributions, or under the Member Funded Initiatives programs, working groups can pool funds to contract developers to implement the features they desire.
Why are there so many levels of membership?
Because the Java EE ecosystem is a big place, and we want to ensure that there are roles for all of the players in it. We see the roles of the various member classes to roughly align as follows:
- Strategic members are the vendors that deliver Java EE implementations. As such they are typically putting in the largest number of contributors, and are leading many of the projects.
- Influencer members are the large enterprises that rely upon Java EE today for their mission critical application infrastructure, and who are looking to to deliver the next generation of cloud native Java. They have made strategic investments in this technology, have a massive skills investment in their developers, and want to protect these investments as well as influence the future of this technology.
- Participant members are the companies that offer complementary products and services within the Java EE ecosystem. Examples include ISVs which build products on Java EE, or system integrators that use these technologies in delivering solutions to their customers.
- Committer members are comprised of the committers working on the various EE4J projects who are also members of the Eclipse Foundation. While the Eclipse bylaws define the criteria for committers to be considered members, in essence any committer members are either a) a committer who is an employee of an member company or b) any other committer who has explicitly chosen to join as a member. Giving Committer members a role in the working group governance process mimics the governance structure of the Eclipse Foundation itself, where giving committers an explicit voice has been invaluable.
What makes this different from the Java Community Process (JCP)?
Theworking group will be the successor organization to the JCP for the family of technologies formerly known as Java EE. It has several features that make it a worthy successor to the JCP:
- It is vendor neutral. The JCP was owned and operated first by Sun and later by Oracle. is designed to be inclusive and diverse, with no organization having any special roles or rights.
- It has open intellectual property flows. At the JCP, all IP flowed to the Spec Lead, which was typically Oracle. We are still working out the exact details, but the IP rights with and EE4J will certainly not be controlled by any for-profit entity.
- It is more agile. This is an opportunity to define a 21st century workflow for creating rapidly evolving Java-based technologies. We will be merging the best practices from open source with what we have learned from over 15 years of JCP experience.
SEE ALSO: EE4J will not inherit the Java EE name
Is the WG steering committee roughly equivalent to the JCP Executive Committee?
No, not really. The JCP EC always had two mixed roles: as a technical body overseeing the specification process, and as an ecosystem governance body promoting Java ME, SE, and EE. Inthe Steering Committee will be the overall ecosystem governance body. The Specification Committee will focus solely on the development and smooth operation of the technical specification process.
Does a project have to be approved as a spec before it can start?
That is actually a decision which will be made by the EE4J PMC, not the working group. However, it is a goal of the people and organizations working on creating this working group that the Java EE community move to more of a code-first culture. We anticipate and hope that the EE4J PMC will embrace the incubation of technologies under its banner. Once a technology has been successfully implemented and adopted by at least some in the industry, it can then propose that a specification be created for it.