4 ms·

If an open source developer is defined as "one who is committed to a particular OSS project and is a regular code/review contributor" there are only two scenari

by param 17y ago

If an open source developer is defined as "one who is committed to a particular OSS project and is a regular code/review contributor" there are only two scenarios that I see where my company should hire him 1. My company stands to benefit from the evolution of said project (think red hat) 2. He is ready to move on and not contribute to the project any more. I would need his full attention to be on the project I am hiring him for. I don't agree with the article that any random company should go and start hiring open source developers.

callahad 17y ago
Though an individual may be "committed to a particular OSS project," it's hard to work on OSS in a vacuum. An open source developer is much more likely to have a broader awareness of the software landscape, especially when it comes to the F/OSS ecosystem. That knowledge can be invaluable when large tasks with tight deadlines pop up. So as to your first point, I'd argue that the added domain knowledge would benefit your company, even if the specific project does not. As to your second point, it seems like that policy would only allow you to hire individuals that do not practice their craft off-hours. I'm not sure how that would improve the quality of your team or its products. All else being equal, I do believe that random companies should hire open source developers preferentially. If nothing else, the first and third bullets are quite useful: You can see real, working code before making a decision, and the commitment to a F/OSS project is a commitment to honing the developer's professional craft.
thirdusername 17y ago
(I'd like to apologize in advance if my tone is a bit harsh, I'm not trying to be insulting.) You'll get my full attention when you pay me for 16 hours of work, what I do in my spare time isn't for you to decide. There also aren't a whole lot of programmers to pick if you disqualify all the ones that work on side projects (open or closed), just because you can see that hes working on something else on his own time doesn't mean hes not doing his job.
rosser 17y ago
But for the purposes of that article, that's not how an open source developer is defined. Maybe in his last point, but we'll get to that. For the most part, it seems like he's just talking about the benefits you get from hiring, or even considering, someone who hacks on open source projects. Problem is, the article isn't very cogent. All of his benefits are generalizations, and either obviously true or wrong: 1. You can look at their code on the internets. 2. They can reverse engineer obfuscated, changing protocols. 3. They like to code. 4. They can upgrade httpd. 5. You're ... apparently also adopting whatever project they hack on. Huh? If I'm hiring developers, though, I probably am going to look positively on folks that hack OSS.
makecheck 17y ago
In my case, I have a full-time job unrelated to free software, and I dedicate substantial time outside of work to my free software. You are wrong to assume that a developer who has programming interests outside of work, would somehow fail to give you "full attention" on the job. If anything, it shows that the developer knows how to write many different kinds of programs (a strength).

by param 17y ago

callahad 17y ago

Though an individual may be "committed to a particular OSS project," it's hard to work on OSS in a vacuum. An open source developer is much more likely to have a broader awareness of the software landscape, especially when it comes to the F/OSS ecosystem. That knowledge can be invaluable when large tasks with tight deadlines pop up. So as to your first point, I'd argue that the added domain knowledge would benefit your company, even if the specific project does not. As to your second point, it seems like that policy would only allow you to hire individuals that do not practice their craft off-hours. I'm not sure how that would improve the quality of your team or its products. All else being equal, I do believe that random companies should hire open source developers preferentially. If nothing else, the first and third bullets are quite useful: You can see real, working code before making a decision, and the commitment to a F/OSS project is a commitment to honing the developer's professional craft.

thirdusername 17y ago

(I'd like to apologize in advance if my tone is a bit harsh, I'm not trying to be insulting.) You'll get my full attention when you pay me for 16 hours of work, what I do in my spare time isn't for you to decide. There also aren't a whole lot of programmers to pick if you disqualify all the ones that work on side projects (open or closed), just because you can see that hes working on something else on his own time doesn't mean hes not doing his job.

rosser 17y ago

But for the purposes of that article, that's not how an open source developer is defined. Maybe in his last point, but we'll get to that. For the most part, it seems like he's just talking about the benefits you get from hiring, or even considering, someone who hacks on open source projects. Problem is, the article isn't very cogent. All of his benefits are generalizations, and either obviously true or wrong: 1. You can look at their code on the internets. 2. They can reverse engineer obfuscated, changing protocols. 3. They like to code. 4. They can upgrade httpd. 5. You're ... apparently also adopting whatever project they hack on. Huh? If I'm hiring developers, though, I probably am going to look positively on folks that hack OSS.

makecheck 17y ago

In my case, I have a full-time job unrelated to free software, and I dedicate substantial time outside of work to my free software. You are wrong to assume that a developer who has programming interests outside of work, would somehow fail to give you "full attention" on the job. If anything, it shows that the developer knows how to write many different kinds of programs (a strength).