That is what we call a development ideology, which stands for less dependency on the code that does not belong to you. However, in the software engineering world, there’s no need to reinvent the wheel. When you need a certain functionality or a component, you have to evaluate whether it wouldn’t take too much time to do it yourself. Let’s say, you have enough time and it’s not complicated – then it’s relatively easy to create the components yourself. But imagine that the scope of a task is broader. In that case, you might want to consider an open source option. What are the things you have to bear in mind?
- The weight. Some open source packages and libraries claim that they’re lightweight. Meanwhile, in reality, they’re not. So as as developer, you have to evaluate whether the weight of the code (kb) is acceptable for a particular scenario.
- Dependencies of dependencies. You have to take into consideration dependencies of the package on the other modules or libs. Ideally, it should not have any dependencies.
- Security. It’s really important to understand what’s happening under the hood of the package – at least on a conceptual level. The reason behind it is that the code might have backdoors (intentional and unintentional), which causes security threats or even breaches.
How does it work in real life? For example, at Tesonet we have been using a bootstrap library, which had a dependency (another lib) – jQuery. It was not the best fit for us to work with, so after a thorough research, we discovered the bootstrap native (https://github.com/thednp/bootstrap.native) package. It is the same bootstrap, but in Vanilla JS. This trick helped us to lose some weight and dependency. We managed to purify our code base, got rid of dependencies we didn’t intend on having. There’s no need to be afraid of this shift. In this situation, you are gaining more by replacing old dependency with your own code or another more performant and lightweight library. Also, you reduce dependency on dependencies in the process, which is a win as well.
Another concern regarding third party dependencies is that you are very limited and restricted when solving an issue, for example, a bug in the code, or it isn’t working as expected in a specific use case. Basically, you only have a few options:
- report the issue to the maintainers of the package and expect them to fix it (this probably will happen if they are not to busy, or the same issue is bothering more users)
- if you are capable of fixing it, then be a “good citizen”: fork the library, fix the issue and make a pull request to the original repository of the lib. While waiting for the approval you can use your fork.
- write your own library or module to replace the one that is not working for you.
The two latter options might be time-consuming as you have to either maintain your own library (especially, if it’s a big one). If you went with a “good citizen” option, it might take ages to get your pull request to be approved. It is a constant battle for efficiency. Sometimes, a better option is to go with writing your own code versus using a third party library to solve your specific issues.
Finally, if you are not cautious about which third party libraries you use, you can find yourself in a situation where communication between different parts of your solution is overcomplicated and you might have to start „building bridges“ to cover these inconsistencies. Implementing these “bridges” might take up a good chunk of your time. It might take longer than creating the actual functionality you were expecting from a third party library. Also, a code to bridge communication between packages might require high maintenance, as sometimes libraries bring breaking changes when updating. Furthermore, if you are using different vendors for different visual components, you might find yourself struggling to achieve consistency to the visual representation of your solution.
All in all, the most important thing here is to keep balance. It would be tricky not to depend on an open source at all, but it’s always useful to critically evaluate the added value of a third party solutions. It’s important to compare them to each other and make a wise decision when it’s worth using an existing solution versus writing your own.