The value that Open Source provides to my Job
Open source projects hold the most important parts of the applications I work with everyday at my job.
At the time of writing, I work mostly with PHP and Python.
For PHP projects, we use Laravel and other composer packages that take care of almost all non-business related features.
Our Python projects are not based on any framework, but we use packages managed with pip.
At the same time, all those libraries use other libraries to provide functionality that is not part of their core, so I started to see a point here: All non-business related features can be converted as a library or package.
I started to review our projects to identify those features, and I decided to remove and import them as external dependencies.
I will dedicate other posts to those libraries, but I would like to highlight the values that provide opening those portions of code:
Leverage
We use the same libraries across different projects, which means that we only have to maintain them in one place.
I like to think about them as microservices. Should we call them microlibraries?
Visibility of issues
Since the code is public, any developer can spot issues that our development and QA team may not detect. The more eyes are watching, the less issues we deploy.
Smaller codebases
By removing parts of the code from our applications, we have less LOC to cover by tests, less duplications, and higher percentages for coverage reports.
Reduced CI/CD Costs
GitHub offers GitHub actions, a free tool for building, testing and deploying open source projects. We are using it on our public repositories.
I have been sharing these thoughts with colleagues that work on different places, and it seems that not all development teams agree with this way of working.
Some do not like to use libraries at all and others are concerned about exposing parts of their code to the public but, in our case, working this way brings more benefits than issues.
Thank you for reading!
