TEC Talks to OpenMFGFree and Open Source Software Business ModelsPart Two: OpenMFG
Written By: josh chalifour
Published On: September 2004
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 (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 Two of a three-part series.
One was based on a discussion with David Jones, leader of the Open For Business
project and Part Three is based on a discussion with the Compiere project leader,
OpenMFG is based on an idea that the Open Source concept of being able to freely
redistribute software in source form works well for commodity-level infrastructure
tools like operating systems and databases but is not necessarily the best solution
for vertical application software such as an enterprise resource planning
(ERP) system. Thus, OpenMFG itself is not an open source ERP system but leverages
open source in two key ways: the product is built on top of inexpensive open
source software such as Linux and PostgreSQL, and the company makes its own
source code available to its partners and customers. As CEO Ned Lilly explains,
their own software is offered under a licensing method that borrows some ideas
from the open source model but is different.
Lilly: There's two different ways that we license software from the
pricing perspective but the terms of the license—what you can do with the software
and source code availability—are the same. Anyone who purchases the
software from OpenMFG gets the full source code and under the terms
of the OpenMFG license any changes they wish to make to the source code. . .
they need to iterate with us and we, under the terms
of the license, essentially take ownership of those changes and then
have the prerogative to bring them back into the main release. We're trying
to bottle in a way, the development energy that goes into open source and frankly
we don't expect to see as much of that among end user customers as we do among
our resellers. Our VARs are systems integrators, software resellers, consultancies,
by and large, companies that have been in the ERP business for a while that
know manufacturing and manufacturing processes, but also companies that have
enough technical orientation to at least be interested in modifying the software
and that's where we expect to see more code contribution along the lines of
what you'd see in an open source project.
How do you work with your VARs to find out if what they and the clients are
saying are functional priorities for them? How does their having access to code
help OpenMFG incorporate improvements back into the main product? Is this process
different in any respect because you're dealing with source code from a not
purely proprietary perspective or because you're dealing with an open source
I think we look at our partners and to some extent our customers as an extension
of our development team really. The process by which you iterate the design
ideas and enhancements isn't really that different from how you'd do it inside
a traditional internal proprietary software development organization, or for
that matter, in an open source community. You say, here's the need, we want
to add engineering change tracking to the bill of materials, to pick an example,
so how do we want to do it? Anybody got any ideas? Yeah, I've looked at the
bill of materials table and the other tables in the database that are affected
here and I've looked at the relevant source code, here's my idea for how to
do it and how it would impact the other code. Somebody else might jump in and
say here's how another vendor does it, you might want to think about that. Then
we might jump in and say, well here are some changes we're looking to make for
the next route, so make sure you take that into consideration in your spec and
you sort of iterate it much in the way that design discussions get iterated
in open source communities today and then somebody goes off and writes it.
That could be the VAR or that could be OpenMFG.
Yeah, it could be the VAR or it could be someone internal to the company.
You've said that you believe software vendors tend to force prefabricated solutions
on customers. Could you please elaborate, how does OpenMFG's model better suit
your clients' business requirements?
The mantra that you hear from a lot of big software vendors, and probably the
emblematic example of this is Oracle . . . basically telling them [customers]
not only do you not have to modify the software ever, anyone that tells you
otherwise is selling you a bill of goods. That does a disservice to the end
user who's looking for functionality to solve specific problems that they have
and it does a disservice to the partners who are in the business of providing
perhaps more customized services and solutions. If you buy the basic premise
that software, by and large, is becoming more commoditized and the value
is increasingly in the level of services that are attached to the software,
and we do believe that by the way, then it leads you to a point where you say
"how can we design an ERP product and a framework that is more responsive to
customer needs and partner needs?" That's not to say we want everyone to go
out and modify source code willy-nilly and come up with weird custom one-offs.
Because if you do that we won't support you. We will still only support the
officially released and QA'd and documented version of the software but what
we do that's different is we actually take partner and customer enhancements
and bring those into the officially released software.
Would you say that allows you to get changes or enhancements taken care of more
Absolutely. Like pure open source, we find that it leads to quicker fixes for
bugs—and all software's got bugs—and quicker turnaround on new functionality
How does this fit in with the types of services OpenMFG offers. You were saying
the model centers more around services, consulting, and training, right?
We think that's where more and more of the value's going to be. What we want
to do is enable our partners to do as much of that as we can. I think, like
most software companies serving smaller customers, we can't and don't want to
be in the business of doing it all ourselves. We need and rely on good
local partners who provide that first level of customer touch. Both
for the implementation of the software and the ongoing support services as well.
There will always be certain customers that we have more of a direct relationship
with, whether for geography, size, or strategic reasons, but by and large what
we try to do is build a company and a product and a framework that allows our
partners who are sufficiently trained, and are experts on the software and how
to implement it properly, to provide that level of service.
Back to your license and the way VARs have access to your source code. I'm interpreting
it as though they're paying an annual fee, almost a subscription, to continue
to have access. Is that the way OpenMFG derives its revenue as opposed to consulting
specifically to clients?
We will still be deriving software license revenue. The difference here is whether
we collect a traditional perpetual license, which is skewed toward a larger
up-front payment and then on-going maintenance or whether the customer opts
for an annual site license, that is, more of a subscription type model. In either
case it's still a payment for software.
But on the one hand you're looking at something that is more about the services
you may be providing to a client, whereas on the other hand ... for example,
the development partners, there is an annual fee they pay you.
That you can think of as almost basic training. It's essentially two seats of
You believe that open source makes more sense for the commodity level infrastructure
tools such as operating systems and databases.
For a pure open source license, I think so. Generally speaking, the more horizontal
the software, the more appropriate pure, free open source is—because the software
is more commoditized, by and large.
What are some examples of how your clients are using your software where access
to the code works to their advantage? Perhaps not the end user clients but the
VARs, where it sounds like you think it makes more of an impact—a situation
where it's helped or not.
There have been a number of situations, where in the course of the sales cycle,
the VAR has identified particular functionality that the customer would
want and in a couple of cases they laid out a suggested design of how
it might work or how the customer would like to see it. We have gone through
those design discussions several times now and in fact, we've just finished
implementing our first chunk of VAR-submitted code. It's like any other project,
you start on the outside with the smaller stuff and work your way into the more
There are a number of issues involved in developing functionality for projects
where many people outside of the core developers can contribute code. These
issues include determining and prioritizing what gets developed based on the
value of certain types of functionality.
Well if the application itself is completely free you're going to be looking
for the value somewhere else. We think there is still plenty of value
in what ends up being a fairly narrow vertical in specific manufacturing functionality.
It may be that something like a plain vanilla general ledger basic accounting
would make its way to pure open source before a full utility ERP package. I'm
sure that's already happened to some degree. People often ask us how we compare
to Compiere; to the best of my knowledge Compiere is kind of a plain vanilla
CRM and accounting but doesn't go terribly deep into the actual nuts and bolts
of manufacturing, managing the shop floor, scheduling and planning, the supply
chain, because you know, that's harder and there is a more narrow group of people
that are perhaps interested in that, or interested in contributing to a pure
open source project.
For some pure open source solutions the problem is that while they manage to
initially develop a fair amount of general functionality, they have a more difficult
time gaining the trust they require from end user organizations in order to
support development for the more key types of functionality. They need to gain
trust to get funding, which supports that type of specialized development. But
without already having some of those key features they find it difficult to
gain trust. Is OpenMFG in a different position because of the model you've chosen?
It becomes a real management nightmare too in some pure open source plays, without
a strong coordinating management effort. Assuming [the project is] a pure e-commerce
play, say someone implements pricing schedules; there's a reasonable chance,
given the way a lot of loosely run open source projects work, that a consultant
would grab the code, bring it up and running, implement a one-off, maybe submit
the code back to the project depending on whether it's GPL or not, whether they
care frankly, it becomes an ongoing management challenge. If the changes that
that particular consultant made in the way of implementing this elaborate pricing
schedule, if those changes aren't implemented back into the project, then the
next time the next release comes out, the customer will be looking at best,
at a hairy upgrade. That's always been the challenge of traditional source code
licensing, you know people have had source code availability for a while, that's
not a new thing.
But now, with the Free and open source philosophies, there is a different social
aspect to the way that code is managed or distributed.
Yeah, if there's a strong core group or if one person, in the case of the Postgres
database it's a core team of five people, or like the Apache project, but there's
got to be a strong central management that says this is going in, this is not
going in, here's why. In our situation it's the company that's doing that. We're
taking ownership of the code, very literally taking ownership of the code, and
saying this is our officially supported product.
The code you're providing includes what you've accepted to the product from
clients, but OpenMFG would not provide a service from the perspective of helping
clients make sure that what they've done, any changes, etc., will work with
OpenMFG system upgrades.
I think absent a . . . commercial organization with software license
dollars attached to it, it's hard to get that kind of model working in a pure
open source world for more narrow vertical application software because
the dollars just don't make sense. If it's an operating system where 10,000
people use it for 10,000 different things or a database where 5,000 people use
it for 5,000 different things, there's a lot more common horizontal functionality
that everybody can agree on. Take for example, if a developer went to the Postgres
project and said "I want to develop some custom OLAP analytic functionality
that's only going to work with this type of data on this type of platform, with
my product that I want to sell," the Postgres team would tell him to get lost.
I understand that for a developer to start working with your system, they're
going to have to know PostgreSQL, Linux, and QT, so how does that mesh with
what you're offering, what is the nature of those relationships with OpenMFG.
In terms of Linux, not much, it could just as easily run on
a commercial Unix or Mac OSX, we have a couple customers running
on that now too, because Postgres does, and that's really just a server. The
client, again because of the QT framework for C++,
the client could run on Windows, Linux, OSX, and there's no
run time license associated with that for QT. The reason we say developers need
to get up to speed on these technologies though is because when you start talking
about actually writing code, you're talking about writing client code, and you're
talking about writing C++ that interfaces with the QT libraries. If you're talking
about writing server-side business logic, and all of our business logic is in
the Postgres procedural language, then you're talking about Postgres knowledge
and then when you're talking about implementing the system, getting it up and
running, then you've got to have some Linux knowledge just to configure the
server and everything else. We're trying to basically put up some threshold
questions just to make sure we're getting the right people.
Your target market is the small and mid-size manufacturers, how do you see that
changing in the future? Is the OpenMFG solution targeted this way because it's
based on open source software platforms? Do you think the nature of those platforms
makes them naturally better suited to small and medium enterprises or is it
that they offer an advantage, which makes them more appealing to SMEs?
Truthfully, that's really more of a market segmentation exercise for us right
now—going where the greatest pain is. There are 300,000 small manufacturers
in the US, that's sales of 1 to 50 million and an awful lot of them don't have
any ERP at all. The main reasons they don't is because everything out there
is too expensive, too complex, and can't map to their needs or budget. We
think building a system on top of open source software changes the cost equation
fairly dramatically because they're not paying for an Oracle license or a SQL
Server license; because they're not paying for a Crystal Reports license;
because they're not paying for all the other Windows XP, 2003, upgrades and
what have you. All those component costs that go into an ERP project can very
quickly add up to 30, 40, 50,000 dollars and you know, 50,000 might be the whole
budget for a small manufacturing company.
There has been this idea floating around that it is not as necessary to have
strong sales teams for open source products as it is for proprietary ones. Possibly
this is related to a focus not on selling software as a product but rather on
paid consulting and development engagements around the software. I don't know
whether you subscribe to that theory or not, but how are customers finding you,
how does business flow in? Would you agree that in a lot of these cases the
onus is more on the customer to do the presales, to figure out the functionality?
Any software company that wants to succeed still has to market itself. We're
doing that in much the same way that any other traditional software company
would . . . I don't know if I'd say the onus is on the customer, I'd say that
the vendor needs to give the informed customer as many tools to self-educate
as he can. Someone who's looking for an ERP system is a fairly educated consumer
already. . . . You know, they've got, at least in the back of their minds, a
basic checklist of what they're looking for and may go somewhere like you guys
. . . These are people who by and large know what they're looking for and the
more substantive tools that we as a vendor can put in front of them, the more
we can tell them about here's how we work, here's how our product works, here's
how we want to work with you, here's how you can work with our local partners,
if you went that route, we try to be as, pardon the pun, open in the sales process
as we can.
According to OpenMFG's CEO, Ned Lilly, the open source software model works well just for wide-ranging commodity types of software. OpenMFG's model however, bets that it can harness some of the useful aspects that result from thriving Free and open source communities, including the exchange of problem-solving ideas, quicker
turn-around on bug fixes, and an inexpensive, stable platform base for clients; while they avoid the revenue challenges that could bar progress for a "non-commodity" open source application.
concludes Part Two of a three-part series.
One was based on a discussion with David Jones, leader of the Open For Business
project and Part Three is based on a discussion with the Compiere project leader,
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 firstname.lastname@example.org.