Enterprise System Spectator blog: ERP and enterprise system vendor evaluation, selection, and implementation.

The Enterprise System Spectator

Wednesday, October 04, 2006

Compiere's open source ERP business model and growth plans

Late last week, I interviewed Jorg Janke, founder and CEO of ComPiere Inc., an open source ERP/CRM developer. In June, the firm announced it had received $6 million in venture capital to expand its business, and I wanted to find out what it planned to do with the money. I had also gotten word of a plan by a few members of Compiere's open source developer community to "fork" Compiere's source code into a separate version, and I wanted to get Janke's view on that.

Through the rest of this post, "Compiere" refers to the open source product, and "ComPiere Inc." refers to Janke's corporation, which manages the development of Compiere.

Business Model
Like most attempts to make money with open source, ComPiere Inc.'s business model requires some explanation. Janke along with co-founder Kathy Pink began Compiere development in 1999. They released it under an open source license that mimics the Mozilla Public License. Basically, this means tha anyone can download the software, play with it, implement it, use it, and enhance it--all at no charge. You can even redistribute it and create derivative works from it as long as such derivatives are distributed under the same open source license.

ComPiere Inc. makes money by offering services to its worldwide network of consultants, many of whom pay a fee to ComPiere Inc. to become "Partners," in exchange for sales and marketing support, second level technical support, and training services.

The Partners, which currently include about 100 organizations employing a total of 300-400 individuals, make money by providing traditional implementation and consulting services. Some of the Partners also develop complementary products or extensions to Compiere, which they are free to sell as proprietary products, as long as they do incorporate Compiere's source code. (ComPiere Inc. itself makes money from sales of proprietary products, such as migration tools that facilitate upgrade between versions of Compiere.) Partners also form the bulk of Compiere's open source development community, as they submit bug fixes and enhancements to Compiere Inc. for incorporation into the product.

In addition, Janke estimates that there are another ten to fifteen "freelancers"--independent consultants who are not Partners but provide implementation consulting services for Compiere. These freelancers also participate in Compiere's development community.

Business Volume
Since there are no sales transactions recorded for open source software, it is difficult to make head-to-head comparisons between Compiere and commercial software vendors such as SAP or Oracle. Open source projects like to use "number of downloads" as a substitute for sales figures, but although these numbers may run into the hundreds of thousands or even millions, they do not represent actual use of the product.

I was able to determine from Janke, however, that there are about 250 companies paying for support from ComPiere Inc. or its Partners, which is a pretty good indication of Compiere's installed base. There are, no doubt, some companies that have downloaded Compiere's source code and have managed to run it in production without any knowledge of ComPiere Inc. or its Partners. According to Janke, some of these companies eventually reach out to Partners for support, especially when they get in over their heads. But the total number of such organizations is difficult to determine.

Problems in the Development Community
As indicated earlier, there have been grumblings among Compiere's development community that have evolved to the point that a few of the non-Partner developers (freelancers) have forked development of Compiere into a separate open source project, dubbed Adempiere.

A public discussion on the decision to fork Compiere's source code is available, and it provides interesting insights into the dynamics of an open source development community.

The motivation to fork Compiere's source code seems to be centered around several issues:
  1. The speed at which ComPiere Inc. processes fixes and enhancements submitted by contributors and the refusal, in some cases, to even accept them.

  2. The refusal of ComPiere Inc. to provide Compiere version migration tools except in the sale of a support agreement.

  3. Rumors that ComPiere Inc. is planning to limit the functionality of its open source offering, to better position some future proprietary offering.
I asked Janke about each of these issues. In the case of the first, Janke admits that resources at ComPiere Inc. have been limited: basically, all product development at ComPiere Inc and contributions from the community are funneled through Janke and Pink. One of the reasons that ComPiere Inc sought venture capital was to be able to hire more developers to support contributor efforts to enhance Compiere.

In the case of the second issue, Janke indicated that licensing of migration tools is one of the services from which ComPiere receives revenue, which it needs in order to fund its services to the development community.

As for the third issue, Janke denied any plans to restrict functionality of Compiere in order to make a separate closed-source offering more attractive. I would also add that if a closed source offering made any use of Compiere's source code, it would by definition need to be an open source product. After our discussion, Janke wrote an even stronger rebuttal of this point:
There is certainly no plan to cripple the product or discontinue or "privatize" functionality - the very opposite is the case. We will continue to develop substantial new functionality Open Source, and hope to increase Open Source contributions from the community. It's disconcerting to see people spreading unsubstantiated false rumors in this regard.
Janke said that he hopes the addition of new developers at ComPiere Inc. will enable new enhancements and fixes submitted by the development community to be incorporated more quickly, and that the developers who have forked the source code will want to return to the original Compiere project. It takes a lot of work to maintain an open source project, and certainly one combined effort will be more productive than two.

