TEC Talks to the Compiere ERP/CRM ProjectFree and Open Source Software Business ModelsPart Three: Compiere/ComPiere

Introduction

Consider that Free and open source software models, as opposed to the traditional proprietary models, may afford end user organizations a direct line to getting the software that is most well-adapted to their specific needs and at a lower cost. If that tends to be the case, one should ask how it is that the groups providing Free and open source enterprise software model their businesses to support that notion.

TEC talked about business models with three organizations centered around Free and open source enterprise software. In the first part we talk with David E. Jones, project leader of the Open For Business (OFBiz) project (www.ofbiz.org). OFBiz is an e-commerce and enterprise automation (ERP, CRM, EAM, etc.) solution developed through open source methodologies. The second part focuses on a discussion with Edward L. Lilly, Jr., CEO of OpenMFG (www.openmfg.com), an ERP solution geared toward small and medium-sized manufacturers. While OpenMFG itself does not strictly fit the definition of Free or open source software, it is based on open source platforms such as Linux and the PostgreSQL database. Finally, we talk with Jorg Janke, founder and project leader of the Compiere (http://www.compiere.org) ERP and CRM solution. Compiere, like OFBiz, is an open source project. Compiere runs on a combination of open source and proprietary platforms.

This is Part Three of a three-part series.

Part One was based on a discussion with David Jones, leader of the Open For Business project and in Part Two we talked with the CEO of OpenMFG, Edward L. Lilly, Jr.

Part Three—Compiere/ComPiere

Jorg Janke began developing the Compiere project in 1999 (for a detailed analysis see the ERP Evaluation Center or Accounting Software Comparison Center). Compiere is available under the Mozilla Public License (MPL), which is approved by both the Free Software Foundation (www.fsf.org) and Open Source Initiative (www.opensource.org). Thus, the software is not only an open source ERP/CRM solution, it also supports certain Free or open source platforms as well as proprietary ones. Traditionally software is sold based on license fees, but Compiere, as an open source solution, relies on a different model. According to Jorg, with Free and open source software you can only charge for real services.

TEC: Is your revenue more likely to come from implementation, consulting, training, or other service areas? Could you also explain how your business is arranged around Compiere, insofar as the difference between Compiere and ComPiere?

Jorg Janke: ComPiere with a capital P is the commercial company, Compiere with a lower case p is the Open Source project. Nevertheless, you can go to the dot-org site, download Compiere, use it, and never talk to the professional services side ComPiere. From that perspective . . . if you are technically savvy, have the time to experiment and the tolerance for downtime, there's no need for us. Our services help people to efficiently implement and use Compiere and eliminate the risk of open source software.

Our forty plus partners provide implementation help—we concentrate on development, second level support, and training.

What I meant with "real services" is that, especially in some countries, it is easy to get paid for providing direct services. That's what we do. In some countries, people are not very keen on paying for licenses or something abstract like a usage right.

TEC: Do you think that stance is common? The fact that Compiere is open source somewhat eliminates the whole idea of "piracy" in your case, since you can download the software at no cost anyway.

JJ: Piracy is not necessarily so unusual even in the US. Paying for something intangible obviously has less acceptance then paying for a concrete service offering.

We have a significant number of downloads and a significant user base, but as a percentage, the number of people who pay is relatively low. That's the general business model you find in the open source area, i.e. lots of people are using it, but not that many paying for support. For example JBoss has several million downloads but if you take the number of support contracts they have, it's actually not even in the percentage range. From that perspective, if you don't have a high volume constituency, open source software is not a long-term viable business.

TEC: You offer a guaranteed support option, which is one method for generating revenue from open source software. What does your support constitute?

JJ: There are three main areas. One is if there is a bug or some needed change, we fix it and make it available in source code, so what you then need to do is build your system and apply it. With support, you can download the ready-built system and just go on with life. The second added service is version migration. If you have version 2.5.0, and want to take advantage of the new functionality in 2.5.1, you need to migrate your data. What we provide in the service is the migration of your data from any version to the current one. Alternatively, you can do the migration yourself, which is a little labor-intensive and a bit risky. The third area is the priority. If a customer has an issue, that's the ultimate priority—we make things work and follow things up very effectively. In a complex system, there are many areas of potential improvement. Our partners and customers determine the priority.

There are companies who are not too keen on diving into source code, making our professional support attractive. We know that not every Compiere user will sign up for support—and "unfortunately" Compiere is more stable than most ERP/CRM products. We are offering basically insurance that if something happens, you are up and running ASAP and that your issues are on the top of our priority list.

TEC: How do you support a client that has made their own modifications to the code?

JJ: This is one of our design principles. We distinguish the core solution and any number of extensions and customizations. So, it's no issue at all if you "copy and modify" or add-on. If you change the core solution, the next migration will eliminate the changes. But, before we overwrite them, we tell the user, so that you have the chance to mark the modifications as yours. We have people with very extensive customizations and extensions and it has never been an issue.

TEC: These guaranteed support services are provided by ComPiere with the capital P. How does that work with your value added resellers (VARs), what is the process that goes back and forth with ComPiere and the VARs?

JJ: Yes, that is our support offering. In ERP, people want to have local guys to call. In our business model, partners are the only channel. What we offer is second-level support. We do not directly get involved in implementations; that is what our partners concentrate on. Their advantage is that they are local, they speak the language, they know the industry better. They are the local representatives of Compiere and can help the customer do whatever is needed. Partners resell our support offering and provide first-level support. First-level support is especially needed in the small and medium markets - preparing everything so that the user can just enter the transactions, etc.

TEC: Some people believe the open source methodology works well for commodity software such as an operating system or database, but is not well-suited for building a business around specialized applications like an ERP system. It may be difficult to develop something specialized without a lot of customer funding. Compiere itself is open source and it is not a commodity application. How does this work for you? Do you agree or disagree that development based on the open source model is only good for commodity types of software?

JJ: There is a lot of discussion on what open source is but one situation where open source is usually not a good model, is where the requirements and priorities are diverse or even conflicting. That is the case for business applications where in general; there is not the single spec you can work from.

There are basically two approaches. One is a tool-based approach, which I think is used by most of the other open source business applications. The user assembles the application by selecting the different set of tools and develops the missing or specific parts.

We have always had a very product-centric "works out-of-the-box" approach. You install it and can go into production—I think the record was over a weekend. For that, we have to be very disciplined in managing the scope of the application. Our partners help us getting the priorities right.

TEC: So for example, in your case, Compiere is very strong for financials and for inventory management it has a lot of functionality. Human resources (HR) on the other hand is not an area that seems to have been developed.

JJ: Yes, so far HR did not get many votes, but the demand is actually increasing.

TEC: Suppose that was something that a customer required, would you then need them to fund that? Is that how that functionality would become part of the system?

JJ: Yes, at this point we're exclusively doing sponsored development. That means that either one or multiple customers have said "we want this, do this for us." Certainly, if someone wants to have HR functionality they could build it themselves. People are not comfortable building core functionality, but they are comfortable adding customizations and functionality to give them a competitive advantage. HR is a relatively central area you may not want to maintain yourself. We see all sorts of extensions, billings extensions, etc. and people are very comfortable doing this. One customer for example, extended Compiere to manage their diamond and gold transportation business. They told us,

"We need extensive security—that's something you need to build in, we don't want to maintain it, we just want to use it. Whereas the operational part as to how to move diamonds and gold around the world, that's something just for us, we do not intend to share this."

That is part of their security—that they don't share it and it is part of their business model. From that perspective they were very comfortable adding significant functionality to Compiere but didn't want to touch the core engine. Another reason for customer driven development is that we want to make sure that the solution meets actual operational needs.

TEC: So ComPiere keeps them up-to-date. Do you find that you've had many people using Compiere that contribute back new functionality?

JJ: In the beginning we looked around for a business-friendly license, which does not require that you publish or make available any additions. One benefit of the GNU or other licenses is that the developer gets feedback and sees what's going on in the market, but people are a little bit cautious sharing their specific business functionality. With Compiere there are no publication requirements even if you distribute Compiere with your own extension.

In tightly coupled systems, contributing code is always an issue. Realistically, it works only if the API and timeframe is agreed first. We found that many contributions were built on "old code" and sometimes hard to integrate or were made to support just a very specific business case. One of our main responsibilities is to ensure a stable application and we need to make sure that contributions meet our quality standards and do not destabilize the application.

Code is also just 10 percent of the development effort and with today's tools actually the easiest part. The main challenges are the requirements and the design. This is the real work and here we get lots of help from our partners. These "do things right" contributions are invaluable. One of the reasons why open source applications are far more stable than commercial applications is because of the "do things right" contributions—i.e. the bug feedback of many people testing very different scenarios. We get this feedback very early and can make sure that our releases are very stable.

TEC: Even though you do want people to contribute, they don't always do it the right way, so you have to act as custodians. A benefit of open source is that anyone could contribute, but you're saying if it's not managed properly, in some cases that can become a detriment.

JJ: Yes, I think the open source business applications nowadays have learned to manage contributions. Three years ago there were many more of them, but they killed themselves quite effectively through contributions.

TEC: In what ways do you see Free and open source software solutions impacting customer implementation timeframes and budgets?

JJ: Compiere requires no final decisions at implementation time! You can change everything, even in production. This unique design principle of Compiere allows companies to go into production very fast. The record we know of is three days—average one to two months. The good thing is that it takes the pressure out of implementation projects. You make sure that it is working and then have time to fine tune and evaluate alternatives later on. Bigger projects take longer to implement, but Compiere also reduces the risk as you can get Compiere into production earlier and iteratively. Compiere is not designed for "Big5" consultants to burn hours.

TEC: You've said that open source can better suit a client's business requirements. Because communications are visible to everyone, an open source-based provider wouldn't be able to tell a client that that client is the only one with a particular problem. In addition, in true open source fashion you've mentioned that customers are part of the solution—meaning they have the option of fixing problems themselves or with others. So for the issue of communications being visible to everyone, how do you deal with facilitating that? You use SourceForge (www.sourceforge.net), for example, you have newsletters, what other ways do you communicate with your community? Are there certain communication services you're in a position to provide from the core of the Compiere project?

JJ: No information hiding. The SourceForge forums are for users to talk, exchange views, enter support requests, etc. If a customer has an issue, we ask them to create a support request visible to everyone and we then follow up. In addition, we conduct monthly conference calls for partners, where we say this is what's going on, this is what we're planning and ask for feedback. We also have a restricted partner forum where we give nearly daily updates of developments and plans and directions. This is helpful for partners and customers developing extensions and doing implementations to help their planning and prioritization. The reason we use a restricted forum is to make the communication efficient, as all participants are Compiere and functionality experts. In the beginning we did this in a SourceForge forum and got too much volume and "noise." My favorite was a posting starting with "I don't know ERP or Java, but this is what you should do..."

The open forums and discussions allow that you get direct, uncensored information—although you need to develop your own validation filter as even repeated information may not be accurate.

TEC: Is the role of conducting the partner forums and monthly conference call, a responsibility of ComPiere, the business not the open source project?

JJ: Yes, that comes from the capital P. We found it increases the efficiency of the communication significantly due to the lack of "noise". As we have a significant number of partners, we have a good representation of the committed user base.

TEC: Let's discuss presales. In the open source world you don't seem to think it's necessary to have people putting their efforts into selling software. Your point seems to be that with open source projects such as Compiere, the sales and presales work is left up to the customer, which might work well for a lot of people but potentially not everyone. What does this mean for the potential ComPiere client and why is this the case for an open source project?

JJ: I've been with Unisys, Oracle, and the company that developed the basis of SAP's R/2 in development capacities, but also in presales. Basically presales is funded by licenses. Development is always funded by support. I always wondered why that is. It is more or less obvious: development needs the stable funding base of support, whereas if you get more sales people, in theory the sales [of licenses] go up. As an open source application you have no way to recover presales costs. If someone says "I would like support from you" it means the money goes to direct services. We can do only some general marketing, part of which is appearing in the TEC knowledge bases (www.erpevaluation.com).

You can check out the documentation and web site, and also install and test it yourself. Many people get Compiere up and running in two to three hours but there are also too many "drop-offs" either in the installation part or when testing or implementing Compiere. One of our [ComPiere's] goals is to ease the installation further and provide more "get going" help. If you want local help or assistance, you probably need to pay someone.

Both ComPiere and our partners offer "Next Step," a service you can use to get your questions answered and/or get a custom-tailored demo. "Next Step" also acts as a filter for our partners and us, to make sure that there is a real interest in using Compiere. Some partners also restrict their "Next Step" offering as they get more leads then they can handle.

TEC: Would you say that's how all your VARs, across-the-board, work now?

JJ: I think so. In the beginning, many gave free help, hoping to recover the effort during implementation. That did not work as the margin on services is not high enough to recover product marketing costs. The "Next Step" model also allows the do-it-yourselfer to get the questions answered without pretending to be interested in implementation services. We are also looking for more partners to handle the number of requests we get.

TEC: What are the target markets most suited for open source software?

JJ: The criteria for a customer to implement an open source solution are functional fit and risk assessment. We concentrate on distribution, retail, and professional services industries; and are extending this into utilities and manufacturing. The general perception is that open source is a higher risk. This risk is reduced if you have people in-house who are capable of handling the technology. I actually think that the risk is less, as you are not dependent on your vendor—if necessary, you can help yourself.

We offer traditional support services to reduce the risk of open source software. We are now about five years old as an application and people now are more comfortable trusting Compiere to run their business. People are also getting more comfortable with the open source business model and realize that successful open source applications will not just vanish. Compiere has far too many users to be discontinued.

The size of the company is also a factor. Very big and very small companies tend to be more risk-adverse. From a functional perspective, the flexibility of the software seems more important for small-medium companies, so a good fit for Compiere.

TEC: I read that Compiere would be functioning with PostgreSQL soon. Do you think it will be a greater trend in the industry to move toward open source databases or is this effort just because Compiere is open source? Is there even a relation?

JJ: We have two motivations for database independence. One motivation is to increase the number of implementations for the guys on a very tight budget. They will, as they do now, help in stabilizing and improving Compiere. We also have customers and many prospects with a very high number of outlets or franchises. They found that, for them, the required licenses [for non-open source databases] are cost prohibitive.

TEC: The main motivation is cost.

JJ: If you're talking about 5,000 outlets, if something even costs just 500 dollars—you can do the multiplication. It's a significant cost area. It's basically distribution companies who have a few hundred plus outlets or franchises.

TEC: Are training services a reliable stream of revenue? Is it a growing area for ComPiere?

JJ: At the moment training is a funding source, but we do not want to get into the training market itself. That is something we say our partners should do. We limit ourselves to four trainings per year, where you can learn everything about Compiere. Our trainings are geared towards super-users and new partners. Even though at this point in time, training is one of the major funding sources, we need to restrict them because we want to concentrate on development.

Conclusion

The Compiere project is one of the most well-known and mature pure open source ERP/CRM solutions. Not only does it successfully attend to industry concerns for operating on the stable database platform, Oracle, but the project is also managing to respond to client demand for a less-expensive open source alternative. While Compiere is not immune to the difficulties that can arise in developing specialized functionality under the rubric of Free or open source software, it seems the ComPiere business is functioning as a clear example of one way that a group can sell important services based on its expertise with a Free and open source project.

This concludes Part Three of a three-part series.

Part One was based on a discussion with David Jones, leader of the Open For Business project and in Part Two we talked with the CEO of OpenMFG, Edward L. Lilly, Jr.

About this Article

TEC is launching its Free and Open Source Software (FOSS) Evaluation Center. It will provide impartial analyses of enterprise solutions that support FOSS platforms such as Linux. To complement the evaluation center, TEC is augmenting its research coverage of Free and open source solutions. Please send comments or inquiries to the author, Joshua Chalifour, at jchalifour@technologyevaluation.com.