Being in the open source ecosystem for business software for a long time, one of the most common traps I have seen people fall into is “customization”. This is specially true for business software which is complex to start with.
Photo by Sharon Chen on Unsplash
Everyone is Special
Each business is unique in a way an individual is. Business operate in different domains, regions, different stages of a supply chain, are of various sizes, have different strengths and are incredibly complex. The challenges in each of these scenarios is very different, and every company also has it’s own way of doing things which has made it successful so far.
Given that business are unique, it makes sense that the primary business software they use, should tailored uniquely to their needs. Other than this, an organization is also used to a certain way of working. Embedded in this are the habits of people who manage these systems. So any new system that is being used should not force a major change of habits as it is extremely painful and distressing to human behavior.
This means that when a company implements an organization wide tool like an ERP system, they need to spend time in making sure it works for them. There are usually three approaches to achieving this goal.
- Configuration: Most systems, like ERPNext, are built to be configurable. This means you can make them behave the way you want them without touching the core source code.
- Add-ons: Given the unique needs of the organization, the company needs to create additional features that do not interfere with the core functionality of the product. Examples of add-ons include specific integrations, incorporating branding or capturing additional data points.
- Feature Modifications: In this case, the company needs to change the existing way the software is designed to behave to suit the needs of the company. This could be something that is not an add-on, but it requires changing a core feature or functionality. Examples include changing the way the user interface is designed to behave, or merging two functionalities into one.
I Will, Because I Can
In the case of open source software, it is very easy to scratch this itch of uniqueness. The source code of these tools is easily available, there are communities of generous people willing to help newbies and most solutions to a problem are only a web-search away. Even feature modifications look enticing, and why worry about maintenance when we can always contribute ‘em.
On the other side, for proprietary tools, this door is permanently locked. Most business software fails because it cannot be adapted to be used by the organization or is too different for people to effectively change their behaviors. Open source on the other hand can save organizations from this problem. The danger here is of over doing the customization.
Photo by Ben White on Unsplash
Building Good Software is Hard
One of the least understood parts about software development is really how hard it is to build good quality software. It is extremely easy to hack a solution that fulfills one particular use for a particular size of data.
In reality, businesses are fluid and dynamic and constantly changing. This means that the software too needs to be dynamic and not static. Also the cost of software failure could be very high for organizations. When we understand the total cost of any project we need to understand the following:
- Cost of designing
- Cost of development
- Cost of testing
- Cost of integration
- Cost of learning
- Cost of using
- Cost of maintenance
- Cost of scaling
- Cost of support
- Cost of maintaining dependencies
- Cost of failure
- Cost of a security breach
Those who have maintained any kind of software will immediately realize that the true cost of software is not really the cost of development. And it requires years of craftsmanship and expertise to build good software which is not the core business of the organization implementing it. Add on top of this the entropy of managing such a complex process.
This is often realized in hindsight, specially in the case of open source software.
Start with NO
In my experience with over ten years, organizations that have successfully implemented ERPNext have started with saying NO to feature development.
- Configuration is necessary and a good consultant can save you a lot of feature development with good configuration
- Add-ons are fine too for integrations. Automation is a great use-case that justifies building add-ons.
- Feature development must be avoided. In case feature development is required, it is important to plan for the life-cycle costs of such an investment. If the feature enhancement cannot be ported into the core, the product become hard to upgrade. With each subsequent version, the gaps widen and the cost escalates.
The best approach is to work with the core developer team to build the enhancement right into the product. If you are in an extreme hurry and cannot wait for a right model, then you have to weigh your options very carefully.
The ability to tailor open source software is both a boon and a curse. Like all superpowers, it needs to be wielded very carefully to ensure successful long term benefits of using the software.
