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:
- The speed at which ComPiere Inc. processes fixes and enhancements submitted by contributors and the refusal, in some cases, to even accept them.
- The refusal of ComPiere Inc. to provide Compiere version migration tools except in the sale of a support agreement.
- Rumors that ComPiere Inc. is planning to limit the functionality of its open source offering, to better position some future proprietary offering.
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"
10 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
http://web.mit.edu/coeus/www/coeus_description.htm
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? ;-)
Post a Comment