Hi Jacopo, I did not receive your reply to this thread. I saw your reply when Gaetan replied on your email. Am I missing something? Is it because you are replying from your gmail account?
Thanks -- Divesh Dutta www.hotwaxsystems.com On Fri, Jul 3, 2026 at 2:41 PM gaetan.chaboussie via dev < [email protected]> wrote: > Thanks Jacopo for such an elaborate answer. > > I don't think the subject can be addressed in a better way than the way > you did. > > I agree on every point. > > Regards, Gaetan > > On 7/2/26 12:46, Jacopo Cappellato wrote: > > 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 > >> >
