> 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)
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.
> 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.
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.
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)
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.
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.
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
Odoo, an open source invoicing software, produces factur-x invoices systematically (whatever the country): very convenient as it's parsed automatically.
Invoices in Sweden have a design created for easy OCR-scanning. I prefer this way because it means that there can be no discrepancy between what I see and what the machine sees.
Another benefit is that it's really easy to recognize an invoice at a glance, and you know exactly where all the info is.
