The Making Of OpenERP
v6.openerp.com
v6.openerp.com
The good:
* Done in python. Easy to read.
* Easy to extend or modify (done via python modules)
* Supposedly can be extended/configured to a certain extent without code (field additions, etc)
* Has a long list of modules available, and core modules which support my needed (accounting, finance, warehouse/supply chain, HR/Payroll)
* Requires PostgreSQL...my database of choice.
* Seems pretty stable...I haven't hit many bugs yet.
* Fully open source under the AGPL...you get the entire product, unlike others such as OpenBravo and XTuple where you have to pay to get certain features. The flip side of this is that because it's AGPL, you have to release the source any modifications or modules you make unless you pay OpenERP for a subscription (and consequently, a different license)
The bad:
* The documentation is badly out of date. There are two versions...web-based and PDF. The web-based ones are more updated, but still out of date. Trying to learn as complex a system as an ERP with broken documentation is a very frustrating exercise. This is probably to biggest headache for me and it has significantly slowed our evaluation. It'd be at least a little better if I could pay for improved docs, but this is all they have...even paying customers are provided out-dated documentation.
* Not many success stories in the US. I get the impression that it's more popular in Europe (OpenERP is out of Belgium).
* Company is a bit unresponsive. I've contacted them and had very little successful communication with them, even though they have a US rep. If you read online, others seem to have had similar problems.
- Internal inconsistencies w.r.t formatting -- sometimes there's newlines between functions, sometimes not.
- Docstrings are fairly haphazard. I remember seeing some somewhere, but can't find them anymore. I have no idea what the `ir` module does or what it's for.
- The custom ORM (`bin/osv/`) scares the daylights out of me. It only has 4 test cases that I can see (in `test/test_osv.py`). I don't see any test cases for the DSL that the `osv` module provides.
- It appears that the ORM uses raw SQL as an intermediate for composing queries, then uses regular expressions to extract data from these intermediates.
I've only spent 10 minutes thumbing through the code, haven't read the docs or anything, so the above is a very shallow analysis.
Generally, I find the code to be well-organized and easy to find (it's just a set of python modules for the most part). I can't speak to the syntax formatting or functionality of the ORM yet...
You can get an overview of the technical "core" in the Memento: http://doc.openerp.com/memento/OpenERP_Technical_Memento_v0....
Here's what I can find:
5000+ lines of ORM code: http://bazaar.launchpad.net/~openerp/openobject-server/trunk...
300 lines of tests: http://bazaar.launchpad.net/~openerp/openobject-server/trunk...
The ORM code is fairly shocking - really hard to follow, hundred line methods/functions and multiple one and two character variables.
That said, the addons I mentioned _are_ part of the core. OpenERP is an extremely modular system, where even some basic blocks are modules. But these modules come with the server, not with the "addons" set. See https://bazaar.launchpad.net/~openerp/openobject-server/trun...
Also, there is a Montreal (EST time zone!) based consultancy company called Savoir-Faire Linux that are involved in the development of OpenERP, and can help you with any implementations.
Completely normal, this is one of the common risks with software projects:
".... This is a fact that companies do their best to have revenue since the first days of their creation. This implies another fact that always a proper documentation is the last thing they provide to the users....." (http://www.drdacademy.com/?id=17)
SAP suffers from the same problem too. Of course, this could be a business objective for the software producer, since, training brings in income.
* Yes OpenERP is easy to extend and modify and has a good modular architecture. However, the API is badly broken, have a look at an on_change event handler on the server side [2]. Think of modifying this in your extended module!
* Extending/Configuring without code is marketing speak. It sounds and looks great for a demo, but is impractical to be used in any business. For example, you modify how a product view looks like by changing it without code and it works, then next time you upgrade the product module, you will lose all the changes. It is also a quick recipe to making your ERP a 800lbs gorilla which cannot be maintained.
* They have a long list of modules. Most of the modules are crap uploaded by OpenERP partners who implemented some specific business case for a customer of theirs and is not generic. In most failed OpenERP implementations, the primary reason is almost always these extra modules which introduce dangerous bugs. I would not blame the developers alone, because OpenERP itself lacks a culture of testing and lacks sufficient tools to test the software. Be sure to evaluate every module with real world business cases. For example, purchasing in a different currency could be a feature on the "wishlist" [3]. And BTW.. they have a module which can order " sandwiches, pizzas, prepared meals, etc." for the 2500 employees :P (i am not joking [4])
* Postgresql - it's a great database, but badly misused in Open ERP [5] (it is from the core stock module which keeps track of your inventory). I will personally not trust any software which uses "distinct" [6] in a query as important as that. It also shows how OpenERP will not scale and how Open ERP developers lack the basic knowledge of SQL (not that they know better python).
* Open ERP is far from stable. Memory leaks are pretty common and add to that poorly written python. We have been maintaining production instances for a really long time and I would not find it a stable software.
* As for AGPL - it may not be the right license for an ERP. AGPL requires you to make the source of the software available as a downloadable link to all users of the software. Would you be willing to do that for all your employees ? And moving a bit more back - they switched overnight from GPL to AGPL claiming OpenERP SA owns all the copyright. Even if we assume they really do, you have an "open source" software which has no community contributions or you have a software which has a license which stands to be sued by any previous contributor some day.
* Success Stories: There may not be many actually. I personally know several of the companies in the openerp success cases page who do not use OpenERP anymore.
* Partners/Implementors of Open ERP: Here you will find the good, bad and the ugly. There are some great implementors who understand OpenERP well but may not necessarily be the partners in the spotlight. The gold, silver and ready partnership levels are just a matter of how much money you paid Open ERP SA (the company behind openerp). Chose your implementor very carefully. If they say, it has everything you want and works just like that - they are lying to you. I recommend reading a recent article a community member has written, it's pretty detailed and in french (but google translate seems to translate it well) [7].
And finally, the recent fuss about "sorry sap". It looks more like an ambitious plan to have a negative social campaign about SAP and hope that SAP would fork out a few million dollars to acquire them. Venture capitalists who invested in OpenERP surely have an exit plan ?
[1] http://bazaar.launchpad.net/~openerp/openobject-server/trunk...
[2] http://bazaar.launchpad.net/~openerp/openobject-addons/6.1/v...
[3] https://groups.google.com/d/msg/tryton/1kOND1_kGZ8/7MCU2V699...
[4] http://v6.openerp.com/node/1278
[5] http://bazaar.launchpad.net/~openerp/openobject-addons/trunk...
[6] http://www.thedwick.com/2005/11/how-distinct-hides-bad-sql/
By any mean, any communication coming from OpenERP (and partners) must be taken with a grain of salt. It's not that it's PR stunt level but it's often not very far.
That said, there's not better OpenSource alternative.
Also, don't be lured by the OpenSource term.
Also, disclaimer: Sharoon Thomas (if that's actually him) is involved in Tryton (http://www.tryton.org/en/) which is an OpenERP fork. Better in some ways, worse in other ways.
Anyway:
* I work for Openlabs (http://openlabs.co.in)
* I am a board member of the Tryton Software Foundation (http://foundation.tryton.org/) (The entity behind Tryton a fork of Open ERP)
* But, all the above views and opinions are personal.That said, I think your remarks are that of anybody who has expertise in OpenERP and who finally feel free to criticize the software. Me an several of my ex-coworkers share the same.
The business model is interesting though. The days of the 90% profit margins SAP/Oracle get on their maintenance combined with their outdated software licensing model, lends itself to be highly disrupted. My money is currently on Workday to be the market leader.
http://www.workday.com/company/leadership_team/aneel_bhusri....
Highly recommend watching this video: (especially if you're a techie interested in this area)
Also, as mentioned somewhere else in this thread, ERP software (Payroll, HR, Financials, etc) are all about the details. Payroll and Financials are very complicated, which results in companies only trusting the big players (SAP/Oracle)
Disclaimer: I work for Workday
I can honestly see why you might think that (I've had exactly the same thoughts before) - then you find out what a Tier-1 ERP does and can be quite a staggering collection of functionality a lot of which is absolutely required and not optional.
Most SAP horror stories are from customers who don't realize their ability to process their Accounts Payable isn't a business core competency and is not bringing them competitive advantage.
If customers come around on this, THEN the days of SAP will be numbered.
Yes, basically this. Often what I found is that customers and vendors are extremely complex in the way they do business. "But we want to pay in 34 days, and if we pay on the 31st day at noon, we get a .005% discount relative to the current exchange rate" Try doing that in your self-made python system, that scales, has high-availability, disaster recovery, is available in 92 countries, and has an ecosystem of developers that come cheap from Asia.
What I actually find is that the people who are making the decision to purchase the software want to make sure they have the most feature rich system so when things do change, the "TCO" isn't impacted and they can fairly easily satisfy the changing requirement. I believe half of enterprise software is just deciding what the requirement is. (which is really no shocker to those is non-enterprise tech)
SAP ERP is pretty stable. That's what customers are paying for. Material management has been debugged for decades. Try to compete with that. A couple of python scripts seem like a nightmare to me.
Yes, the code is horrible and ABAP itself is a nightmare, but the software as product is very hard to tackle. The only way I can think of is a disruptive move of Big Business in general, ie. small networked entities instead of crusty old ones.
I don't see a single customer here that is either a Fortune 500 or close to being that size: http://v6.openerp.com/products/new-references
PS - A note to the guys from OpenERP if they are reading. I would recommend doing something SAP does really well - touting it's customers success very publicly. It will massively raise your profile. Example: http://www.saphana.com/community/customer-stories
Note - I hope people understand I'm not criticizing them for their success, but rather for their statement that they are directly competing with SAP. They may be gaining market share in SME, but until you are doing this: http://www.workday.com/company/news/press_archive/kimberly_c... you are not really competing with SAP's bread and butter. And again, congrats to your success. I would be as chuffed as the author is here.
But, one of the most important reasons, as OpenERP have just proved, we're often crap at it.
BTW, do not make the mistake of dismissing OpenERP as a small player in a market dominated by giants like SAP. OpenERP is asymmetric competition for those giants! The company's goal is to shrink the market, by taking away more of revenue from competitors for every dollar the company earns.
As Josh Kopelman of First Round Capital says, "We love investing in technologies and business models that are able to shrink existing markets. If your company can take $5 of revenue from a competitor for every $1 you earn – let's talk!"[1]
Congratulations to Fabien Pinckaers and the rest of the OpenERP team!
--
[1] http://redeye.firstround.com/2006/04/shrink_a_market.html
One of my best customers (in terms of contracting work) is an electrical motor company who has an Oracle EBS and a QAD MFG/Pro install. When they expanded to China, they didn't want to use either MFG/Pro or Oracle EBS for IP/InfoSec reasons, so we customized Adempiere to fit their needs, and then generate data that they could batch import nightly into their MFG/Pro and Oracle EBS systems. Their CFO and CTO (at the time) were so impressed, they ended up rolling out Adempiere out across their organization prior to being acquired.
This version of OpenERP looks much...smoother (with an emphasis on UI) than the previous versions of their software; major kudos are in order. :)
Look at this recent ERP disaster for the AirForce .. DEAMS.
One billion spent, then scrapped.
Dod Audit report: [edit] correct one here: http://www.dodig.mil/audit/reports/fy12/DODIG-2012-140.pdf
News report: http://www.dailytech.com/USAF+Staff+Appalled+at+Wasting+1B+U...
http://www.xtuple.com - company site http://www.xtuple.org - community site
I would strongly recommend anyone considering using OpenERP in the US to find a company currently running any version and ask them about their experience.
2. Things like reconciling bank accounts and taxes are geared towards a European system that seems much different than ours, and as a result cause a lot of problems in a US implementations. Again, OpenERP doesn't have a localized US package that addresses these issues in a concrete way. Searching for help, you'll probably be referred to half finished module, with 0 documentation that still requires a lot of work to be ready for production.
3. On the stock and manufacturing side of things the system works much better in my opinion. And with the right amount of work done up front, the they both offer flexibility while following a strict business logic[2] set in place at the time of implementation, that they can do some amazing things for a sales / fulfillment side of the organization. The reporting and automation that OpenERP can provide on this side is really awesome.
[1]. I am not an accountant. [2]. It is a ton of work defining a business's process in the terms of an ERP. Sometimes I felt like OpenERP got blamed for a company poorly defining their process (if they even had one) So be wary of that when looking at forums and things...
About bank reconciliation, what is the issue?
We're porting our modules (infamous plug: I work for ThinkOpen Solutions) and v7 is definitively a big improvement in terms of the interface, including usability.
The core seems to be more stable, both in terms of regular use as well as API, and the functionality seems better integrated. The new messaging system is definitively nice.
The release notes for 7.0 are worth a read if you're interested: http://v6.openerp.com/node/1272
Great idea, but I don't see an untested open-source application disrupting SAP or Oracle anytime soon. Workday is even closer to that. The devil is in the details and even small errors in HR, such as vacation balances being off by percentage of an hour... or invoices not being penny accurate will test this product.
Moved to Tryton ( http://www.tryton.org/en/ ), which is a lot more pythonic, a lot more concise and follows standards, including PEP8 and company still Tryton today.
Financials and forecasting with OpenERP can be a mess, specially when you get users that are used with quickbooks.
Check Tryton ( http://www.tryton.org/en/ ). I am sure you will like it. There are a bunch of modules that also install as python modules, virtualenv support, PostgresSQL, clear development roadmap and much more. Also, thre is this magento integration that is pretty nice -> https://imagento.openlabs.co.in/
EDIT : you need to go on this page and share http://www.sorrysap.com/
EDIT 2 : or try https://demo1.openerp.com/?ts=1355245099781#page=0&limit...
Have been developing ERPNext (https://erpnext.com) on similar lines. Its no where near OpenERP but would love to get some critical comments.
Also still no paypal integration, Google checkout, stripe, paymil etc.
Not sure what you're aiming at but ERPs are not magento plugins.
You honestly expect me to make a professional recommendation for software I can't even show the demo for? SAP sucks, we all know but I fail to see how your product sucks any less except for the price tag. Is that your pitch? We suck just like SAP but for less money.
Recreate instructions? It appears at least one of their employees is monitoring this thread...I'm sure they'll appreciate your help.
I am the CIO for a $300M company. We have two ERPs in-house, one of which is a very profitable and widely used off-the-shelf system. Over our three years of use of said system, we have found a number of bugs. We find them, we report them, and they are dealt with (albeit a bit slowly). We'd fix them ourselves, but of course we have no access to the source (which is not the case with OpenERP).
Hurry...please point out an ERP which doesn't have bugs. You can't. It sucks you found one in OpenERP so quickly, but complaining about it without offering recreate instructions is useless to everyone.
As far as the product not being released... The guy is advertising a huge "SUCK IT SAP" website bragging about the new version of their software being released in 9 days. Not exactly an alpha version here.
I fail to see what the size of 'your' specific company has to do with anything. Anecdotal evidence is just that. 'Your' company might have the technical resources to fix bugs in open-source software, but that can't be a serious suggestion. That's like saying every enterprise out there should keep technical staff on-hand to patch the linux kernel. That's silly.
I posted a screenshot in another reply but in case you care, here's the bug that basic, and I stress that word, testing would have caught.
Easily reproducible in two seconds by simply using the interface.
It's not that I necessarily like the product yet, but I'm willing to give it a shot, and willing to accept that there might be bugs.
Sorry you have problems with it. Can you tell me what browser did you use? I ask you because OpenERP 7.0 doesn't support IE 8 or lower, unless they have the Chrome Frame installed.
I'm not going to go back and open up the developer tools to see which part of the buggy javascript UI crashed. I will say again though that the UI was throwing 'unhandled exceptions'. Do I really need to defend myself here? When is it ever a good idea for a user of a piece of software; especially ERP software which by it's very nature will interact with non-technical users constantly, to ever see an unhandled exception. Come on.
Just for fun. I went back to their website: demo1.openerp.com. It takes 2 seconds to crash their websites by interacting with it. Just click on their navigation links on the top of the page quickly.
Here is a link: http://imgur.com/fp8oW
This is an easily reproducible problem. Come on.
OpenERP Server Error
Client Traceback (most recent call last):
File "/home/odoo/source/web/addons/web/http.py", line 195, in dispatch
response["result"] = method(self, **self.params)
File "/home/odoo/source/web/addons/web/controllers/main.py", line 724, in create
params['create_admin_pwd'])
File "/home/odoo/source/web/addons/web/session.py", line 28, in proxy_method
result = self.session.send(self.service_name, method, *args)
File "/home/odoo/source/web/addons/web/session.py", line 95, in send
raise xmlrpclib.Fault('AccessDenied', str(e))
Server Access denied.I'm glad. Alas, I know many people who are forced to use IE in their workplace.
I'm not attacking you or asking you to defend yourself, just offering a suggestion. I hadn't try the demo site, but we've been working on 7.0 for a few weeks and we didn't have such issues, and the Runbot instance[1] is also working fine.
If I may ask, where did you get that link? Did you "shared the news" and got the link from them? Because that demo site seems outdated, and not linked from the site.
For instance, here is one: https://demo2.openerp.com/#action=114 that was posted a few comments up.
I've tried pretty much all of them listed in this thread. They all take me to the same interface that crashes.
* the product is NOT open source if a single company owns the entire copyright ? why will they not call it proprietary tomorrow ? (they don't have a contributor agreement either)
* AGPL is the wrong license to have for an ERP system. In addition to all its ambiguity, AGPL software "must offer an ... opportunity for all users interacting with your Program through a computer network to request immediate transmission by HTTP of the complete source code of your modified version or other derivative work" [1]. Does that mean that 2500 users of the software in your company should be able to download the source code of your ERP to comply ?
For me, the license switch was to make the software impractical to use for any serious business and offer a "private use" license at a price as a vendor lock in.
What's wrong with that? First, I'm free to use the code at no charge to me. I'm even free to customize it as much as I'd like...I just have to make a link available to those customizations that my users can access. I have no problem personally doing this...none of our users would have any interest in the code we develop. If I do decide downstream that I'd like to develop a private module, I can approach OpenERP and subscribe. I've already received pricing, and their cost for 1000 users annually is cheaper than what I pay for our commercial ERP for 100 users.
The way I see it, the AGPL insures that OpenERP (the company) gets their due for giving away the code. Nothing more. Seems fair.