Odoo: Open-Source ERP(github.com) |
Odoo: Open-Source ERP(github.com) |
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.
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.
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.
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.
"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.
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.
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.
ERPNext on the other hand is fairly mature and fully open source: https://frappe.io/erpnext
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.
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.
It was quite bad experience, the API documentation is horrible as you mentioned.
Exemple https://97044826-master-all.runbot256.odoo.com/doc/account.a... (login:admin pw:admin)
Two of its technology bets - Python and Postgres paid off very very well. As main Cloud Providers invested tens of billions to improve both Python and Postgres over the past decade, it really boosted the Odoo tech foundation.
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
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 :)
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.
Running Odoo in a fully isolated environment within a factory, in some less popular locations - is a very frequent request. And the Community edition does check the boxes.
Pair Community edition with some in-house/custom-built Replenishment solution, and you have a very decent solution for a Distributor or Retailer.
Enterprise modules are a good value too, as long as business processes and geography do match the regions it is developed for.
https://www.dolibarr.org/ https://github.com/Dolibarr/dolibarr
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.
Been through the source code, interesting ideas in it.
What's the state here?
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
Especially in a category like ERP that has a big integrator and reseller ecosystem.
Today, we have way more free trials on the saas, than download of the open source version.
Our clients (entrepreneurs, CFO, logistic, HR ...) don't care that we are open source: they just want the best product, at a good price.
But it helped us grow our partner network of IT companies. For them, open source is a real value.
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.
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 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.
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.
Odoo is not an alternative to Gmail. (We have a spreadsheet app, but more for reporting purposes)
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.
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)
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.