This post is the first in what may become a series of stream-of-consciousness thoughts on OpenERP, for those who want to follow my journey dealing with OpenERP. While there is no intention to state things that are untrue or misleading, stuff said here is just my current perceptions and has not been checked for accuracy, so it may still be untrue, unfounded, wrong, etc. and it may be just me letting off steam. So read here with a healthy dose of skepticism. Consequently, this post will get deleted in due course.
Submitted some bug reports (e.g. https://bugs.launchpad.net/openobject-addons/+bug/690044); some of them got filed in the “Won’t fix” category, which means “this is acknowledged as a genuine bug but the project has no plans to fix it” according to https://help.launchpad.net/Bugs/StatusesIn other words: there are over 300 modules in OpenERP, BUT some proportion of them won’t work with each other – there are known bugs which stop them working, and there currently isn’t a plan or schedule to fix those bugs; they’re sitting in limbo in the “Won’t fix” category.
Incidentally, some of the bugs reported highlight one area where Dot Net is more mature than Python – the area of versioning of libraries and type-checking. In the Dot Net realm, bugs such as these (in the Python realm) just wouldn’t exist:
About all those modules in OpenERP
Most of them really should be called “modifications” not “modules” because they’re just small features that can be added on to what other people would call a module. So, at a guess, there’s really only around 50 modules in OpenERP.
What’s good about OpenERP
- Cost – it’s free.
- It has a decent desktop interface. Some web-only packages have written off the speed-hungry power users; not so with OpenERP. Also, the desktop interface is available for Windows, Linux and even Macintosh desktops.
- It has a very decent web interface.
- You write code only ONCE for both the desktop and web interfaces. The web interface is also quite functional.
- Python – it’s written in Python, and it’s really efficient to code in Python as compared to Java or even C#.
- The multi-language implementation rocks. You can translate labels on the screen as well as your own data, e.g. your product code can be presented to one user in English and another user in Chinese.
What’s bad about OpenERP
- It’s got scalability issues – look at the bugs for performance issues in Launchpadand in the OpenERP Forum, especially this issue. Also check this post about Python performance: Python’s GIL is evil.
- It’s got heaps of missing functionality – it’s fine if you’re a small business, but for medium businesses, it just won’t cut it. For example, the stocktake (aka. Periodic Inventory) is very basic – no freezing of stock counts. Lots of reports, such as the Debtors’ (AR) Aged Trial Balance, are missing.
- It’s just not ready for the western world yet. E.g. the GL Financial Reports list the total amounts then the composite records UNDERNEATH instead of the other way around. For the Australian market, it doesn’t yet have a BAS report for GST.
- I don’t like the ORM – it’s home-grown. I don’t think it’s multi-threaded; the database layer is NOT separated from the ORM layer (unlike the Tryton ORM) – they could have had database independence – sigh. This cuts them out of the Microsoft-SQL-Server-only places. The ORM looks a lot uglier than C#’s ActiveRecord implementation http://www.castleproject.org/activerecord/.
- Some of the code is badly written (as is common in many products, unfortunately). http://www.openerphell.com/
- The Windows GTK client is a bit clunky – you can hit a button but sometimes nothing visible will happen for a few seconds, not even an hour-glass (or a circle nowdays). This is even on decent hardware. You should get immediate feedback, always, even if it’s just a busy-hourglass.
- There’s still a fair few bugs – see the list in Launchpad.
- Lack of type checking in Python – the whole issue of type safety is to reduce bugs; testing to find bugs is not as rigorous as compiler type-checking.