Interviewers: Scott Swigart and Sean Campbell

Interviewee: Paolo Juvara

In this interview we talk with Paolo of OpenBravo. In specific, we talk about:

• Openbravo and the niche for open source ERP
• Drawing developers to an ERP project
• The roles of modularity and customizability in Openbravo
• Acquisition by external companies as a goal of some open source projects
• Effectively differentiating free from paid product versions
• Openness as a core Openbravo value

Scott Swigart: Can you please start us off by introducing yourself and Openbravo?

Paolo Juvara: I’m currently the Chief Technology Officer at Openbravo, and my role here is to manage the product development organization, which is the organization responsible for delivery of the open source project. I’m also responsible for community development, which is very important to us.

My whole career has been in enterprise software development. I have a degree in electronic engineering, with a specialization in software engineering, from the Politecnico di Milano in Italy.

After graduating, I started working for Oracle, mostly in the application business. I worked in Oracle France for two years, and after that I moved to Oracle Headquarters in Redwood Shores, where I spent 12 years working in the development organization. I worked first in financials, then in supply chain, and eventually CRM. I left Oracle in August 2007, joined Openbravo, and moved to Spain.

Openbravo provides open source ERP business management applications that integrate and manage all of the major systems within a company, ranging from procurement, sales, finance, and accounting, to warehouse management, manufacturing, and MRP.

The Openbravo project started in 2002 and published its code for the first time in 2006. Since then, I would say it has been a smashing success; we have reached 1.2 million downloads of our application, and we have users all over the world. The product is localized in something like 55 countries, thanks to the community, which is growing very well.

In addition to the community edition, we also offer a professional subscription that offers the peace of mind that a lot of enterprise adopters expect.

Scott: Talk a little bit about the notion of open source ERP. I think when people think of ERP systems, they think about systems from big providers like SAP or Oracle.

Paolo: The large-scale market for ERP solutions is dominated by SAP and Oracle, Microsoft is the largest provider in the mid-market segment, and every country has its own solutions for the micro-company market, whether it’s QuickBooks in the US or ContaPlus in Spain or Buffetti in Italy.

Even so, those top players have in the neighborhood of 30-35% of the market share, but the rest is actually very fragmented. There are literally thousands of solutions that divide the rest of the market share.

Openbravo competes primarily in the mid-market segment, and we find that there is a lot of interest in a slightly different approach than the larger providers. One aspect of our appeal is that we are open source, which can allow more of the project budget to be dedicated to things like personalization, adaptation, and business process re-engineering, which provide high value to the end customer.

Many times, the services are actually delivered to the end customer by a system integrator or value added reseller that may see Openbravo as a good foundation they can use to differentiate themselves. Instead of being one of thousands of partners to one of the big providers, they can be appreciated for themselves.

There is also lots of interest among independent software vendors whose own solutions have reached end of life and who have identified Openbravo as an opportunity to build their own new solution on top of an open source platform.

Scott: How does Openbravo fit in among the other open source offerings, such as Compiere?

Paolo: When Openbravo started in 2006, Compiere was a very small company with very large adoption. At the time, Openbravo entered the field as a second option, and now in the past two or three years, a number of solutions have popped up, such as ADempiere, Open ERP, OFBiz, opentap, and xTuple.

There really is a lot of community interest around these solutions. Not so many years ago I remember reading that open source will never happen in the ERP space, because people don’t enjoy doing accounting in their free time.

That point of view really speaks to a misconception of what open source is, in the sense that people don’t necessarily do it in their free time for fun. They do it because they have an interest and they have a need.

Sean Campbell: What do you think brings individual contributors to an ERP project? There’s an obvious draw to some projects, such as productivity tools, which obviously can provide a direct benefit to an individual contributor, in the form, for example, of providing a feature they have been wanting for a long time.

I can more easily understand contributions from companies, but do you also get much in the way of individual contributors?

Paolo: We have a very diverse community of of both end users and service providers who have a professional interest around Openbravo.

For example, their business may benefit if certain functionality is improved, by allowing them to either enter new markets or provide better services to their customers. In that case, their motivation is to make investments to develop the means to meet their customers’ needs.

