Maven – Apache Maven Project Roles

The Apache Maven project is not just the software it produces. The Apache Foundation has a phrase: “Community over code” which is about how it is the community that grows around a project that is the most important thing.

Everyone reading this is part of the Apache Maven community, and even if you are an invisible part of the Apache Maven community you are still part of the community.

There are many ways we can sort the people in our community, we present the following as one such way. Please do not take offence if you disagree with this categorisation. It is important to remember that we are a community not a clique so you are entitled to disagree with others in the community.

Note: the right to disagree with other people’s opinions comes with the responsibility not to deliberately cause offence or discord.

Informal roles

Lurkers

People who do not use Maven at all, but have an interest in the project. This can include people who are developing competing software tools to Apache Maven.

It would be great if the lurkers would come out of the shadows and make themselves visible, but every community needs its lurkers, so if you are a lurker sulking about on the fringes of the Apache Maven project, know that you are a valued member of our community. If you ever feel the need to change your role, we will welcome you with open arms… (and if we don’t welcome you with open arms, please advise the Project management committee who are responsible for ensuring that the community is a healthy one)

Consumers

People who use Maven, but do not actively join the community. This does not include people who are: subscribed to one of the Maven mailing lists; active in a Maven user community (e.g. something like stackoverflow; submitting bug reports; etc.).

Maybe Apache Maven is the perfect product for you and does exactly what you need and want, and you never have a need to ask questions about how to use Maven as it is immediately obvious to you how one is supposed to use Maven… If that is the case, could you please consider taking a more active role in our community, as Maven is none of the above to our minds and you might have a point of view that we have missed.

If you do have issues with Maven (we all have issues with it so there is nothing wrong in having issues with Maven), please let us know:

Submitting bug reports is the best way to let us know about bugs,
Asking questions on the Users Mailing List is the best way get answers to questions.

As a last resort, other Maven user communities are another route to getting more involved in the Maven community, but keep in mind that Apache Foundation projects are supposed to encourage the community at the ASF, so you will get more eyes and a quicker response if you engage directly with the ASF hosted community.

Users

People who use Maven and have joined the community. This includes people who have:

Submitted a bug report,
Asked a question on the Maven user list,
Joined one of the other Maven user communities.

We hope your bug report has received some attention. If it hasn’t, why don’t you see if you can fix the issue yourself and submit a patch?

We hope your question was answered. If it hasn’t, think of all the other users who’s questions sit unanswered, how many of them do you know an answer for (even if only a partial answer)? Why don’t you respond to their questions with the answers you know? If everybody did that, your question would have an answer. Pay it forward!

We hope your experience in one of the other Maven user communities is a positive one, so why not join the canonical Maven user community and subscribe to the Maven user list?

Contributors

People who use Maven, have joined the Maven community and contribute back to the community. This includes people who:

Submit reports of the results of testing proposed releases of Maven and Maven plugins,
Answer questions on the Maven user list (or even other Maven user communities),
Submit patches to resolve reported bugs in Maven or Maven plugins hosted at Apache,
Help curate bug reports by identifying duplicate reports, or related issues.

We wrote a guide for contributors.

Keep up the contributions, you are a critical member of our community. If we like what we see, we may even ask you to consider taking a formal role in our project.

Formal roles

Committers

These are those people who have been given write access to the Apache Maven code repository and have a signed Contributor License Agreement (CLA) on file with the ASF.

The Apache Maven project uses a Commit then Review policy and has a number of conventions which should be followed.

Committers are responsible for ensuring that every file they commit is covered by a valid CLA.

Committers who would like to become PMC members should try to find ways to demonstrate the responsibilities listed in the PMC Members section in order to make it easier for PMC members to decide that the committer is ready for the responsibility.

Emeritus committers

If a committer decides that they cannot currently continue with the responsibilities of a committer, they may elect to go emeritus.

At any time, an emeritus committer for the Apache Maven project may decide that they want to become an active committer again by informing the project management committee. The current policy is that committer role reinstatement is automatic.

Project Management Committee

The Project Management Committee as a whole is the entity that controls the project. Membership of the Project Management Committee is decided by the board of the Apache Software Foundation, based on nominations from the Project Management Committee.

It is a long standing tradition of the Apache Maven Project that the Project Management Committee reviews the active committers approximately every 6 months with a view to determining whether any of those committers would be suitable candidates to recommend to the board for inclusion on the PMC. It should be noted that this is simply a tradition and not a right. There are significant responsibilities that accompany the PMC role and as such, if a person is not demonstrating those responsibilities, they may not be nominated or their nomination may be rejected by the board. Such decisions are not a reflection of the technical competence of the person, and indeed the person themselves may even decide to turn down the nomination. For that reason the results of such periodic reviews are kept confidential.

The Project Management Committee has the following responsibilities:

