What I don't quite understand in this discussion is the either/or nature being suggested here and elsewhere in the thread. There are plenty of opportunities to contribute to OSS in the context of proprietary software. Even if you write proprietary software, you most likely use open source software (I know that's not true of everyone-- more on that below). And when you use it a lot, you find bugs or missing features, which you can fix as part of your job. When I was less experienced and there was no Github, I shrugged my shoulders and worked around problems I found, which usually just led to more pain. Now, I grok the code and make a pull request. It helps the proprietary project I'm working on and helps, almost incidentally, all of the other users. And ultimately, I suspect that's where a huge portion of OSS code comes from: people who need it and are thus willing to contribute as part of their proprietary software jobs, not from dedicated OSS developers volunteering their time, forgoing sanity and a paycheck. That's why there's so much good OSS infrastructure software.
With that in mind, let's imagine a manager hiring engineers for a project built on top of an OSS stack. Sometimes that stuff won't work right, and sometimes--I'd argue usually--the right answer is to just fix it. And you're looking at a developer with experience doing just that and someone who hasn't. One has taken the initiative to learn their way around the internals of the tools they use and the other may or may not have. Who do you pick? Contributing to OSS is not just a badge of honor here; it's what's left behind by good development work.
Sure, some jobs don't have that. Maybe it's a video game built on some proprietary toolkit, maybe it's a low-level library written from scratch. But surely those aren't the employers who care so much about your Github account, right?
Comments
What I don't quite understand in this discussion is the either/or nature being suggested here and elsewhere in the thread. There are plenty of opportunities to contribute to OSS in the context of proprietary software. Even if you write proprietary software, you most likely use open source software (I know that's not true of everyone-- more on that below). And when you use it a lot, you find bugs or missing features, which you can fix as part of your job. When I was less experienced and there was no Github, I shrugged my shoulders and worked around problems I found, which usually just led to more pain. Now, I grok the code and make a pull request. It helps the proprietary project I'm working on and helps, almost incidentally, all of the other users. And ultimately, I suspect that's where a huge portion of OSS code comes from: people who need it and are thus willing to contribute as part of their proprietary software jobs, not from dedicated OSS developers volunteering their time, forgoing sanity and a paycheck. That's why there's so much good OSS infrastructure software.
With that in mind, let's imagine a manager hiring engineers for a project built on top of an OSS stack. Sometimes that stuff won't work right, and sometimes--I'd argue usually--the right answer is to just fix it. And you're looking at a developer with experience doing just that and someone who hasn't. One has taken the initiative to learn their way around the internals of the tools they use and the other may or may not have. Who do you pick? Contributing to OSS is not just a badge of honor here; it's what's left behind by good development work.
Sure, some jobs don't have that. Maybe it's a video game built on some proprietary toolkit, maybe it's a low-level library written from scratch. But surely those aren't the employers who care so much about your Github account, right?