Once contributors like that have developed functionality, they can contribute it to Openbravo as core functionality, in which case they benefit because they are no longer individually responsible for maintenance, and their customers have an easier upgrade path.

Another option is for them to develop it as a value-added module that they can redistribute and share with the rest of the community. Openbravo recently changed its architecture to support modularity, so people who develop independent pieces of functionality can distribute them independently .

That capability is really getting our community very excited. While many people want to make core contributions, doing so is fairly difficult; a core feature, in fact, must meet all the stringent quality requirements of core, like multiple language support, database independence, etc.. On the other hand, developing a module allows a contributor to take it just as far as it makes sense for them to go with their functionality. In other words, modularity significantly reduces the barrier to contributing and to sharing within the community.

Sean: If you’re a systems integrator, there’s always pressure to build products adjacent to your consulting services. Once you have picked up a lot of domain knowledge about an area, there’s pressure to productize it.

With a complicated product offering like an ERP system, most customers will want some type of customization, and that customization will need to be maintained. At the same time, though, they don’t necessarily want to be trapped by a purely proprietary architecture.

It seems that, from an systems integration standpoint, Openbravo might offer the best of both worlds in a sense. You get to sort of productize the offerings you have, but yet you don’t have to build all the original IP.

You could also rapidly produce micro-solutions that, even if you don’t brand them uniquely as your own, you can use them as the basis for engaging with customers and building an offering. In that sense, do you find Openbravo to represent a sort of middle road between building a unique product from the ground up on the one hand, versus trying to win strictly on the basis of hourly rates and overall level of service?

Paolo: That is exactly what we are doing. Modularity allows people to develop these extensions and to distribute them independently, as well as to leverage our distribution channels. We have a central repository that allows people to download and install them from the Openbravo user interface, similarly to downloading a plugin for Firefox.

We also allow them to do this in either an open source format or a commercial format; we don’t force people that develop a solution on top of us to be open source. A lot of partners have developed very sophisticated solutions, and they may not want to offer those in free format, because they need to recover their investment.

Our approach allows them to re-factor their solution in a number of modules, some of which they can share with the rest of the community, and some of which they may choose only with a proprietary license.

If they choose to keep some of their higher-value components proprietary, we support their ability to do so, and we allow them to publish and distribute them through our channel anyway. That also benefits the community, because everybody else knows that that solution exists and they don’t have to reinvent the wheel.

A number of companies sometimes come together with a special interest, for example high tech manufacturing. They start collaborating around solutions, sharing the work, and increasing the value of what they can deliver. That takes us toward the idea of micro-verticals, which is tremendously valuable, although it’s difficult to do, because it targets a very, very narrow market. This community model allows to do it in an economically viable manner.

Sean: Everyone wants to get away from just providing a basic commodity software product, and it has become a cliché to say, “We want to build a solution, not just a product.” It seems that your point is that it’s relatively easy to do that in the general enterprise segment, where you can invest a massive amount of development resources and have the potential for a large number of purchasers.

On the other hand, it’s hazardous to bet on just a couple solution areas, and your approach seems to be to build a foundation and then the SIs build micro-vertical solution stacks that are unique to a particular industry, which you support through an add-on framework.

Paolo: Exactly. As the platform provider, we take the burden of developing the common foundation, which is a commodity product. Doing so in an open source format encourages contributors to invest in the platform. We let the SIs specialize in doing what they do best, which helps us make sure that the platform remains competitive and technologically advanced.

Sean: The recent spate of mergers and acquisitions around open source companies has been interesting, to say the least.

For, example, Red Hat took up Consumer Net for a fifth of what Citrix paid for XenSource, and honestly, Red Hat seems to be getting more immediate value out of that acquisition, since the community is rallying behind it. When you consider Oracle with Sun, there are a thousand obvious questions about how a predominantly proprietary company will deal with the gaggle of open source projects from Open Office to MySQL and so forth.

The reason I mention all this acquisition activity is that more and more of the open source projects we talk to seem to have aspirations to grow to the point where they will be acquired. We rarely run into projects that envision staying small or becoming large in their own right.

