Saturday, March 17, 2012

Why LedgerSMB is Headed for Greatness

Edited 2012-03-21 based on feedback from Ned Lilly.

Ok, so this post is going to be about the ERP market, and why LedgerSMB is headed for greatness.  We are a long-standing open source project and are not going anywhere soon.  There are significant strategic reasons to choose LedgerSMB over others.

We have made a lot of progress since we started, and that progress is expected to continue to accelerate.  Here's why....


First, we are great because of PostgreSQL.  There is no getting around that.  PostgreSQL is an awesome database management system for ERP's.  While there are some things it doesn't do yet as well as I would like, no other RDBMS does these either (see my recent post about this).

However, what PostgreSQL offers is an extremely powerful set of tools for addressing an ERP environment, and without per connection license costs.  The latter is especially important because it allows for additional utility programs to connect to the database and perform tasks without this requiring additional client access licenses and there is a lot that can be done with the flexibility that results.

Currently we take heavy advantage of PL/PGSQL and various built-in types and functions.   While there has been some talk of using PL/Perl and other stored procedure languages, we haven't yet found a case where this makes sense.

It's worth remembering that most of the work in an ERP system is in storing, retrieving, and displaying information.  The database is the ideal place to put all of the logic regarding storing and retrieving the information, as well as some of the display logic.  Consequently we are becoming more database-heavy and lighter-weight on the Perl side.

Less is More

In LedgerSMB we focus aggressively on overall architecture, with the idea of flexible, re-usable modules which get the logic right the first time around.  For 1.4, we are removing the project and department system and replacing it with a more general "business reporting unit" system.  This allows us to offer project accounting, department reports, manufacturing job costing, and more, without dedicated code to each task.

Differences are then handled by workflow scripts rather than by the model.  This ensure that the application can eventually be a simple yet powerful ERP development environment rather than an application which must be everything to everybody.

Each major release of LedgerSMB has had more features but a smaller code base than the previous version.

This approach is good for a number of reasons.  First it places emphasis on where the emphasis needs to be:  on LedgerSMB as a platform.  Secondly it encourages flexibility in implementation while focusing on getting the details regarding accounting right.  It also gives us fewer maintenance points and hence a better, higher quality codebase.  There are many more reasons why that is the case, but in general we try hard to do more with less.

LedgerSMB is a Multi-Vendor Project

 Most open source ERP's are single-vendor products that make money selling enterprise versions.  This means that the community version is basically a sales tool and many features will not be added for fear of hurting the vendor who sponsors the tool.

LedgerSMB began as a joint project between Metatron Technology Consulting and Command Prompt Inc, with a number of other consultants joining in early.  While the ecosystem is constantly in flux as new individuals enter the project and old ones leave for one reason or another, one theme remains the same:  you can get top-notch support from a variety of sources, and no company retains a monopoly on commit privileges.

This changes the dynamics of the project.  Instead of releasing a moderately functional tool open source and then charging for advanced features, we release most things open source and only where that model breaks down do we look at subscriptions.  This allows us to do things that other open source projects in the area have not yet been able to really try to do in a significant way, such as good working payroll systems with maintained rules for various tax jurisdictions (forthcoming in 1.4 at least for a couple of jurisdictions with more coming).  Instead of paying for fixed asset management, you can save that money and put it towards things that matter, like maintaining payroll logic.  The logic "sold" under subscription can even remain open source, since the major problem is just that of keeping the code up to compliance with the latest regulations.

LedgerSMB is a Development Platform

 LedgerSMB 1.3 and higher isn't intended to be just an ERP application, but rather a development platform for helping businesses implement ERP applications in accordance to their workflows.  The framework while minimalist is designed to facilitate rather than get in the way.

The framework is designed to get your teams of developers up and running as quickly as possible.  The object model is designed to be clean, and most of the actual work is shipped off the the database via stored procedures, or handed off to modules to parse templates, or handed off to various CPAN modules.  The actual Perl code is basically glue that holds all the rest together.

One advantage to this sort of platform is that reference implementations can be created in other platforms as well, and the basic framework can be set up such that it can be used for non-interactive batch jobs or thick clients, not just web applications.  In fact that has been a major guiding feature of our framework.

Secure by Default

