Open core, not open source, only for the Community edition, wait till you notice that you will need enterprise license since most powerfull features/addons are enterprise only and you end up paying more money for "open source" ERP than normal ERP
> you end up paying more money for "open source" ERP than normal ERP
That's not what I see on the market. Even the paying version of Odoo is way more affordable than traditional ERP:
- licenses are 5x lower than competition: https://www.odoo.com/pricing (avg 25€/user/month vs 180€ for Netsuite - Odoo has a "no-extra" / transparent pricing policy)
- On implementation service fees, Odoo is usually from 30% to 75% cheaper: more capabilities and easier to implement or customize.
As a result of capabilities + affordable, Odoo became the most used ERP in the world: 16m users (incl free ones), 200k+ clients. (Netsuite is 43k clients, Dynamics BC is 40k clients)
> That's not what I see on the market. Even the paying version of Odoo is way more affordable than traditional ERP:
The system looks well organized and clearly built by people with knowledge of the domain(s), but traditional ERP has significantly more depth in functionality, I don't think that comparison makes sense at this point in time.
The competition licenses include support (like that netsuite €180 license). Odoo doesn't.
When you factor in finding another company to provide support them Odoo becomes easily equal in cost to other options. Or you have to do it yourself which is also very expensive (in time rather than money).
Also for some weird reason the Odoo forum is incredibly locked down. After a year of using it, I hadn't even earned enough trust to comment, let alone ask a question.
Oh hey, it's my favorite pet peeve. When flagging a potential conflict of interest, the word is "Disclosure". "Disclaimer" means "I'm just a random guy who cannot assume responsibility for what they're saying", like in IANAL.
It’s an awesome start to a stack, you’re right though a typical seat based install runs average enterprises 25+k usd per year. I wish that someone would just make open oodo compatible plugins, because the big fundamental win is a unified data model built on open technologies.
I've been looking into switching our manufacturing business over to Odoo, replacing Dynamics GP + another mfg software. My impression is that it's very customizable, but may require some specialized expertise to implement correctly for one's environment. Enterprise would probably net save us money on just support contracts compared to our current setup.
"Open-Source" is a bit of a misnomer. The majority of the important modules are enterprise only. That said even enterprise is source-available for paying customers which is a breath of fresh air compared to the competition.
We have been using Odoo for some specific processes in the company in the past.
There are some bright ideas based on strong fundamentals.
Regarding the strong fundamentals:
- A clever, extremely flexible, roles/permissions system. It is based on giving CRUD permissions to user roles, allowing to define access rules based on the fields (for instance a READ access with a record rule [('user_id', '=', user.id)] would allow to read only own records). In most of the software permissions are expressed in the code, in Odoo they are abstracted and enforced at ORM level.
- The custom ORM system is very strong and allows to create objects and fields at runtime. You can create a model and its fields and start using it right away without restarting the server.
Some of the smaller bright ideas:
- Records navigation is rather smart: the pagination system allows to manually define the records range to be seen avoiding the usual "records per page" dropdown; standard filters can be defined using the same domain syntax from access rules above (the filter for "My records" would be [('user_id', '=', user.id)]).
- Many views use kanban, I find them extremely practical to get a good overview, in particular for CRM opportunities and candidates screening processes.
I tried to get Odoo adopted at my company for about a year but eventually gave up in favor of a paid solution.
The thing is that what you really need to get something like this working is support (by phone, screen sharing etc.), and it came down to two options: either I permanently become Odoo support for everyone else, or we pay someone else to do it. All the companies offering Odoo support are very expensive, so any financial benefits to using Odoo are gone several times over. It was much cheaper to just switch to a paid solution that includes support in the monthly fee.
Besides that, the source code is a mess, so when I tried adding some basic customs functions it was a total headache even for very basic things. For some reason they've built their own front end framework which is clearly inspired by a very old version of React.
My experience as well. In 2018 we used odoo at a startup to avoid using systems like Monday and Jira. By 2019 we were back on those systems. My experience was so sour, that I heard an odoo ad on npr the other day and I didn’t even go back to see what has changed.
Last time I worked with Odoo (v15/v16, enterprise, self hosted) we had to send a dump of the production database over to you to be migrated to the new version and then it was sent back. The upgrade path for third-party and custom addons was not defined.
And since it is Odoo, everything is in that database: from employee's time tracking to customer support chats, from stock info to accounting data, from e-mail addresses to password hashes. I found this inacceptable but at that point we had no choice.
You can crypt the data before sending to the upgrade platform. Before it was an external script, and since Odoo 16 you can use the `oboo-bin obfuscate` command, before running the upgrade script.
See `./odoo-bin obfuscate --help` to check how to crypt your custom data and uncrypt after upgrade.
It's not perfect (crypt specific columns rather than full DB) but, unfortunatelly, to operate our upgrade service, we need access to the database. Upgrades are complex and requires testing, fine tuning scripts to your specific use cases, etc.
The other alternative is to not use our services, but do it yourself using upgrade scripts from the community: https://github.com/OCA/OpenUpgrade
1/ Upgrade are super complex: requires a service, not just a script
2/ We used it to monetize Odoo Enterprise
Upgrade: Even after 1000+ upgrades, we still run into issues regularly as every environment is different (set of modules, customizations, community apps, ...). So we need to test the database, and fix scripts when necessary. If we would just provide scripts, it would cost us a lot in support for issues... and a bad customer experience. At least, by having the control we can ensure a smooth customer experience; it just works - and you don't see everything we do behind. (most of the time)
Monetization: The open core business model is hard, when your goal is to do a maximum open source. Our main competitor being Odoo Community, we charge 5x less than competitors for a better software. (25€ vs 180€)
So, we had to pick a few apps and services to monetize Odoo Enterprise, like the accounting app, or the upgrade service.
Fortunetally, there is OpenUpgrade (scripts from the community) so that there is no lock-in on the upgrade. (you spend time with open-upgrade or go to Enterprise and we do it)
Is it possible to pay to have an Odoo employee execute the migration script on the on premise server? I remember I heard about that but I don't know if it's still an option.
These approaches should be completely flipped, the default should be your upgrade engineers get remote access to the customer's database (vpn, etc) and run the standardized and ad-hoc upgrade scripts on their system. Shipping the customer's data back and forth for every upgrade is absurd and a privacy nightmare.
Me and my customers are perfectly happy to even pay for the upgrade scripts, just allow us to run them on-prem.
Make it an encrypted binary for all I care, just allow us to run it on-prem.
Edit-due-to-pinky07-reply-edit:)
1+2 - I get all that. Perhaps provide enterprise customers with a GitHub repo to the upgrade scripts? Require the same subscription key like for Enterprise proper. Then you can continue to iterate on the scripts while still giving customers who wants (and pays extra!) for it as a white glove service to run it on their own servers.
Might be that me and some of my customers are old-school "server huggers", but I think it is holy to be able to decide on which CPU and disk my DB is processed on.
By having every services inside one tool, what are the new possibilities that Odoo can do easily that is hard to do with others suite of tools (where you’d need to connect together multiple independent services) ?
Just an example: when I send an email marketing campaign with Odoo, I have all the stats attached: the usual # clicks, open rate, ... but also # Leads, # Orders, Revenues.
Because Odoo as it all:
- You send an email with link tracker (Email Marketing App)
- The visitor goes on website (Website App)
- He fills a form that creates an opportunity (CRM App)
- 4 weeks later a sales make a quotation (Sales App)
- After Delivery (Inventory App)
- We send the invoice to the customer that books revenue (Accounting App)
So, you get the revenue for every email sent. Imagine that power for everything. (eg. stock is common between eCommerce, CRM, POS - Wommunication on whatsapp, SMS, chat, emails are centralized for helpdesk, ...)
But the main advantage is convenience. Once you use Odoo, everytime you have a need, you can install an app in one click that fully integrates with your stack. No need for developers to integrate, to call vendor to buy software, ...
The complexity of an IT stack grows with the square of the number of software components it contains. Most Odoo clients run everything on Odoo, eliminating the need for integrations and significantly reducing overall complexity.
Odoo SA (my company) has 6700 employees: we only use 2 software to run everything: Odoo and Google Workplace.
I noticed this on your site recently whilst evaluating Odoo for a use case, and I’m glad I get the opportunity to ask…why? That seems an astronomical amount for this product. This isn’t a criticism, I am just genuinely curious about the business.
Imagine we develop: Shopify + Wix + Quickbooks (accounting in 140 countries) + Netsuite + Asana + Discord + SAP + DocuSign + Payroll + ... 30 other apps.
On the service side, we onboard 14.000 new clients per month. (need a lot of sales too for that). Projects varies from a 5 users company (4 hours of service), to 5000 users. (1 year implementation for a team of 5)
The spread in people is more or less: 30% developers, 30% consultants, 30% sales.
In addition to our 6700 employees, we also have a large partner network: 200k FTE working on Odoo (selling, developing, doing services). They developed 50k apps, and onboard tens of thousands of companies per month.
How close is Odoo to the Django Stack? In my mind, since both are python, I always thought it was some kind of Django fork,l. I bet I am wrong. So how came Odoo into being?
It's not a fork of Django, even thought the stack has similarities: Python, ORM on top of Postgresql, Modules. We use werkzeug (it's been a long time I checked Django, not sure they are on it too), but the rest of the stack is Odoo's own framework: ORM, Templating (QWeb), API, etc.
But it's not comparable to Django:
- Odoo is built for management application: think CRM, Accounting, Project Management, ... a strong backend
- Django is often used as a framework, Odoo for end-users apps (even though our framework is super advanced)
- Odoo has a CMS (website builder) too but with a focus on being end-user friendly, like Wix, or Squarespace but for businesses (eCommerce, Jobs, Events, ...)
- the javascript client of Odoo is huge whereas Django is minimal
- Odoo has it's own ORM optimized for speed and complexity of an ERP
- templating engine based on XML rather than inline python instructions
ERPNext has a very peculiar home-grown deployment system that is required to host it yourself. I didn't much like it when I looked into it a while back.
They are running a massive out-of-home media campaign in my city, they billboard even busstops in home-districts with lowered traffic speed in the suburbs :-))
Honestly, before they started their ad campaign here, I had never heard of them. Though the product looks very mature.
Could be a "small SAP" competitor.
I've built a couple of Odoo integrations for clients. For the longest time, they only offered XML-RPC as an external API. At some point they also added JSON-RPC, which is the same kind of suckage. But now they're suddenly planning to remove both in the next major version (to replace them with something different) with very little advance notice.
Their API documentation is virtually nonexistent. You have to basically reverse engineer their poorly documented models to get anything done, and those can change between releases. I suspect they deliberately under-document their changes in order to force people to pay them more money. At least I hope their official partners get access to better documentation.
Beware putting all of your eggs into this particular basket.
Dunno if Odoo is more ERP or CRM but... if you speak about Microsoft Dataverse/Dynamics 365 Sales/Customer Engagement and such, the documentation, the tools the API the underlying foundation are just excellent.
Dolibarr is used by 1 million of users (so not as much as Odoo with 16m users).
Similar to Odoo in a lot of point but full opensource, more affordable than Odoo and easier to use and customize. Has less external addons (1200 vs 40000) than Odoo but external addons are rarely required.
Odoo would be a better choice if you have a very large company with an internal team of developper, Dolibarr will be easier and cheaper if you have less than 5000 employees.
Disclaimer: i'm on old Odoo integrator, now Dolibarr developer.
if you go with Odoo, my best advice is to use Odoo Community and hire a good freelance developer or integrator.
In my experience, the Enterprise version is poor value: support is often absent or slow, and most of the “Enterprise-only” features are not magical—they can be developed or replaced with custom modules at a lower total cost if you know what you’re doing.
Odoo’s real strength is the unified data model and extensible core. If you control your stack and invest in competent development instead of licenses, Community can be a solid ERP foundation. If you expect a polished SaaS with strong vendor support, Enterprise will likely disappoint relative to its price.
These guys have the dubious distinction of absolutely blasting tons of podcasts with the stupidest commercials I've ever heard. Basically at the level of "grondo has what plants crave", Odoo has what businesses need.
Open core, not open source, only for the Community edition, wait till you notice that you will need enterprise license since most powerfull features/addons are enterprise only and you end up paying more money for "open source" ERP than normal ERP
> you end up paying more money for "open source" ERP than normal ERP
That's not what I see on the market. Even the paying version of Odoo is way more affordable than traditional ERP:
- licenses are 5x lower than competition: https://www.odoo.com/pricing (avg 25€/user/month vs 180€ for Netsuite - Odoo has a "no-extra" / transparent pricing policy)
- On implementation service fees, Odoo is usually from 30% to 75% cheaper: more capabilities and easier to implement or customize.
As a result of capabilities + affordable, Odoo became the most used ERP in the world: 16m users (incl free ones), 200k+ clients. (Netsuite is 43k clients, Dynamics BC is 40k clients)
Disclaimer: I am the founder of Odoo.
> That's not what I see on the market. Even the paying version of Odoo is way more affordable than traditional ERP:
The system looks well organized and clearly built by people with knowledge of the domain(s), but traditional ERP has significantly more depth in functionality, I don't think that comparison makes sense at this point in time.
> licenses are 5x lower than competition
The competition licenses include support (like that netsuite €180 license). Odoo doesn't.
When you factor in finding another company to provide support them Odoo becomes easily equal in cost to other options. Or you have to do it yourself which is also very expensive (in time rather than money).
Also for some weird reason the Odoo forum is incredibly locked down. After a year of using it, I hadn't even earned enough trust to comment, let alone ask a question.
> Disclaimer: I am the founder of Odoo.
Oh hey, it's my favorite pet peeve. When flagging a potential conflict of interest, the word is "Disclosure". "Disclaimer" means "I'm just a random guy who cannot assume responsibility for what they're saying", like in IANAL.
It’s an awesome start to a stack, you’re right though a typical seat based install runs average enterprises 25+k usd per year. I wish that someone would just make open oodo compatible plugins, because the big fundamental win is a unified data model built on open technologies.
It is at least "source available". Once you pay for an enterprise subscription (or just search around) you get the source.
I've been looking into switching our manufacturing business over to Odoo, replacing Dynamics GP + another mfg software. My impression is that it's very customizable, but may require some specialized expertise to implement correctly for one's environment. Enterprise would probably net save us money on just support contracts compared to our current setup.
"Open-Source" is a bit of a misnomer. The majority of the important modules are enterprise only. That said even enterprise is source-available for paying customers which is a breath of fresh air compared to the competition.
We have been using Odoo for some specific processes in the company in the past. There are some bright ideas based on strong fundamentals.
Regarding the strong fundamentals: - A clever, extremely flexible, roles/permissions system. It is based on giving CRUD permissions to user roles, allowing to define access rules based on the fields (for instance a READ access with a record rule [('user_id', '=', user.id)] would allow to read only own records). In most of the software permissions are expressed in the code, in Odoo they are abstracted and enforced at ORM level. - The custom ORM system is very strong and allows to create objects and fields at runtime. You can create a model and its fields and start using it right away without restarting the server.
Some of the smaller bright ideas: - Records navigation is rather smart: the pagination system allows to manually define the records range to be seen avoiding the usual "records per page" dropdown; standard filters can be defined using the same domain syntax from access rules above (the filter for "My records" would be [('user_id', '=', user.id)]). - Many views use kanban, I find them extremely practical to get a good overview, in particular for CRM opportunities and candidates screening processes.
I tried to get Odoo adopted at my company for about a year but eventually gave up in favor of a paid solution.
The thing is that what you really need to get something like this working is support (by phone, screen sharing etc.), and it came down to two options: either I permanently become Odoo support for everyone else, or we pay someone else to do it. All the companies offering Odoo support are very expensive, so any financial benefits to using Odoo are gone several times over. It was much cheaper to just switch to a paid solution that includes support in the monthly fee.
Besides that, the source code is a mess, so when I tried adding some basic customs functions it was a total headache even for very basic things. For some reason they've built their own front end framework which is clearly inspired by a very old version of React.
My experience as well. In 2018 we used odoo at a startup to avoid using systems like Monday and Jira. By 2019 we were back on those systems. My experience was so sour, that I heard an odoo ad on npr the other day and I didn’t even go back to see what has changed.
I am the founder of Odoo: ask me anything. Happy to see Odoo on HN.
Last time I worked with Odoo (v15/v16, enterprise, self hosted) we had to send a dump of the production database over to you to be migrated to the new version and then it was sent back. The upgrade path for third-party and custom addons was not defined. And since it is Odoo, everything is in that database: from employee's time tracking to customer support chats, from stock info to accounting data, from e-mail addresses to password hashes. I found this inacceptable but at that point we had no choice.
What's the state here?
You can crypt the data before sending to the upgrade platform. Before it was an external script, and since Odoo 16 you can use the `oboo-bin obfuscate` command, before running the upgrade script.
See `./odoo-bin obfuscate --help` to check how to crypt your custom data and uncrypt after upgrade.
It's not perfect (crypt specific columns rather than full DB) but, unfortunatelly, to operate our upgrade service, we need access to the database. Upgrades are complex and requires testing, fine tuning scripts to your specific use cases, etc.
The other alternative is to not use our services, but do it yourself using upgrade scripts from the community: https://github.com/OCA/OpenUpgrade
Small partner here who absolutely love Odoo for what it is and you can make it to be.
But - I can't wrap my head around why an on-prem customer cannot be allowed to run the upgrade scripts on-prem.
I have almost lost customers to it, and it's a super big headache delaying the upgrade process for both political and technical reasons.
Having tried to discuss the options and reasons with both Odoo support and employees at OXP has been an almost Kafkaesque experience.
Please explain to me like I am 5 years old.
2 reasons:
1/ Upgrade are super complex: requires a service, not just a script
2/ We used it to monetize Odoo Enterprise
Upgrade: Even after 1000+ upgrades, we still run into issues regularly as every environment is different (set of modules, customizations, community apps, ...). So we need to test the database, and fix scripts when necessary. If we would just provide scripts, it would cost us a lot in support for issues... and a bad customer experience. At least, by having the control we can ensure a smooth customer experience; it just works - and you don't see everything we do behind. (most of the time)
Monetization: The open core business model is hard, when your goal is to do a maximum open source. Our main competitor being Odoo Community, we charge 5x less than competitors for a better software. (25€ vs 180€)
So, we had to pick a few apps and services to monetize Odoo Enterprise, like the accounting app, or the upgrade service.
Fortunetally, there is OpenUpgrade (scripts from the community) so that there is no lock-in on the upgrade. (you spend time with open-upgrade or go to Enterprise and we do it)
Is it possible to pay to have an Odoo employee execute the migration script on the on premise server? I remember I heard about that but I don't know if it's still an option.
We have done a few exceptions (e.g. Defense departments), but we usually refuse if not really justified.
These approaches should be completely flipped, the default should be your upgrade engineers get remote access to the customer's database (vpn, etc) and run the standardized and ad-hoc upgrade scripts on their system. Shipping the customer's data back and forth for every upgrade is absurd and a privacy nightmare.
Me and my customers are perfectly happy to even pay for the upgrade scripts, just allow us to run them on-prem.
Make it an encrypted binary for all I care, just allow us to run it on-prem.
Edit-due-to-pinky07-reply-edit:) 1+2 - I get all that. Perhaps provide enterprise customers with a GitHub repo to the upgrade scripts? Require the same subscription key like for Enterprise proper. Then you can continue to iterate on the scripts while still giving customers who wants (and pays extra!) for it as a white glove service to run it on their own servers.
Might be that me and some of my customers are old-school "server huggers", but I think it is holy to be able to decide on which CPU and disk my DB is processed on.
By having every services inside one tool, what are the new possibilities that Odoo can do easily that is hard to do with others suite of tools (where you’d need to connect together multiple independent services) ?
Just an example: when I send an email marketing campaign with Odoo, I have all the stats attached: the usual # clicks, open rate, ... but also # Leads, # Orders, Revenues.
Because Odoo as it all:
- You send an email with link tracker (Email Marketing App)
- The visitor goes on website (Website App)
- He fills a form that creates an opportunity (CRM App)
- 4 weeks later a sales make a quotation (Sales App)
- After Delivery (Inventory App)
- We send the invoice to the customer that books revenue (Accounting App)
So, you get the revenue for every email sent. Imagine that power for everything. (eg. stock is common between eCommerce, CRM, POS - Wommunication on whatsapp, SMS, chat, emails are centralized for helpdesk, ...)
But the main advantage is convenience. Once you use Odoo, everytime you have a need, you can install an app in one click that fully integrates with your stack. No need for developers to integrate, to call vendor to buy software, ...
The complexity of an IT stack grows with the square of the number of software components it contains. Most Odoo clients run everything on Odoo, eliminating the need for integrations and significantly reducing overall complexity.
Odoo SA (my company) has 6700 employees: we only use 2 software to run everything: Odoo and Google Workplace.
> has 6700 employees
I noticed this on your site recently whilst evaluating Odoo for a use case, and I’m glad I get the opportunity to ask…why? That seems an astronomical amount for this product. This isn’t a criticism, I am just genuinely curious about the business.
Imagine we develop: Shopify + Wix + Quickbooks (accounting in 140 countries) + Netsuite + Asana + Discord + SAP + DocuSign + Payroll + ... 30 other apps.
On the service side, we onboard 14.000 new clients per month. (need a lot of sales too for that). Projects varies from a 5 users company (4 hours of service), to 5000 users. (1 year implementation for a team of 5)
The spread in people is more or less: 30% developers, 30% consultants, 30% sales.
In addition to our 6700 employees, we also have a large partner network: 200k FTE working on Odoo (selling, developing, doing services). They developed 50k apps, and onboard tens of thousands of companies per month.
What does Google Workspace do for you that Odoo can't?
Gmail, Docs, Slides...
Odoo is not an alternative to Gmail. (We have a spreadsheet app, but more for reporting purposes)
How close is Odoo to the Django Stack? In my mind, since both are python, I always thought it was some kind of Django fork,l. I bet I am wrong. So how came Odoo into being?
It's not a fork of Django, even thought the stack has similarities: Python, ORM on top of Postgresql, Modules. We use werkzeug (it's been a long time I checked Django, not sure they are on it too), but the rest of the stack is Odoo's own framework: ORM, Templating (QWeb), API, etc.
But it's not comparable to Django:
- Odoo is built for management application: think CRM, Accounting, Project Management, ... a strong backend
- Django is often used as a framework, Odoo for end-users apps (even though our framework is super advanced)
- Odoo has a CMS (website builder) too but with a focus on being end-user friendly, like Wix, or Squarespace but for businesses (eCommerce, Jobs, Events, ...)
- the javascript client of Odoo is huge whereas Django is minimal
- Odoo has it's own ORM optimized for speed and complexity of an ERP
- templating engine based on XML rather than inline python instructions
Here is a 2 minutes overview: https://www.youtube.com/watch?v=nbso3NVz3p8
I don't have anything against Odoo but it's more accurately desribed as open core.
ERPNext on the other hand is fairly mature and fully open source: https://frappe.io/erpnext
ERPNext has a very peculiar home-grown deployment system that is required to host it yourself. I didn't much like it when I looked into it a while back.
It’s a bit different, but if you compare it to solutions from the likes or Oracle, SAP, etc. it’s significantly less awkward to develop for.
You could just use docker and pretend like bench didn't exist.
[dead]
This is open core. An old free fork: https://tryton.org
Interesting to see them on HN!
They are running a massive out-of-home media campaign in my city, they billboard even busstops in home-districts with lowered traffic speed in the suburbs :-))
also i'm seeing a bunch of youtubers i follow doing ads for them.
Huge billboards all over Nairobi, Kenya for several years now as well.
Wow, do they have already that reach?
Honestly, before they started their ad campaign here, I had never heard of them. Though the product looks very mature. Could be a "small SAP" competitor.
Oh to be unchained from the $250k/year Oracle Netsuite ERP SaaS handcuff.
I've built a couple of Odoo integrations for clients. For the longest time, they only offered XML-RPC as an external API. At some point they also added JSON-RPC, which is the same kind of suckage. But now they're suddenly planning to remove both in the next major version (to replace them with something different) with very little advance notice.
Their API documentation is virtually nonexistent. You have to basically reverse engineer their poorly documented models to get anything done, and those can change between releases. I suspect they deliberately under-document their changes in order to force people to pay them more money. At least I hope their official partners get access to better documentation.
Beware putting all of your eggs into this particular basket.
Damn. Just finished an integration with their XML-RPC.
It was quite bad experience, the API documentation is horrible as you mentioned.
Use the /doc url on your database. To test: https://demo.odoo.com/doc
Any odoo db can present you with its documentation in the /doc url
Exemple https://97044826-master-all.runbot256.odoo.com/doc/account.a... (login:admin pw:admin)
I'm aware. And it sucks. It's a poor description of an object model, it barely explains how things interact or what their significance is.
I only have horror memories for trying to integrate with Acumatica as well....
But does it suck more than oracle or SAP? That's the question...
In that sense all popular ERP vendors seems to be the same.
Dunno if Odoo is more ERP or CRM but... if you speak about Microsoft Dataverse/Dynamics 365 Sales/Customer Engagement and such, the documentation, the tools the API the underlying foundation are just excellent.
Yup, came here to offer the same sentiment on the SMB ERP systems I've worked with.
Previously: (did not deserve SCP)
2019 Story of Odoo: Open-Sourced Competitor to Oracle, SAP (195 points, 74 comments) https://news.ycombinator.com/item?id=21865699
2014 Odoo: The new OpenERP (44 points, 44 comments) https://news.ycombinator.com/item?id=7750020
Why not Dolibarr?
looks interesting
https://www.dolibarr.org/ https://github.com/Dolibarr/dolibarr
Because no one knows it. Are you using it?
Dolibarr is used by 1 million of users (so not as much as Odoo with 16m users).
Similar to Odoo in a lot of point but full opensource, more affordable than Odoo and easier to use and customize. Has less external addons (1200 vs 40000) than Odoo but external addons are rarely required. Odoo would be a better choice if you have a very large company with an internal team of developper, Dolibarr will be easier and cheaper if you have less than 5000 employees.
Disclaimer: i'm on old Odoo integrator, now Dolibarr developer.
if you go with Odoo, my best advice is to use Odoo Community and hire a good freelance developer or integrator.
In my experience, the Enterprise version is poor value: support is often absent or slow, and most of the “Enterprise-only” features are not magical—they can be developed or replaced with custom modules at a lower total cost if you know what you’re doing.
Odoo’s real strength is the unified data model and extensible core. If you control your stack and invest in competent development instead of licenses, Community can be a solid ERP foundation. If you expect a polished SaaS with strong vendor support, Enterprise will likely disappoint relative to its price.
What's the value over say, ERP5, for solo devs'?
I remember when this was OpenERP.
Been through the source code, interesting ideas in it.
Odoo ( OpenERP before) became almost the default ERP option in Belgium as far as I'm aware ( they are from Belgium as well).
Nice to see them here! I played a bit with customizing V7. Was a pretty unique experience to see how it works internally
Everything could be changed. Which is basically an advantage and a disadvantage. Please try to adjust to the system if possible :)
[dead]
[dead]
These guys have the dubious distinction of absolutely blasting tons of podcasts with the stupidest commercials I've ever heard. Basically at the level of "grondo has what plants crave", Odoo has what businesses need.
And yet you're here, mentioning the advertisement, so it seems like it worked!