Active management of those projects identified by the resolution of the Board of Directors of the Apache Foundation;
Ensure the project remains a healthy top-level project of the Apache Foundation (if a PMC member wants the project to be hosted elsewhere they should resign from the PMC stating their reason - if the PMC shrinks beyond the minimal viable size then as a result of a desire by the bulk of the PMC to move the project elsewhere, the Board of the Apache Foundation will take that into account when moving the project into the Foundation’s Attic)
Prepare reports as required by the Board of the Apache Foundation and ensure those reports are ready for presentation by the PMC Chair in a timely manner;
Defend the trademarks belonging to the project;
Proposing active contributors for committership;
Ensure that votes in the community are used as a tool to establish consensus and not a weapon to disenfranchise or alienate a minority of the community;
Binding votes in project decisions;
Ensure that code committed to the project is either committed under a valid CLA or is code that was contributed with a clear indication that the Apache License applied (i.e. small patches submitted to the issue tracker or to the mailing list are assumed to be submitted with the intent of being covered by the Apache License unless the submitter clearly marks those patches as not being covered)
Ensure that third party dependencies shipped as part of the project’s releases are covered by a compatible license.
Voting on release artifacts;
Ensure Developers Conventions are followed, or updated/improved if necessary;
Knows and respects the goals and processes of the community and helps educate newer members about them.

Standards for Community Commitment

In the spirit of supporting the health of our community, Project Management Committee members refrain from actions that subvert the functioning of the committee itself.

Promotion of other projects

The Apache Foundation currently does not have a policy requiring projects to cross-promote. For example Subversion is an Apache project, yet projects are free to choose from Subversion and GIT (a non-Apache project) for source control.

When considering integration of technologies within Maven, there is thus no requirement that other Apache projects be picked over non-Apache projects.

The primary requirements for picking technologies to integrate with Maven are thus:

A compatible license, i.e. Category A or Category B
A good technical fit
A strong preference on behalf of the portion of the community that will be doing the integration.

Where a PMC member is advocating a specific technology, they should declare any interest / involvement that they have in that technology or a competing technology - irrespective of whether the project is an Apache project or a project hosted elsewhere.

PMC members with a stated interest / involvement should try to abstain from making binding votes in either direction with respect to the relevant technology choices.

Forks of the project codebase

All code that gets released by the community should have sufficient opportunity for review both:

By the PMC, to check the legal responsibilities delegated by the Board; and
By the committers (which includes the PMC), to check that the technical direction and quality is in line with the consensus roadmap (where such a roadmap has been agreed).

It is self evident that the opportunity for review is much greater if the code is committed to the project’s source control as early as possible. Similarly small commits are easier to review than large commits.

There is nothing inherently wrong with maintaining a fork of the Maven codebase outside of the Apache Foundation. Individual developers can have their own style of working and may prefer to work in a fork so that they can throw away failed experiments with less visibility (though it could be argued that the visibility of such failed experiments can be valuable documentation for others). As soon as changes in that fork are identified (by the people maintaining the fork) which should be brought back to the project those changes should be introduced into at least a branch hosted on the Apache Maven source control in order to facilitate the easier review by the community. The PMC should encourage by example the early committing of such changes from a fork (that they are involved in maintaining) back to Apache Maven source control.

Similarly, if a fork is being hosted elsewhere in order to get contributions from other talented individuals, the PMC members should endevour to bring those individuals and their talent to the project as committers.

Finally, where a fork is hosted outside of Apache hardware, there is less traceability of the code provenance, for example GIT commits can be squashed and history re-written to mask or otherwise hide the source of contributions. This does not mean that code coming from an external fork inherently has such issues, instead it means that the requirements for review and verification of provenance grow exponentially when dealing with large sets of changes originating from a long running fork hosted outside of Apache foundation source control. Anybody maintaining a long running fork should be aware of the risk that review obligations may grow above the time capabilities of the PMC and committers such that when they eventually decide to try and bring the changes in their fork back to the Apache Maven project their contribution may end up being rejected on the basis of the review of a large set of changes being too difficult/timeconsuming.

Project Management Chair

For various legal reasons, there are certain things that the Apache Software Foundation can only delegate to an officer of the foundation.

The Project Management Committee is responsible for nominating the lucky victim who gets made an officer of the foundation (subject to the approval of the board).

This person then becomes the interface between the board and the project management committee. They do not have any other additional gravitas in the project, it is the Project Management Committee as a whole that is responsible for the direction of the project.

If things break down and there is no consensus and there is no clear ability to reach any conclusion and it is in the interest of the foundation because damage is done and the board expects the chair to act as an officier of the foundation and clean things up, then the chair can act as an ultimate decision maker, however, by this point the board of the foundation must already be well aware of the situation and should be actively monitoring the chair.