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....


PostgreSQL

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.