Sunday, August 23, 2009

OpenERP vs Adempiere, an open letter to Adempiere experts

Hi, Thanks to Smile.fr my former French employer, I had the opportunity to study and compare quite deeply the main open source ERP's two years ago. I know some of them might be biased by huge financial interests and some others were simply developed without analyzing too much at the existing alternatives, or because alternatives were less apparent at that time (Tiny had closed SVN access and no mature web client yet for instance). But I know, and had even recent confirmations that at least the Adempiere community is made of a lot of independent and very skilled folks. That's why I'm very interested in knowing why they stick to Adempiere why I would myself rather stick with OpenERP. Here is an open letter to them:


UPDATE: wow, about at the exact same hour when I got interested in Adempiere again, Red1, Adempiere Malaysian rock star who was at the origin of the Compiere fork back to 2006, just released a fantastic book about the open source ERP's story. The book focus on the Compiere, Openbravo and even Ofbiz story, largely omitting OpenERP (cited only once). Still there are really really good critics about Compiere and Openbravo VC backed models; I share them at 100% and feel sorry for not having been able to be more explicit about Openbravo back in 2008. In my opinion what made Adempiere success largely applies to OpenERP (a powerful community), I even see some architectural decisive advantages in OpenERP, that's why I'm writing that post. So for folks interested about the genese of OpenSource ERP's, aside from my own study from 2007/2008 here http://www.smile.fr/publications/livres-blancs/erp-open-source, I really recommend you take the time read the Book from Red1, it's not only about ERP's, but also about open source thermodynamics of complex systems in general:
http://red1.org/aaa/WebEconomy.zip




Hi Adempiere Community.


CONTEXT: FIRST OPEN SOURCE ERP SURVEY IN 2007:

