Though I would love to say that open-source code is often free and without any issues, that is rarely the case. Open-source does not necessarily mean free, and in all cases requires developer effort to learn and make optimal use of it. Furthermore, open source and "free" does not mean free of maintenance or adjustments over time. All software requires constant attention and refactoring to ensure it is well maintained.
Human Cost
There are various levels of human effort involved in open-source code. In some cases, the developer is writing the code; in other cases, the developers are learning the code. Either way, someone is spending precious time using this code. The actual human cost can become apparent when communities become aggressive and demand that developers who have been volunteering time to make this open-source code deliver more features or updates without ever giving back to these developers. Even if someone volunteers their knowledge and effort, the software community should still consider their needs. GitHub has tried to improve this by providing tools for funding the actions of some open-source developers. But, the software industry still needs to reduce the aggressive and entitled attitudes that are rife among its members.
Dependency Overload
For years there has been a catchphrase that there is an app for "that." In software development, there is a package or a component for "that" in nearly all cases. We often disregard the adding of more dependencies to our applications, and we build in the most rapid manner possible. But it's exceptionally costly to do this in the long run. Dependency pruning is a laborious exercise since it comes with heavy refactoring. Our code also suffers if we don't optimize our tests around those dependencies, so when we have to replace them for whichever reason, we have to write complex tests retroactively. Just because there is an open-source package that does something doesn't mean teams should immediately adopt it without question.
Distributed Vendor Lock-in
Distributed vendor lock-in sounds far more fancy than it is. Ultimately when we overuse open-source code, we distribute our vendor lock-in cases. Now this may sound like a good thing, but I assure you, it's not. Rather than aligning with a handful of systems with regular updates, we're aligning ourselves with multiple, similar to the dependency overload issue. The catch here is the deeper down this rabbit hole we go, the more challenging it is to refactor our way out. It's common for vendors of various open-source tooling to work with them until they cease serving them. Then your team is left to find a way to dig out of a hole, this can be cases where the vendor stops supporting packages or where underlying technology changes dramatically enough that the open-source package no longer supports it and becomes outdated. Whether you are pulling in code from numerous vendors or many packages from a single vendor, be mindful of the cost impact that would happen if you had to replace these packages.
Software is a complex system. We can reduce this complexity by being prudent in selecting what we add to our applications. It doesn't mean avoiding all open-source packages or only sticking to vendors with years of experience; it means properly debating or weighing the value of writing the code internally or using an external resource.
Top comments (0)