The debate around open source has been a hot-button tech topic for decades now.
But it’s a question that has largely stayed off of the desks of ERP software decision-makers. To this point, open source projects have gained more traction further down the technology stack. While projects like Linux, Apache, and PostgreSQL have massive user communities, the enterprise application space has lacked success stories at a similar scale.
But in 2017, market interest in open source is rising up the technology stack. Two of 2017’s most anticipated tech IPOs (Alteryx and Cloudera) offer flagship enterprise applications based on open source technology. Each solution includes business intelligence capabilities designed to improve the front-end reporting experience for business analysts and executives.
Is ERP the next application class set to see an expansion in open source interest?
Ned Lilly, CEO of xTuple, joined me to discuss why he believes the future is bright for open source ERP.
In our conversation, Ned discusses some of the intriguing value propositions offered by open source ERP software. With open source: code access provides new opportunities for customization; end-users have more impact on product development; and transparency elevates quality standards.
The growing user community for xTuple is another indicator of the appeal that open source can hold for ERP decision-makers. For business executives willing to think outside the box provided by closed code base proprietary systems, open source ERP deserves a closer look.
The fundamental reason companies look at open source ERP/CRM is less technical, and more strategic: in an ever-changing vendor landscape (see my ERP Graveyard blog), companies need control over their IT investment, and insurance against vendor caprice or inattention.
Bob Young, the Red Hat cofounder likes to say, “You wouldn’t buy a car with the hood welded shut, where your only option for service was to take the car back to the factory where it was built. You may not be a mechanic yourself, but you’d sure like to be able to take the car to the garage of your choice.” That’s what open source affords companies at the most basic level: the freedom to make your ERP work for you, rather than the other way around.
Now, over and above that basic strategic rationale, there are the tactical process arguments, such as the ability to ride the wave of innovation and rapid quality improvements that open source affords. Also, open source offers the ability to participate in, and benefit from, a global community of finance, operations, and IT professionals whose experience directly informs ongoing product development.
In much of the software infrastructure world, the question you ask has already been flipped - why would you not consider open source? Indeed, many governments around the world have taken it a step further and mandated that open source solutions be considered in their IT projects. We believe that trend will accelerate, and consideration of strong open source solutions will become more the norm in companies’ evaluations of business management systems.
This actually goes back to my initial hypothesis when starting the company. I spent some time looking at the ERP world, and was struck by the disconnect between the agendas of the big vendors and the needs of the end-user companies. There was definitely a high-handedness that bordered on arrogance–a sense that the vendors knew best what was good for your business, and you were going to pay a lot of money for it. I recall an Oracle user group meeting in particular where Larry Ellison told the crowd that no one should never have to make any modifications to the Oracle Applications suite.
What I had seen in my study of ERP was just the opposite–that while there is certainly some core common functional requirements across companies, variations and specific business processes demanded a more flexible approach. I had spent some time in the open source world, and was struck by how well many open source communities balanced the need to constantly innovate, while maintaining a stable core application from release to release. I came to believe that open source represented a real process improvement in the development and maintenance of software: functionality driven from the bottom up by real user needs, implemented through expert peer review and transparency throughout.
On the distribution end of things, open source also presents virtuous process improvements for both end-users (who can test and evaluate on their own terms and timetable) and the vendor (who can compress a lengthy sales cycle by encouraging prospects to self-educate).
xTuple’s own experience as a company is instructive. We had modest success early on, before we were fully open source, by giving customers and partners access to commercial source code, and working with them in a limited way to develop the software. We walked before we ran, if you will, in learning how to manage a distributed community of business software users, testers, and developers. But it wasn’t until we made the PostBooks core of xTuple fully free and open source in 2007 that the company really began to take off. On both the product development and distribution side of things, open source has been a winning strategy for us.
Well, to begin, there is still a software license: a contract with the owner/copyright holder of the software that specifies how and under what conditions a company is permitted to use the software. There are a variety of different licenses approved by the Open Source Initiative, which vary in their requirements for things like attribution and submitting code changes back to the copyright holder. The OSI license used by xTuple is the Common Public Attribution License (CPAL), which we feel does a good job of balancing the interests of the copyright holder (in our case, a vendor which voluntarily made a huge swatch of its own originally-created intellectual properly available free and open source) and the users of the software, some of whom might choose to contribute to its ongoing development.
It’s a good question, rooted in a common misconception. The availability of source code has no impact on the operational security of a professionally compiled and managed executable instance of a piece of software. Software has always had source code, and it’s always been compiled by a vendor; the difference is who has access to that source code during the development phase. What we’ve found, over and over again, is that a more open approach–more transparency–during that development phase actually leads to better security. Vulnerabilities are more easily spotted and fixed. It goes back to an aphorism attributed to Linux creator Linus Torvalds, “With enough eyeballs, all bugs are shallow.”
Look at all the government organizations, including even secretive groups like the NSA, who are actively involved in the development of Linux. Or consider the story of an old legacy commercial database called Interbase, whose customers once numbered a good portion of the Global 1000 and several branches of the US military. The vendor behind Interbase, faced with declining revenues and unwilling to invest much more in new development, decided to open-source the code. Within days, open source community members found a long-standing security backdoor that had been created by a long-departed Interbase employee. The contributor submitted a patch to fix the vulnerability, and an embarrassed but relieved Interbase very quickly issued an updated version of the software.
If you picture the collected user communities of various types of business software, it’s useful to think of a large pyramid. The base of the pyramid are those lower levels that you mentioned, with wide and diverse populations using those more horizontal technologies for a variety of applications. As you work your way up the pyramid, the communities inevitably become smaller and more specialized–even within the context of functionality we might associate with an ERP system. Everyone needs a general ledger, for example, but not everyone needs to enter equipment depreciation values in that ledger or capture costing variances in volatile commodities warehoused at multiple physical locations.
At xTuple, we believe that the “water level” of commoditization is indeed rising past the pure infrastructure levels (operating system, database) and into the more horizontal application areas such as accounting and CRM. How far will it go? Not surprisingly, that depends on how rapid the rate of adoption is and how large the open source communities grow. I would say that we’re early in the adoption curve now. But adoption is accelerating, aided by the growing acceptance (and even standardization) of open source at the infrastructure level. Open source certainly should be a part of the conversation for anyone evaluating enterprise systems today. All stakeholders in the process (customers, vendors, consultants) should expect for more and more of the resources spent to focus on areas of true value-added differentiation. That is, companies will increasingly invest in the business processes, tools, and configurations that help them, specifically, to succeed–and will be less and less inclined to spend significant resources on basic plumbing.