There are exceptions, but do you think there is something inherent in the fabric of open source that makes these projects so attractive to proprietary companies that they get bought up so often before they get particularly large?

Could it be simply that it’s more challenging to go from a medium sized company to a $40 billion company, and it is an easier route to simply get acquired? Maybe its easier for a larger company to become more open source oriented than for a project and grow beyond mid-sized.

Paolo: Let me start by saying Openbravo does not necessarily know at the moment what will be our exit strategy. We are very ambitious and we want Openbravo to become a significant success, both as a project and as a company, but I am not sure what will be the best way to get there.

Personally, I don’t see an obvious potential acquirer for Openbravo at the momentand I consider the acquisition scenario quite unlikely in the short term.

In my opinion the safest future for Openbravo is to become a self-sustaining company with its own profitable revenue stream.

Outside the ERP space, it could be easier to look for an acquisition and, probably, an acquisition is the easiest way to generate return at the moment.

In many cases, open source companies are very successful at disseminating their solution but have challenges at generating revenues. I think this leads a lot of projects or companies to go for an acquisition rather than a self-standing solution.

Sean: It seems that open source projects have to offer a free version, which corresponds to what they would call a loss leader in retail. Different projects call it different things and structure it differently, but it always seems to be there, regardless of the surrounding strategy.

It brings awareness initially, but it is kind of a monster, in the sense that if you make it wonderful, you make it hard to get people to pay for the product that really funds the overall effort. How do you approach giving people maximum value from the community edition, while still giving them an incentive to use the paid edition?

Paolo: First of all, it’s important to remember that there is a lot of value to having people use the community edition, so it’s not as simple as trying to get people in the door with that and then selling them something.

Community edition users give us feedback, report defects, and so on, which is vital. The more people use your software, the more defects, shortcomings, and general issues will be flushed out of the software, and the software will become better. In that sense, we have the advantage that the ERP is really the nervous system of a company, so once it is deployed, the company runs their business around it.

Many companies are simply more comfortable with a professional edition, because they are putting the company behind it, and if something goes wrong, there is somebody to call and somebody will take responsibility to solve the problems. That makes ERP a particularly well suited area for a professional edition.

In our case, the community edition doesn’t have a reduced feature set, which is different from the approach that many commercial open source companies take. Both the community and the professional editions are exactly the same solution, but the professional edition includes additional warranties and services.

We take a lot of pride in making sure that defects reported by subscribers are resolved fast. Our target is 48 hours. That is our primary differentiator, and it works quite well in our market.

Sean: Similar to that idea of competing with your own community edition, of course, someone could use the open source and build a shadow project up right next to you. That’s another challenge for any open source business model, and it has the potential to be even more problematic. How does Openbravo relate to that possibility?

Paolo: There have been forks like that in the ERP field, and of course it is quite possible that somebody could take Openbravo and create a fork out of it. There are three main considerations that mitigate the danger to us there.

The first is that if we do a good enough job at managing our community, a fork would not be needed. The second thing is that the technical and functional knowledge you need to develop and support an ERP is very, very broad, so the investment required would be quite high.

Finally, we offer a distinct value proposition for our community, in the sense that we will enable anyone to create their own specialized solution, so there is an incentive to collaborate with us rather than to compete.

Scott: I think that’s a good spot to ask you if you have any closing thoughts as we wrap up. Is there anything that we have left out that you’d like to add?

Paolo: I would like to mention that we take a lot of pride in the openness of our development program, which our community and partners appreciate a lot. I think it sets us apart and allows us to have an excellent process, even compared to some of the more mature projects in this area.

Everything we do is very much out in the open. Not only is our source code always available, but all the artifacts of the development activity are also available, so that people can monitor our progress and participate as they like. Starting with the planning phase of each release, the community can suggest or vote for new features; they can also comment on the specifications and the designs and monitor our weekly status updates as we build the product. Once the code is frozen and during the testing cycle, the defect tracker also lets people participate and raise issues.

As a development team, we put a lot of effort into these areas, and we are particularly proud of that.

Scott: Thank you for taking the time to talk with us today, Paolo.

Paolo: Thank you.

Bookmark this: