ERP for an enterprize

In response to a scalability question, this is the moderately long answer:

Introduction

First, let me state that I don't believe in the word "enterprize", because it has traditionally been abused in the IT world to mean all sorts of mostly negative things, like "enterprize" as in "cost you a fortune", "enterprize" as in "absurd and complicated" etc.

Apart from that, we can stick to the literal meaning of an "enterprize" which may have 5 aspects:

1. a large number of users
2. a large number of requests and/or data traffic
3. a large database, in millions of records
4. an extensive set of operations, procedures, workflows
5. a strict set of protocols (of deployment, security, manageability) and SOPs

 

1. Number of users

Here, no truly open source software really suffers, because there is no licensing on the number of users (beware of offers that limit you on that! ). We just put a 32-bit number on the UID and let you have as many as you like.

This will hold as long until the point that too many users request something from your server, which takes us to point 2.

2. Number of requests/resources

We have all sorts of physical or soft limitations to the number of requests (and their speed) you can serve at any time.
So, you may have 10k users idling around with just a login session, but the actual trouble begins when 1000 of them decide that they want page X, now. Requests vary in nature, in the time they require your CPU and I/O to be processed.
Do remember that, by default, Postgres will only serve some hundred of connections. You might want to increase this limit, to the cost of RAM which will be reserved for the db. Other system limitations to look for is the open files, number of processes and, of course, always the available RAM.

There is two sides on scaling this thing up: you can add more hardware (on a single or distributed - load balanced - system) or you can resolve the performance curlpits to let the application run lighter.

3. Large database

Our database, Postgres, doesn't practically have any hard limits on the number of records or so. [ well, it does, but they are sky-high! ]

However, a large db will bring up all sorts of performance problems, when sub-optimal queries are used. For example, computing a set of 500 accounts with 5-10M of accounting entries would cause unacceptable delays in the application's responsiveness.

4. Operations, Workflows

There, we talk about the complexity of the ERP schema, and the implications of using it in a extended deployment.
A good ERP will be flexible, and scalable, meaning that it will allow your IT team (you have one, don't you? ) configure it and adapt to your company's complex needs.
How much would it cost to add a form? Or re-route a workflow? Or implement some custom data connector to your legacy systems?

5. Protocols, deployment

A little different from point 4., the deployment has to do with IT rules that you have chosen to follow for all your enterprize software.
Would you blindly download something from the cloudy Internetz and use it in your production servers? Would you just "place the files there" and hope it runs? Could you survive a vague release schedule, and/or distribution methods?

Conclusion

Over the years, I've tried to address as many of the above points as possible, in several complementing ways:

• extensive optimizations and profiling of the ERP
• debugging, more debugging and counter-measures against bugs
• making the framework more developer-friendly, more easy to hack and adapt to any different needs
• keeping *always* some strict design principles, to ensure that the final product will be deployable in enterprize environments, will have proper release schedules and smooth migrations.
• adding hooks for extension, so that a production server can be amended even in a "hot" production-critical setup.

That's what powers F3, as a matter of fact.

F3, a little closer

Conceived: 2009
Implemented: 2009-2011

An open-source project cannot live, nor thrive under a stubborn governance of a single vendor. No matter how nice the sales figures may be, the diminishing  community participation in OpenERP has always been a concern.

Plan A has been to convince the heads of OpenERP SA that open-source is their greatest asset, and would only remain so if they learnt to respect the open-source principles.

Now, we are at plan B, which is to evolve this project in a community-led governance model. So far (because I'm not a marketing guy), the name is "F3" as in "3rd feature branch".
Apart from a wide set of improvement patches that have been developed against 6.0 in the "pg84" and "pg84-next" branches (the 2nd feature branches), the goals of "F3" are, in short:

• to have an open project, where all contributions will be treated equally (technically bad ones will still remain out!) and all contributors will be awarded for their effort
  Note: this means we could have more than one branch, different "series" of the project depending on debated decisions. It is nice to have plurality, rather than a SVN-style "trunk" and stick with bad decisions.
• to remain compatible with previous codebase, respect the work all of us have done against previous versions. Also, respect our customers which have had wide installations and integrators that invested in them.
• to have scheduled, predictable releases. A sane release cycle with feature windows, testing periods, release + integration hold-off time. Features shall be predefined, too.
• to be stable. To be business-minded (ERP users expect a rock-solid system, not marketing fireworks).
• to be frank. Open-source is supposed to be free of marketing b**hit. No demo-quality features, only ones that can really stand in production. If we have a bug, we admit it and fix it.
• to be efficient. Both at the final product (pg84-next is already >40% faster than 6.0/6.1) and the way we develop it (right tools, debugging, tests, communication)

So far, some of you may have discovered the branches of "F3" series that are already out. That code is just the beginning, and a proof that this project is alive. More important are all these flags in my mailbox, "lost" commits that all of you had done against 6.0 and got ignored in the bzr series.

A set of design innovations and technical features of F3 is yet to be written (you know, documentation is that last task we tend to avoid :S ).

Why not Tryton? I get this question often. It has to do with the codebase, which departed from the Tiny API, back then, and would require major porting (and lack of features) from any current TinyERP/OpenERP installation. Still, their work and community model is highly appreciated.

In June 2010, in G-R, I said I would make OpenERP (6.0, then) a better product. My plain word is stronger than some who don't honor their promises (see: release date, features+support, payments).

Let the code speak for itself.