Hi Gaetan, Thanks for bringing this up. I share your concerns, and I think they are important points for every committer to consider.
The copyright attribution aspect mentioned by the ASF guidance is particularly relevant for a project like OFBiz, which is used in production by many organizations. Having clear provenance for contributions is not just a matter of compliance, but also of transparency and trust. Another aspect that comes to mind is that AI tools significantly lower the cost of implementing new features, components, and integrations. On one hand, this is a great opportunity, as it enables developers to prototype and implement ideas much faster than before. On the other hand, it also makes it very easy to add more and more code to what is already a very large codebase. Personally, I would like to see OFBiz evolve toward a lighter, more focused, and easier-to-maintain codebase, so I think we should be mindful not only of the quality of new code, but also of whether new functionality truly justifies the additional maintenance burden. There is also an asymmetry between implementation cost and review cost. AI dramatically reduces the effort required to produce code, but unless we consciously decide to embrace "vibe coding" or similar development models, the cost of reviewing that code remains essentially unchanged. In fact, for complex contributions it may even increase, since reviewers still need to understand the design, verify correctness, and ensure consistency with the rest of the project. I can imagine this leading to frustration if reviewers feel they are expected to spend significantly more time reviewing a contribution than the contributor spent producing it. While "vibe coding" may be an interesting experiment for a new project that is built around that philosophy from the beginning, I don't think it is currently a viable approach for OFBiz. We have a large, mature codebase that has been carefully crafted over more than twenty years by the collective effort of this community. Given the current state of these tools, I believe that preserving the project's long-term maintainability and consistency should remain our primary objective. That said, I also see tremendous opportunities for using AI in ways that can benefit the project without compromising those goals. For example, I think we could further experiment with using AI to: * create and improve unit tests; * assist with Minilang-to-Groovy conversions; * help modernize and upgrade parts of our technology stack; * perform security reviews and identify potential vulnerabilities; * automate repetitive refactoring tasks * automate translations (localization) instead of maintaining large language files in multiple languages in our codebase. These are areas where AI can amplify developer productivity while still keeping experienced contributors firmly in control of the design and review process. More generally, I think these tools are incredibly valuable when used by skilled developers who understand both their capabilities and their limitations. They can substantially improve productivity and, when applied thoughtfully, even improve the quality of the final result. The key, in my opinion, is to view them as assistants rather than replacements for engineering judgment. Best regards, Jacopo On Wed, Jul 1, 2026 at 9:24 AM gaetan.chaboussie via dev <[email protected]> wrote: > > Hi all, > > It's a topic that's been on my mind for a while now when reviewing code. > I re-read the Official ASF position on Generative AI that can be found > here [1][2]. > > I think this quote is important: > "When providing contributions authored using generative AI tooling, a > recommended practice is for contributors to indicate the tooling used to > create the contribution. This should be included as a token in the > source control commit message, for example including the phrase > “Generated-by: ”. This allows for future release tooling to be > considered that pulls this content into a machine parsable > Tooling-Provenance file." > > In complex changes that impacts low level code, it also raises the > question of maintainability. > I trust that every contribution has been read and understood, but if for > any reason the committer is not able to commit anymore, maintaining such > code could become quite tricky. > > Any thoughts ? > > Gaetan > > > [1] https://www.apache.org/legal/generative-tooling.html > [2] > https://news.apache.org/foundation/entry/why-generative-ai-guidance-is-essential-to-contributors-of-open-source >