By the end of 2007, my former employer, Smile.fr asked me to do an extensive 6 months survey about emerging Open Source ERP (to be found here, sorry French was required http://www.smile.fr/publications/livres-blancs/erp-open-source ). I quickly identified Adempiere in the top 6. But I should say its integration by Smile.fr has been quickly discarded at that time because:
  • Smile was not so interested in pure community driven open source. In the opinion of Smile leaders, that model hardly ever worked at Smile, probably because they wanted to scale a lot making it difficult to rely solely on individual talents rather than being backed by a strong and reliable editor. I probably see myself more weight in those talents within the oss process because I think there have been an oss speculative bubble about to burst recently and for this successful VC baked oss projects (Alfresco?) remains the exception rather than the rule. Now compare this to talented leaders that led for instance: Linux, JBoss, Compiere before 2006, Rails, Ruby, JRuby, Python, OpenERP... This is yet an other story, but that's why strong editor backed yet community oriented oss projects like OpenERP (formerly TinyERP) and """promising""" Openbravo where favored at the time while unilaterally editor driven oss like Compiere or ERP5 were dropped at the end of the list.
  • by 2007, the path to a strong web interface was still uncertain for Adempiere given the investment to be made. On the contrary, Smile was really web grounded already.



FEEDBACK TWO YEARS LATER: OPENBRAVO DROPPED, SUCCESS WITH OPENERP:

Now I should say I have been totally disappointed by Openbravo since then. Despite the successive $6M + $12M fund raised by Openbravo, it's still very limited in term of usable built'in features and effective refactoring since their original obsolete architecture, not to speak about the lack of effective community (the vast majority of their forums is frequented by Java/oss newbies, apparently seduced by the massively funded commercial hype, but providing no valuable code/feature/help feedback). They might still have some cache to invest, let's see if their new architecture moves (Hibernate Data Access Layer, modules, new GUI which are all really at the proof of concept stage for now) brings them more community/business momentum, but I should say I'm not really optimistic about that, especially considering the competitive OpenERP global outbreak. On the contrary, OpenERP was for sure a great surprise both for us and our customers (see for instance one tesimony here http://www.erp-infos.com/info_article/m/709/anevia-deploie-openerp-en-moins-de-trois-mois.html ), allowing a sustainable business, even if it should still be considered as maturing (quickly).


RENEWED CURIOSITY ABOUT ADEMPIERE:

2 years after that survey and more than 4 full SMB's OpenERP integrations later, I recently quit Smile.fr to start my own FOSS consulting company based in Brazil this time ( http://www.akretion.com ). While working hard on the Brazilian OpenERP localization, I see that Adempiere is historically more heavily rooted in Brazil (especially because the community divorced from Compiere and because just like in lot's of developing countries, the usual SMB's proprietary ERP's from SAP, Sage and M$ didn't really attack this market yet, giving more room to oss outsiders). This led me to re-investigate Adempiere. My findings is that Adempiere is finally much stronger than Openbravo and possibly than Compiere. Indeed, Adempiere seems what more advanced than Openbravo in the process of escaping raw PL/SQL at the profit of a higher abstraction, Java code in your case. Moreover, Adempiere definitely has a strong community and it seems that with AdempiereGWT, a viable web based interface is finally emerging.




OPENERP VS ADEMPIERE IN 2009, ROUND 2:

Now I'm sorry, I still see plenty of advantages in OpenERP over Adempiere. But some of you here will know Adempiere much better than me so that's why I ask you to defend Adempiere here so that I make a more accurate judgment. Don't take this post as an aggression, just like for OpenERP, I'm really aware of the passion behind the Adempiere project and I really hope you make the most of it, emulation is always good, and I'm simply curious about what I might have missed in it.

I think that it's just too hard to really compare the raw business features beteween OpenERP and Adempiere. I think they are roughly equivalent, at some place X will have a broader scope than Y, but Y will do the thing with less bug or in a more integrated manner, so it's really just to complex to say (while it's easy to say that both along with Compiere have a broader scope than Openbravo ERP for instance). I tend to think that OpenERP has a broader scope, especially in the service area while Adempiere might have less bugs eventually at its functional core.

So, instead of judging pure business functionality, I prefer evaluating more impartial criteria that will probably determine mid and long term business coverage. Would you agree that community dynamism and technology govern this in the long run?

About Community dynamism, I would say that both are again roughly equivalent. Both are FOSS led by very passionate people (both are farm grown, just discovered this!), and also backed by active third party integrators. I think that Adempiere is historically more grounded, but OpenERP community has been growing quicker those last 2 years.
At least Google Insight shows that, but I have other indicators showing also (forum topic counts, partners network, sucess stories...):
http://www.google.com/insights/search/#q=adempiere%2Copenerp%2Ccompiere%2Copenbravo&cmpt=q
(IMHO you can consider Openbravo really overrated here because of all the money they smoke making commercial hype, when you count real third party integrations, figures are very different)

So the next factor is technology/architecture in my opinion. I think that:
- the web is the platform. An other client that the web client might be used too, but a very good web client is required to look appealing to the market
- technology should maximize code reuse bewteen third parties (=> modules repository) in order to boost synergies (eg systemic cost savings)
- technology should boost productivity
- technology should should decrease entry barrier (please no J2EE bloat for the bloat, comes a time where the community should contribute efficiently rather than spend time in compiling standards in committees, just like J2EE unfortunately ended. Bloat that is affordable for fortune 500 ERP's is not affordable for SMB's ERP's. It's not a university where you should make the system happy, real world effciciency is required.)technology should enable very broad customizations. We live in a globalized world where the survivors are the one who maintain an original business model, the others die or get merged. This means that past time where one black box ERP could rule them all is over. Even SAP approach, "we think about lots of standard business, pre-build the thousands of tables and then you need to hire a $ expert to customize it because it's so boring and if you want to develop outside behind the tables it would just cost you $ instead", is being beaten by the open API and open module system approach). Today's ERP should be highly customizable at SMB's costs.




THE MAIN DISCRIMINANT FACTOR I SEE IS TECHNOLOGY/ARCHITECTURE, LET'S GO FOR 10 REASONS WHY I FIND OPENERP MORE VIABLE:

Concerning the technology/architecture topic, I see lots of advantages of OpenERP over Adempiere. But that might just be because I don't know Adempiere enough, so please correct me and develop why you think Adempiere is better for you, I hold no OpenERP share and I'm very open.

1) Is it possible in Adempiere that a module EXTEND any core form (eg view) at any point, replacing, adding, removing form element, rather than redefining/copying the whole view or patching the original view directly in the source code which I consider less maintainable and harder to deploy? I saw few very frameworks featuring OOP at the view level...

2) Can modules extend views and business objects in cascade? In OpenEERP it's very common a customer run 30 modules, 10 being custom, and most of the 10 being only like 40 lines at most. This sytem, many small modules and large bundles of modules really makes the most of code reuse, just like OSGI for you Java folks.

3) Can a module extends a CallOut process (or Controller/Business Object layer if you prefer) and call 'super', like for instance: do the normal thing you should do when I click here and then bring me back to my custom code which do exactly and only what I need. Might be a dumb question, but that still not possible in Openbravo. From my day to day OpenERP work, that would mean way more time, patching/duplicating large piece of codes rather than acting with a surgery scalpel.

