Contributors mailing list archives

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

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