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.
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.
is Part Three of a three-part series.
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,
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.
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?
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.
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.
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.
You offer a guaranteed support option, which is one method for generating revenue
from open source software. What does your support constitute?
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.
How do you support a client that has made their own modifications to the code?
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.
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?
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.
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?
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.
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.
Yes, so far HR did not get many votes, but the demand is actually increasing.
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?
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
"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.
So ComPiere keeps them up-to-date. Do you find that you've had many people using
Compiere that contribute back new functionality?
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.
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.
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.
In what ways do you see Free and open source software solutions impacting customer
implementation timeframes and budgets?
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.
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?
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
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.
Is the role of conducting the partner forums and monthly conference call, a
responsibility of ComPiere, the business not the open source project?
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.
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?
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.
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.
Would you say that's how all your VARs, across-the-board, work now?
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.
What are the target markets most suited for open source software?
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.
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.
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?
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
The main motivation is cost.
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.
Are training services a reliable stream of revenue? Is it a growing area for
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.
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.
concludes Part Three of a three-part series.
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,
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 email@example.com.