TEC Talks to OpenMFGFree and Open Source Software Business ModelsPart Two: OpenMFG

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 (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 Two of a three-part series.

Part 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, Jorg Janke.

Part Two—OpenMFG

TEC: 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.

Ned 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.

TEC: 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 software base?

NL: 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.

TEC: That could be the VAR or that could be OpenMFG.

NL: Yeah, it could be the VAR or it could be someone internal to the company.

TEC: 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?

NL: 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.

TEC: Would you say that allows you to get changes or enhancements taken care of more quickly?

NL: 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 and enhancements.

TEC: 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?

NL: 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.

TEC: 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?

NL: 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.

TEC: 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.

NL: That you can think of as almost basic training. It's essentially two seats of training.

TEC: You believe that open source makes more sense for the commodity level infrastructure tools such as operating systems and databases.

NL: 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.

TEC: 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.

NL: 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 core functionality.

TEC: 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.

NL: 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.

TEC: 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?

NL: 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.

TEC: But now, with the Free and open source philosophies, there is a different social aspect to the way that code is managed or distributed.

NL: 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.

TEC: 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.

NL: 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.

TEC: 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.

NL: 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.

TEC: 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?

NL: 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.

TEC: 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?

NL: 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 [TEC www.erpevaluation.com]. . . . 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.

Conclusion

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.

This concludes Part Two of a three-part series.

Part 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, Jorg Janke.

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.