Contributors

Re: Guidelines for LLM generated contributions

On Fri, Sep 19, 2025, 5:22 AM Matthieu Mequignon <notifications@odoo-community.org> wrote:

Hi!

While I understand the concern and the need for compromise here (because I know this is going to happen, no matter what is decided), I'm gonna be «this guy»: I am totally against LLM generated contributions.

Regarding migrations, we already have great tools to facilitate developments, such as oca-port doing migrations in seconds.
I would be ok with community scripts doing the boring/automated changes, such as `tree` -> `list`, `_` -> `self.env._` etc…
From there, the remaining work is the hardest, and LLM can (at best) only assist.

The point is LLMs such as Claude

-Code or Gemini-CLI now use tools like bash tools. So you can instruct them to run oca-port as the start and do the remaing code adjustments to run the tests and even get the pre-commit green. So it'not anyone about using an LLMs alone.

You can also feed the AI context with OpenUpgrade analysis and scripts, the migration diffs of the dependency modules migrations and diffs such as

https://github.com/akretion/odoo-module-diff-analysis/tree/main

So at the end the LLM will have plenty of migration context and can do A LOT extremely fast.

I would say more and more that's you that will assist the AI and not the reverse...

About basic functional knowledge: well may be it's hard to admit but they have more functional ERP knowledge out of the box than most of Odoo developpers have...

And when you feed the LLM with the OCA code before aksing in the prompt, it can quickly "understand" what the code does. I would say the module authors still beat it, but if you are not the author/main contributor, chances are the LLM will "understand" the modules details quicker than you (disclaimer: you really need to pass the module code and its dependencies to the LLM for this go happen though otherwise yes you get mostly hallucinations).

About installing, screenshots etc: AI such as Gemini-CLI can run inside a Github action were Odoo is installed exactly like the OCA CI is. At the moment I run it in a virtualenv were I have my Odoo installed and it can run pytest-odoo untill it makes tests passes. I woukd say it's a matter of just a few months/weeks before we can have the screenshots of the changes from the LLM+tools directly (people using popular stacks like react have it already).

But meanwhile full human control and responsability is what I advocated for.

Also Gemini-CLI tends to work better than Claude Code because the Odoo codebase is huge so if you don't want the LLM to hallucinate you need to feed its context window with all the relevant Odoo/OCA code required. And with 1 millions tokens Gemini beats Claude and most other AI by a faire margin for Odoo. (Claude is only 256k tokens and just account/models from odoo/odoo will consume 350k tokens and max it out). I'll talk more about that in another thread.

At the end yes I think we should forbid lazy AI made PRs by people who just ask anything to chatGPT or similar tools without any testing/critical thinking.

But my point is: an OCA specialist with an LLM will do 10x more than what he does today with AI help and the same quality or better (yes it already really writes better code than you for the 50% of the easy code).

So when the entire industry is making the shift, when our customers will not expect you quote them 5 days for something that could now be done in 1 day, when they will not want to use an Odoo version lagging 2 or 3 versions behind and getting exponentially better, we will have to use AI or die. Like mechanical engineering now use computer simulation instead of only human calculus on sheets of paper.

In this context, it's easy to claim AI will not do it as good and boycott it entirely. But sadly that's simply not true.

Finally, about all the ethical and energy issues raised in other answers, yes I agree this is absolutely a major concern. I think we should act politically regarding this if it is even possible to avoid people would do the bad things and submit you from other countries/juridictions.

by Raphaël Akretion - 02:41 - 19 Sep 2025

Reference

Guidelines for LLM generated contributions

Dear all,

at least one contributor is planning again to flood the OCA projects 
with PRs for module migrations: https://github.com/OCA/web/issues/3285. 
This volume is likely made possible through automation, with an LLM 
generating the actual migration code (on top of, hopefully, a more 
deterministic tool like OCA's odoo-module-migrator).

Regardless of the volume and the submitter, if the submitter has 
reviewed, refined and tested the code generated by an LLM, this should 
not be a problem but as a reviewer I'd like to know what I can expect. 
Holger Brunn pointed out to me that in other projects, this may be 
covered by a demand in the guidelines to disclose LLM usage and its 
extend. For an example, see 
https://github.com/ghostty-org/ghostty/pull/8289/files.

I would very much like to see such an addition to the OCA guidelines. 
Additionally, I would like to suggest that the basic premise (the 
generated code is indeed first self-reviewed, refined and tested) is 
also made explicit, and that it is unacceptable to pass on reviewer 
comments to the LLM only to copy back the LLM's response (which has 
happened to me on one or two occassions).

Can I have a temperature check for your support for such an addition to 
the guidelines? Or do you have other ideas or perspectives on the matter?

Cheers,
Stefan


-- 
Opener B.V. - Business solutions driven by open source collaboration

Stefan Rijnhart - Consultant/developer

mail:stefan@opener.amsterdam
tel: +31 (0) 6 1447 8606
web:https://opener.amsterdam

by Stefan Rijnhart - 09:40 - 18 Sep 2025

32 replies 32 replies

RE: Guidelines for LLM generated contributions
Thanks Stuart for the decent & constructive reply.

Copyright is indeed an issue industry wise, as you mentioned, with many lawsuits in place but no clear direction. This is due to how LLM models are trained and how data converted into tokens, relations, and weights and stored into multi-dimensional vector space. Certain paths may represent a piece of copyrighted artifact.

Yes, I do supervise my AI agents very strictly. Vibe coding, or whatever they call it, does not work in writing code for Odoo or any enterprise/ERP level codebase. In such complex codebase best is to treat AI agent as normal employees flow, keeping a human at last step is a must. It is crazy to see an LLM getting lazy like if it is the last hour before weekend, but it happened many times. Since those AI Agents are trained using humans data/traces, it includes good and bad behaviors and it requires some skills similar to managing normal team.

I do respect and admire OCA brand very much and I know code quality is very high in general. It is not easy to get a module into OCA repository. OCA guidelines & policies are really rail guarding the quality and the brand.

I think of LLM-OCA subject as two parts: 1) list of concerns and clarifications that would result into guidelines & policies, 2) AI tools and their usage. Even though there are many AI tools/agents but the ones that can really work in such codebase are very few.

It is my pleasure to be part of it, it is always a joy to contribute.

Sincerely,

Hussain H.

From: Stuart J Mackintosh <notifications@odoo-community.org>
Sent: Thursday, October 9, 2025 7:18 PM
To: Contributors <contributors@odoo-community.org>
Subject: Re: Guidelines for LLM generated contributions

Thank you for your comments. Indeed we must not overlook the opportunities with automation however there are still issues unresolved (across industry) such as - if you use automated tools to create code, which was based on training code, and that was under AGPL, must you also apply AGPL terms? You certainly couldn't use AI as a filter to republish AGPL code as MIT for example.

Ask your AI what rights you have to the code it creates for you - it is easy tl lead it to assuring you that the code is ok, but ask explicitly if it is safe to publish under MIT licence.

In your case, it looks that you are supervising AI, but not everyone is as responsible, and abdication of responsibility is very different to delegating, and it takes quite some effort to keep up with moderating code at the speed and volume that it can be generated.

Transparency is essential, and for any OCA code, guidance & policy are prerequisite so as to not dilute the brand.

