I spent last week out in Belgium, the home of fine chocolates, waffles and Open Source Enterprise Resource Planning applications. I was lucky enough to sample all three as I was on a training course in the OpenERP head office. OpenERP 6 has just been released and it is an amazing thing to have a full ERP system that is Free Software and has Ubuntu as the preferred platform (we were all given an Ubuntu VMware/Virtualbox virtual machine for the training course). The training I did covered the technical aspects of the OpenObject framework rather than the accountancy and business management angle of the functional training, in fact throughout the course we did nothing related to moving money and stock about.
Back in the past I used to be a Lotus Notes and Domino developer, building business applications for medium to large enterprises all over the world. Notes has a bit of a reputation for being unpopular with users for a variety of reasons, but if you forget about the email client aspects of it the underlying platform is the granddaddy of all the NoSQL database engines and a forms based development environment which, despite IBM’s best efforts to break it, is still rather powerful. The OpenObject platform is similarly powerful, it has a few advantages and a few drawbacks, what I want to do here is provide a bit of a comparison and terminology cross reference between the two platforms and see what concepts are common to both. I will be referring throughout to OpenObject rather than OpenERP because I am talking about the framework on which OpenERP is written, just like Notes Mail is an application on the Notes framework.
Database / Server
The OpenERP server can host multiple databases, each one contains totally isolated set of applications and a different set of user profiles, I think of this like multiple Name and Address books and as each openERP database effectively has a separate NAB I would compare them to separate servers or perhaps domains in the Notes world.
Modules / Databases
Yeah, I know databases sort of got renamed to Applications in the Notes client but everyone still calls them databases. In OpenObject this maps most closely to a Module. A database is a collection of related stuff that comes together to peform some useful function. A bunch of modules might work together to form an integrated suite, just like a suite of databases in Notes or the OpenERP suite of modules.
Model and Form View / Form
In OpenObject you list the fields an object has in a python class. This is the back end list of fields that corresponds to the fields on a Notes form. There is a separate file in XML format where the layout of the form is defined. There is a slightly confusing terminology clash here, in OpenObject this is called a form view. If you don’t define a form view it will create an automatic one for you just laying out all the fields defined on your model with their labels in a 4 column grid. So in summary forms in OpenObject are done in two parts, back end field definitions in python and front end layout in XML.
_defaults / Field default values
default values can be pre-filled in new documents by creating a _defaults dictionary in your model class. Basically this is a list of the back end fields that you want to give a starting value to and the value you want.
_constraints and _sql_constraints / Validation formulas
The _constraints dictionary is a set of rules that are enforced just in the user interface, these are implemented as python functions that get passed the relevant field values and return true or false and if neccessary give a message to the user on what is required. _sql_constraints are written down to the database layer so will be enforced even if the document is edited programatically without using the forms user interface.
Records / Documents
OpenObject uses PostgreSQL engine as the underlying database engine, this is a big grown up RDBMS, more comparable to Oracle than the fast and lightweight MySQL. The back end of a document in OpenObject is a record in a table. These are abstracted a bit by the ORM (Object Relational Mapper) so you don’t need to worry too much about the underlying tables, text fields can have up to 1GB of text in them and you can do multivalue fields (called selection fields) and have relational fields that you can think of like an array of doclinks but actually they add columns to tables or create new tables to allow joins and things to happen in the SQL layer as appropriate. You don’t need to worry about this bit too much, it just works. Changes work too. If you add a new field to your model you can just start using it, when the server starts and updates your module it will adjust the schema without losing data to accomodate your new field. If the new field is mandatory then you must provide a default value so it can backfill the existing documents, but if not you can just add the field and start using it like in Notes.
Functional fields / Computed and Computed for display fields
Functional fields can be set to store the value to the database or not.
Read only fields / Computed when composed fields
If a field has a default value and is read only then it will act like a computed when composed field in Notes.
Tree Views / Views
So in OpenObject the UI of a document is called the “form view”, when looking at a bunch of documents this is known in the user interface as “list mode” but in the back end it is actually a “tree view” which you might correctly surmise means it can correspond to a categorised view in Notes. There have been some optimisations in version 6 which allow progressive loading of collapsed tree views which allows the client to drill down into a huge view without loading all the rows, a bit like Notes does. Unlike Notes I don’t think it does progressive loading of flat views, so you probably have to be a bit careful of lists with many thousands of rows as it will send all of the data to the client on opening the view.
Calendar Views / Calendar Views
These really correspond rather well from the OpenObject concept to the same thing in Notes, it is just a treeview but you specify the column that is your start time and which one is your duration. Time zone support is a tricky subject in both, but there is no real perfect solution for all situations when it comes to timezones.
Gantt views / n/a
I never really figured out why Notes didn’t grow a nice gantt chart view format, it would have been so easy to do, probably simpler than the calendar view. OpenObject has one and it works fine, similar to the calendar it is just a tree view and you tell it which column is the start, duration and which contains links that draw dependency lines to other documents. Simples.
Diagram Views / n/a
These allow you to map out related objects, I think it was implemented to allow a visual workflow editor to be built but I could see how you would use this to have a dynamically drawn org chart in an HR application for example.
Graph Views / n/a
Graphing data is great and this works in both the GTK desktop client and in the web client with a rather fancy looking Flash graphing object. Again, these are simple to make, just views with a few extra rules to tell it to draw a bar chart or pie chart and whether to group by a particular value and what operator to use when grouping, this allows you to have bar charts that sum values from related documents. This isn’t supposed to be a sophisticated graphing toolkit, just a nice easy way to visualise some of the data in the ERP system.
Domain / Selection formula
Domains in OpenObject are expressed in a rather odd python syntax as a list of tuples and conditions half in reverse polish notation and half in the normal order. They can be used to restrict the number of options in a dropdown list (e.g. a dropdown list of states that shows the right options based on what you choose in the country field) and can also be used to restrict what’s displayed in tree views just like a view selection formula.
Python / Lotusscript
OK so I am going to be a language snob for a bit here. Lotusscript is nice and easy, it is a dialect of BASIC and does allow a reasonable amount of modern object oriented coding, but it just isn’t an actively developed language and nobody wants to be a BASIC programmer. IBM understand this and have been trying for years to get Java to do half the stuff you can do with Lotusscript but without credible front-end integration in Java it just isn’t going to happen. Python is a proper modern language that has an active development community around it. It is as easy to use as Lotusscript, it lacks all the syntactical punctuation of Java and C++ and there is none of the indignity of having to do your own pointer arithmetic like you get with C. There are Python libraries to do pretty much anything you could possibly imagine, there is no great app store of .lsx files waiting to be called in to extend your Lotusscript capabilities.
Access Controls List / Access Control Lists
All the modules installed on your server add options to the central consolidated Access Controls List rather than each application having a separate ACL. Access can be given to groups of users at the record type or object level and you can give read/write/create/delete access. This is kind of like setting the access rules on forms in Notes (the key tab on the form properties that nobody uses because readername fields on a form make bad things happen). For more fine control there are Record Rules, this is where you would implement Author and reader field type security to allow an Employee to see HR records where the EmployeeID is equal to the current user ID for example.
n/a / Replication
This doesn’t really exist in the OpenObject world. It is a client-server model and if you want to do anything you need access to the server. You can have multiple servers in a high availability cluster but there is no multi-server replication. There is support for using the server over XMLRPC which allows a dumb client (i.e. with no locally installed code other than python) to access the full OpenObject API including methods defined in your custom modules. This could be used to write a simple offline client that can then synchronise objects with the OpenERP server. You could even write an interface to synchronise data to a Notes client. Hmm, I might actually do that at some point.
n/a / What You See Is What You Get
Notes is a WYSIWYG development environment. If you want a field label green or change a table border width you just make it so because you are simply editing a block of rich text. This makes form development in Notes falling-off-a-log easy. It also gives you the flexibility to make a right old mess on screen. OpenObject is more declarative, which leads to less addition of random bling and more consistency across the entire database, which is what you want really. A corporate theme (which I haven’t figured out how to do yet) would apply to all modules in the database regardless of where they came from.
n/a / Public Key Authentication
This is just baked in to the Notes API at a really low level and simply isn’t there in OpenERP. Yes, administering ID files can be a pain in Notes and users tend not to want to invest any time in understanding the value of them over a username and password, but having real encryption and signatures as a fundamental feature is awesome, even if they are woefully missunderstood by the development community and undervalued by the users.
One interesting and somewhat related feature on the roadmap is that OpenERP is going to grow OpenID authentication, thus it will allow you to log on to OpenERP using credentials from Google, Facebook, Launchpad accounts etc.
Internationalisation / Domino Global Workbench
OpenObject uses a common internationalisation framework used in Open Source projects based on the GNU gettext format, all modules are written in US English then all the strings are exported to a .pot template files and .po files are created with translated strings for each target language. The Launchpad website has a great collaborative interface for allowing anyone to contribute and validate translations of your modules. I have done multi-lingual notes databases and yes, there was an attempt to integrate translations into Notes in Domino Global Workbench, last time I looked at that it was a bit rubbish.
Workflow / Lotus Workflow,formally known as Domino.Workflow
The graphical workflow engine is an optional extra on the Notes side (and a pig to integrate – yes I have done it) but built in as a standard feature across all modules in OpenERP. It has a nice graphical editor and you can do quite powerful operations and state transitions on multiple objects and call sub-workflows and so on. It does take a bit of getting used to, but it is the same across all modules.
Reporting and Printing / n/a
Actually I always had stuff printing out OKish from Notes, but OpenERP has a proper reporting engine built in based on the RML Report Markup Language
It allows you to create fancy looking reports combining data from multiple objects plus images, barcodes and other complicated things.
Text & HTML / Rich Text
Well there is no native concept of rich text in OpenObject, there are text fields which can be big and can contain HTML and in the web client you can shoehorn in a web HTML editor. Basically it doesn’t compare to Notes if you want formatted text as a native datatype. That said, Notes Rich Text is a major pain when it gets down to doing stuff with it at CD record level or hacking about with rich text stored as MIME, or even using the NotesRichTextNavigator object to work with it. Rich text in OpenObject is limited, but that isn’t as much of an issue as you might expect and when you do integrate formatted objects things will at least be standards compliant and you will be manipulating HTML or perhaps ODF or possibly even MediaWiki markup – there is a wiki module but I can’t get it to render the pages – tips on this in the comments please if you know how.
AGPL / Proprietary
The OpenObject framework is licensed under the Affero GPL. This means that to comply with the license all your modules should be AGPL or a compatible license. If your business model relies on restricting the freedom of your customers you can look away now. Personally I always encouraged customers of Notes development work to review and look at my code and share and reuse it, plus I published interesting things developed or discovered for discussion with other developers in the community. I know this isn’t universal and some people do get all protective about intellectual property rights and like to hide their source code. There is actually no conflict at all between meeting the requirements of the GPL and being paid by a customer to build something they want. As long as you can get past this mental hurdle it really makes little difference to a bespoke software development business.
Notes is OK, but proprietary and closed and quirky and carrying over 20 years of baggage with it. OpenERP has more of a rigorous and correct feel to it with standards compliance, a modern framework, nice APIs and a real grown up relational back end with transactions and atomicity and so on. The NoSQL engine at the core of Notes is a great idea, and new implementations of the architecture such as CouchDB are dead handy, especially for distributed applications.
All these detail comparisons are rather academic, the bottom line is that having poked about at the application development layer of OpenObject and looking back at all the Notes applications I have written over the last 15 years or so I am left thinking that most of them I could rebuild now in OpenObject, but slightly better.
One final note, I am going to delete uninformed and outdated Notes bashing in the comments, if you were going to say something like “I once used Notes 5 in a place I worked and everyone hated using it for email” then please save the wear on your keyboard and don’t bother, but if you have some clueful and current bashing you want to get off your chest (of either Notes or OpenERP) then pitch right in.