While I was writing this post, Janke wrote a Compiere status update that addresses the issues I have outlined above, and more. It is worth reading for a more complete view of what ComPiere Inc. is doing with the venture funding.

The future of open source ERP
Compiere is just one attempt to build a complete ERP system under the open source model. Open For Business (OFBiz) is another. ERP5 and Tiny ERP are still others. OpenMFG might be considered as well, although its license is not truly open source. In addition, there are several open source CRM projects, most notably SugarCRM, which offers an open source version as well as a "professional" or commercial version.

Although open source ERP has been gaining some ground, none of these projects match the scale of open source efforts such as Linux, Apache, mySQL, or JBoss. It appears that the higher one moves up the technology stack, the more specialized the requirements and the narrower the development community. ERP applications, at the top of the stack, would appear to be the most difficult market in which to sustain an open source development effort.

If this be the case, then it would appear that the primary success factor is a critical mass of developers. ComPiere's greatest asset, in my opinion, is not Janke's knowledge and experience as a developer--it is the 100 Partner organizations that are committed to extend, enhance, and support Compiere. Janke is right to devote a good chunk of his venture funding to hire new developers (he indicated four new programmers added in the past few weeks, and a total goal of about 20 a year from now). His development staff's top priority should be the rapid evaluation and incorporation of changes submitted by the Partner network. In addition, the freelance contributors should be treated the same as the Partners--if they have fixes or enhancements, they should be evaluated on the quality of their contributions and not given lower priority just because they don't pay a Partner fee. The freelancers--especially those in developing countries--have more time than money, and ComPiere Inc. should take advantage of that fact. The development community--whether Partner or freelance--is the competitive advantage for open source, and organizations such as ComPiere Inc. should take every opportunity to serve and grow that community.

Other open source projects, such as Linux and the others mentioned earlier, demonstrate that open source products can be as good or better than their commercial equivalents and that they can even claim a dominant market share, as in the case of Apache for web servers. Open source ERP may not reach this level of market share, but it can certainly gain more than it has today--as long as it fosters a robust and thriving development community.

Compiere may be on the road to doing so, and I hope it is successful.

Related posts
Open source ERP gaining adherents
Why organizations choose open source software
Build/buy pendulum swinging back toward build
Key advantage of open source is NOT cost savings
Open source: turning software sales and marketing upside down
Open source ERP
Buzzword alert: "open source"

by Frank Scavo, 10/04/2006 10:14:00 AM | permalink | e-mail this!

 Reader Comments:

As you move further up the technology stack into the applications, a number of things happen.

In particular, the needs of individual companies become much more prominent and differentiated, and this is why there are hundreds and thousands of ERP packages through the years. Even though we have consolidation going on, many of these implementations involve customization and variation from a standard set of code. So, open source ERP is a challenge in my opinion since you have a smaller potential market than say for a fairly horizontal tool such as a DB or deevlopment toolkit. Plus even though the market is smaller, the support requirements are higher, since ERP is a bet your business and keep the doors open sort endeavor. I think the key for Compiere is to get the right partners, who develop a really good understanding of their target market and zero in on that market.
Paul wrote, "the needs of individual companies become much more prominent and differentiated"..."these implementations involve customization and variation from a standard set of code"..."the support requirements are higher"...

Actually, Paul, do you realize you have actually just made the case FOR open source, not against it. Companies that have highly differentiated support requirements, with much customization on a standard set of code, are sitting part way between a vanilla package implementation and custom development. Open source advocates would say that is a perfect fit for open source. You pay nothing for the standard source code and save all your money to invest in the developer's efforts to use that standard source code as a starting point for your customizations.

For a company that needs a "partly custom" implementation, such as this, open source better aligns the costs of implementation with the needs of the customer.

Now, whether Compiere or any other open source product is a viable choice--that's another issue. But the economic alignment in the case you have outlined is very strong.
In Higher Education, there are many open source and "community source" (I myself am not sure what the difference is) applications. The 2 that I am most familiar with are Kuali, a Financial system, and Coeus, an MIT-developed system for Research Grants that has evolved into a community-source project.

These may be more probable to succeed, since in Higher Education, there seems to be higher levels of cooperation than between, say Coke and Pepsi, or Ford and Toyota. I haven't heard many people talk about this issue too much - could open source ERP systems be perceived as "cooperating" or "colluding" between the companies that use them? They are in some sense sharing resources to develop systems, which could pose some sort of anti-trust issue between them depending on the companies we are talking about, no? I could be way offbase here.