Hopefully we will get together sometime soon to consider the various points and outline the key criteria.

Best wishes,

Stuart.

On 09/10/2025 10:22, Hussain Hammad wrote:

Hi All,

I’ve seen this subject “AI Usage” opened few times in mailing list but every time I see the same problem repeated. I think the main point is very missed in this area, starting from terminology and semantic to what is used and how. I’m not touching on people technical skills here, I’m touching on experience in AI arena. Who have first-hand experience in this area to clarify things and explain, in Odoo not other technology. Who can contribute in this knowledge level-up. Who can answer those concerns. I’m not talking about visionaries, I’m talking about first-hand users AI+Odoo.

Proper decision comes from facts and understanding these facts.

I believe we need to level up OCA (Management, Members, Contributors…etc) knowledge about the subject before thinking about policy and/or adaption, otherwise decisions might harm more than benefit.

Why I’m raising this concern? We at OCA are late already in this subject. For someone like me, and many others, who breath code daily we cannot imagine not writing code for months. Believe it or not, in last 6 months I have not written a single line of code. It is more of architecting, code review, refactor, fine-tune, QC then production. AI tools are your team, managing it is on you. Bad players should not prevent us from adaption, same measures for bad player existed prior to AI time.

I’m welling to do a session about it internally for OCA, or whatever OCA sees as good start to really open this subject. A list of questions and concerns can be answered as well, coordinated by OCA.

Sincerely,

Hussain Hammad | Solutions Unity Co.
6957 Abdullah Bin Harith Street, Shati District

Tarout 32617, Saudi Arabia

+966 56 963 4488
hussain@solutionsunity.com

www.solutionsunity.com

From: Joël Grand-Guillaume <notifications@odoo-community.org>
Sent: Monday, September 29, 2025 10:27 AM
To: Contributors <contributors@odoo-community.org>
Subject: Re: Guidelines for LLM generated contributions

...

Whatever the case, transparency is essential, and omitting this will cause many problems such as compliance with the the new EU regulation which will activate in under 2 years.

+1 - Transparency is key in this first steps - this will maintain trust.

What's the action now - as Frederik proposed, a working group should pick this up, process the views of the community and define a policy based on consensus. This will continue to evolve so I don't think trying to nail it all down now is practical with this dynamic factored in.

+1 to have the governance working group leading this topic

Best wishes,

Stuart.

On 27/09/2025 15:07, Raphaël Valyi wrote:

Hello,

I think IA policies and risks/benefits may vary a lot depending on the use cases...

The thread was initially started about migrations. This is really a use case where IA can bring a lot of benefits with very limited risks. Indeed, recent migrations are very easy for most modules. We could have a huge benefit if we could get 1000+ modules easily migrated (with possible AI automated ports), using standard OCA tools and letting the AI adjust the tests and pre-commit considering the framework and upstream modules changes in the context window. As Graeme explained, these simple migrations usually involves no creative work nor copyright issues.

As for generating larger pieces of new modules/vibe coding, well of course there would be more things to care about, like copyrights, quality control etc...

Some projects like Qemu recently banned IA completely because they fear large pieces of contributed IA code may infringe copyrights (the LLM would kind of replicated copyrighted code without enforcing licenses) and taint the whole project. This is definitely something we should pay attention to.

For instance if the AI is trained on Odoo Enterprise code (or just even just in the context window) and new similar code is generated it could taint the OCA code. On the contrary it is also entirely possible AI could very soon replicate many EE module or ERP feature just from the UI/specs without infringing any copyright (Odoo tends to copy other apps from their UI, AI could soon do it too...)

But more importantly, there is no need for AGI nor phD level AI for AI (probably an OpenAI/Anthropic bubble) to change completely the software industry. The current level of LLMs with lowering costs is far enough to raise many concerns how code is made and more importantly how open source communities like us are organized.

As Daniel explained, AI may of course multiply toxic or spam behavior and we should hold AI users responsible for it.

But I think it is also very important to consider this: as many open source communities, the whole OCA was organized as a meritocracy where ability to create proper code and ERP knowledge was earned after many years of seniority and acknowledged as such. Despite ocasional disputes, modules authors, repo PSCs and all our OCA decision process is kind if naturally structured atop of this "traditional" coding and ERP expertise. merged code was kind of our "proof of work" in our pre-IA world.

But AI will soon bring us to a world were an LLM will be more knowledgeable than senior ERP consultants and only top coders will be able to add any value over AI generated code. Good coders with access to compute will also be able to generate or maintain orders of magnitude more code. Bad coders with bad intentions will also be able to flood the OCA with poor quality contributions and the average person will not be able/not have time to filter the good options. In this is world that is coming in just a few months, how will we be able to maintain trust and organization? IMHO this should be a top concern for the OCA.

Finally, for more than a decade, the business model behind the OCA was kind of: in traditional ERPs 70% of the cost is from consulting/customization and 30% from licenses. So some alien skilled people able to do both the code and the consulting (or small companies able to do both) would charge the 70% and use that revenue produce the ERP code free of license charges. That was working because non specialists would typically not be able simply download open source code and do their ERP project alone. So companies would somehwat hire module authors, pay the 70% consulting/customization cost and with limited parasistism, the ecosystem could somehow sustain itself.

But soon the expertise to use OCA modules will drop a lot. The AI will bring it to the user directly bypassing modules authors and contributors entirely...

How will our open source economy work in this context? Well an option I see is use AI on our side: manage order of magnitude more code and more customers for a fraction of the cost... Now, I'm almost certain if we simply reject the IA entirety, then yes, it won't take long before we are made completely obsolete.

On Sat, Sep 27, 2025, 4:47 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:

Indeed - it would be of benefit for OCA to have a position.

Best wishes,

Stuart.

On 27/09/2025 09:27, Frederik Kramer wrote:

Hi Stuart, hi all,

very valuable for decision making but I think within our community we have people thinking as strict as Gentoo, NetBSD on the matter and others that would rather adopt the stance of the Linux or Apache Foundation. So possibly the board / governance/community health WGs shall come up with a decision proposal along these lines and ask for a solid quorum in the next AGA.

Best Frederik

Am 26. September 2025 08:42:39 MESZ schrieb Stuart J Mackintosh <notifications@odoo-community.org>:

Following up and to take a look at how others have dealt with these matters, I noticed Fedora released an AI policy yesterday so I have briefly summarised (perplexity) this compared with a bunch of other policies, full analysis here: https://codimd.mackintosh.me/s/ifsByh-G8#

Brief overview of policies:

- The main goal is to blend innovation with strong safeguards—using AI tools to help, but keeping people fully responsible for results.
- Most projects see transparency as crucial for maintaining trust and enabling fair review and collaboration.
- Quality control and copyright protection are prioritized: automation should not dilute standards nor introduce legal risk.
- Some policies are stricter, fully banning AI output unless human-vetted and legally certified.
- Clause implementation mostly revolves around commit messages, contributor guidelines, and reviewed workflow steps—simple, actionable, easy to follow.

This format ensures contributors know where, when, and how AI use is welcomed—and where human effort and discretion are absolutely required.

Best wishes,

Stuart.

On 24/09/2025 11:01, Stuart J Mackintosh wrote:

