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.
Filed under: About open source, About opentaps by Si Chen - 5 Comments →
by RSS Feed
