Since the time we have made Bahmni but more so with Avni, we get inquiries during our sales about customers wanting to own the software solution after the initial few years. This happens mostly with large nonprofits or when government entities are involved. Since these products are open source technically there is no restriction in taking the entire source code of the solution - without even asking the authors of the software. But in practice taking over open-source products is far more complex than it appears. In this article, we explain why this is so.
Bahmni, Avni, and other such products are generic in nature by design, so they can serve the purposes of multiple organizations with slightly different needs. We have written about the generic and specific nature of such software previously and discussed what it technically means to use open source. When considering such a solution from an ownership point of view one has to account for the complexity of ownership. These platforms are much larger in their codebase size compared to if the same solution was developed for one customer for the same use case. This is for two reasons:
1. Most customers of these products will not use all the features of the software. But there is usually no clean way to remove such unwanted code. Some components can be done away with but feature-wise removal of unnecessary code is quite difficult.
2. This is the more important reason. A generic software solution implements many things in an indirect manner. For example in the case of Avni usage for maternal and child health programs, one will not be able to find even the mention of the term pregnancy in the code, or any table called mother and so on. These are concepts implemented on top of generic entities like Subject, Encounters, Visits, and so on. For any specific customer, most of the generalization done in code is of little value. But more importantly, the code base is far more complex due to this necessary generalization.
Overall one may be owning the size of the codebase which is 5x to 10x larger in size compared to if one just developed a custom solution for oneself. For a software team that will maintain and enhance this software on their own - there is a lot of unnecessary complexity in the code without a corresponding value. The value of this complexity is only for the product team - because they want to solve the problems of multiple customers. Hence owning such a codebase requires a higher level of skills and team size, making it more expensive and not practical.
Surely for smaller generic open-source solutions some of these problems are easier to tackle - as even a generalized product code may not be so difficult to maintain.
This doesn't imply that one should develop one's own solution. We have discussed here why it is a better idea to use open source products and here why developing one's own solution is difficult. Developing in-house poses risks and costs which are not obvious. But in generic products, there is a complexity-related tradeoff involved which one should be aware of.
We have a couple of suggestions to resolve this problem to some extent.
- Support the existing product team in ensuring that they continue to support you in the long run. Maybe for other reasons, but this is getting recognized across the world with open source software projects that underlie many software systems in use.
- Expect these software products to have the integration ability so that in the future one can slowly migrate to a different system.
Author: Vivek Singh
Published on: 27 May 2022