Hi all, The mission of the project is, in line with the ASF, to provide software for the greater good and offering (potential) adopters a choice. In the projects case this is done through providing the OFBiz works (each and all products, as well as the supporting tooling for enabling contributors like JIRA, Github services, etc.)
The project has since its inception as a TLP made it clear, with the above in mind, that the the project is not responsible for the choices a (potential) adopter has made, nor that it will be held responsible for the future choices of an adopter. This means, when talking about the code of the main OFBiz product, the project does not care whether an adopter (being it either an enterprise having OFBiz implemented, or a service integrator offering services and/or solutions for payment or not) uses, enhances or diminishes the OFBiz functionalities in upstream activities. The project has also made clear in communications to every kind of community member and adopter, that for use, enhancement or diminishment of OFBiz functionalities in his environment of development and service delivery the adopter should always start from releases and not from the volatile trunk repositories. Unfortunately, there have been (and are) several prominent members of the OFBiz community that have made assertions that it was quite ok for adopters to start with the code in the trunk branch of the repo for their own develop and/or implementation. When these community members propagate this start-with-trunk paradigm in their upstream needs-and-wants model, they tend to shoot in their own foot. But instead of acknowledging that they took a wrong turn and remediate that situation, they elect to bring their problem down to the OFBiz project and demand that the other contributor removes this undesirable change from the OFBiz code base, in order to keep the upstream deviation minimally disrupted. Given what Mathieu has brought forward regarding the 'depends-on' enhancement of the OFBiz functionality, it is clear that it strengthens and enhances understandings regarding the OFBiz product and its intricacies (where the code is the documentation). When looking at the process undertaken by Mathieu, he was working within his mandate as a community member with the commit-privilege to commit the changes to the trunk branch of the repo (as per ticket OFBIZ-11296, commit eeabe69813a1d9f42911dec70a912574046ef49b). Moreover, he was also working along and in-line with precedents established by other community members before he became a privileged contributor. The discussion that later developed was a good thing, but with precedents as they are it is unfortunate that the commit was later reverted. Unfortunate, not because the discussion developed but because the commit did not 'break the code'. Precedents have shown that questionable commits did not lead to reversal of these commits. If, and when, all understand the rules of engagement of the OFBiz project, and act accordingly, there would never by such a (heated) discussion as this one, or the ones leading up to this (whether started and followed through in JIRA tickets, or on any of the mailing lists). Apparently many of the community members (including those with privileges) do not understand what these are or these provide to ambiguity which leads to deviations when contributing. Best regards, Pierre Smits *Apache Trafodion <https://trafodion.apache.org>, Vice President* *Apache Directory <https://directory.apache.org>, PMC Member* Apache Incubator <https://incubator.apache.org>, committer *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges) since 2008* Apache Steve <https://steve.apache.org>, committer