Here are the websites if you want to dig deeper into these other open source projects: http://www.kuali.org
The previous comment raises an interesting point about antitrust issues. In the case of Compiere, I've been told that the end-user organizations are nearly "silent" in terms of participation in the developer community. Except for the handful of developers at ComPiere, Inc. the development community comprises nearly 100% system integrators/implementors that contribute enhancements and bug-fixes as a way of making their life easier in the next implementation.

Furthermore, even if Ford and Toyota were users of Compiere, and Ford and Toyta programmers contributed enhancements, they would be contributing to the development organization, not to each other. I can't judge on legal merits, but it would seem to me to be a stretch to view it as collusion. Especially since any enhancements are open source (available to any and all takers).

Maybe others with more experience as open source developers have an opinion.
Interesting article Frank. Have you ever downloaded the source code of compiere and looked in it?
It is a very rare occurence indeed to find a name other than Jorg Janke in all that code! In fact, it is so rare that I have never actually seen it myself. Which I think is very unusual for a 5 year open source project! Now, having more than one developer and accepting patches and enhancements from others is not a requriement of being OSI certified, but it is one of the core ideas preached by OSI founder Eric S. Raymond in his oft quoted "The Cathedral and the Bazaar" essay. Perhaps this lack of inclusion is the reason why Compiere has 382 "open" bugs on their SourceForge project. That from a project that has not released any code in over 6 months!
Now it is true that Compiere Inc now professes change but I think it is no coincidence that this ocurred only after Compiere's community, following six months of no code releases or even a single message from Compiere Inc on direction despite numerous queries and pleas over that period, finally got fed up and decided it better do something itself.

On the point of the the denial that there will not be two versions of the application in the future, well I would just point out that right now today if you pay Compiere Inc you get different code than if you simply download the latest version from SourceForge. Does that not mean there are already two versions, a commerical and open version, of the application?
Colin, thanks for the feedback. I did speak with Janke about two of the points you raised in the preceding comment.

1. You are correct that none of Compiere's source code is annotated by anyone other than Janke. This is because in practice, very few if any enhancements have been contributions from others. Partners tend to keep their enhancements at their own proprietary offerings. In my post it appears I overstated the role of the community in contributing enhancements. Janke did not say this, but I suspect that in the cases where contributers did offer bug fixes or small changes, Janke has not attributed the change to the contributor because of fears that this would compromise ComPiere Inc.'s ownership rights to the code. See http://dreamsongs.com/IHE/IHE-29.html#pgfId-999299 for a discussion on the difference between "license rights" conferred by the open source license and "ownership rights" that accrue to the author of the code. Again, this is only my speculation.

2. Concerning two versions of Compiere--one available to Partners and one available for public download from SourceForge--Janke admits that the latest version has been released to Partners earlier than it is available on SourceForge. However, he claims this was due to technical problems with SourceForge and not a deliberate move. In any event, Janke indicates that ComPiere Inc. is making some infrastructure changes shortly that will fix this problem and the same version will be available publicly that is available to Partners. However, Janke indicated that ComPiere Inc. may in the future make new versions available earlier to Partners, as part of the the value proposition to Partners. No plans right now, but the firm has the right to do so.

I am sensing that there are a lot of changes going on at ComPiere Inc. and decisions at the board level are being made, then unmade. The board is trying to find its way.

Clearly, the Compiere community are frustrated by the slow pace of development of Compiere. A group of community members has decided not to wait around to see whether things will improve. They are exercising their rights under the open source license to fork the code, creating the Adempiere project, which is now one of the top 10 most active projects on SourceForge.

Which way will be most successful? It probably won't take long to find out.
What Paul Sita touched on is just as Frank said previously in http://fscavo.blogspot.com/2002/10/open-source-erp.html where "It would seem that the higher you go up the technology stack toward complex business applications, such as ERP, the more difficult the open source model would be to sustain".

Now with the advent of Compiere, which fulfills the "existence proof", the TCO pyramid, as I call it, also moves higher, where the more expensive stack justifies a robust enough demand side.

For such an ERP category community to thrive, and in comparing erroneously with Linux or Apache's, we just need the quality not the quantity.

If not mistaken, I read somewhere that JBoss' Marc Fleury remarked on this when he said that he probably needed only 10 committers at any one time in his project.

With the power of the web, costs of getting to such quality goes away, and the collateral requirements of implementation, patches, demos, reference sites, maturity and success has been proven undeniably by Compiere, that is hardly 5 years old, securing angel funding, and did hit top spot for some number of years at SourceForge, against the likes of 'more sensible' utilties such as Gaim and BitTorrent.
What I think is that ERP software is not such vertical (and probably never will be) as operating systems.

But this is not true for starting or small business. Starting or small business doesn't have many requirements, in fact normally they're eager for a software that "organizes" them.

So I think a good ERP system can be installed almost without changes (vertically) only in starter of small business.

What happen on medium or big business?