LedgerSMB  has made security a top priority since the beginning of the project.  By default users cannot do anything in LedgerSMB, but beyond that even if they find and exploit holes in the web application, the security is still further enforced on the backend.

We are trying hard to provide industry-leading security, and such that can be enforced even when integration with other software is at issue.   We have plans to support Kerberos 5 authentication as soon as it is needed, as well.

Comparisons to xTuple

LedgerSMB and xTuple share a common approach to the database.  We are both heavily stored-procedure centric.   Both of us focus heavily on the database as an engineering discipline in itself.  This means that both of us focus heavily on interoperability with other applications and a good API.

There are however two important differences.  xTuple is a C++/QT application while LedgerSMB is written in Perl.  This means that LedgerSMB can deliver rapid application development possibilities in a way that xTuple cannot.  Rapid application around xTuple would require using other existing frameworks.  Rapid application around LedgerSMB can be done in within the LedgerSMB framework.   This first difference is critical because larger businesses fundamentally buy ERP frameworks as development platforms, while smaller businesses haven't yet found the value in doing this (something LedgerSMB hopes to change).

Secondly, xTuple is a single-vendor solution.  It is offered by a single company, which owns the codebase, and sells add-ons.  This means that the incentive for the company is to release as little as they can and remain viable while selling licenses to as much as they can.  Since LedgerSMB is multi-vendor, the incentive is to provide as much open source as possible and sell as few addons as possible.  One can see already that LedgerSMB comes with fixed asset management for which xTuple charges about $700.  As we continue to develop, those areas where xTuple is currently ahead (such as manufacturing) will probably disappear, and the areas where we offer features that xTuple sells for profit will likely increase.

The above paragraph has been stricken because, as Ned Lilly points out it is inaccurate.  In fact the fixed asset tool was developed by a third party, and this is one area they cultivate around their market.  He points out further that this is an example of rapid application development in Postbooks and therefore I am incorrect there.  He further asks me to suggest that their incentives are not to reduce a minimalistic product.  If their marketplace materials are not mostly made by them, then I would agree on all these points.  Points accepted.

I will however stand by the point that generally single-vendor solutions tend to have incentives to release minimalistic solutions to encourage folks to buy licenses.  Kudos to xTuple for not falling in that trap.

I will also have to look a lot more closely at how this Javascript automation is doable.  It may be possible in essence to do a fair bit more than I had considered here.

Comparisons to OpenERP

OpenERP is an open source, single-vendor ERP solution written in Python.  It features a pleasing interface, a modular structure, and so forth. However the same problem occurs relating to single vendor management.

OpenERP offers rapid application development possibilities both in Python using the framework provided or in it's "application builder."  However, what OpenERP as a business is really interested in selling you is a software license for the full version, which gives you exemptions from the requirements of the AGPL v3 as well as technical support.  This makes it harder, I think, to leverage a larger development community around the software.

Comparisons to OpenTAPS

 OpenTAPS is an ERP application and framework that is multi-vendor, built in Java, and supports multiple databases.  It is based on the Apache Open for Business ERP framework.

