I worked in "the Enterprise" long time ago where just the IT headcount reached well above 2000. I was in the Microsoft space then, but I had always admired those Java folks who could just use Spring for dependency management and AOP, and could deploy their apps to a Unix or Linux server. I wanted to use Spring.NET for easier unit testing through dependency injection, however, I had to:
- fill out a form
- wait three-four weeks to get scheduled to present my case to the committee
- wait for the committee's decision
- start using the open source tool a few weeks later
I did not have two months to be more productive, I wanted to use that tool right away, right at that moment.
A different - and I should say more progressive - software company was a bit more relaxed. We only had to check the open source license for the tool or framework we wanted to use, and if it was the most permissive MIT license, we did not even have to ask.
I finally reached the freedom I had always wanted in the startup world. There is no committee I have to go for permission there. If the developers are onboard with it, I glance at its license, and if it's permissive, we don't think twice about using it.
We built our app entirely on open source software. Our code editors, the database server, the programming languages, the server operating system, the web framework, our app's API layer are all using open source software. We did not pay a single penny for them.
However, it takes serious effort to build and maintain a code base. Developers are working on them after work, during the weekend, not expecting any compensation in exchange for it. As the creator of LightService, I realize what it takes to maintain a library.
I set a rule for myself:
If I use a particular open source software extensively, I make every effort to contribute back to the project.
It does not have to be a huge change. Reviewing documentation, adding missing tests is always great and appreciated by the project's maintainers.
Some projects - especially the ones under heavy development and massive changes - are easier to contribute to. One example of this is the great jsonapi-resources gem, where I helped renaming certain methods with deprecation warnings. It took a while to submit that pull request, but I felt so much better using it, as that project is the foundation of our API layer.
I am sure you are using open source software one way or other. Consider this rule and apply it yourself.