Apache Maturity Model Assessment for PLC4X


This is an assessment of the PLC4X podling’s maturity, meant to help inform the decision (of the mentors, community, Incubator PMC and ASF Board of Directors) to graduate it as a top-level Apache project.

It is based on the ASF project maturity model at https://community.apache.org/apache-way/apache-project-maturity-model.html

Maturity model assessment

Mentors and community members are encouraged to contribute to this page and comment on it, the following table summarizes project’s self-assessment against the Apache Maturity Model.

ID Description Status



The project produces Open Source software, for distribution to the public at no charge.

The project source code is licensed under the Apache License, version 2.0.


The project’s code is easily discoverable and publicly accessible.

Our sourcecode is available at Apache GitBox and GitHub and linked to from our website


The code can be built in a reproducible way using widely available standard tools.

our Maven build has been tested on Linux, MacOS and Windows and build description is available on our website


The full history of the project’s code is available via a source code control system, in a way that allows any released version to be recreated.

The entire commit history is available from the beginning.


The provenance of each line of code is established via the source code control system, in a reliable way based on strong authentication of the committer. When third-party contributions are committed, commit messages provide reliable information about the code provenance.

The project uses the git repository, managed by Apache Infra, ensuring provenance of each line of code to a committer, each line committed before entering incubation was equally configured.

Licenses and Copyright


The code is released under the Apache License, version 2.0.

Both the source distribution as well as the convenience binary artifacts clearly declare that they are licensed under the Apache 2.0 license


Libraries that are mandatory dependencies of the project’s code do not create more restrictions than the Apache License does.

The list of mandatory dependencies have been reviewed to contain approved licenses only.


The libraries mentioned in LC20 are available as Open Source software.

All mandatory dependencies are available as open source software.


Committers are bound by an Individual Contributor Agreement (the "Apache iCLA") that defines which code they are allowed to commit and how they need to identify code that is not their own.

The project uses a repository managed by Apache Gitbox — write access requires an Apache account, which requires an ICLA on file.


The copyright ownership of everything that the project produces is clearly defined and documented.

All files in the source repository have appropriate headers which is enforced by tooling included in the build. ICLAs from all initial committers have been documented. CCLAs from all companies involved have been documented. SGA is on file for the initial contribution.



Releases consist of source code, distributed using standard and open archive formats that are expected to stay readable in the long term.

Current source releases are distributed via dist.apache.org and Older source releases are available from archive.apache.org. Both are linked from the website.


Releases are approved by the project’s PMC (see CS10), in order to make them an act of the Foundation.

All incubating releases have been unanimously approved by the PLC4X community and the Incubator, all with at least 3 (P)PMC votes and more +1 than -1.


Releases are signed and/or distributed along with digests that can be reliably used to validate the downloaded archives.

All releases are signed, and the KEYS file is provided on dist.apache.org


Convenience binaries can be distributed alongside source code but they are not Apache Releases — they are just a convenience provided with no guarantee.

Convenience binaries are distributed via Maven Central Repository only. Currently due to the platform-dependency of C++ libraries, these are not distributed currently.


The release process is documented and repeatable to the extent that someone new to the project is able to independently generate the complete set of artifacts required for a release.

We have a guide for release managers, that has been tested by multiple release managers available on our website.



The project is open and honest about the quality of its code. Various levels of quality and maturity for various modules are natural and acceptable as long as they are clearly communicated.

All issues are documented in our JIRA instance, which is our primary bug and issue tracker.


The project puts a very high priority on producing secure software.

even if we haven’t received any security issues targeted at PLC4X yet, we pro-actively monitor our dependencies and if reported would treat them with the highest priority, according to the CVE/Security Advisory procedure.


The project provides a well-documented, secure and private channel to report security issues, along with a documented way of responding to them.

We are using Apaches default way to submit security related information, which is described on our website


The project puts a high priority on backwards compatibility and aims to document any incompatible changes and provide tools and documentation to help users transition to new features.

We try to keep everything as backward compatible as possible. If we are forced to introduce incompatible changes, these is documented in a Incompatible changes section as part of our release notes.


The project strives to respond to documented bug reports in a timely manner.

Bug reports are treated with priority and are automatically posted to our developer mailing list dev@plc4x.apache.org" class="bare">https://lists.apache.org/list.html?dev@plc4x.apache.org so they are prominently recognised.



The project has a well-known homepage that points to all the information required to operate according to this maturity model.

The project website has a description of the project with technical details, how to contribute, team.


The community welcomes contributions from anyone who acts in good faith and in a respectful manner and adds value to the project.

So far we have recognized any form of contribution and every contributor with the desire to become part of the team has been invited to join.


Contributions include not only source code, but also documentation, constructive bug reports, constructive discussions, marketing and generally anything that adds value to the project.

It’s part of the contribution guide and the current committers are really keen to welcome contributions.


The community is meritocratic and over time aims to give more rights and responsibilities to contributors who add value to the project.

So far the community has elected 4 committers, all of them also being added to the PPMC.


The way in which contributors can be granted more rights such as commit access or decision power is clearly documented and is the same for all contributors.

The criteria is documented in the contribution guide.


The community operates based on consensus of its members (see CS10) who have decision power. Dictators, benevolent or not, are not welcome in Apache projects.

The project works to build consensus. All votes have been unanimous so far.


The project strives to answer user questions in a timely manner.

Responses to reported issues or asked questions typically are handled by the community withing a matter of a few hours (Responses being faster during typical European time-zone business-hours).

Consensus Building


The project maintains a public list of its contributors who have decision power — the project’s PMC (Project Management Committee) consists of those contributors.

We’re currently working on filling the team page.


Decisions are made by consensus among PMC members 9 and are documented on the project’s main communications channel. Community opinions are taken into account but the PMC has the final word if needed.

All decisions are made on one of our mailing lists. Every decision discussed off-list has been taken back to the list for final discussion and we’ll keep on doing that.


Documented voting rules are used to build consensus when discussion is not sufficient.

We have documented our decision making rule on our website.


In Apache projects, vetoes are only valid for code commits and are justified by a technical explanation, as per the Apache voting rules defined in CS30.

This part actively contradicts the voting rules of the Apache Incubator. This project follows the voting rules of the Apache Incubator which we documented on our website.


All "important" discussions happen asynchronously in written form on the project’s main communications channel. Offline, face-to-face or private discussions 11 that affect the project are also documented on that channel.

As mentioned in CS20 it is impossible to prevent off-list discussions when meeting in person. But we have always handled things in a way that we always write up summaries of important discussions and post them to the mailing lists.



The project is independent from any corporate or organizational influence.

The group of active committers and PPMCs consists of members of more than independent 4 companies.


Contributors act as themselves as opposed to representatives of a corporation or organization.

While there are several cases where committers and PPMC members utilize corporate infrastructure or these companies, no case has been found where any of these committers and PPMCs have represented corporate interests.