I propose that you address these points through the mechanism proposed by Daniel - responsible use, and behavioural guidance alongside a code of conduct which can determine obligations such as disclosure of AI use; Ai is just one of a set of issues that must be addressed.

Best wishes,

Stuart.

On 24/09/2025 10:47, Graeme Gellatly wrote:

I disagree. If you are holding yourself out as a professional you should declare AI usage and the scope.   Declaring AI usage is mandated for my profession, if I prepare any advice or report in a professional capacity I must declare. It is just not an option to say, oh well it is just a tool, when it really isn't, it directly created output.

It also gives valuable information to both the reviewer and ultimately the users.

It is also important from a copyright perspective. There is no copyright in a lot of AI generated work without later creative human input and even then only the human inputs are usually covered. To be fair there is also no copyright in a lot of human generated output (i.e. bug fixes and migrations) as there is no creative output, so for that kind of work AI is actually ideal. Ref https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf

On Tue, Sep 23, 2025 at 8:27 PM Daniel Reis <notifications@odoo-community.org> wrote:

Hello all,

It begs the question of what is "AI generated code".
AI can assist code writing from code completion suggestions, to full design and code writing.
Or just assist with code reviews or issue resolution, without writing code.

In the end AI is just a tool.
Irresponsible use can happen with AI or any other automation tool.

What really matters is the behavior of people using these tools.
I feel that we might need a guideline regarding responsible use of automated tools, including AI, rather than specifically for AI use.
This could be fitted into a code of conduct for the community.

Thanks
Daniel

On 18/09/2025 08:41, Stefan Rijnhart wrote:

Dear all,

at least one contributor is planning again to flood the OCA projects

with PRs for module migrations: https://github.com/OCA/web/issues/3285.

This volume is likely made possible through automation, with an LLM

generating the actual migration code (on top of, hopefully, a more

deterministic tool like OCA's odoo-module-migrator).

Regardless of the volume and the submitter, if the submitter has

reviewed, refined and tested the code generated by an LLM, this should

not be a problem but as a reviewer I'd like to know what I can expect.

Holger Brunn pointed out to me that in other projects, this may be

covered by a demand in the guidelines to disclose LLM usage and its

extend. For an example, see

https://github.com/ghostty-org/ghostty/pull/8289/files.

I would very much like to see such an addition to the OCA guidelines.

Additionally, I would like to suggest that the basic premise (the

generated code is indeed first self-reviewed, refined and tested) is

also made explicit, and that it is unacceptable to pass on reviewer

comments to the LLM only to copy back the LLM's response (which has

happened to me on one or two occassions).

Can I have a temperature check for your support for such an addition to

the guidelines? Or do you have other ideas or perspectives on the matter?

Cheers,

Stefan

--

Opener B.V. - Business solutions driven by open source collaboration

Stefan Rijnhart - Consultant/developer

mail:stefan@opener.amsterdam

tel: +31 (0) 6 1447 8606

web:https://opener.amsterdam

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

DANIEL REIS
MANAGING PARTNER

>> Schedule time on my calendar.
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Phone: +49 4181 13503-12
Fax:    +49 4181 13503-10
Mobil: +49 179 3901819

Email: frederik.kramer@initos.com
Web:   www.initos.com

Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Hussain Hammad - 04:26 - 11 Oct 2025

Re: Guidelines for LLM generated contributions

Thank you for your comments. Indeed we must not overlook the opportunities with automation however there are still issues unresolved (across industry) such as - if you use automated tools to create code, which was based on training code, and that was under AGPL, must you also apply AGPL terms? You certainly couldn't use AI as a filter to republish AGPL code as MIT for example.

Ask your AI what rights you have to the code it creates for you - it is easy tl lead it to assuring you that the code is ok, but ask explicitly if it is safe to publish under MIT licence.

In your case, it looks that you are supervising AI, but not everyone is as responsible, and abdication of responsibility is very different to delegating, and it takes quite some effort to keep up with moderating code at the speed and volume that it can be generated.

Transparency is essential, and for any OCA code, guidance & policy are prerequisite so as to not dilute the brand.

Hopefully we will get together sometime soon to consider the various points and outline the key criteria.

Best wishes,

Stuart.

On 09/10/2025 10:22, Hussain Hammad wrote:

Hi All,

I’ve seen this subject “AI Usage” opened few times in mailing list but every time I see the same problem repeated. I think the main point is very missed in this area, starting from terminology and semantic to what is used and how. I’m not touching on people technical skills here, I’m touching on experience in AI arena. Who have first-hand experience in this area to clarify things and explain, in Odoo not other technology. Who can contribute in this knowledge level-up. Who can answer those concerns. I’m not talking about visionaries, I’m talking about first-hand users AI+Odoo.

Proper decision comes from facts and understanding these facts.

I believe we need to level up OCA (Management, Members, Contributors…etc) knowledge about the subject before thinking about policy and/or adaption, otherwise decisions might harm more than benefit.

Why I’m raising this concern? We at OCA are late already in this subject. For someone like me, and many others, who breath code daily we cannot imagine not writing code for months. Believe it or not, in last 6 months I have not written a single line of code. It is more of architecting, code review, refactor, fine-tune, QC then production. AI tools are your team, managing it is on you. Bad players should not prevent us from adaption, same measures for bad player existed prior to AI time.

I’m welling to do a session about it internally for OCA, or whatever OCA sees as good start to really open this subject. A list of questions and concerns can be answered as well, coordinated by OCA.

Sincerely,

Hussain Hammad | Solutions Unity Co.
6957 Abdullah Bin Harith Street, Shati District

Tarout 32617, Saudi Arabia

+966 56 963 4488
hussain@solutionsunity.com

www.solutionsunity.com

From: Joël Grand-Guillaume <notifications@odoo-community.org>
Sent: Monday, September 29, 2025 10:27 AM
To: Contributors <contributors@odoo-community.org>
Subject: Re: Guidelines for LLM generated contributions
...

Whatever the case, transparency is essential, and omitting this will cause many problems such as compliance with the the new EU regulation which will activate in under 2 years.

+1 - Transparency is key in this first steps - this will maintain trust.

What's the action now - as Frederik proposed, a working group should pick this up, process the views of the community and define a policy based on consensus. This will continue to evolve so I don't think trying to nail it all down now is practical with this dynamic factored in.

+1 to have the governance working group leading this topic
Best wishes,

Stuart.

On 27/09/2025 15:07, Raphaël Valyi wrote:
Hello,

I think IA policies and risks/benefits may vary a lot depending on the use cases...

The thread was initially started about migrations. This is really a use case where IA can bring a lot of benefits with very limited risks. Indeed, recent migrations are very easy for most modules. We could have a huge benefit if we could get 1000+ modules easily migrated (with possible AI automated ports), using standard OCA tools and letting the AI adjust the tests and pre-commit considering the framework and upstream modules changes in the context window. As Graeme explained, these simple migrations usually involves no creative work nor copyright issues.

As for generating larger pieces of new modules/vibe coding, well of course there would be more things to care about, like copyrights, quality control etc...

Some projects like Qemu recently banned IA completely because they fear large pieces of contributed IA code may infringe copyrights (the LLM would kind of replicated copyrighted code without enforcing licenses) and taint the whole project. This is definitely something we should pay attention to.

