Feature request: OCA addon packaging system with central repository similar to conda/pip, and soft fork from odoo community edition that contains a fully-fledged system out of the box without depending on enterprise addons

[kcleung]

We all know that the odoo community edition is extremely stripped-down and one cannot have a functional system without relying on custom addons.

Currently, the user must manually search online for addons and download and install addons into their addon folder, which is very difficult to navigate. Furthermore, the user must manually check the license of each module for compatibility / legal issues.

This put a lot of potential users off.

The best way forward is to have an official repository for OCA with a packaging system similar to conda, pip or debian, where developers can develop their project in a git repository, which has a packaging system to package into one or more packages, and get the packages vetted/registered/maintained at the official repository like how it is done in conda/pip/debian.

Then we also introduce an OCA addon that automatically fetch the list of addons from the official server, handle the dependency and conflicts (both software version and license) and automate the installation and uninstallation process.

The proposed OCA addon central repository will also have a policy that packages can only be licensed with either LGPL-3 or AGPL-3

During submission of addon packages, and perhaps also installation of the packages, the system will also have automatic check of licensing dependencies too.

Furthermore, it may be a good idea to make a soft fork from odoo community edition after odoo 19 has been released that:

• contains all odoo community and enterprise features that OCA has equivalent of out of the box
• has the above-mentioned packaging system and central online repository to allow installation and management of addons without the user having to manually download the addons

In relation to the proposed soft fork, we may wanna give it a new name to avoid trademark issues, should we revert to OpenERP, or should we think of other names?

I believe that the above is a matter of urgency, as the fragmentation, and the resultant maintenance headache will make odoo/OCA pretty usuable to newcomers.

[rvalyi]

Hello this is largely done. OCA modules are published as wheel packages to pypi after each change.

See for instance:
https://pypi.org/project/odoo-addon-web-responsive/

On modern Odoo versions, the name of the pypi package is simply odoo-addon-module-name
where _ are replaced by - in module-name.

To install the Odoo OCA addons easily with pip or uv, see for instance: https://youtu.be/oQbrZoVttt8?si=1bPBZheNE9dyhbKW

As for Odoo Enterprise alternatives, the OCA started a serie of blog posts/webminars to promote alternatives. See for instance: https://odoo-community.org/event/online-training-mis-builder-introduction-and-more-2025-11-13-195/register?s=09

But there are some intrinsic limitations like:

• self implementing a real ERP project, even an Odoo one is hard. It's kind of a profession requiring years of experience. If you don't have it, chances are very high you end up doing critical mistakes that will make your project fail. Unlike the Odoo propaganda tend to suggest, Odoo is a real ERP system with a real intrinsic ERP complexity behind... Self hosting and self migrating an Odoo project is even harder...
• the OCA is not a fork of Odoo. Odoo SA is bringing like twice as much open source R&D as the OCA every year in Odoo Community even if the OCA codebase is much larger (it has less evolution/fine tuning). Without Odoo SA, an OCA Odoo fork would be a much more limited system and probably less popular...
• Odoo implementations for small companies still require years of preparation and very professional services. The kind of hosting odoo.com provides (it's hard to compete on these low hosting prices). The public who come to the OCA are more like persons who need more than the basic things Odoo Enterprise does. So the OCA is a more complex ecosystem with 3000 modules per version (after 2 years some migration delay). The public for the OCA is kind of this expert public where not 2 projects are equal and it is normal to have many options to addresses business problems with subtle variations.
• The OCA is a set of coordinated volunteers, a bit like the Debian project. For instance, the code of the OCA modules themselves is not paid by the association but by a galaxy of third party companies/individuals hiring companies/developers to meet their own need first... As such the OCA cannot pretend it will fix anybody ERP project easily. It does what is possible and people with enough skills make the most of it already. When it will be bigger it will do more and more and make it easier even for less expert users...

[kcleung]

Thanks heaps for your heads up. However, to allow a new user to quickly set up the necessary addons, I suggest that OCA has industry packages / metapackages (say accountant, law firm etc etc) that depends on a set of OCA packages so that the user can get the system working without excessive effort to search through the 3000 OCA packages.

Also, it appears that a lot of OCA projects are not available in pypi. For example: the set of account financial tools

https://github.com/OCA/account-financial-tools

https://pypi.org/search/?q=%22odoo-addon-account-financial-tools%22&o=

Have I looked at wrong places or searched in a wrong way?

In a nutshell, it would be essential that the user must be able to quickly install necessary addons by selecting metapackages / industry addons through a packaging system in a turnkey way, like the ERPNext. Otherwise, the usability of odoo/OCA would be severely hampered.

[rvalyi]

what is published on pypi is each of the individual OCA modules, not the repository! here you search for account-financial-tools which is a repository (a curated set of OCA modules with similar dependencies). If you look instead for an individual module of this repository like account_usability, you will find it:
https://pypi.org/project/odoo-addon-account-usability/

I understand you wish it would be easier to get a list of modules that will fit your need. But bare in mind that this is not easy at all. If you are talking about very small projects, that will be hard to do it cheaper than what odoo.com does. And if you are talking about more complex projects for companies larger than say 5 people, then the OCA is a great fit but these are more complex projects...

Outside from a given vertical not two companies are equal, often localisation modules impact many aspects, you may need different modules according to the Odoo version, because the base Odoo modules havd different features, because the OCA modules might not have been all migrated yet... You may need different modules according to your company size or what matters for you... This is pretty much how ERPs use to differ from smaller softwares...

All in all the OCA does what is possible with the budget it has (a lot less than Odoo SA) and I think the OCA board is very aware in an ideal world things would be simpler and is working to achieve that.

The OCA has a few vertical repos already for instance (which are a bit industry meta packages), but there aren't always enough volunteer contributions to keep them complete and up to date as one would dream and people won't always agree on what really belong to a given vertical meta package...

So all in all the OCA is a nice start, then it all depend on our little code or monetary contributons to move things forward...

If you are want to weight behind the OCA startegical decisions, you can become a member, then apply to be elected as a delegate and then vote for what you think is better and also defend your ideas. But I would say the OCA is already aware of these points, if they aren't all implemented it is more because of the limited resources...

[kcleung]

Ahhh I see. Can you please give us some examples of existing OCA vertical repos, and OCA pip metapackages which we can install and pull a set of OCA addon packages?

[rvalyi]

you'll find them with the vertical- prefix:
https://github.com/OCA?q=vertical&type=all&language=&sort=

Once you enter such a repo, you can switch the branch and you will often see they tend to be much more complete on older versions like 16.0 or even earlier versions.

So that's why I say there is no point in willing to create many more verticals and whishing ready modules for everything if the community cannot even maintain the ones it already created in the previous years...