OpenTAPS is impressive, features-wise, and it is used by some major corporations, but the choice of Java as a language means that development is less rapid than it would be in Perl or Python, and therefore the framework capabilities are more within the reach of large businesses, which likely have internal development teams familiar with Java, than small ones.  This means that small businesses are still faced with the necessity of building business processes around the application rather than the other way around.  It is therefore more of an upper-market product, while LedgerSMB currently shoots primarily for the midrange.


  1. Chris, a couple of factual errors and details that you've overlooked in your comparison with xTuple.

    First, you don't seem to be aware that xTuple supports Javascript extensions to the Qt/C++ core code base - and has for the entire 3.x series, going back to 2008. There is ample documentation around this capability, which most people would indeed see as a development framework. You can use multiple tools to do this work, including the embedded screen designer and IDE, which has pretty decent debugging tools.

    In fact, the fixed-asset management tool, which you mistakenly state is developed by xTuple for $700, is actually an example of this capability. It's developed fully in Javascript packages by an independent developer based in New Zealand. He makes the base package available for free on our xChange online store, and has two commercial add-on products covering depreciation and ongoing maintenance.

    Finally, I would be careful about making sweeping statements about what another company's incentives or motivations might be. At xTuple, we developed our entire codebase from scratch, and have made the core PostBooks functionality - which covers all accounting, CRM, sales, purchasing, reporting, and a great deal of inventory, manufacturing, and distribution - available free and open source.

    We generally don't engage in direct tit-for-tat with other open source projects, as we feel there's enough opportunity out there for all of us among the bloated, nasty, closed-source commercial incumbents. But in this particular instance, I felt that your post called for a direct response.

    We wish you guys all the best.

    Ned Lilly
    CEO, xTuple

    1. Hi Ned;

      First, I want to apologize for the delay in replying. I have been pretty sick for a few days and just now recovering.

      I was not aware that the fixed assets module was developed by someone else. I assumed it was done so by you. It's also good to hear there are some RAD functions in xTuple.

      Give me a couple more days and I will either your feedback into the post (and credit you with it!).

      Anyway, thanks again for the corrections and feedback.

      Best Wishes,
      Chris Travers

    2. Actually will get this done right now. Thanks again for your feedback.

  2. Hi,
    My name is Tatiana, and I have a problem with a PostgreSQL database. When I try to access the program and type the password I receive an error message:

    Server doesn`t listen
    The server doesn`t accept connections: the connection library reports
    Could not connect to server: Connection refused (0x0000274D/10061) Is the server running on host “” and accepting TCP/IP connections on port 5432?
    If you encounter this message, please check if the server you`re trying to contact is actually running PostgreSQL on the given port. Test if you have network connectivity from your client to the server host using ping or equivalent tools. Is your network / VPN/SSH tunnel / firewall configured correctly?
    For security reasons; PostgreSQL does not listen on all available IP address on the server machine initially. In order to access the server over the network, you need to enable listening on the address first.
    For PostgreSQL servers starting with version 8.0, this is controlled using the “listen _address” parameter in the postgresql.conf file. Here, you cant enter a list of IP addresses the server should listed on, or simply use ‘*’ to listen on all available IP addresses. For earlier server (Version 7.3 or 7.4), you`ll need to set the “tcpip_socket” parameter to ‘true’.
    You can use the postgresql.conf editor that is built into pgAdmin III to edit the postgresql.conf configuration file. After changing this file, you need to restart the server process to make the setting effective.
    If you double-checked your configuration but still get this error message, it`s still unlikely that you encounter a fatal PostgreSQL misbehavior. You probably have some low level network connectivity problems (e.g. firewall configuration). Please check this thoroughly before reporting a bug to the PostgreSQL community.

    I checked the postgreconf.file, and it is configurated with ‘*’ for “listen_addresses”. The other thing that I checked was the firewall, which said “Allowed the conection” to port 5432.

    The logs file says:
    2012-04-03 14:48:17 VET LOG: database system was interrupted while in recovery at 2012-04-03 14:39:01 VET
    2012-04-03 14:48:17 VET HINT: This probably means that some data is corrupted and you will have to use the last backup for recovery.
    2012-04-03 14:48:17 VET LOG: database system was not properly shut down; automatic recovery in progress
    2012-04-03 14:48:17 VET LOG: redo starts at 1D/2D0689F0
    2012-04-03 14:48:17 VET LOG: loaded library "$libdir/plugins/plugin_debugger.dll"
    2012-04-03 14:48:17 VET FATAL: the database system is starting up
    2012-04-03 14:48:18 VET LOG: could not open file "pg_xlog/000000010000001D00000031" (log file 29, segment 49): No such file or directory
    2012-04-03 14:48:18 VET LOG: loaded library "$libdir/plugins/plugin_debugger.dll"
    2012-04-03 14:48:18 VET FATAL: the database system is starting up
    2012-04-03 14:48:19 VET LOG: startup process (PID 2580) exited with exit code 255
    2012-04-03 14:48:19 VET LOG: aborting startup due to startup process failure

    When I went to “Services” to start the service, I received this message:
    The PostgreSQL Database Server 8.3 service on Local Computer started and then stopped. Some services stop automatically if the are not in use by other services or programs.

    Thank you for your time and assistance.

    1. Hi. the pgsql-general list is a great place to ask these questions. I would recommend asking there instead.

      Nonetheless, this looks like database corruption to me, from the log messages you have posted. If you have important data that you can't afford to lose you may need to hire an expert. If not, or if you have sufficiently recent back-ups, you can delete your data directory, and either restore from a base backup or use initdb, and then reload from a dump.