Normally their needs are not fulfilled easily, for these enterprises the need is a FULLY CONFIGURABLE SYSTEM - to be configured by consultants (this is the SAP model in fact).

The market question is if Compiere Inc. WANTS to do that? Their past movements have showed another business model in their mind. And they only "reacted" pressed by community going to ADempiere.

What I'm sure that ADempiere community WANTS to do that, the challenge is to escalate that Compiere system (good architected but plagued of hardcodes) to a really configurable system for consultants.

And probably also make a vertical solution for starters and small business to help them grow with a good solution.
Frank, I would suggest that on the question of community contribution to the code, it's primarily a question of the posture and attitude of the organization and the people in it.

OpenMFG's version 2.0, which will be released next week, contains lots of code from people outside OpenMFG - and not just VARs and solution providers.

As an example, we've got a whole new subsystem of "Buffer Management" displays that builds on Theory of Constraints concepts, dramatically simplified. This was contributed by an end-user customer.

It's less a question of which license you choose, more how much do you want to engage your community in the development process. It's been my observation that lots of VCs who are interested in open source are discounting the development help you can get, focusing only on the distribution multiplier. Therefore, the key metric is # of downloads.

It's the 2006 version of "eyeballs" in the dot-com time. How do we monetize all this traffic?

Our experience suggests that a lot of people are missing a big part of the upside of living in an open source world. Even though our application isn't free software, I daresay our posture toward our community is more "open" than lots of the better known open source projects out there.

How's that for flame-bait? ;-)
This comment has been removed by a blog administrator.
Post a Comment

Links to this post:


Powered by Blogger

(c) 2002-2018, Frank Scavo.

Independent analysis of issues and trends in enterprise applications software and the strengths, weaknesses, advantages, and disadvantages of the vendors that provide them.

About the Enterprise System Spectator.

Frank Scavo Send tips, rumors, gossip, and feedback to Frank Scavo, at .

I'm interested in hearing about best practices, lessons learned, horror stories, and case studies of success or failure.

Selecting a new enterprise system can be a difficult decision. My consulting firm, Strativa, offers assistance that is independent and unbiased. For information on how we can help your organization make and carry out these decisions, write to me.

My IT research firm, Computer Economics provides metrics for IT management, such as IT spending and staffing benchmarks, technology adoption and investment trends, IT management best practices, IT salaries, outsourcing statistics, and more.

Go to latest postings

Search the Spectator!
Join over 1,700 subscribers on the Spectator email list!
Max. 1-2 times/month.
Easy one-click to unsubscribe anytime.

Follow me on Twitter
My RSS feed RSS News Feed

Computer Economics
Outsourcing Statistics
IT Spending and Staffing Benchmarks
IT Staffing Ratios
IT Management Best Practices
Worldwide Technology Trends
IT Salary Report


2014 Best Independent ERP Blog - Winner 2013 Best ERP Writer - Winner Constant Contact 2010 All Star Technobabble Top 100 Analyst Blogs

Key References
Strativa: Business strategy consulting, strategic planning
Strativa: IT strategy consulting
Strativa: Business process improvement, process mapping, consultants
Strativa: IT due diligence
Strativa: ERP software selection consulting and vendor evaluation
Strativa: CRM software selection consulting and vendor evaluation
Strativa: Project management consulting, change management
StreetWolf: Digital creative studio specializing in web, mobile and social applications
Enterprise IT News: diginomica

Spectator Archives
May 2002
June 2002
July 2002
August 2002
September 2002
October 2002
November 2002
December 2002
January 2003
February 2003
March 2003
April 2003
May 2003
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
July 2008
August 2008
September 2008
October 2008
November 2008
December 2008
January 2009
February 2009
March 2009
April 2009
May 2009
June 2009
July 2009
August 2009
September 2009
October 2009
November 2009
December 2009
January 2010
February 2010
March 2010
April 2010
June 2010
July 2010
August 2010
September 2010
October 2010
November 2010
December 2010
January 2011
February 2011
March 2011
April 2011
May 2011
July 2011
August 2011
September 2011
October 2011
November 2011
December 2011
January 2012
February 2012
March 2012
April 2012
May 2012
June 2012
July 2012
September 2012
October 2012
December 2012
January 2013
February 2013
March 2013
May 2013
June 2013
July 2013
September 2013
October 2013
December 2013
January 2014
February 2014
March 2014
April 2014
May 2014
June 2014
July 2014
August 2014
September 2014
October 2014
November 2014
December 2014
February 2015
March 2015
April 2015
May 2015
June 2015
July 2015
September 2015
October 2015
November 2015
February 2016
May 2016
June 2016
July 2016
August 2016
September 2016
October 2016
January 2017
February 2017
May 2017
June 2017
October 2017
January 2018
April 2018
May 2018
Latest postings