Mitigating Maintenance Cost with Open Source Software

Open source is an interesting thing. If I open the source for my software product, anyone can make a clone of my product and easily recreate my company’s money-maker. Open source is bad in this situation. On the other hand, due simply to the price difference, many will choose the open source solution. Is price difference the only sensible reason to choose an open-source product? And is open sourcing their code always bad in business?

Some types of open source software see organizations form around it. Each of these organizations has a stake in the success of the software, likely because it is a tool that their business uses. This software is not their business, but they still need it, so they must spend resources keeping it up to date and bug-free. If an organization chooses to use community software, there is temptation to write features tailored to your own business without contributing them back to the community code base. This is called code fragmentation, or branching, and it is not a good thing for community software.

Fragmentation occurs when a piece of code deviates from the original. Any updates to the original can not be easily merged into the branch. In most cases, having a fragmented piece of software means that fewer people use it and fewer people can support and maintain it. Software maintenance costs can be huge, and no business wants to pay unnecessarily high costs to maintain software. It is in their best interest, therefore, to contribute back to the code base to ensure that their version of the software does not branch too far from the original.

In this way, community-maintained code can have much lower maintenance costs than in-house developed software. Here lies an opportunity! If a business is considering developing in-house software tools, they become the sole maintainers of it. But, if they can find other organizations that have the same problem, they can pool their resources to develop the code as an open source project.

The only maintenance costs for community software is periodically updating your copy of the code from the community’s copy. This takes manual work and can be error-prone. If only there exists a single-command to update from the community’s copy. But there are such ways! Many languages and platforms have press-button ways of easily getting the latest version of someone else’s code, usually using the term ‘packages’. Microsoft has NuGet, Ruby projects have Gems, Python projects have pip, and even platforms like iOS and Android have the App Store and App Market which sell entire packaged programs.

Salesforce also has a concept called “packages” that contain code and functionality that you can download into your org from the App Exchange, which can be used to distribute easily updatable code packages. Many of these packages cost money and are supported by a third party, however, there are also packages of open-source software on the App Exchange. These shouldn’t be so easily dismissed, as you get an free solution to a common problem, and the code is supported for free by the rest of the users of the packaged solution.

This may be a simplified view of the process, but I think that open sourcing a coding solution may be a great strategy, especially if you don’t want to be the only maintainer. A good business stays focused by putting resources towards its trump suit. If software is not your money-maker, then it’s best to avoid paying unnecessarily high costs to write and maintain custom software. Software support and maintenance can be a huge cost that can be mitigated by working together with other people who have the same problem.

Posted in: Programming, Software Maintenance