Many software engineers are unfamiliar with open source software (OSS) and have never contributed, but we all consume it, heavily. I suggest all software engineers have familiarity with OSS and consider contribution as part of the foundational culture and rhythm of software engineering. It could be authoring a new project or contributing to other projects. It could be writing tests and documentation, or helping users in community chat rooms, or blogging about your experience with various tools and libraries.
Essentiality
Imagine if we didn't have languages, tools and web frameworks to build on top of. Or if we had to purchase a license to use some stack (a well known company already tried this and apparently decided open source was a superior strategy).
Progress would be significantly slowed. Instead of going from idea to rails new and having a proof of concept in a few hours or days you'd be reinventing
the wheel for the nth time or scouring pricing information to figure out which
stack strikes the right balance of time vs cost savings. In other words: not
building.
It legitimizes your work
Code and systems that have gone through the crucible of public scrutiny and survived are that much stronger, more legitimate, with vastly more permanence.
It forces the author to create and maintain all the peripheral work around a solid piece of technology. It pushes the tech through edge cases and unexpected use cases. It forces one to write documentation, maintain test coverage, publish artifacts, build community, and consider how much generality is sufficient to elevate a system from one-off usage to becoming useful in other contexts making itself resilient to bit-rot.
It forces the author to achieve a level of excellence that probably wouldn't have otherwise been realized without the extrinsic motivation.
Contrast this with internal code. Whether that code lives or gets extirpated depends on a ton of variable factors in the company. Reorganizations, rewrites, politics, strategy, and all kinds of other factors out of your control affect the longevity of your code. And if it does live on for some amount of time, it will most likely be just good enough to maybe barely do what it's supposed to, in a perpetual alpha state. Many Project Managers don't understand the value in comprehensive technical excellence, and therefore won't prioritize technical debt cleanup, necessary refactoring, coverage, documentation, or giving talks.
After working X years at Y corp don't you want something to show for yourself? As for me, every time I solve a problem the first thing I ask is "can this be open sourced?"
It sharpens your skills
When you put your work out in the open, you invite criticism. That may seem scary, but you know makes it more than worth it? Leveling up your skills and sharpening your thoughts in the crucible of public opinion. Do hard things and you can't help but grow and become stronger and more mature in the process.
Social responsibility
Great. You've decided open source is worth pursuing. You want to make the world a better place. So what is your responsibility to the community when you open source a project and that project achieves some degree of fame or number of users? Do you "owe" your users nothing? Or something?
If your thing is worth the attention of the community there is a certain standard of excellence that should be met and maintained. By achieving some level of recognition, whether you wanted it or not, you now have a responsibility to your users.
- make a best effort to ensure the quality and security of your code
- publish a roadmap
- let users know how they can contribute
- optional: welcome new users and offer to mentor engineers who are making an honest effort to learn and grow
- be open to feedback and criticism
- aim for the good of the community
- fix bugs in a reasonable amount of time
- delegate stewardship when appropriate to reduce becoming a single point of knowledge
- pass off stewardship and leadership if you personally can't commit to the above
These are not easy things to do. Ideally we engineers have the support of our employers to uphold this commitment to social good and technical excellence. After all, it's often the tech companies who are directly benefiting financially from the wealth of open source technology that they build upon.
Epilogue
We consume millions (billions?) of hours of work put into the technology we use and built atop every day. Each of us will never come close to giving back as much as we consume. But please contribute if you can, however great or small, from a place of joy, curiosity, and sincerity, striving to to advance technology and shape community while growing yourself. Be an advocate for building culture that cares about open source at your company.
Raise the floor.