When I first found out about open source software, I felt the sky was the limit — with the source code, I could do anything now! But after working on open source ERP for the last seven years, I’ve come to realize that customizing software, even open source software, should not be taken lightly. I recently spoke with Phil Simon, long-time enterprise software veteran and author of The Next Wave of Technologies and Why New Systems Fail, and asked him for his thoughts on when you should customize open source software such as ERP and CRM. Here’s what he had to say:
Customizations and Open Source Applications
One of the issues that I have routinely seen over my years as a software consultant concerns customizations. On many a project, the functionality of a COTS application did not meet one of my clients current business practices. Invariably, this would beg the question, “Should we customize the system?” In this post, I’ll look at this from the angle of open source applications.
Reasons for Customizations
I could reinvent the wheel here, but there’s no point. The best post that I have seen on this comes from my friend, John Henley of Decision Analytics. Henley details some advantages to customizing an application. They include:
- Core competencies
- Your other front/back-office systems require it
- You want additional fields and/or different field sizes
- Regulatory requirements
Henley notes an interesting paradox of customizations. Specifically one trap that almost every organization falls into is that of customizing under the false pretense of core competency when in fact what they are doing is customizing to make their ERP to look and work just like the system it is replacing. The second edition of my first book, Why New Systems Fail, takes a deeper look at open source applications, as they continue to make inroads against traditional on-premise applications from the SAPs and Oracles of the world.
In the book, I write:
- Organizations considering customizations should look carefully at their available options, ideally with the help of experienced business and technical consultants. It is imperative that they carefully consider the short- and long-term implications of these customizations, lest they be stuck with an unsustainable status quo and paint themselves into a corner.
Against this backdrop, I can’t help but wonder: Are customization decisions fundamentally different for clients with COTS apps versus those with OS ones?
Five Considerations
It’s an interesting question. To answer it, consider the factors:
Who Will Support Your Customizations?
Let’s be honest here. The vast majority of “standard” support agreements between clients and on-premise software vendors do not cover customizations. For example, if you want to change the way that the program calculates employee taxes or runs a P&L, you can certainly do so. However, if you read the fine print of your support agreement, you would have violated its terms. You can call support for help, but expect to be billed for assistance.
One of the main advantages of open source is that it allows you to customize the software more easily. That’s a major value proposition of OS: they understand that businesses have different needs and don’t have such rigid rules about customizations. Don’st expect unlimited bites at the apple, however. Open does not mean free; if you need support for your customizations, read the support agreements carefully to determine what will and will not be covered. OS projects could be supported by the original developer, like OpenTaps or SugarCRM, which is equivalent to a vendor. Will your vendor support your customizations without incorporating it back into their core product? Not always. Alternatively, they could be supported as part of the open source project by the community, but in that case, your customizations would have to be open sourced as well. Finally, since the source code is openly available, a third party could potentially support your customizations, but the process of getting another group to work with your source code might not be so easy.
Too many customizations is ill-advised in either environment
One of my favorite IT books of the last year is Roger Sessions’ Simple Architectures for Complex Enterprises. Sessions writes about Kevin Drinkwater, CIO at Mainfreight. Drinkwater is “widely recognized for his innovative approach to IT and for the cost effectiveness and agility of his solutions.” In a nutshell, Kevin understands the need for simplicity and, to this end, has a long history of minimizing or removing complexity from many environments. While aiming for simplicity doesn’t guarantee “success”, it sure decreases the chances of failure. In other words, regardless of whether your organization goes with COTS or OS, aim for simplicity. It’s just simpler for everyone involved.
Upgrades and ticking clocks
Here’s a—and perhaps the—major advantage of OS apps. You control the application. You are not beholden to a vendor’s forced upgrades. Many first-time clients of major vendors foolishly expect that the customizations will work after an application patch or upgrade of versions. Don’t. Again, you are not compelled to upgrade with open source.
Ease of customizations
There are too many different types of customizations, COTS apps, OS alternatives, and programming languages for me to make some type of sweeping generalization here. Just make sure that you do your homework. Don’t assume that an OS customization is easier because it’s OS. Spend some time to understand how easily your application can be customized, and how maintainable those customizations are over time. Note the two are not necessarily the same thing–some applications make customizations easy to make but very hard to maintain.
Not all customizations are created equal
We’ve all been here. Some VP or Director is accustomed to seeing a report in a certain way and, like a bulldog, won’t let go until s/he wins. Changing the sorting on a report or the name of “front end” field is fundamentally different than changing batch programs behind the scenes that affect thousands of transactions each cycle.
Conclusion
There’s no one right answer about whether an organization should customize its app (OS or not). Just think about the factors discussed in this article before going down this road. Make sure that your organization budgets the time and financial and human resources to effectively handle the customization. Finally, test whatever changes you have made before going into production. Most OS projects are modular in nature: it’s required for the parallel development style of an OS project. In that sense, technically the average OS project should support add-on modules and customizations more easily than proprietary apps. Of course, each project’s technical structure is different. First check everything carefully.
5 thoughts on “Should You Customize Open Source ERP?”
I think that it is very tempting to customize any product, be it an ERP, common application or even your distro’s repositories.
But, when you want stability over all, which is mandatory for servers and applications that run on them, there’s no point in risking getting left behind when new features are delivered in said applications’ releases, or even end up with broken systems. Better safe than sorry.
Maybe a better way to go is to send patches to maintainers to try to get our changes incorporated into a new release. Anyway, there’s no guarantee that they will be taken into consideration at all.
No easy answer.
Great post. This is one of those question/answers where a class is left with an open question and the real answer is… \"It depends\". If it were only so easy to tell that his/her understanding how the system works will be immensely hard to implement and just because its open source doesn\’t mean changing the source will add cost down the road.
One thing that really interests me in this conversation that goes off topic a bit is how distributed version control systems might really help us leverage dealing with customizations for customers in an open source company. Just look at the two communities github and bitbucket.org and how they are getting so popular. Look at how quickly and often people will branch the code and work on whatever feature that itches and how you can pull those itches that turn into good functionality back in to the core. Often times the connection between the core code and customizations is across to vcs projects. And merging or branching across subversion is not cheap in time or complexity. Github and bitbucket are really bridging that gap of having to add people to your subversion access and grant authority to commit and having to police the trunk. Instead, these dvcs\’s let you fork easily and pull in changes you see fit without having the overhead of managing all those users. It\’s social networking being applied to code.
So my question is this? Why wouldn\’t the open source companies get involved with bridging their customers\’ customizations so that there is an opportunity to support, incorporate, or push out of the core customizations more easily by using a dvcs?
@I Giron – Completely agreed. There are pros and cons to each approach. I’d only recommend that organizations understand what they’re signing up for from a resource perspective.
@Drew Purdy – I suppose that it’s all a function of numbers. If an OS app gains significant traction, then you’d think that bridging would take place. I just read Here Comes Everyone by Clay Shirky and he cites a stat that something like 75% of all OS projects are essentially untouched. He cites a “power distribution” in which projects like Firefox, WordPress, and Linux account for the vast majority of OS work.
So, I’d assume that more popular OS apps stand a better chance of bridging than really obscure ones.
Of course, I could be wrong.
Yes, “tempting” is indeed the right word! But do you really need it? I think Phil’s point is that (only) in a small number of cases do you really need to customize. The other customizations are probably not necessary, but often are done to placate different groups of existing users. In other words, if you showed up with the software “as is” and told a new group of users “learn this and use it,” they would probably be okay. But if you go into a company with a group of existing users, they will often come up with customizations that aren’t necessary.
Do not however assume that sending patches back to the maintainers would always work. I think people often don’t realize that there’s a real cost for “maintainers” to maintain code, be a code that they wrote or other people contributed. This is where Drew’s comments to this thread about making the code “social” really make sense.
I think moving to a distributed version control system is a really good idea, and we are looking to do that for opentaps. That way, more people could share their customizations and enhancements on top of the core opentaps.
The distributed version control system is just one part of the puzzle, though. Another big part of it is making the architecture more modular, so that a lot of enhancements could be viewed as modules on top of the core, rather than customizations to the core. I’m really impressed for example at how many modules there are for WordPress or Magento, and that’s how I’d like to structure opentaps going forward as well.
Comments are closed.