4) Is anything you do in an Adempiere client, auto-magically natively exposed as a webservice you can programmaticaly call from any system without extra coding on the ERP side? Featuring access rule and object lifecycle validations? Because in OpenERP, this makes integration so much easier. For instance I wrote an oss Ruby on Rails connector where your Model+Controller in Rails can be seamlessly imported form OpenERP while the View layer fits in Rails, and the connector is less than 500 Ruby LOC, no extra code on OpenERP. Openbravo added that recently but they only support 50% of what OpenERP does out of the box, because they only support Cread Read Update Delete and not business methods at the moment. Where does Adempiere stands?

5) I guess that Adempiere also features a "relative ID" system where you can import any XML fixtures and update existing records with their foreign keys, without any need to think about real database ID. But is it really the case on Adempiere? (For instance is is also a definitive boost with Ruby On Rails). Speaking about this I wish everybody (including OpenERP) moves to YAML as this is mostly hand written and need to be human readable and YAML beats XML here.

6) In term of scalability. We all know that Python is an order of mangitude slower than Java. But investigation shows that OpenERP SQL is quite optimized while 80% of request time is spent in the Postgres SGBD layer, so no point in adopting a faster language for less than 10% of the time (the other being latency over a good network) at the cost of code expressiveness. Also notice that raw PL/SQL interpretation is even way slower than Python... But OpenERP optimizes SQL because it leverages both an ORM level 1 cache system and also a very smart SQL cache where results are cached in columns (so read is only one select) while the cached is flushed in a transactional manner by OOP cache invalidation listeners on business objects. All this makes it very easy to have SQL optimization. Something you would achieve polluting business code a lot if you code in PL/SQL like say with Openbravo. Moreover OpenERP has native support for MPTT (Modified Pre-order Tree Traversal, see http://dev.mysql.com/tech-resources/articles/hierarchical-data.html ) making it only one request to retrieve complex aggregates in tree hierarchies like accounts and stock locations. Does Adempiere feature any of those SQL optimisation, how?

7) I think that the OpenERP Pylons based web-client (Turbogears dependency dropped 4 months ago) is more mature than Adempiere emerging web clients (Adempiere Zk and GWT). I suspect OpenERP web client is used in production in more companies (inlcuding Tiny Saas offer) and is already fully functional and fast. Tell me if I'm wrong. That said, I'm enthusiast about AdempiereGWT but had trouble following the last updates about it.

8) OpenERP is component oriented, making it so easy to compose your screens using various sub-views of all your business object tree. Is Adempiere like this or is it the Openbravo way (page oriented) where you see a record and then linked objects are always shown in other tabs rather than in the same view?

9) Finally, I know that both OpenERP and Adempiere (and even Compiere) feature a powerfull workflow engine which still lacks in Openbravo (what old code the hell did they forked?). None are a standard (but BPEL might be over-bloated for foss), so I see no difference here.

10) I won't go in a language war, but in my Opinion the Java language is being slowly abandoned ( http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html ) at the profit of less verbose langages, some being dynamic (Ruby, Python, Groovy...), while some statically typed (Scala, Clojure, D...). Notice that on the contrary, the Java Platform and JVM (portable and JIT bytecode execution which is independent from the Java language) still have a very bright future. While having been a Java fan boy by 2003, I find Python less verbose and more effective to code the business layer. Is isn't a very big win as you might argue a statically typed language makes the platform core stronger in Adempiere, which I would agree with. Adempiere might also slowly move to JRuby/Jython/Groovy JVM backed dynamic languages for its business layer while OpenERP might have a smooth transition to Jython enabling Java/scala for its very core, so no real big issue here, exept that personally I think I'm more effective today, as an integrator, writing fewer lines Python business code in OpenERP rather than in Java.


Now I easily admit some issues with OpenERP, mainly:
  • adopt a large test suite to avoid bugs/regressions,
  • set better community management process to deal with required code refactoring, API changes, release planning,
  • better ensure modules play well together to minimize runtime/integration time bad surprises,
  • consolidate financial periods ending processes and period financial reports. But so far, I think this is being solved right now and OpenERP is currently already very usable for many companies.


WHAT IS YOUR OPINION, WHAT DO I MISS HERE?

Still I'm very curious, what you Adempiere folks will answer to those points? Are you aware of those pros of the OpenERP platform (I recognize that knowing several ERP's deeply is hard)? Or is it me that misses Adempiere key points? What are those Adempiere pros over OpenERP in your opinion?