For instance if the AI is trained on Odoo Enterprise code (or just even just in the context window) and new similar code is generated it could taint the OCA code. On the contrary it is also entirely possible AI could very soon replicate many EE module or ERP feature just from the UI/specs without infringing any copyright (Odoo tends to copy other apps from their UI, AI could soon do it too...)

But more importantly, there is no need for AGI nor phD level AI for AI (probably an OpenAI/Anthropic bubble) to change completely the software industry. The current level of LLMs with lowering costs is far enough to raise many concerns how code is made and more importantly how open source communities like us are organized.

As Daniel explained, AI may of course multiply toxic or spam behavior and we should hold AI users responsible for it.

But I think it is also very important to consider this: as many open source communities, the whole OCA was organized as a meritocracy where ability to create proper code and ERP knowledge was earned after many years of seniority and acknowledged as such. Despite ocasional disputes, modules authors, repo PSCs and all our OCA decision process is kind if naturally structured atop of this "traditional" coding and ERP expertise. merged code was kind of our "proof of work" in our pre-IA world.

But AI will soon bring us to a world were an LLM will be more knowledgeable than senior ERP consultants and only top coders will be able to add any value over AI generated code. Good coders with access to compute will also be able to generate or maintain orders of magnitude more code. Bad coders with bad intentions will also be able to flood the OCA with poor quality contributions and the average person will not be able/not have time to filter the good options. In this is world that is coming in just a few months, how will we be able to maintain trust and organization? IMHO this should be a top concern for the OCA.

Finally, for more than a decade, the business model behind the OCA was kind of: in traditional ERPs 70% of the cost is from consulting/customization and 30% from licenses. So some alien skilled people able to do both the code and the consulting (or small companies able to do both) would charge the 70% and use that revenue produce the ERP code free of license charges. That was working because non specialists would typically not be able simply download open source code and do their ERP project alone. So companies would somehwat hire module authors, pay the 70% consulting/customization cost and with limited parasistism, the ecosystem could somehow sustain itself.

But soon the expertise to use OCA modules will drop a lot. The AI will bring it to the user directly bypassing modules authors and contributors entirely...

How will our open source economy work in this context? Well an option I see is use AI on our side: manage order of magnitude more code and more customers for a fraction of the cost... Now, I'm almost certain if we simply reject the IA entirety, then yes, it won't take long before we are made completely obsolete.
On Sat, Sep 27, 2025, 4:47 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:
Indeed - it would be of benefit for OCA to have a position.

Best wishes,

Stuart.

On 27/09/2025 09:27, Frederik Kramer wrote:
Hi Stuart, hi all,

very valuable for decision making but I think within our community we have people thinking as strict as Gentoo, NetBSD on the matter and others that would rather adopt the stance of the Linux or Apache Foundation. So possibly the board / governance/community health WGs shall come up with a decision proposal along these lines and ask for a solid quorum in the next AGA.

Best Frederik
Am 26. September 2025 08:42:39 MESZ schrieb Stuart J Mackintosh <notifications@odoo-community.org>:
Following up and to take a look at how others have dealt with these matters, I noticed Fedora released an AI policy yesterday so I have briefly summarised (perplexity) this compared with a bunch of other policies, full analysis here: https://codimd.mackintosh.me/s/ifsByh-G8#

Brief overview of policies:

- The main goal is to blend innovation with strong safeguards—using AI tools to help, but keeping people fully responsible for results.
- Most projects see transparency as crucial for maintaining trust and enabling fair review and collaboration.
- Quality control and copyright protection are prioritized: automation should not dilute standards nor introduce legal risk.
- Some policies are stricter, fully banning AI output unless human-vetted and legally certified.
- Clause implementation mostly revolves around commit messages, contributor guidelines, and reviewed workflow steps—simple, actionable, easy to follow.

This format ensures contributors know where, when, and how AI use is welcomed—and where human effort and discretion are absolutely required.

Best wishes,

Stuart.

On 24/09/2025 11:01, Stuart J Mackintosh wrote:
I propose that you address these points through the mechanism proposed by Daniel - responsible use, and behavioural guidance alongside a code of conduct which can determine obligations such as disclosure of AI use; Ai is just one of a set of issues that must be addressed.

Best wishes,

Stuart.

On 24/09/2025 10:47, Graeme Gellatly wrote:
I disagree. If you are holding yourself out as a professional you should declare AI usage and the scope. Declaring AI usage is mandated for my profession, if I prepare any advice or report in a professional capacity I must declare. It is just not an option to say, oh well it is just a tool, when it really isn't, it directly created output.

It also gives valuable information to both the reviewer and ultimately the users.

It is also important from a copyright perspective. There is no copyright in a lot of AI generated work without later creative human input and even then only the human inputs are usually covered. To be fair there is also no copyright in a lot of human generated output (i.e. bug fixes and migrations) as there is no creative output, so for that kind of work AI is actually ideal. Ref https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf
On Tue, Sep 23, 2025 at 8:27 PM Daniel Reis <notifications@odoo-community.org> wrote:
Hello all,

It begs the question of what is "AI generated code".
AI can assist code writing from code completion suggestions, to full design and code writing.
Or just assist with code reviews or issue resolution, without writing code.

In the end AI is just a tool.
Irresponsible use can happen with AI or any other automation tool.

What really matters is the behavior of people using these tools.
I feel that we might need a guideline regarding responsible use of automated tools, including AI, rather than specifically for AI use.
This could be fitted into a code of conduct for the community.

Thanks
Daniel

On 18/09/2025 08:41, Stefan Rijnhart wrote:
Dear all,
 
at least one contributor is planning again to flood the OCA projects 
with PRs for module migrations: https://github.com/OCA/web/issues/3285. 
This volume is likely made possible through automation, with an LLM 
generating the actual migration code (on top of, hopefully, a more 
deterministic tool like OCA's odoo-module-migrator).
 
Regardless of the volume and the submitter, if the submitter has 
reviewed, refined and tested the code generated by an LLM, this should 
not be a problem but as a reviewer I'd like to know what I can expect. 
Holger Brunn pointed out to me that in other projects, this may be 
covered by a demand in the guidelines to disclose LLM usage and its 
extend. For an example, see 
https://github.com/ghostty-org/ghostty/pull/8289/files.
 
I would very much like to see such an addition to the OCA guidelines. 
Additionally, I would like to suggest that the basic premise (the 
generated code is indeed first self-reviewed, refined and tested) is 
also made explicit, and that it is unacceptable to pass on reviewer 
comments to the LLM only to copy back the LLM's response (which has 
happened to me on one or two occassions).
 
Can I have a temperature check for your support for such an addition to 
the guidelines? Or do you have other ideas or perspectives on the matter?
 
Cheers,
Stefan
 
 
 
 
 
-- 
Opener B.V. - Business solutions driven by open source collaboration
 
Stefan Rijnhart - Consultant/developer
 
mail:stefan@opener.amsterdam
tel: +31 (0) 6 1447 8606
web:https://opener.amsterdam
 
 
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--

DANIEL REIS
MANAGING PARTNER

>> Schedule time on my calendar.
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Phone: +49 4181 13503-12
Fax:    +49 4181 13503-10
Mobil: +49 179 3901819

