Hi Divesh, I always use my gmail account in these lists. Please check your email filters and/or your spam rules.
Regards, Jacopo On Fri, Jul 3, 2026 at 11:36 AM Divesh Dutta <[email protected]> wrote: > > 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 > > >> > >
