Compiere from the Source

Open Source Business Models (for Compiere)

In this post, I elaborate on options of open source business software providers based on my experience with Compiere. This is from the perspective of an open source vendor/provider - and with the assumption that you are looking for an income stream.  This is a bit different from the interests of businesses using open source products for income.  In the first part of the series, I outlined the development of the open source business model of Compiere, in the second one the dynamics of open source contribution I experienced.

Open Source basics

The fundamental promise of open source is vendor independence, that you can use and modify the the product ... assuming you have the skills and time.

From an commercial open source provider point of view (i.e. you want/need to create income), the fundamental challenge is that users have no obligation to “give back”. This giving back might include contributing product enhancements, helping others or donations.

In addition to providers and users there is a third group: intermediaries, who help end users use the product in exchange for payment.  Also here no obligation to give back.

A challenge for commercial open source vendors is that - if the project provides true vendor Independence - despite best intensions, in tough times payments to the open source vendor are in danger of becoming discretionary.

The basic question: How do you want to make money?

After open sourcing your product, your income options are reduced. Here are the usual options:

Service based

• Consulting
• Support, Maintanance
• Hosting

Product based

• Product add-on / extensions
• Sponsored develipment
• Legal (commercial license, hold harmless agreement)

Are you the real provider?

A provider has the legal rights to the product over and above the Open Source license (i.e. you “own” the product). If you are not the provider, you options are reduced.  The usual options for contributors and third parties are consulting, maybe support and hosting and depending on the license, charging for product extensions.

Open Source Contributions (Compiere ERP)

In this second part of the series, I will discuss what options Compiere has to go forward as an open source product and what prerequisites there are for building a thriving community. The indication for an active community are (user) contributions.  In this blog, I will cover why people contributed to Compiere and why not.

In the first part of this blog series, I mentioned that one cause for the diminishing open source community for Compiere was the business model.  Compiere started out as free product with revenue generation via services and evolved to a free open source trial/entry product with "real" commercial product and services (Open Core).  As mentioned this model only causes conflicts with the community and also customers as they see it as nothing else than a free trial/entry product with restricted functionality or access with the ultimate goal being to 'upgrade to a paid or enterprise version. This 'try before you buy' method is today quite common in non-open source software products, so no advantage for using open source anymore.

One of the biggest assets of an open source product is a thriving community.  As a user, you are not restricted to the vendor as source for information and help.  Building an active community is not easy and depends on people contributing.

Contributions today

Contributions are the major aspect of open source.  The main areas of contributions are support, documentation, testing and functional improvements.

One of the origins came from the lack of (timely) support from the original vendor, so users helped each other.  For some time, contributions were just found in open source projects, but today this is no longer true.

Commercial products like SAP and Salesforce have a very active user community and in both cases, you get your question answered probably much faster if you use the support forums then via the formal technical support.  Also most product's documentation is provided as Wiki, so that users can make comments and with that contribute to the quality of the documentation.  In many cases, commercial companies also now let their users vote on "ideas" (functional improvements) and bug priority.  The community of users have always been 'testers' by reporting bugs, and many companies now include customers in focus groups.

So, the only unique domain of contributions left for open source are code contributions  (with the restriction that if you get the source as part of the commercial product, companies may also get suggested bug fixes).

Compiere Open Source failed?

Recently, Consona acquired Compiere.  Is this a failure of Open Source business model? What decisions led to the current situation?  In this first chapter of a three part blog series, I will provide some details and insight into the inner workings of commercial open source companies.

In the open source environment, many business models have been tried.  In the Compiere environment (including the forks like Open Bravo and Adempiere) different models were put into practice.  One of the crucial aspects in open source is inbound marketing. Long before inbound marketing became fashionable, the successful open source projects used this approach to gain momentum.

The blog concentrates on open source business (application) software with it's special challenges, but the lessons learned also apply to infrastructure and tool open source projects.   

Adempiere failure - the chance for Consona to revitalize Compiere

The Compiere troublemaker and Adempiere leader "red1" (Redhuan D Oon - @red1Oon) resigned: "I have quit as 'leader of ADempiere' . I have enough after nearly 4 years of battles. Anyway the legend is born. It shall have to die now." I have to say that it is not too surprising. The Compiere fork Adempiere had pure monetary motivations (despite singing the "open source song") and it did not work out for the community. 

In my upcoming blog series, I will elaborate on the motivation for the Adempiere guys to fork and why they failed.  Due to the recent purchase of Compiere, I had quite a few discussions with people interested in a revival of Open Source ERP.  Maybe Consona sees that as an option too.

Open Source ERP has a future. The "competing" open source products are quite weak compared with Compiere - maybe it is time for a new start where the objective is to create a great product to compete against the commercial ERP applications and frameworks.  The open source community also became more mature - with little support for "troublemakers" and the need for technical and business leaders.

Compiere from the beginning to Consona

I am in the process of creating a very detailed three part blog about Compiere history and potential future:

1. The Business of Open Source - from the early Compiere days until today
2. Open Source Community and Contribution for Business Applications - my experience with creating the most successful open source business application and lessons learned.
3. Open Source ERP - a technical review of options then and today.