Email: frederik.kramer@initos.com
Web:   www.initos.com

Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

Open Digital Consulting Co Logo

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

by Stuart J Mackintosh - 06:16 - 9 Oct 2025

1 attachments 1 attachments

RE: Guidelines for LLM generated contributions
Hi All,

I’ve seen this subject “AI Usage” opened few times in mailing list but every time I see the same problem repeated. I think the main point is very missed in this area, starting from terminology and semantic to what is used and how. I’m not touching on people technical skills here, I’m touching on experience in AI arena. Who have first-hand experience in this area to clarify things and explain, in Odoo not other technology. Who can contribute in this knowledge level-up. Who can answer those concerns. I’m not talking about visionaries, I’m talking about first-hand users AI+Odoo.

Proper decision comes from facts and understanding these facts.

I believe we need to level up OCA (Management, Members, Contributors…etc) knowledge about the subject before thinking about policy and/or adaption, otherwise decisions might harm more than benefit.

Why I’m raising this concern? We at OCA are late already in this subject. For someone like me, and many others, who breath code daily we cannot imagine not writing code for months. Believe it or not, in last 6 months I have not written a single line of code. It is more of architecting, code review, refactor, fine-tune, QC then production. AI tools are your team, managing it is on you. Bad players should not prevent us from adaption, same measures for bad player existed prior to AI time.

I’m welling to do a session about it internally for OCA, or whatever OCA sees as good start to really open this subject. A list of questions and concerns can be answered as well, coordinated by OCA.

Sincerely,

Hussain Hammad | Solutions Unity Co.
6957 Abdullah Bin Harith Street, Shati District

Tarout 32617, Saudi Arabia

+966 56 963 4488
hussain@solutionsunity.com

www.solutionsunity.com

From: Joël Grand-Guillaume <notifications@odoo-community.org>
Sent: Monday, September 29, 2025 10:27 AM
To: Contributors <contributors@odoo-community.org>
Subject: Re: Guidelines for LLM generated contributions

...

Whatever the case, transparency is essential, and omitting this will cause many problems such as compliance with the the new EU regulation which will activate in under 2 years.

+1 - Transparency is key in this first steps - this will maintain trust.

What's the action now - as Frederik proposed, a working group should pick this up, process the views of the community and define a policy based on consensus. This will continue to evolve so I don't think trying to nail it all down now is practical with this dynamic factored in.

+1 to have the governance working group leading this topic

Best wishes,

Stuart.

On 27/09/2025 15:07, Raphaël Valyi wrote:

Hello,

I think IA policies and risks/benefits may vary a lot depending on the use cases...

The thread was initially started about migrations. This is really a use case where IA can bring a lot of benefits with very limited risks. Indeed, recent migrations are very easy for most modules. We could have a huge benefit if we could get 1000+ modules easily migrated (with possible AI automated ports), using standard OCA tools and letting the AI adjust the tests and pre-commit considering the framework and upstream modules changes in the context window. As Graeme explained, these simple migrations usually involves no creative work nor copyright issues.

As for generating larger pieces of new modules/vibe coding, well of course there would be more things to care about, like copyrights, quality control etc...

Some projects like Qemu recently banned IA completely because they fear large pieces of contributed IA code may infringe copyrights (the LLM would kind of replicated copyrighted code without enforcing licenses) and taint the whole project. This is definitely something we should pay attention to.

For instance if the AI is trained on Odoo Enterprise code (or just even just in the context window) and new similar code is generated it could taint the OCA code. On the contrary it is also entirely possible AI could very soon replicate many EE module or ERP feature just from the UI/specs without infringing any copyright (Odoo tends to copy other apps from their UI, AI could soon do it too...)

But more importantly, there is no need for AGI nor phD level AI for AI (probably an OpenAI/Anthropic bubble) to change completely the software industry. The current level of LLMs with lowering costs is far enough to raise many concerns how code is made and more importantly how open source communities like us are organized.

As Daniel explained, AI may of course multiply toxic or spam behavior and we should hold AI users responsible for it.

But I think it is also very important to consider this: as many open source communities, the whole OCA was organized as a meritocracy where ability to create proper code and ERP knowledge was earned after many years of seniority and acknowledged as such. Despite ocasional disputes, modules authors, repo PSCs and all our OCA decision process is kind if naturally structured atop of this "traditional" coding and ERP expertise. merged code was kind of our "proof of work" in our pre-IA world.

But AI will soon bring us to a world were an LLM will be more knowledgeable than senior ERP consultants and only top coders will be able to add any value over AI generated code. Good coders with access to compute will also be able to generate or maintain orders of magnitude more code. Bad coders with bad intentions will also be able to flood the OCA with poor quality contributions and the average person will not be able/not have time to filter the good options. In this is world that is coming in just a few months, how will we be able to maintain trust and organization? IMHO this should be a top concern for the OCA.

Finally, for more than a decade, the business model behind the OCA was kind of: in traditional ERPs 70% of the cost is from consulting/customization and 30% from licenses. So some alien skilled people able to do both the code and the consulting (or small companies able to do both) would charge the 70% and use that revenue produce the ERP code free of license charges. That was working because non specialists would typically not be able simply download open source code and do their ERP project alone. So companies would somehwat hire module authors, pay the 70% consulting/customization cost and with limited parasistism, the ecosystem could somehow sustain itself.

But soon the expertise to use OCA modules will drop a lot. The AI will bring it to the user directly bypassing modules authors and contributors entirely...

How will our open source economy work in this context? Well an option I see is use AI on our side: manage order of magnitude more code and more customers for a fraction of the cost... Now, I'm almost certain if we simply reject the IA entirety, then yes, it won't take long before we are made completely obsolete.

On Sat, Sep 27, 2025, 4:47 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:

Indeed - it would be of benefit for OCA to have a position.

Best wishes,

Stuart.

On 27/09/2025 09:27, Frederik Kramer wrote:

Hi Stuart, hi all,

very valuable for decision making but I think within our community we have people thinking as strict as Gentoo, NetBSD on the matter and others that would rather adopt the stance of the Linux or Apache Foundation. So possibly the board / governance/community health WGs shall come up with a decision proposal along these lines and ask for a solid quorum in the next AGA.

Best Frederik

Am 26. September 2025 08:42:39 MESZ schrieb Stuart J Mackintosh <notifications@odoo-community.org>:

Following up and to take a look at how others have dealt with these matters, I noticed Fedora released an AI policy yesterday so I have briefly summarised (perplexity) this compared with a bunch of other policies, full analysis here: https://codimd.mackintosh.me/s/ifsByh-G8#

Brief overview of policies:

- The main goal is to blend innovation with strong safeguards—using AI tools to help, but keeping people fully responsible for results.
- Most projects see transparency as crucial for maintaining trust and enabling fair review and collaboration.
- Quality control and copyright protection are prioritized: automation should not dilute standards nor introduce legal risk.
- Some policies are stricter, fully banning AI output unless human-vetted and legally certified.
- Clause implementation mostly revolves around commit messages, contributor guidelines, and reviewed workflow steps—simple, actionable, easy to follow.

This format ensures contributors know where, when, and how AI use is welcomed—and where human effort and discretion are absolutely required.

Best wishes,

Stuart.

On 24/09/2025 11:01, Stuart J Mackintosh wrote:

