The enterprise software vendor consolidation trend has now reached the open source corner of the market, with Consona's announcement that it is acquiring Compiere, Inc.
Background on Compiere and Consona
Compiere was one of the first open source ERP developers. I interviewed Compiere's founder and then-CEO Jorg Janke back in 2006 and wrote an extensive post about the product. At the time, Compiere was facing a rebellion from some of its community "freelance" developers, who took the open source code base and forked a separate development project, dubbed Adempiere. Read the whole post for background on Compiere. And read the many comments also, which give good insight into the issues and challenges of managing an open source project.
Since that time, Janke was replaced by Don Klaiss as CEO and eventually departed from Compiere altogether. Compiere continued to demonstrate some success in the market, however, as I noted in 2009 with its win of a very large deal at La Poste, a $27B (USD) global postal processing organization.
Consona, which is Compiere's new owner, has been rolling up smaller ERP vendors for some time. Originally the parent of Made2Manage, it changed its name to Consona in 2007 and has since acquired several other ERP and CRM systems for the SMB market, notably Intuitive, Onyx, Encompix, DTR, Cimnet, and Axis. Consona, along with most or all of the traditional on-premise enterprise software vendors, has had a tough several years due to the recession.
Issues in the Announcement
A couple of issues I note in the announcement this morning. First, the press release references 130 customers of Compiere today. But in 2006, Janke indicated to me that Compiere had about 250 customers. What happened to the other 120?
Secondly, what happens to Compiere's open source offering? Though founded as an open-source project, Compiere had been focused largely on its own proprietary enhancements, add-ons, and services--in other words, making money. As I noted in my 2006 post, this was one of the factors that led to some of Compiere's community forking the code to the Adempiere project. Now with Compiere's ownership under Consona, how much effort will the new owner put into continuing development of the open source code base?
Benefit of Open Source
In a sense, it doesn't matter as much as it would if Compiere's original code base was proprietary. One of the tenents of open source is that no matter what the owner of the code does, the users of the code continue in their rights to use, extend, enhance, and distribute the code. The Adempiere fork of Compiere is evidence of this.
To my knowledge, this is the first instance of an open source ERP/CRM developer being acquired by a vendor of proprietary software. It will be interesting to see whether Compiere's users are helped or hindered by this acquisition.
Update, 12:45 p.m. Read the comments on this post for more insights on Compiere's architecture. Plus, Ned Lilly has a really good post on the Consona/Compiere acquisition. Ned is in a particularly strong position to comment, as he leads another open source ERP project, xTuple (formerly OpenMFG). Ned's ironic conclusion is that Compiere "failed as a company" not because it was open source, but "because it turned its back on open source." But, please, read the whole thing.
Update 2:30 p.m. I have been educated by three Adempiere developers regarding the inherent multi-tenant architecture of Compiere and have therefore edited this post to remove my previous comments regarding Compiere's lack of multi-tenant capabilities. I was clearly wrong there. See the comments section on this post for details. Thanks, guys!
Update, 2:47 p.m. Josh Chalifour did some analysis of activity (or lack thereof) on Compiere's user forums and finds a disappointing lack of care and responsiveness from Compiere toward its community. Not a good sign and hopefully something that the new owners at Consona can remedy.
Update, June 21: I just discovered that Jorg Janke has been maintaining a website, Compiere from the Source, and he is planning to write "a very detailed three part blog about Compiere history and potential future." Check it out.
Related posts
Big win for open source ERP project Compiere
Compiere's open source ERP business model and growth plans
Consona layoff
Open source ERP and CRM carry strong ROI
Total cost study for an open source ERP project
11 comments:
Hi Frank,
Your post is very interesting and the news about Compiere being acquired by a larger group like Consona is even more.
Just a few pointers if I may add to your analysis, about Compiere´s multi-tenant architecture it is true that the system allows multiple tenants and multiple organizations from a single database instance, and it is because it has been designed like this from its very inception, thus making it a very powerful feature if you scale that into the new world of cloud computing where resource efficiency and ease of system administration is king.
Regarding your comment on why the number of supported companies of Compiere has decreased, I would guess it is because of their bad support service, I think companies going the extra mile paying support expect exceptional service like response time and bug fixes, for instance, this has nothing to do with the product itself, I still think it is great.
Last, about the future commitment from the new owners to Open Source it will be interesting to see how they respond to that, my piece of advice to them, if they want to see a succesful case about fostering open source communities would be, hey turn around and see how Adempiere has done it :-).
Best Regards,
Enrique Ruibal
Enrique, thank you. I really appreciate your comments, especially since you are familiar with Compiere's source code.
I am interested in what you said about Compiere allowing "multiple organizations from a single database." That shows a great deal of foresight on Janke's part, as he would have designed the database long before "multi-tenant" was the a popular concept.
One question though. You indicate multiple organizations are supported on a single database. Does that mean that a single instance of the application itself can support multiple organizations? Or does each organization (customer) need a separate instance of the software, which then can share a single database. As you know, that would still not allow a multi-tenant SaaS offering.
"Does that mean that a single instance of the application itself can support multiple organizations?"
That is correct.
Also each Tenant (or Client as it was called in Compiere before it was renamed and as it is still named in Adempiere) can have multiple Organizations and each Org can be optionally flagged to show it is a separate legal entity so the Tenant/Client plus its Orgs become parent company plus subsidiaries and a single database and code instance can have multiple Tenants/Clients.
The difficulty was / may still be that there is/was no obvious way that a single Tenant/Client could be backed up/restored.
regards
Frank it is the earlier, a single instance of the application itself supports multiple organizations. We have a customer in Chile with 30 small suppliers sharing a single instance of ADempiere so it is not theory. It does work.
Jorg Janke was well ahead of his time, he designed this before the multi tenent term was coined.
Regards
Ramiro Vergara
Thanks to Enrique Ruibal, Ramiro Vergara, and the anonymous commenter who is apparently another Adempiere developer. I stand corrected and have edited the post accordingly.
Frank,
I am not surprised that Jorge had this multi-tenancy designed into Compiere from the get go. He was an ex-oracle Apps guy. Oracle Apps (E-Business Suite) had Multi-tenancy built way back in 1999-2000 to support multiple business entities within a global entity. Every application built as part of the suite supports that feature. But real multi-tenancy in a SaaS world is much more than just striping data by creating virtual walls between different customer data. As your readers might be well aware multi-tenancy from the SaaS vendor site needs to account for the nature of the business being conducted and architect striping of data accordingly.
Subraya Mallya
Subraya,
If you read ancient history, actually you would find that Jorg's ideas on the ERP future architecture wre originated when he was at ADV/ORG helping SAP to define the architecture of R/3. That was in the late 80's. I am not surprise some of those ideas permated into Oracle when Jorg spent some time there in the 90's (this is just speculative) but certainly they did not permate into Jorg as you imply.
Multitenant capabilities in ADempiere (came from Compiere) allow completely different business processes for different business segments to share a single instance of the solution.
Subraya, from what I am hearing from our Adempiere friends, the multitenancy built into Compiere would go far beyond the "multi-entity" of Oracle's EBS.
Multi-entity is not multi-tenancy. To my knowledge Oracle's EBS as written today (pre-Fusion) cannot be deployed in a single instance to support multiple separate customers. When Oracle hosts its EBS in an on-demand setting it has to set up a separate instance for each customer. This is commonly known.
Our Adempiere friends are saying that this is not the case with Compiere.
Hi Again Frank,
Thank you for your quick reply, I think I got back too late to answer your questions because my peers just did a great job at that.
This is a big day for enterprise Open Source because I think it closes a cycle that Jorg Janke started many years ago when he programmed his first Compiere prototype, he certainly deserves a lot more credit for what he accomplished.
Aside from that, anything can happen on the EOS arena after today, but again this isn't the end of the world or anything like that, the sun will still shine tomorrow and the day after that.
So my thinking is Open Source + Cloud Computing will still be a great alternative for many small to medium size businesses in the short term, and even in the long term they will become viable alternatives for the bigger companies too.
So, lets wait and see what is their next move for the new Consona/Compiere initiative, and in the mean time we should keep the good work helping more and more companies adopt open source based business solutions or at least providing them with valued support services like rimini is doing on the other side, errrh some people call them 'the dark side', of course I think is a good joke, nothing against the big guys either, at the end of the day is just a matter or Value and ROI, pure and simple.
Best Regards,
Enrique Ruibal
"To my knowledge, this is the first instance of an open source ERP/CRM developer being acquired by a vendor of proprietary software."
I think you're right, Frank, but it's just a matter of time, the relatively low number of open source ERP and CRM projects, and the classic "working up the stack" process.
In middleware and below, the trend is pervasive and long-lived: IBM of Gluecode, Progress/Iona of LogicBlaze, Novell of Suse, Google of On2, EMC of some Sourcelabs IP, Citrix of Xensource, Zimbra first by Yahoo and then VMware and -- of course -- Oracle/Sun of MySQL :)
Regards,
Dennis
Dennis, correct. And that's why I was careful to qualify as open source *ERP/CRM*.
The issue in my view is not whether the code is owned by a proprietary software vendor or other party (e.g. a non-profit or consortium, etc.). The issue is whether the open source community development approach (the "bazaar" as they like to say) will be fostered.
One of the criticisms of Compiere, Inc. was that it did not foster the community. Code contributions were not encouraged, beyond pointing out bug fixes, and when contributions were made they were often not evaluated for inclusion. This ultimately led to the Adempiere fork, which from what I can see has a pretty robust community of developers behind it. They are the ones making most of the comments on this post.
Open source without community development is technically still open source but it won't thrive, in my opinion. Otherwise, it's just another product in Consona's portfolio. Whether Consona understands this or not is a big question.
Post a Comment