Pronking for Programmers
paulbutcher.com
paulbutcher.com
It's not even that they don't work on projects in their spare time. They do, but they're not part of open source culture, where people share things by default. They're satisfied with having made the thing itself, and they're not going to put their hardware or software project on github any sooner than they're going to make a website for the house they built from scratch.
If you work at an open source shop and hire with this attitude, all you're going to do is make sure that you have a monoculture in this dimension. That's not the worst thing in the world, but it filters out people who don't particularly care about open source, which is the majority of programmers. If that's a moral imperative for you, I don't have any objection to that. Otherwise, I don't see why you'd want to do this.
I think the idea of "doing open source work" sounds a bit disproportionate. At least to me. Instead, think about people sharing some small tools they have built for themselves. Even if they work for IBM, they should be able to customize their environment by tweaking some tool or writing a script to make their lives easier. They only have to share that code, not to show off but to help others with similar problems.
Not everyone has a huge body of work they can put out there in the world of FOSS for a vast variety of reasons. Of the two best programmers I know, one is active and publishes, the other is a guy you would kill to have on any team, but whose work is all in pursuit of his closed source job.
"Doing research" is not mutually exclusive with doing open source work either. In fact, I think these days, I would be suspicious of a systems software research project that didn't release the code. A lot of systems software research projects use Linux or some other open source code base as a starting point, since re-inventing the wheel is not very conducive to publishing quickly.
It's pretty obvious why companies would want to look at open source contributions. They show that someone works well on a team, is motivated, and can write code. Of course, they're not ever going to be the only thing companies consider.
It's not even that they don't work on projects in their spare time. They do, but they're not part of open source culture, where people share things by default. They're satisfied with having made the thing itself, and they're not going to put their hardware or software project on github any sooner than they're going to make a website for the house they built from scratch.
How do you know they work on projects in their spare time? Is it because they shared them with you?
I think the context here is doing Open Source work in one's spare time. And I guess that Linus does it mostly during the daytime. (I think his diving software thing has probably been done in the spare time, though.)
Please don't contribute to OSS unless you really want to. It's great if you do. But making it a near-mandatory requirement just means that it drives yet more self-promotion (it isn't a real project unless you buy a domain!), more low quality contributions, and, ultimately, becomes yet another thing-you-really-should-be-doing.
Particularly if it's an employer that doesn't itself contribute to open source.
Personally, I contribute to open source because I want to see things fixed and generally want to move fast since that's how I operate. Sometimes this has meant figuring out fixes myself and opening up a pull request. I see this as a way of helping projects I like move forward since they can focus less on bugs and more on feature development.
I have tried several times. At least, I've looked at a few of the suggestions on how to get started. All of the ideas don't quite work, though. Namely because most of the suggestions are things that I've either never even heard of or that I do not use. The gardening approach mentioned not long ago on this site seems very good for beginners - but I feel that just jumping in and starting with this could be a bad thing if the organization already has some sort of system set up.
For example, I have used Express. I don't really understand it well enough, and I've never had reason to, jump into the source code. There are only ten open issues. For just about every open source thing I've used, this is the case. Am I just doing something wrong?
[0] Though be careful with that. Only refactor stuff if you're pretty confident about how it works, and that your changes don't decrease performance or readability.
Instead, look for things that are interesting to you, follow your passion; if that eventually leads to an OSS project (either your own or helping on an existing one), great! Just avoid toxic startup cultures that require forced OSS track records and then provide "unlimited" vacations.
http://openhatch.org works a lot on making initial contributions easier, if you are interested in express then you dont need to work on the core framework, write a plugin and open source it, contributing is by far easier when you have a real need to do so, maybe someone will use your plugin and find a problem they want to fix, maybe you will use someones project and want to fix something.
And what's a great motivator for releasing things when working alone? It's having other people expect you to make progress on your projects. That's why I made a club that meets weekly to screenshare what we're working on.
It's the benefits of YCombinator weekly dinners, without the benefit of awesome speakers, great advice, or mentorship. But I'm there! If you want to get feedback on your projects and give feedback on other people's projects, then you should join my club.
It also tells you something else about a candidate: that their previous job probably wasn't particularly hard or that they didn't have much in the way of responsibilities. If you're the lead developer on a several hundred thousand line codebase, it seems less likely that you have time to build an open source resume than if you were a junior developer.
Honestly, I think open source is a bit of a mixed signal. If the code shown in the repositories is great, then that's fantastic, but if it's merely average then I think it makes you look worse than just not having it there at all. This is really my biggest objection with open source: if you want to use it as some sort of resume, then you have to contribute huge amounts of time to it in order to make it representative of your skill. Then it's no longer an open source project you do for fun, but just a second day job. Additionally, when it gets good enough for an employer to see, what interviewer is going to have time to read through it? This problem is magnified especially when developers start treating open source as a form of resume, and interviewers have to wade through shockingly poor repositories from every candidate to determine the candidate's quality.
> Sorry about that.
Sorry about you, BBC.