I propose that you address these points through the mechanism proposed by Daniel - responsible use, and behavioural guidance alongside a code of conduct which can determine obligations such as disclosure of AI use; Ai is just one of a set of issues that must be addressed.

Best wishes,

Stuart.

On 24/09/2025 10:47, Graeme Gellatly wrote:

I disagree. If you are holding yourself out as a professional you should declare AI usage and the scope.   Declaring AI usage is mandated for my profession, if I prepare any advice or report in a professional capacity I must declare. It is just not an option to say, oh well it is just a tool, when it really isn't, it directly created output.

It also gives valuable information to both the reviewer and ultimately the users.

It is also important from a copyright perspective. There is no copyright in a lot of AI generated work without later creative human input and even then only the human inputs are usually covered. To be fair there is also no copyright in a lot of human generated output (i.e. bug fixes and migrations) as there is no creative output, so for that kind of work AI is actually ideal. Ref https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf

On Tue, Sep 23, 2025 at 8:27 PM Daniel Reis <notifications@odoo-community.org> wrote:

Hello all,

It begs the question of what is "AI generated code".
AI can assist code writing from code completion suggestions, to full design and code writing.
Or just assist with code reviews or issue resolution, without writing code.

In the end AI is just a tool.
Irresponsible use can happen with AI or any other automation tool.

What really matters is the behavior of people using these tools.
I feel that we might need a guideline regarding responsible use of automated tools, including AI, rather than specifically for AI use.
This could be fitted into a code of conduct for the community.

Thanks
Daniel

On 18/09/2025 08:41, Stefan Rijnhart wrote:

Dear all,

at least one contributor is planning again to flood the OCA projects

with PRs for module migrations: https://github.com/OCA/web/issues/3285.

This volume is likely made possible through automation, with an LLM

generating the actual migration code (on top of, hopefully, a more

deterministic tool like OCA's odoo-module-migrator).

Regardless of the volume and the submitter, if the submitter has

reviewed, refined and tested the code generated by an LLM, this should

not be a problem but as a reviewer I'd like to know what I can expect.

Holger Brunn pointed out to me that in other projects, this may be

covered by a demand in the guidelines to disclose LLM usage and its

extend. For an example, see

https://github.com/ghostty-org/ghostty/pull/8289/files.

I would very much like to see such an addition to the OCA guidelines.

Additionally, I would like to suggest that the basic premise (the

generated code is indeed first self-reviewed, refined and tested) is

also made explicit, and that it is unacceptable to pass on reviewer

comments to the LLM only to copy back the LLM's response (which has

happened to me on one or two occassions).

Can I have a temperature check for your support for such an addition to

the guidelines? Or do you have other ideas or perspectives on the matter?

Cheers,

Stefan

--

Opener B.V. - Business solutions driven by open source collaboration

Stefan Rijnhart - Consultant/developer

mail:stefan@opener.amsterdam

tel: +31 (0) 6 1447 8606

web:https://opener.amsterdam

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

DANIEL REIS
MANAGING PARTNER

>> Schedule time on my calendar.
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Phone: +49 4181 13503-12
Fax:    +49 4181 13503-10
Mobil: +49 179 3901819

Email: frederik.kramer@initos.com
Web:   www.initos.com

Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Hussain Hammad - 10:21 - 9 Oct 2025

1 attachments 1 attachments

image001.png
Re: Guidelines for LLM generated contributions
...

Whatever the case, transparency is essential, and omitting this will cause many problems such as compliance with the the new EU regulation which will activate in under 2 years.
+1 - Transparency is key in this first steps - this will maintain trust.

What's the action now - as Frederik proposed, a working group should pick this up, process the views of the community and define a policy based on consensus. This will continue to evolve so I don't think trying to nail it all down now is practical with this dynamic factored in.
+1 to have the governance working group leading this topic

Best wishes,

Stuart.

On 27/09/2025 15:07, Raphaël Valyi wrote:

Hello,

I think IA policies and risks/benefits may vary a lot depending on the use cases...

The thread was initially started about migrations. This is really a use case where IA can bring a lot of benefits with very limited risks. Indeed, recent migrations are very easy for most modules. We could have a huge benefit if we could get 1000+ modules easily migrated (with possible AI automated ports), using standard OCA tools and letting the AI adjust the tests and pre-commit considering the framework and upstream modules changes in the context window. As Graeme explained, these simple migrations usually involves no creative work nor copyright issues.

As for generating larger pieces of new modules/vibe coding, well of course there would be more things to care about, like copyrights, quality control etc...

Some projects like Qemu recently banned IA completely because they fear large pieces of contributed IA code may infringe copyrights (the LLM would kind of replicated copyrighted code without enforcing licenses) and taint the whole project. This is definitely something we should pay attention to.

For instance if the AI is trained on Odoo Enterprise code (or just even just in the context window) and new similar code is generated it could taint the OCA code. On the contrary it is also entirely possible AI could very soon replicate many EE module or ERP feature just from the UI/specs without infringing any copyright (Odoo tends to copy other apps from their UI, AI could soon do it too...)

But more importantly, there is no need for AGI nor phD level AI for AI (probably an OpenAI/Anthropic bubble) to change completely the software industry. The current level of LLMs with lowering costs is far enough to raise many concerns how code is made and more importantly how open source communities like us are organized.

As Daniel explained, AI may of course multiply toxic or spam behavior and we should hold AI users responsible for it.

But I think it is also very important to consider this: as many open source communities, the whole OCA was organized as a meritocracy where ability to create proper code and ERP knowledge was earned after many years of seniority and acknowledged as such. Despite ocasional disputes, modules authors, repo PSCs and all our OCA decision process is kind if naturally structured atop of this "traditional" coding and ERP expertise. merged code was kind of our "proof of work" in our pre-IA world.

But AI will soon bring us to a world were an LLM will be more knowledgeable than senior ERP consultants and only top coders will be able to add any value over AI generated code. Good coders with access to compute will also be able to generate or maintain orders of magnitude more code. Bad coders with bad intentions will also be able to flood the OCA with poor quality contributions and the average person will not be able/not have time to filter the good options. In this is world that is coming in just a few months, how will we be able to maintain trust and organization? IMHO this should be a top concern for the OCA.

Finally, for more than a decade, the business model behind the OCA was kind of: in traditional ERPs 70% of the cost is from consulting/customization and 30% from licenses. So some alien skilled people able to do both the code and the consulting (or small companies able to do both) would charge the 70% and use that revenue produce the ERP code free of license charges. That was working because non specialists would typically not be able simply download open source code and do their ERP project alone. So companies would somehwat hire module authors, pay the 70% consulting/customization cost and with limited parasistism, the ecosystem could somehow sustain itself.

But soon the expertise to use OCA modules will drop a lot. The AI will bring it to the user directly bypassing modules authors and contributors entirely...

How will our open source economy work in this context? Well an option I see is use AI on our side: manage order of magnitude more code and more customers for a fraction of the cost... Now, I'm almost certain if we simply reject the IA entirety, then yes, it won't take long before we are made completely obsolete.

On Sat, Sep 27, 2025, 4:47 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:

Indeed - it would be of benefit for OCA to have a position.

Best wishes,

Stuart.

On 27/09/2025 09:27, Frederik Kramer wrote:

