Lilly said his company's licensed software suite, used mostly by manufacturers for ERP and similar functions, is the only cross-platform application package that can run on Windows, Mac, Linux, and embedded Linux, since it is built on the Qt cross platform framework and runs on Linux and the PostgreSQL database.
"We make source code available, and have a license that encourages code contributions from partners and customers," Lilly said. "Unlike other ERP applications -- including Compiere, which only runs on Oracle -- we require no third-party, proprietary components, and our functionality is much, much, deeper than any of the fully open source options."
Lilly says OpenMFG's software might not be considered "fully open source" because OpenMFG does not claim to be compliant with Open Source Initiative (OSI) guidelines. While you get the source at no extra charge, the company does charge a license fee for the software.
"We think this hybrid approach to licensing and product development
makes more sense for complex vertical applications than either purely
open source or the old proprietary model," he said.
We recently asked Lilly about OpenMFG and its reception in the market.
NewsForge: What's OpenMFG's niche?
Lilly: Functionally, the OpenMFG ERP Suite is
comparable -- and in some areas superior -- to the leading mid-tier
packages. But there's no one else in the market that makes that
functionality available at such a low total cost, and gives customers the
flexibility and control to really take ownership of their technology
NF: Where has the business model been challenged (not legally, but
procedurally as you have deployed it)?
Lilly: We've found that people who are interested in working with the source
code (partners and customers both) are more than happy to have us take
ownership of the code, in exchange for working patches into the mainline
product. We project-manage all outside development, and assume the QA and
ongoing support role that any other software vendor would have with its own
product. Source code licensing isn't a new thing, but we think this is a new
angle on it; very few people want to be in the business of maintaining
one-off code forks, and then having to work on their own to make sure those
modifications work with future releases of the main product. It's a hybrid
approach that draws on what's made open source software so successful.
NF: Why do you feel that licensing software was your best strategy?
Lilly: Simply put, we had a very sophisticated vertical software product that
had years of development into it, and we felt that the market would be more
than willing to pay for the value represented there. That's not to take away
from the premium we place on a good implementation of the software -- which
is the most important part of any ERP project -- and strong, responsive
ongoing support, but we felt it was appropriate to recoup some of our early
investment in product development through license fees.
Generally speaking, our feeling is that the more narrow and vertical a
software product, the less appropriate "pure" open source is. In a
given population set, there might be a thousand people who have a shared
interest in developing an operating system like Linux, a hundred who would want to work on a database like PostgreSQL, but only a handful who want to roll up their
sleeves and write advanced manufacturing planning and scheduling code.
NF: While it encourages consultants, VARs, and solution providers to partner with it, OpenMFG's end user agreement prohibits developing, implementing, installing, training for use, and modification of the software to outside parties. What is your response to the claim that the license's prohibition of services runs contrary to the spirit of open source and community?
Lilly: That's the end-user license agreement you're referring to. Our
partner/reseller agreement certainly permits and encourages the sale of
services around OpenMFG. We just want to make sure that the people who
do offer those services are properly trained.
NF: Are you waving the open source banner with the company name while not being pure open source?
Lilly: The word "open" has been around for quite a while before the OSI came about. And we are very careful to tell people that we don't claim to be "pure" open source. We don't think [our software] meets the OSI definition, and we rather expect that they'd agree. But we do think it's a substantial improvement for the end-user [over] any conventional software license we've seen.
We're also very involved in the Postgres and Qt communities, and if we move ahead with a full open-source release of OpenReports, I think we can put that question to bed forever.
NF: How has your product been accepted?
Lilly: Very well. We've won customers in competitive bids from big companies
with hundreds of millions in revenues, and who knows how many man-years in
product development. We're fortunate in that we're built with robust open
source components, so we can take full advantage of things like the
PostgreSQL procedural language or Qt's multi-platform support. That cuts
down on our development time substantially. And of course, we were able to
start fresh on a new product. Having seen and worked with many other ERP
packages in the past -- a clean, new codebase is very compelling to
customers who see all the acquisition/rollups of old creaky code that
comprise the majority of the market today.
NF: How much of an advantage do you feel you have in freedom from
OpenMFG's Ned Lilly referred to his company's close involvement with open
PostgreSQL core team member Josh Berkus thinks the vast majority of the PostgreSQL community is actually unaware of OpenMFG, but he himself sees no conflict with OpenMFG's business model.
"Open source simply moves where the money is," Berkus said. "If you can't
Berkus said that open source software forces companies and people to be
"They have to be ready to change the way they make their money," Berkus
Lilly: We think that's a huge advantage in any scenario, as you dramatically
diminish the amount of finger-pointing back and forth where, for example,
the ERP vendor might say the problem is with the database, and the database
vendor points back to the application.
It's also an issue in the reverse, as the component vendors, particularly
Microsoft, are aggressively moving into application software. While you
now -- at least theoretically -- have a single throat to choke as a
customer, you've also dramatically raised your risk by putting all your eggs
in one basket. There have been plenty of examples over time of companies who
get complacent or worse when they become your single source provider.
And lastly, of course, it's a significant cost savings, as our
customers don't have to pay for Oracle or SQL Server licenses, Crystal
Reports per-seat charges, forced-march upgrades to Windows server software,
NF: Who is your competition in this space?
Lilly: There are plenty of firms with midrange ERP packages that run on
Windows, but very few who run on Linux or Mac -- especially on the client --
and no one who runs on all three.
NF: Briefly comment on the role of open source software in business
applications such as ERP.
Lilly: To expand on my point about more narrow vertical applications not
having as big a community as horizontal tools -- we do believe, over time,
that software development will be more and more open, transparent, and
global. As that phenomenon continues, there's a necessary element of
commoditization that works its way up the technology "stack" -- from the
hardware, to the OS, database, app/Web server, tools, and then the various
tiers of business applications. That's bad news for incumbent vendors, of
course, and good news for newer companies like us who can be more nimble in
their approach to licensing. For example, we're considering a fully
open-source license for our OpenReports
report writer and rendering engine. It fills the same role in our ERP suite
that Crystal Reports does for almost every other ERP application on the planet, but
unlike Crystal, it also runs on Linux and Mac. It could also fill a need for
one of the most-requested items in the open source PostgreSQL database
community. Maybe at some point in the future, it might make sense to
open-source other horizontal components in our suite, like the accounting
modules or even basic inventory management.
So open source at the application level will likely be a moving target --
and we'll be responsive to the market in continually asking ourselves where
we draw the lines, and what old assumptions we need to revisit. At the
component level, however, I think the debate is all but over. Who the heck
wants to pay Oracle, Sun, or Microsoft anything when there are such robust,
compelling alternatives available without any license fees or vendor caprice
attached to them?