Open Source CRM and ERP: Bending the Back Office
SugarCRM, Openbravo and Compiere tap the power of open source development to make customization easy, but the line between community and commercial is quickly crossed.
I discovered the biggest gap between the community version and the professional version when testing Compiere's tools. The community version took a morning to install, and I found myself flummoxed by the client that would constantly keep resetting the Postgres port to 5444. The professional version, on the other hand, started up in about 15 minutes once I added the newer EnterpriseDB version of Postgres.
The basic community version of Compiere dates from the era when the browser wasn't as sophisticated and AJAX was just a kitchen cleanser. The community version interacts with the central database using a custom Java client. You need to buy the newer professional version to get the modern and more convenient Web-based interface.
More features start appearing once you start paying. Documentation is not free unless you sign up for the standard version ($25 per seat per month). Reporting tools are also tossed in. To get the Web-based interface you must spring for the professional edition ($50 per seat per month), a level of service that also includes unlimited support requests and other assorted bug fixes. There's also a "cloud edition" ($66 per seat per month) that wraps the professional edition into a pre-built image for Amazon's EC2.
There's not as much openness with Compiere as with SugarCRM and Openbravo. There's no open bazaar of plug-ins, nor is there much obvious energy devoted to modifying the code. Most of the threads on the forum hosted at SourceForge seem focused on installation problems. I'm not sure why. It isn't because the system is closed. In fact Compiere includes a pretty nice set of APIs and tools for calling external pieces of code.
The AJAX-enabled collection of forms for Compiere includes a number of pop-up divs that handle adding new data entries on the fly. This enforces the constraints on the tables by forcing users to fill in the entries for the sub table before adding the main rows.
Most of the customization energy is built into the tools now. Compiere calls its customization process "model driven," which means that you just start adding the columns to the tables in the data models and Compiere does most of the rest. Adding a field to a form means filling out several additional forms, an act that left me wondering whether forms begetting more forms meant that they were a life force all of their own.
One piece of Compiere documentation promised that the customization process required no "error-prone procedural programming," which I thought was a pretty accurate description. Adding new lines to the forms and building new rules for them is programming, it's just not at the grungy Java level. The developers took their ERP mechanism and applied it to managing the source code itself.