It will take me a few days to complete it and receive/include some feedback and validation I requested.

Subscribe here to get the complete Compiere story with its highs and lows directly from the source ... I promise that there will be a few surprises.

Agile Development - the cure all?

Kathy Pink: I just completed a 2 day class in Agile Development aimed at Product Managers.  While I have a good understanding of the concepts and practices of Agile Development, it is always a good idea to validate what you know (or think you know).  Also it helps to understand how others are using the processe and what issues and concerns they have.

What surprised me was that some people look to the Agile Development methodology as the 'cure all' or panacea for their devleopment woes.  No development methodology can make a disfunctional organization functional.

Cloud Hype and Reality

Cloud computing is "in" - and actually with the latest price change from Amazon it is becoming a bit more real.

I signed up with Amazon, installed the Java tools, created my own image, changed it via Windows Remote Desktop, saved that image and re-started that image - in half a day.  Far easier than I thought - just another half day to install database, application, etc.  As they have nice Java interfaces for the operations, I think that the entire process can be automated (or you could use the Management Console).

Realistically, the Amazon Elastic Compute Cloud (EC2) is just an alternative to dedicated hosting - but rather than paying for 24h/day, you pay just for the time you have your instance up.  You still need to maintain the operating system, application, configure firewalls, implement a back-up strategy - the tasks which are included in a Software-As-A-Service (SAAS) model.  Main benefit is that you can select from quite a few starting points, Amazon Machine Images (AMIs) - from several free Linux O/S as well as Windows or commercial vendors (Oracle, RedHat, IBM, JBoss, Compiere, ...) combining convenience and license payment.

We will be using it for our automated build with one instance and one instance per configuration for regression and load testing and are "burning" currently max 2 hours per day for the 3 configurations (4 planned).  As these tasks are not essential, delays and non-availability is not an issue.  As these are test instances, we just load the image, run it and remove it - no need to save as we are starting the tests always from a clean install. 
As you know, persistency is "a bit" of an issue as you need to create a new AMI for any change to your configuration.  If the instance crashes, you are back to the last saved image - only S3 storage is persistent.  For 24/7 production use, you must solve external database backup and recovery.  You might want also to save certain log files externally.

Agile ERP Development

When exposed to the German education system, you'll pick up the importance of methodology and planning.  In the Business Administration classes, we learned how important it is to do your strategic planning (10+ years) and operational (2+ years).  OK, in the late 70s the world turned a bit slower.  So when introduced to the presessors of RUP (Rational Unified Process), a heavy top-down, big-bang approach seemed very sensible.  Well, it worked (somehow) and I thought I just have to improve my planning skills and spend days with Rational Rose trying to get the full round-trip to work.

When starting Compiere in 1999, I know I had to do something else.  Especially with Open Source, the traditional Big Bang approaches did not seem to work.  So, I thought, I have to start "without a methodology".  After a while, we managed to publish stable daily releases and incorporated feedback very quickly.  Initially users and customers were concerned about using the daily releases in production, but our track record was persuasive. So, it became standard procedure to use a daily build in production, especially if an important bug fix /improvement was made available.

One day, a friend told me that "our agile approach" was working nicely.  I was surprised that what we did had a name - so looked it up and was astonished to find the pricipals I was living actually written down. Happy to have found a name for what I was practicing for quite a while, I signed the Agile Manifesto in early 2002  

Agile ERP Implementatation

For some time the 'buzz' in development is Agile (aka Extreme) development.  Its basic concept is that this method of development promotes project management processes that encourage frequent inspection and adaptation, a leadership philosophy that encourages team work, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.  What is these same concepts and ideals were applied to the implementation process for an ERP application?

Would this work for all ERP applications?  Frankly, No.  The application would need to be flexible and allow the user to make changes to the basic set up parameters at any time.  How else can you make adapations? 
By its design, Compiere is ideal for using this methodology for implementation.

Accounting Schemas and Default Accounts

In Compiere the accounts used for posting the accounting consequences of any document are defined as default accounts in the Accounting Schema.  A tenant may have multiple accounting schemata (one reason for this would be to have parallel accounting currencies).  This is to ensure that all necessary accounts are present and avoid any posting errors because required accounts are not provided.  It also means that  the person entering the document (e.g. Invoice) does not need to have any knowledge of how the accounting is done or at what level.

During Initial Tenant Setup the user provides the default accounts as a .csv file to the process.  The first (and therefore) primary Accounting Schema is created using these default accounts.  If all the default accounts are not provided then the Initial Tenant Setup process will fail.  The default accounts are then copied to the appropriate entities when a new entity record is created.  For example, when a new Business Partner Group is created the default accounts are copied for each Accounting Schema defined.  Then, when a new Business Partner is created, the default accounts are copied from the Business Partner Group selected for the Business Partner.  When a new Bank Account is created, the default accounts are copied from the Accounting schemata (as there is no intermediate entity like Business Partner Group).  For all entities with an 'Accounting' tab, records are never added to this tab.  The user can modify the default account values but cannot change the Accounting Schema.