Hi Stuart, hi all,

very valuable for decision making but I think within our community we have people thinking as strict as Gentoo, NetBSD on the matter and others that would rather adopt the stance of the Linux or Apache Foundation. So possibly the board / governance/community health WGs shall come up with a decision proposal along these lines and ask for a solid quorum in the next AGA.

Best Frederik

Am 26. September 2025 08:42:39 MESZ schrieb Stuart J Mackintosh <notifications@odoo-community.org>:

Following up and to take a look at how others have dealt with these matters, I noticed Fedora released an AI policy yesterday so I have briefly summarised (perplexity) this compared with a bunch of other policies, full analysis here: https://codimd.mackintosh.me/s/ifsByh-G8#

Brief overview of policies:

- The main goal is to blend innovation with strong safeguards—using AI tools to help, but keeping people fully responsible for results.
- Most projects see transparency as crucial for maintaining trust and enabling fair review and collaboration.
- Quality control and copyright protection are prioritized: automation should not dilute standards nor introduce legal risk.
- Some policies are stricter, fully banning AI output unless human-vetted and legally certified.
- Clause implementation mostly revolves around commit messages, contributor guidelines, and reviewed workflow steps—simple, actionable, easy to follow.

This format ensures contributors know where, when, and how AI use is welcomed—and where human effort and discretion are absolutely required.

Best wishes,

Stuart.

On 24/09/2025 11:01, Stuart J Mackintosh wrote:

I propose that you address these points through the mechanism proposed by Daniel - responsible use, and behavioural guidance alongside a code of conduct which can determine obligations such as disclosure of AI use; Ai is just one of a set of issues that must be addressed.

Best wishes,

Stuart.

On 24/09/2025 10:47, Graeme Gellatly wrote:

I disagree. If you are holding yourself out as a professional you should declare AI usage and the scope.   Declaring AI usage is mandated for my profession, if I prepare any advice or report in a professional capacity I must declare. It is just not an option to say, oh well it is just a tool, when it really isn't, it directly created output.

It also gives valuable information to both the reviewer and ultimately the users.

It is also important from a copyright perspective. There is no copyright in a lot of AI generated work without later creative human input and even then only the human inputs are usually covered. To be fair there is also no copyright in a lot of human generated output (i.e. bug fixes and migrations) as there is no creative output, so for that kind of work AI is actually ideal. Ref https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf

On Tue, Sep 23, 2025 at 8:27 PM Daniel Reis <notifications@odoo-community.org> wrote:

Hello all,

It begs the question of what is "AI generated code".
AI can assist code writing from code completion suggestions, to full design and code writing.
Or just assist with code reviews or issue resolution, without writing code.

In the end AI is just a tool.
Irresponsible use can happen with AI or any other automation tool.

What really matters is the behavior of people using these tools.
I feel that we might need a guideline regarding responsible use of automated tools, including AI, rather than specifically for AI use.
This could be fitted into a code of conduct for the community.

Thanks
Daniel

On 18/09/2025 08:41, Stefan Rijnhart wrote:

Dear all, at least one contributor is planning again to flood the OCA projects with PRs for module migrations: https://github.com/OCA/web/issues/3285. This volume is likely made possible through automation, with an LLM generating the actual migration code (on top of, hopefully, a more deterministic tool like OCA's odoo-module-migrator). Regardless of the volume and the submitter, if the submitter has reviewed, refined and tested the code generated by an LLM, this should not be a problem but as a reviewer I'd like to know what I can expect. Holger Brunn pointed out to me that in other projects, this may be covered by a demand in the guidelines to disclose LLM usage and its extend. For an example, see https://github.com/ghostty-org/ghostty/pull/8289/files. I would very much like to see such an addition to the OCA guidelines. Additionally, I would like to suggest that the basic premise (the generated code is indeed first self-reviewed, refined and tested) is also made explicit, and that it is unacceptable to pass on reviewer comments to the LLM only to copy back the LLM's response (which has happened to me on one or two occassions). Can I have a temperature check for your support for such an addition to the guidelines? Or do you have other ideas or perspectives on the matter? Cheers, Stefan -- Opener B.V. - Business solutions driven by open source collaboration Stefan Rijnhart - Consultant/developer mail:stefan@opener.amsterdam tel: +31 (0) 6 1447 8606 web:https://opener.amsterdam

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

DANIEL REIS
MANAGING PARTNER
>> Schedule time on my calendar.
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Phone: +49 4181 13503-12
Fax:    +49 4181 13503-10
Mobil: +49 179 3901819

Email: frederik.kramer@initos.com
Web:   www.initos.com

Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Joël Grand Guillaume - 09:26 - 29 Sep 2025
Re: Guidelines for LLM generated contributions
How will our open source economy work in this context? Well an option I see is use AI on our side: manage order of magnitude more code and more customers for a fraction of the cost... Now, I'm almost certain if we simply reject the IA entirety, then yes, it won't take long before we are made completely obsolete.

Good points and well made - yes, this future is coming and OCA and community must be at the front of it.

I feel that a clear OCA position is important as without it, there is risk of collaborators working with different rules and assumptions which ultimately costs time and energy. So this is the opportunity for the community to work out what are the shared rules for this new world. If there is insufficient information owing to the rapidly changing landscape, then soft guidance may be the OCA position for now.

Whatever the case, transparency is essential, and omitting this will cause many problems such as compliance with the the new EU regulation which will activate in under 2 years.

What's the action now - as Frederik proposed, a working group should pick this up, process the views of the community and define a policy based on consensus. This will continue to evolve so I don't think trying to nail it all down now is practical with this dynamic factored in.

Best wishes,

Stuart.

On 27/09/2025 15:07, Raphaël Valyi wrote:

Hello,

I think IA policies and risks/benefits may vary a lot depending on the use cases...

The thread was initially started about migrations. This is really a use case where IA can bring a lot of benefits with very limited risks. Indeed, recent migrations are very easy for most modules. We could have a huge benefit if we could get 1000+ modules easily migrated (with possible AI automated ports), using standard OCA tools and letting the AI adjust the tests and pre-commit considering the framework and upstream modules changes in the context window. As Graeme explained, these simple migrations usually involves no creative work nor copyright issues.

As for generating larger pieces of new modules/vibe coding, well of course there would be more things to care about, like copyrights, quality control etc...

Some projects like Qemu recently banned IA completely because they fear large pieces of contributed IA code may infringe copyrights (the LLM would kind of replicated copyrighted code without enforcing licenses) and taint the whole project. This is definitely something we should pay attention to.

For instance if the AI is trained on Odoo Enterprise code (or just even just in the context window) and new similar code is generated it could taint the OCA code. On the contrary it is also entirely possible AI could very soon replicate many EE module or ERP feature just from the UI/specs without infringing any copyright (Odoo tends to copy other apps from their UI, AI could soon do it too...)

But more importantly, there is no need for AGI nor phD level AI for AI (probably an OpenAI/Anthropic bubble) to change completely the software industry. The current level of LLMs with lowering costs is far enough to raise many concerns how code is made and more importantly how open source communities like us are organized.

As Daniel explained, AI may of course multiply toxic or spam behavior and we should hold AI users responsible for it.

