A common question we receive is who or what the
OCA (Odoo Community Association) is and whether there is a difference
between Odoo and the OCA, as Odoo is open-source. Since they are not
the same and Odoo is not the founder of the OCA, we have put together
some background information on the OCA (from our point of view).
What is behind the OCA?
The OCA is an independent, member-based organization providing a wide range of modules/customizations to extend Odoo. The modules are made available via GitHub Repositories. In addition, the modules are also available as apps in the Odoo App Store – free of charge, of course.
Anyone may become a member of the OCA. The members
are both Odoo partners and ”free“ developers.
The OCA’s goals and objectives
According to their homepage, the OCA has the following goals and objectives:
Enable and promote the collaborative software development of Odoo open-source ERP.
Encourage the development of Odoo and its features while coordinating and organizing the collaborative work on the software.
Assist the community while defending its interests and the sustainability of its developments.
Promote the use of the Odoo solution.
Facilitate synergies, collaborations, and fundraising efforts.
Actively collaborate on defining the roadmaps of new versions of the tool and their implementation.
The OCA’s mission
Again, here are the OCA’s own words about their mission:
To ensure a high degree of quality in the OCA’s projects to build and preserve the association brand.
To ensure the long-term support and maintenance of the OCA’s projects and developments.
To provide resources for the OCA’s projects – e.g., infrastructure, CLA, funding, legal.
To encourage implementing open standards and standards-based interoperability in the OCA’s projects.
To support the worldwide use and contribution of the OCA’s projects from the community via the internationalization of the software and community outreach.
To represent the Community’s opinion regarding the Odoo SA roadmap, marketing, and development strategies.
To promote the use of Open-Source software in the industry – e.g., training and outreach.
To organize members’ meetings to improve the collaboration and the knowledge of the OCA’s projects.
Determining the extent of the OCA’s influence on Odoo’s decisions is difficult. Over ten years ago, Odoo said the OCA’s involvement was very welcome. However, as ERP software supports business-critical processes and development is always accompanied by a certain amount of process thinking, the development of the application is not seen as a democratic act, and in the end, Odoo will always remain the author of the core functionality.
Anyone wishing to contribute can do so by publishing apps or modules.
On the one hand, the OCA has many members worldwide; on the other, Odoo, too, has become a large, international company. For us, this raises the question of whether and to what extent the OCA can influence the development of the Odoo core. (And let’s be honest, anyone familiar with Fabian Pinckaers knows that there is only one opinion within Odoo).
However,
we must also recognize that this ERP solution is always oriented
strongly towards a process and even dictates it to a certain extent.
An open solution in the form of a democracy is certainly not the best
approach, especially as it involves controlling business-critical
processes or infrastructure. This should be harmonized from a single
source.
The OCA’s history
The OCA is the Odoo Community Association. It was proclaimed in 2014 and founded by Camptocamp during the release of Odoo 9. How did that come about?
Background
Odoo’s primary source of income is the Enterprise contract. Until 2014, only ONE Odoo existed, and there was no distinction between a Community and an Enterprise version. All modules were published under GPLv2. However, if you look at the modules’ authors, you will find not only Odoo but also the names of various partners.
Many see the added value in the broader range of modules compared to the Community and what they entail, but the real value is the migration of the transaction database. We did not sell this in our first two projects in our early years and “paid dearly“ for the omission. The reason was the complexity of the database structure. The difference may still be visualized with the help of tools, but there are also field values that control a process. These differences are difficult to find. Therefore, a migration means a long and arduous journey of testing, testing, and more testing for someone who does not know all the code changes. And there is still no guarantee after everything is ready.
Obviously, many people did not recognize this added value and recommended – and implemented – Odoo even without an Enterprise contract. This apparently happened too often, and Odoo felt compelled to create further added value for the Enterprise contract.
When the idea of creating two versions and separating the functional scope emerged as a rumor, a storm of indignation followed. Many partners pointed out that this would mean a license change, and they would not accept this. And many obviously feared a withdrawal of Odoo as an open-source solution.
The 2015
Experience and Odoo 9
But as I said, Odoo was forced to act. Camptocamp played a significant role, especially in the development of Odoo 9. At that time, Odoo had commissioned Camptocamp to rewrite the warehouse module completely. Then came the Odoo Experience in 2015 in Louvaine-la-Neuf (as was customary then). Fabian Pinckaers stood on the stage in the large town hall in Louvaine-la-Neuf and we partners stood before him. Fabian announced a lot would change for Odoo 9 (the current layout was also introduced then; Odoo 8 and the previous versions looked completely different). He also announced a change of license and separation into two modules. The reason he gave was to strengthen the Enterprise contract.
As
soon as he finished, Luc Maurer from Camptocamp stepped forward,
declared that he would not accept this decision, and asked all
partners to join him in the basement. There, he proclaimed the
founding of the OCA, which would continue to develop modules based on
GPLv2.
The core of GPLv2
Since we are no lawyers, it is possible that there were interests we do not know about that led to this dispute.
The GPL developed by Richard Stallman is built on a principle he deliberately called CopyLeft. Probably its most crucial aspect is that if someone uses code published under the GPL, the resulting work must automatically also be published under the GPL. Consequently, a mixture of different license models is impossible, completely ruling out the creation of proprietary code.
The
Enterprise packages already included in Odoo 9 were ultimately
published under the MIT license, which is less restrictive and allows
a mixture of licenses.
The presumed cause of the dispute
I cannot and do not want to judge whether a mixture of license models is legal. But the cause of the dispute was certainly the fear that Odoo would no longer be completely open-source.
A part of Odoo’s success may undoubtedly be attributed to some partners' contributions in the early years. If part of the system had no longer been accessible, this would have changed the basis and the way the partners use the system. And it would have also affected the first partners.
The
following years have shown that this did not happen. The Enterprise
package is still delivered in source code.
Can all OCA modules be used in every Odoo version?
Two aspects should be considered when using OCA modules. Aspect 1 is the comparison with the Odoo version used because not every OCA module is migrated to every current version. It may well happen that modules are no longer in maintenance, so migration will no longer be performed.
There are probably several good reasons for this, but at this point, we can only guess what they are:
Lack of resources: Updating modules requires time, knowledge, and often financial resources. If the developers or the company who created the module do not have sufficient resources to perform the update, this may lead to delays or the cancellation of the update.
Outdated technology: If a module is based on outdated Odoo versions or technologies, it may lead to the update being neglected. Maintaining modules that are no longer state-of-the-art can be difficult and costly.
Lack of demand: If only a few users access a particular module, the developers or the company may not see sufficient motivation to continue updating the module. A module that many users work with is usually more likely to be updated regularly.
Changes in requirements: If user requirements or the business environment change, it is possible that a module no longer meets these needs. In such cases, replacing the module with a new or more suitable one may make more sense instead of continuing to update it.
Change of developer: If the original developers of the module leave the project or hand over responsibility for the module to other people or organizations, it may lead to delays in updating.
Conflicts with other modules or extensions: A module can no longer be updated if there are conflicts with other modules or extensions installed in the same Odoo system.
The second aspect is equally important: You should check whether a module depends on another. In this case, all dependencies should be considered in more detail.
Another
aspect in selecting OCA modules is whether a module can be used in
Odoo Enterprise, as the OCA only guarantees functionality with the
Community version. As you can imagine, it is precisely in these areas
that the community has found an answer to functions that are part of
the Enterprise package. However, the community mostly solved
requirements differently than the ones Odoo implemented. This
naturally leads to a different data structure. The OCA modules build
on each other and may, therefore, collide with the design of the
Enterprise modules.
What are the most significant differences?
The greatest caution must be exercised in the areas of accounting and finance. In the Community version, a fundamental data structure for accounting is, of course, available to ensure the basic functionality of creating invoices. However, in Odoo Enterprise, accounting has significantly more functionality than just invoicing and recording (e.g., direct debit, collective payments, and everything to do with bank bookings). The financial modules extend the data structure of the Enterprise version by a not inconsiderable amount.
Of course, the OCA offers various accounting extensions and modules to cover the missing areas of finance (e.g., managing assets, budget planning, and account balancing). In some cases, a comprehensive ecosystem of extensions builds on each other.
This does not mean that the OCA module may not
be used in the Enterprise version of accounting. But the more
dependencies a module has and the more in-depth you go, the greater
the likelihood it will conflict with the existing accounting system.
Note on OpenUpgrade
“OpenUpgrade“ is a very interesting sub-project within the OCA: https://github.com/OCA/OpenUpgrade
https://gitlab.com/odoo-openupgrade-wizard/odoo-openupgrade-wizard
Here, the OCA offers a framework supporting migrations of the Odoo community. This can be used to determine changes in the database structure, generate SQL scripts for transformation, and automate them later. Changes within the data itself can also be determined and rewritten.
However,
despite the framework, you still need good technical knowledge of
Odoo and the code, and you should probably not go ahead without a
partner.
Do we, as openfellas, use the OCA?
We have been using the OCA Connector Framework for many years: https://github.com/OCA/connector
Essentially, the OCA Connector is an interface or extension that helps to connect Odoo with other systems or services. This may mean, for example, that we can integrate Odoo with e-commerce platforms, payment gateways, warehouse management systems, or other third-party tools. This connector forms the basis for connections to Shopify, Shopware, Logistiker, Akeneo, Diamant, SAP, and many more.
Due to this connector's many users, it has always been migrated to the current Odoo version.
However,
we may select and use OCA modules for specific projects, but this is
not regularly the case.
Are Odoo and Odoo Enterprise open-source?
The
answer is yes; Odoo Enterprise is also open-source. Of course, there
are many open-source licenses, but they all have two things in
common:
Firstly, when open-source software is delivered, the
source code is always included, and secondly, in the event of
customizations, the author must be retained and may not be replaced.
Contrary to many rumors, none of the licenses specifies a business
model.
The Odoo Enterprise packages are delivered via a closed GitHub repository. The basis for access is a concluded and active Odoo Enterprise contract. Accordingly, the modules are or can be kept in a separate path. Of course, all files are delivered in source code, so the Enterprise version can also be regarded as a completely open-source solution.
Odoo
may still be used without an Enterprise contract but without access
to the Enterprise modules. These would have to be de-installed and
removed. So much for the legal basis. However, we cannot say whether
this is technically feasible. But we assume it would be very
time-consuming and challenging to realize, and it would require good
knowledge of the systems, time, and patience.
What is an open-source ERP solution?
An open-source ERP solution is an ERP solution that also supplies the source code. Other than that, the fact that an open-source ERP solution is an ERP solution does not change. The fact that the source code is delivered and can be viewed does not change the range of functions or content.
Generally, the following should be the most important factors when choosing a solution:
License: Odoo Community relies on the GPL. The Enterprise packages are published under the MIT license. This means the source code can be used and modified as long as the author is retained. Generally, one needs to check whether the license used is compatible with the requirements and guidelines concerning use and distribution.
Community and support: The dissemination, strength, and activity of the solution and its community are essential. An active community ensures further development and helps solve problems and answer questions. Odoo has had a powerful and broad international presence in this area for many years.
Functionality: Of course, the sheer number of functions is not the only decisive factor, as functions can often be combined. But overall, you should check the depth and breadth of functions within solutions. Odoo is solidly positioned in this respect and has developed its integrative approach well.
Documentation: Everything is only as good as its documentation. This is why good and up-to-date documentation is essential. However, the number of external videos and explanations available via common platforms is just as significant. Due to the firm international acceptance and distribution of Odoo, there is enough material available in almost all languages and on a wide variety of topics. The Odoo documentation is extensive and continuously updated in many different languages.
Scalability and performance: Odoo and any software should be able to keep pace with your growing needs. This is the case for Odoo, mainly due to its customizability. The system is modular from the ground up and may be easily customized to meet specific requirements. A large number of extensions and plugins are offered via an app store and various platforms.
Security: Security gaps may lead to severe consequences, so it is essential to maintain and update the software regularly. Odoo is particularly active here and offers daily versions. Enterprise customers are proactively informed of security gaps, and patches are made available simultaneously.
Compatibility: Of course, hardly any solution can cover all requirements. It must be able to be integrated into an environment and should offer APIs and connection options. Odoo has a robust API that may be used to connect to any system that also provides an interface. If this is insufficient, any system may be connected automatically or semi-automatically via the OCA Connector mentioned above. There are hardly any limits at this point.
User-friendliness: Even if the result of this particular point very much depends on individual assessment, the user-friendliness of any software is essential, as it will have a decisive influence on the acceptance and efficiency of employees or users. ERP is fundamentally a complex topic. How easy it is to create user-friendliness here is undoubtedly a topic in itself. However, if you compare Odoo with SAP or Business Central and remove the choice of color or interface design, Odoo presents itself with very tidy screens, extremely clear and easy-to-understand operation, and uniform user guidance across all modules. In addition, Odoo continues to develop each version to improve the experience with the system despite increasing complexity.
Costs: The business models for open-source products vary greatly. With Odoo, you pay per named user. Each internal user is valued equally regardless of the installed modules or authorization profiles. Odoo offers an extensive range of modules. If you were to add the license costs of specialist applications, you would end up with a multiple of the license costs. Odoo, therefore, understandably argues that the current price per user per month is set very low, and a subdivision is, therefore, not necessary. Moreover, it should not be forgotten that the regular migration of the transaction database to a current version is also part of the license price, as it is performed free of charge within Odoo’s Enterprise contract. When considering the overall costs, it is also essential to consider the position of the implementation. An implementation partner for consulting, training, customization, and support is generally recommended.
Availability of resources: Implementing a solution, particularly an ERP system, requires two different kinds of experience. On the one hand, it is essential to understand requirements and processes and to have knowledge of the functional scope of the system. This requires so-called “functional consultants. “ In addition, developers with specific technical knowledge of the solution’s structure are necessary when it comes to realizing adaptations or extensions.
The
Code basis for Odoo is Python. As Odoo, by now, is a recognized
national and international player with a good level of acceptance in
the SME sector and the environment of medium-sized companies, it is
reasonable to assume that resources are available. Moreover,
universities have now also discovered Odoo and include it in their
curriculum.
What are the advantages of an open-source solution?
Internationally, open-source projects have been firmly established in all areas for approx. ten years. The fact that Microsoft alone has integrated the Linux core since Windows 10 and uses it to provide more and more services, thus making a significant contribution, shows how open-source has become an integral part, and this is only one example.
The many advantages are the reason why more and more companies are opting for an open solution:
Lower total costs: Open-source software is usually free of charge. This can mean significant savings on license costs.
Adaptability: Open-source software may be adapted to meet the specific requirements of a project or organization. Developers have access to the source code and may change it as required.
Transparency: The source code of open-source software may be viewed by anyone. This means the software is transparent, and security gaps or vulnerabilities may be identified and corrected more quickly.
Collaborative development: Open-source software is often supported by a community of developers and users. This encourages collaboration and knowledge sharing and contributes to the software’s continuous improvement.
Variety of options: A wide range of open-source software is available for various applications. Users can choose from different options and decide on the one that best suits their needs.
Long-term availability: Since the source code is public, the software usually remains available in the long term, even if the original developer no longer supports the project.
Independence from providers: Users of open-source software are not dependent on a single provider, which offers flexibility and independence. They can manage the software themselves or use other service providers.
Reduced risk of vendor lock-in: Open-source software reduces the risk of a vendor lock-in, where users are tied to a particular vendor and have difficulties changing.
Security: Even though this is much discussed, various statistics from recent years show that the transparency of the source code may help to recognize security problems and develop secure software. The open-source community often reacts quickly to security issues.
Encouraging innovation: Open-source software promotes innovation since developers can openly share and improve ideas and code. This can help bring new technologies to market faster.
The differences between Community & Enterprise editions
When considering whether to use Odoo Community or Enterprise for the implementation, there are four points to consider:
License costs: How many internal users are required?
Functionality: Does the Community provide sufficient functionalities?
Migration: Odoo Enterprise includes the database migration free of charge. OpenUpgrade supports the migration, but it is only a framework. The effort involved is hard to calculate 100% in advance.
Warranty: The Odoo Community does not offer a warranty.
Who can use Odoo as an ERP solution?
Since Odoo is an international and generalized ERP system, most industries or companies can use Odoo. It is multilingual, multi-currency-capable, and offers the option of setting up different companies in different countries via a multi-client system and adapting them to legal requirements and tax guidelines via localization.
In addition, the generalization guarantees industry-independent use. The fact that it has a link from order management to project management, time recording, and the associated automated invoicing makes it suitable for any service company. However, it also manages warehouse products and consumables in conjunction with parts lists, allowing it to be used by trading or manufacturing companies.
Since all three variants (services, trade, and manufacturing) can be used equally and are controlled exclusively via configurations, every shade of grey in between can also be covered. This is why Odoo has every right to claim that it is a generalized ERP system.
Was this article helpfull information to you?
Would you mind to leave us a review of your experiences with openfellas?
Talk to our experts.
We will find the solution best suited to you and your products!