3 ms·

Nowadays most software depends on open source one way or another, and as developer you will eventually run into issues with the open source software that you de

by alien_ 8y ago

Nowadays most software depends on open source one way or another, and as developer you will eventually run into issues with the open source software that you depend on. Also, larger companies internally operate much like an open source community, having multiple projects that accept contributions from anyone in the company. Reporting and fixing public issues as part of your employment is a sign that you care about the ecosystem that you are part of, giving back rather than just benefiting from it. It's not necessarily a showcase of your coding skills, because these contributions are usually small, but it shows that you will get your hands dirty if needed and fix the problem at the root, instead of hacking a workaround in your own code base. It also shows that you have no problem with learning a new code base and delivering code according to that project's quality standards. If you don't have any public activity it may imply the opposite: that you are just freeloading your community, that you are prone to doing workarounds instead of fixing the problem upstream or that you are unable or reluctant to contribute to other projects.

hocuspocus 8y ago
> It also shows that you have no problem with learning a new code base and delivering code according to that project's quality standards. If you can tell your employer you'll spend the next sprint or two fixing a bug upstream, good for you! From my experience working with complex libraries, when you hit a bug or a corner case, it is probably not going to be an easy fix. There's a reason many open source projects are triaging low-hanging fruits for first-time contributors.
- alien_ 8y ago
  Companies should invest in the open source they depend on, otherwise they will need to re-implement it from scratch or maintain an in-house fork with higher costs. You may be spending those sprints implementing a workaround that you will then have to touch again when the problem is eventually fixed upstream, or you will run a private fork that you're stuck with forever and will have a hard time maintaining. As for the complexity, from my experience it's a mix. There are indeed many complex issues, but often times the fixes are relatively easy and take little time to fix. For the hard ones it's often enough if you can contribute to the conversation to better understand the problem, providing valuable information on how to reproduce, so that someone familiar with the code base can solve it easier.

by alien_ 8y ago

hocuspocus 8y ago

> It also shows that you have no problem with learning a new code base and delivering code according to that project's quality standards. If you can tell your employer you'll spend the next sprint or two fixing a bug upstream, good for you! From my experience working with complex libraries, when you hit a bug or a corner case, it is probably not going to be an easy fix. There's a reason many open source projects are triaging low-hanging fruits for first-time contributors.

alien_ 8y ago
Companies should invest in the open source they depend on, otherwise they will need to re-implement it from scratch or maintain an in-house fork with higher costs. You may be spending those sprints implementing a workaround that you will then have to touch again when the problem is eventually fixed upstream, or you will run a private fork that you're stuck with forever and will have a hard time maintaining. As for the complexity, from my experience it's a mix. There are indeed many complex issues, but often times the fixes are relatively easy and take little time to fix. For the hard ones it's often enough if you can contribute to the conversation to better understand the problem, providing valuable information on how to reproduce, so that someone familiar with the code base can solve it easier.