But I think it is also very important to consider this: as many open source communities, the whole OCA was organized as a meritocracy where ability to create proper code and ERP knowledge was earned after many years of seniority and acknowledged as such. Despite ocasional disputes, modules authors, repo PSCs and all our OCA decision process is kind if naturally structured atop of this "traditional" coding and ERP expertise. merged code was kind of our "proof of work" in our pre-IA world.

But AI will soon bring us to a world were an LLM will be more knowledgeable than senior ERP consultants and only top coders will be able to add any value over AI generated code. Good coders with access to compute will also be able to generate or maintain orders of magnitude more code. Bad coders with bad intentions will also be able to flood the OCA with poor quality contributions and the average person will not be able/not have time to filter the good options. In this is world that is coming in just a few months, how will we be able to maintain trust and organization? IMHO this should be a top concern for the OCA.

Finally, for more than a decade, the business model behind the OCA was kind of: in traditional ERPs 70% of the cost is from consulting/customization and 30% from licenses. So some alien skilled people able to do both the code and the consulting (or small companies able to do both) would charge the 70% and use that revenue produce the ERP code free of license charges. That was working because non specialists would typically not be able simply download open source code and do their ERP project alone. So companies would somehwat hire module authors, pay the 70% consulting/customization cost and with limited parasistism, the ecosystem could somehow sustain itself.

But soon the expertise to use OCA modules will drop a lot. The AI will bring it to the user directly bypassing modules authors and contributors entirely...

How will our open source economy work in this context? Well an option I see is use AI on our side: manage order of magnitude more code and more customers for a fraction of the cost... Now, I'm almost certain if we simply reject the IA entirety, then yes, it won't take long before we are made completely obsolete.

On Sat, Sep 27, 2025, 4:47 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:

Indeed - it would be of benefit for OCA to have a position.

Best wishes,

Stuart.

On 27/09/2025 09:27, Frederik Kramer wrote:

Hi Stuart, hi all,

very valuable for decision making but I think within our community we have people thinking as strict as Gentoo, NetBSD on the matter and others that would rather adopt the stance of the Linux or Apache Foundation. So possibly the board / governance/community health WGs shall come up with a decision proposal along these lines and ask for a solid quorum in the next AGA.

Best Frederik

Am 26. September 2025 08:42:39 MESZ schrieb Stuart J Mackintosh <notifications@odoo-community.org>:

Following up and to take a look at how others have dealt with these matters, I noticed Fedora released an AI policy yesterday so I have briefly summarised (perplexity) this compared with a bunch of other policies, full analysis here: https://codimd.mackintosh.me/s/ifsByh-G8#

Brief overview of policies:

- The main goal is to blend innovation with strong safeguards—using AI tools to help, but keeping people fully responsible for results.
- Most projects see transparency as crucial for maintaining trust and enabling fair review and collaboration.
- Quality control and copyright protection are prioritized: automation should not dilute standards nor introduce legal risk.
- Some policies are stricter, fully banning AI output unless human-vetted and legally certified.
- Clause implementation mostly revolves around commit messages, contributor guidelines, and reviewed workflow steps—simple, actionable, easy to follow.

This format ensures contributors know where, when, and how AI use is welcomed—and where human effort and discretion are absolutely required.

Best wishes,

Stuart.

On 24/09/2025 11:01, Stuart J Mackintosh wrote:

I propose that you address these points through the mechanism proposed by Daniel - responsible use, and behavioural guidance alongside a code of conduct which can determine obligations such as disclosure of AI use; Ai is just one of a set of issues that must be addressed.

Best wishes,

Stuart.

On 24/09/2025 10:47, Graeme Gellatly wrote:

I disagree. If you are holding yourself out as a professional you should declare AI usage and the scope.   Declaring AI usage is mandated for my profession, if I prepare any advice or report in a professional capacity I must declare. It is just not an option to say, oh well it is just a tool, when it really isn't, it directly created output.

It also gives valuable information to both the reviewer and ultimately the users.

It is also important from a copyright perspective. There is no copyright in a lot of AI generated work without later creative human input and even then only the human inputs are usually covered. To be fair there is also no copyright in a lot of human generated output (i.e. bug fixes and migrations) as there is no creative output, so for that kind of work AI is actually ideal. Ref https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf

On Tue, Sep 23, 2025 at 8:27 PM Daniel Reis <notifications@odoo-community.org> wrote:

Hello all,

It begs the question of what is "AI generated code".
AI can assist code writing from code completion suggestions, to full design and code writing.
Or just assist with code reviews or issue resolution, without writing code.

In the end AI is just a tool.
Irresponsible use can happen with AI or any other automation tool.

What really matters is the behavior of people using these tools.
I feel that we might need a guideline regarding responsible use of automated tools, including AI, rather than specifically for AI use.
This could be fitted into a code of conduct for the community.

Thanks
Daniel

On 18/09/2025 08:41, Stefan Rijnhart wrote:

Dear all, at least one contributor is planning again to flood the OCA projects with PRs for module migrations: https://github.com/OCA/web/issues/3285. This volume is likely made possible through automation, with an LLM generating the actual migration code (on top of, hopefully, a more deterministic tool like OCA's odoo-module-migrator). Regardless of the volume and the submitter, if the submitter has reviewed, refined and tested the code generated by an LLM, this should not be a problem but as a reviewer I'd like to know what I can expect. Holger Brunn pointed out to me that in other projects, this may be covered by a demand in the guidelines to disclose LLM usage and its extend. For an example, see https://github.com/ghostty-org/ghostty/pull/8289/files. I would very much like to see such an addition to the OCA guidelines. Additionally, I would like to suggest that the basic premise (the generated code is indeed first self-reviewed, refined and tested) is also made explicit, and that it is unacceptable to pass on reviewer comments to the LLM only to copy back the LLM's response (which has happened to me on one or two occassions). Can I have a temperature check for your support for such an addition to the guidelines? Or do you have other ideas or perspectives on the matter? Cheers, Stefan -- Opener B.V. - Business solutions driven by open source collaboration Stefan Rijnhart - Consultant/developer mail:stefan@opener.amsterdam tel: +31 (0) 6 1447 8606 web:https://opener.amsterdam

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

DANIEL REIS
MANAGING PARTNER
>> Schedule time on my calendar.
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Phone: +49 4181 13503-12
Fax:    +49 4181 13503-10
Mobil: +49 179 3901819

Email: frederik.kramer@initos.com
Web:   www.initos.com

Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Stuart J Mackintosh

Business & digital technology consultant

Open Digital Consulting Co

UK: +44 20 36 27 90 40

FR: +33 1 89 48 00 40

Email: sjm@opendigital.cc

Web: https://opendigital.cc

IM: xmpp:sjm@opendigital.cc
by Stuart J Mackintosh - 05:31 - 28 Sep 2025

1 attachments 1 attachments

logo.png

Archives

Contributors

Re: Guidelines for LLM generated contributions

Re: Guidelines for LLM generated contributions

Re: Guidelines for LLM generated contributions

Reference

Guidelines for LLM generated contributions

RE: Guidelines for LLM generated contributions

Re: Guidelines for LLM generated contributions

RE: Guidelines for LLM generated contributions

Re: Guidelines for LLM generated contributions

Re: Guidelines for LLM generated contributions

Follow us