Maybe this is paranoia, but I'm beginning to find a lot of threads like this (and a few yesterday about 'how to hire people') actively coercive: "Contribute to Open Source or Don't Get Hired".
There are a lot of increasingly shrill remarks out there about how everyone should be doing open source projects in their 'spare time', so no-one has any excuse not to have a track record of FOSS contributions... frankly, it's bullshit.
I work in a closed-source shop (for some very good reasons, we can't open) and our devs do sterling work of a sophistication not seen in most projects, open or otherwise, solving a very difficult and rather open-ended algorithmic problem. On a good day, we get a lot of sophisticated work done.
Strangely, at the end of one of these good days, no one wants to go home and write a big fucking pile of code - we have girlfriends/wives/families that haven't seen us for 12 hours and probably aren't going to want to use the remaining hours (and typing time) to write MORE code. Even if that was a good idea - we are paid for full-time work here which means ideally we go home and relax, not flail away on endless side projects.
This is one of those posts that is made, and upvoted, based on what everyone wants to be true, instead of what is true.
The simple, unassailable truth is that having strong contributions to open-source projects is a massive advantage in any resume-scanning and hiring situation. And as a hiring manager, seeing extensive open-source work is better than seeing a resume. That means the advice is ALWAYS good advice. There is never a situation under which the proper career advice is to not do good visible work.
This doesn't mean it's a requirement, or should be a requirement, but it IS a reality. If you choose not to participate, that's fine, but it comes with an inarguable cost. You can try to convince us all that it shouldn't, but it does, and it probably always will.
I am well aware that strong open-source contributions are an advantage. What I find objectionable is not this advantage. It's the fact that failing to secure this advantage is being portrayed as an obvious professional failure that can be simply rectified by working an extra few hours a night on side projects.
It is propaganda from open source people, many of who have achieved considerably less in their open source projects than a casual inspection might suggest. Usually I come away from people's open source projects with a cheerful acknowledgement that this person (a) likes cool stuff and (b) appears to be able to write working code of a kind. This is good - but not that good.
There's a big difference between 'I wrote some code, look at me' and 'I contributed a competitive register allocator to LLVM' or 'I rewrote the scheduling algorithm for major open source FooOS'. The latter are 'strong contributions' and deserve the 'massive advantage' of which you speak. A handful of pet projects constitute a code sample that suggests that the person can form syntactically correct code.
Just being honest here, but both of your posts come off, to me, much more as you rationalizing a belief about what is true based on what you want to be true, and trying to "convince" us that most of this thing that "we" possibly value isn't all that valuable. Minimizing people's work on github as just some trivial side project, that should be ignored, because you don't want to do it, just isn't a reflection of the reality the situation. I freely admit this might be offbase, but it would appear you are arguing against -really- sound advice simply because you don't want the reality that that advice implies we live in. Except we do.
The underlying issue is that from a hiring perspective, all other things being equal, a candidate that can provably show things is ahead of the guy who simple says he can. Even if "we" all sit around and minimize that as some trivial nonsense that anyone could do and that it proves, at best, they can form "syntactically correct code", the fundamentals of the situation haven't changed. Showing is better than saying. It always will be.
There is an undercurrent of a strawman, as well, in this conversation. I don't think anyone out there is taking actual trivial github stuff and basing hiring decisions on it. But I wouldn't be surprised if some superficial github stuff haven't gotten people past a resume screen that they wouldn't have otherwise gotten past.
I concur that there definitely are strawmans and other poor argument tactics afloat. Onan_barbarian says that while some github contributions are really admirable, but some are of zero value, to which you reply by first reconstructing this argument to be "people's work on github is just some trivial side project, that should be ignored.", followed up by accusing him of rationalizing his hopes and making strawmen.
When someone says he did something, a github commit log showing it is definitely better than just him saying he did it. However, the point you actively dismissed was that a commit log of some mundane contributions is much less impressive than a resume describing work requiring a lot of skill.
Not that you're totally wrong, but a good open-source project also requires -- documentation, tests, community involvement, real users, gathering feedback from those users, collaboration.
Throwing code over the fence is not what open-source is about. I look at it as -- is this person capable of building a product for other people? Is he a team player?
That's not a skill that comes so easily and requires lots of experience or natural talent at other things than churning out code.
This has been going on forever with Academia, where the right to freely publish profoundly impacts where one chooses to work.
Anyone who dreams of becoming faculty must do work that is publishable, which often means taking substantially lower-paying "research" versus "corporate" internships throughout their younger years.
The problem is that I can't believe a word you said. I can't see examples of this awesome super top-secret code because it's all closed-source, as you say, for good reasons.
I also can't trust your references, because you'll only give me ones that will say good things about you, and any digging at your work history will only uncover "yes he worked here" responses.
I want to see open-source contributions because I like being around people who are passionate about solving problems with code, and it is my experience that people who contribute to open-source projects, or start their own, are of that mindset.
I don't think that they are the only people who are passionate, but I want to make a choice so I can get back to solving problems.
If you're making the hiring people work harder, you're going to miss out. Being able to show examples of your work is the best way to do it.
How do you feel about tests? or "write this program that does [x]" spec projects instead?
Thanks for the sarcasm: "awesome super top-secret code".
Realistically, the code and details of are covered by NDA. The task solved, the huge difficulty of same, the overall success of the task being solved, demonstrable fluency in related but public areas of computer science, and the commercial success (modest or otherwise) of the code would not be.
If you don't understand this, or couldn't say the same things about what you're doing, maybe you're not working at the same level, and you are welcome to go fire up the GitHub account and solve tic-tac-toe in Haskell or whatever the hell it is that's meant to be so impressive.
The closest analogy I can come is - say you wrote a pile of LEDA (not a invite to debate if this is a good product, but it's certainly substantial) and you've got references who are in a position to know that say, 'yes, Joe Bloggs really did write all the graph algorithms or geometry algorithms or whatnot in this package'.
Well, you're within your rights to 'not believe a word you've said'. But this falls into the thing I'm complaining about - the whole pathological distrust of programmer achievements. How do you think engineers or commercial research scientists in other fields ever get hired, for fuck's sake?
It honestly wasn't meant as sarcasm and I apologize for the hyperbole. But do you know how often I hear people say "I'm really good, but I can't show you anything. But you can talk to my references and they'll tell you I'm good." That may work with HR people and managers who don't code, but not from programmers.
There's a distrust of programmers because many programmers are not at your skill level. You don't seem to have problems with finding employment. Perhaps open-source contributions don't matter to people of your caliber. But you need to realize that it's not HR or management asking to see your code -- it's your peers.
We need as many metrics as we can to find out who's good and who says they're good. Looking at code and examples of work is exactly how you do that. You can argue all you want, and it may not be fair. Neither is "You have to have a 3.5 GPA to get a job here."
> The problem is that I can't believe a word you said.
It comes down to this: filtering by OSS contributions gives you many false negatives (as the OP has complained) but virtually zero false positives. In hiring, a false negative is a bummer, but a false positive is disastrous. It would be irresponsible of me as an interviewer not to take this into account.
If it someone's pissed because they fall into the false negative bucket, that's rough, but I'm the one calling the shots and taking the risks.
Unless the person is a major contributor to widely used project, all the OSS contributions show you is two things:
(1) The person can apparently code when he's allowed to pick what he wants to work on and doesn't have any real pressure, and
(2) He has time to work on open source.
Most companies need people who can code well under pressure and when they have to work on something they don't necessarily want to work on.
By screening by OSS contributions you will indeed eliminate one kind of false positive--they people who can't code at all. Other kinds of false positives, such as people who can't work well except on self-selected projects, will get in.
In my personal experience, all people who can code well, can do that under stress too. This must be one of those theoretically valid arguments that is rarely encountered in practice.
And from the developer perspective, just the fact that it helps you avoid idiotic CS101 tests over the phone at every interview is enough to make it worth.
'The problem is that I can't believe a word you said'
Thats fair, but the thing is that its YOUR PROBLEM(as a recruiter), not mine as a great "closed source" engineer
I know bunch of people who work on very cool and interesting problems/projects binded NDAs and have no problem on finding a new job if they want to. Hell Facebook, twitter, google are all closed source(mostly) so wouldnt you hire ex-Facebook engineer if he has no open source commitments?
Lets face it - its employees market, where companies compete for bright engineers. If you are saying that you only want open source commitments - thats fine, but you are betting on smaller market and missing some great talents. So you are more "lazy" recruiter, who dont want to look deeper, do facts check, test candidate etc. But again its your own problem, not mine.
But how many Facebook/Google/whatever engineers can a new startup afford to hire?
Not every programmer is a rock star ninja. Most are mediocre. Some are pretty bad but know the theory and can play the resume game, pass the whiteboard test, etc. There are plenty of books and lots of advice that will teach you how to fake your way through a resume, cover letter, and interviews.
Worked at Google/Facebook/Twitter? Great. Odds are I can't afford to hire you. You're not the target of open-source filtering :)
For a shop whose pre-requisite to hiring a developer is that they have code publicly available, you can bet cultural fit is the other thing at the top of their checklist.
Saying "no one wants to go home and write a big fucking pile of code" probably means that regardless of technical aptitude, you wouldn't fit in well with the kind of folks who love and encourage doing just that in their spare time. Most of the developers on our team have and love "endless side projects."
You'd go with a graphic designer with a portfolio you could look at every time, right? Say the graphic designer's previous employer didn't let them put stuff in the portfolio -- I don't know, maybe they only worked on NSA internal marketing -- that's the designer's problem. They aren't going to say "no fair," they're going to find a way to do some work to put in a portfolio.
Wouldn't have to be open source work, just work you could show.
It's tough to hear, but the goal of a new employer is not to give us what we deserve for working hard and being skilled.
The employer's goal is to maximize their chances of hiring someone good.
If a hiring manager has two people that seem about the same but they can see the code one of those people wrote, it's a no-brainer to go with the one who has a portfolio.
Agree with you that some lame open source patch doesn't matter. But if someone's done significant work in public, or even has non-open-source code they're able to share, ignoring that would be an insane choice for the hiring manager to make.
This assumes that all programming in analogous to 'graphic design'. This analogy breaks the moment you consider that perhaps at least some programming is more analogous to, say, civil engineering or in-house material science research or in-house statistics... none of these other professionals are going to be able to disclose their 'portfolio' in any meaningful way.
Yet, mysteriously, civil engineers, material scientists and statisticians somehow keep being hired and the work keeps getting done. Baffling, I know.
The difference is that if you graduate as a civil engineer the probability that you can do what the job requires is quite high. This isn't the case for most graduates in the field we work in.
This is a tragedy - I share your sentiment, but I can understand why companies are unwilling to use the same process that works for engineers as long as the education doesn't produce equivalent results.
Not to mention that research scientists and engineers often have advanced degrees which required a lot of application.
I bet you'd hire a programmer without a degree who can do the work before you'd hire a civil engineer who learned how to build stuff off the Internet. :)
Understand though that, while your points are valid, it it's certainly more valuable to an employer to be able to see your skills in action than not.
At the same time, seeing how you handle version control, how you deal with contributors and bug reports, all that matters. Being able to see that is much better than taking one's word for it.
So yes, as someone who previously worked on a shop where no code would get out, I can relate to the feeling. But the above is still true. A few things you can do about it:
- open not the products you have entirely, but modular parts of it.
- should the previous suggestion not be an option, get the company to run a blog, and have you/your workmates share solutions at a discussion level.
- get the company to allow developers to work 10%, or 20% of their time, on open source. It'll help keeping you guys sharp, at the same time it helps you putting a name out there.
Some companies have a culture built around open source software (e.x. Github), and some don't. The latter will value open source contributions less (or none). If you have no desire to be involved in open source then perhaps you'd fit better in those companies.
Also, contributing to open source projects doesn't necessarily need to happen in your "spare time". Companies contribute to open source too.
The thing to me - as someone who is more devops than dev, works at a currently 100% closed company, and does not have a public track record on github - is that this article and argument are both kind of silly.
Github track records aren't just about the fact of seeing your code; it's about the fact that you're proving you can work with the OSS community projects. That's a skill set in and of itself, as demonstrated by the recent extremely public bickering between gnome and canonical, for example. If you have a demonstrated track record of navigating OSS project drama like that and still getting your patches pulled into trunk, a company that wants to build a relationship with an OSS project is vastly more likely to hire you.
Re-reading your comment on preview, it sounds like you're looking at this like "Okay, I've coded all day on closed-source, now I need to go do up some erlang on some personal bullshit project and commit it to github, with unit tests and a meaningful commit, just so I have a track record to point to in a year or more when I'm looking for a job."
And I'm not saying that wouldn't work, but more that that's not the point at all, and any company hiring based on that is exactly as clueless (albeit a bit more up to date) as the company hiring based on a minimum of CCIE + RHCSA when looking for developers.
For-profit companies are certainly allowed to attempt to convince me that working for free for them is both morally required and in my own best interests. I promise to listen attentively.
Ditto other cultural fit issues like "Your personal life should come second to our business desires", "Marriage and children are unreasonable burdens to saddle us with", "You should be loyal to us; we may reciprocate, but if not, it is just business", etc, etc.
I don't see what this has to do with the issue being discussed - that having made open-source contributions is an important factor in getting hired.
We're not talking about companies demanding that you do open-source work for them before getting hired. It's about the idea that having some code publicly available somewhere is a good way to improve your chance of being hired.
No, it is not. For a side project to be remotely comparable to the efforts that, for example, we have put in, it would have to be quite a side project.
Calling attention to (say) a 250-line neat hack - say a patch to a driver, or solving some elegant toy problem - would constitute a detraction from the programmers' major contribution at work over the course of years.
I view this new fixation on open source contributions as a continuation of the pathological distrust for programmers' skilled contributions that used to be expressed through high-stakes (or even low-stages) white-board coding challenges. I'm not sure which is more irritating.
You act like the code you've written that no one can see should matter to another company interviewing you. There is no way for a interviewer to verify the work you've done at your previous job. Like it or not, if you are looking for a new job it is your job to impress them. Fail to do that an risk them picking someone else.
I think there's a question of degree involved. A lot of employers seem to want you to have a github account that proves that you're glued to your computer 16 hours a day (fortunately, they have no way of finding out if you dream about code too).
That said, I don't see anything wrong with wanting people that have some open source contributions. It doesn't have to be anything along the lines of having written the linux kernel in your spare time. However, it should be something that you put serious time and thought into.
From personal experience with interviewing and screening ~100 candidates over the last two years, I can say that high-quality open source contributions are a big plus for an applicant. I can also say that we've never even considered rejecting someone due to a lack of contributions.
It's great that there are companies which look down on you not using your spare time to do extra programming -- you probably wouldn't want to work at places like that anyway.
If I might reframe the issue slightly, I don’t think the problem is that coders are expected to make FOSS contributions. The problem is that coders are expected to do significant amounts of unpaid work. We all laud Google Summer of Code because it lets young people get some traction without starving. Other companies that want the benefit of hiring people with FOSS experience need to put their money where their mouth is and fund FOSS contributions. There is an awful trend of corporations wanting experienced workers but doing nothing in terms of internships, apprenticeships and mentoring.
Not only that, but "passionate" people aren't always a good fit. I prefer to work with someone who may only regard software engineering as a job, but who has common sense etc.. instead of some hacker kid who is going to try to make things as complicated as possible just for kicks.
It is becoming increasingly rare to work on an island away from open source. A lot of companies use open source in some way and having an in-house developer familiar with the projects they use or relay on can be quite useful. And the improvements that the company is willing to pay for but aren't a competitive advantage can be committed to the open source project. It's a win for everyone.
You people are insane. Going out on a limb here, as I hate making my life public - I worked at Factset Research Systems for just about four years. They are a publicly traded company (FDS - NYSE). Guess what - They would allow precisely 0% of the code I wrote for them while working there to be shown to another company.
So what you are saying, is that, given that, unless I went home and coded and contributed to an open source project during my free time, I am a shitty engineer, not worth your time. Get real. Incidentally I work elsewhere now. They asked me to solve a programming task before an on site interview, and then...shock, I had an onsite interview process.
Do you think that when a heart surgeon from NYC applies to work in Seattle or LA, they say, "That's great that you didn't kill anyone at First General on 57th street, but, do you have any published video of you doing surgery pro bono we can watch so that we know you're not full of it?"
> Do you think that when a heart surgeon from NYC applies to work in Seattle or LA, they say, "That's great that you didn't kill anyone at First General on 57th street, but, do you have any published video of you doing surgery pro bono we can watch so that we know you're not full of it?"
I think their diploma and med license are sufficient. I also think a lot in hiring decision for particular surgeon can depend on their peers opinion.
While medical cert (rather painful and time consuming to obtain) give a good guarantee that a doctor wouldn't butcher people outright, there is never such a protection with CS diplomas.
This puts developers in companies that commit to open source projects like Chromium to be at a significant advantage to those developing proprietary software. I understand where the author is coming from, but this is unfair for those who work on closed-source projects.
Of course I have my own personal projects, but for most of them, I am not about release their source.
Look, I work on a lot of proprietary stuff as well, but even if Github didn't exist, we'd both be subject to the same "unfairness." Here's a job interview, circa 1981:
Candidate 1: "I brought this fanfold printout of the source code for _____ I wrote with me, have a look.
Candidate 2: "I can't show you any of the code, but trust me, it's good."
Github merely drags that conversation forward from 1981 up to 2011. When you and I choose to write code that is locked away in somebody else's vault, we ought to charge extra to compensate for the fact that we might as well have been surfing Oahu.
That's funny, in 1982 that's exactly what I did for a job interview - I brought in a listing of source code to show what I could do. I found out later that that's why I was offered the job.
The argument that this isn't fair to many programmers has also been going on at least for the last 30 years. Fair or not, it helps a lot in convincing an employer you're worth hiring.
> When you and I choose to write code that is locked away in somebody else's vault, we ought to charge extra to compensate for the fact that we might as well have been surfing Oahu.
I like that idea. Part of the value from working on open source projects for companies is the public nature of your contributions: It's easy for you to take your commits to Chromium and show it to Facebook or Apple when looking for a job there.
references are useless, companies are very wary to give bad references due to the chance of a lawsuit, and a probation period is a massive cost to the company
> a probation period is a massive cost to the company
Perhaps, but it's a lot less than the cost of not having a probationary period and winding up stuck with a poor member of staff indefinitely because you couldn't do the impossible and spot every problem candidate during a momentary interview.
On the one hand you're saying this is unfair to those who do closed source projects at work. On the other, you're saying you have personal projects, but you refuse to release the source.
So what are you complaining about exactly? If you don't want to be judged by your own work, then there's no problem: that's your decision. If you do, but you refuse to let anyone see it, then you're creating your own problem, so you have no basis for complaint.
There is nothing "unfair" about this. Rather, you're given a choice about whether or not you want to participate and you have decided that you don't.
You're correct that I am given a choice about whether I want to release my source. But I mentioned a specific example (Chromium developers paid by Google) who are being paid to produce open source work.
I do exhibit some of my smaller projects on github; my larger projects are not online because of competitive reasons.
Considering John Resig is the creator of jQuery, which is open source, yes, he's probably more interested in someone who's familiar with the OSS development model, tools and methodology and can prove it.
His criteria don't (and shouldn't) apply to every SW hire, even though it's clear his message is "demonstrate > declare".
The hiring process isn't meant to be fair - it's meant to get the best results. A good way to see if someone can write good code is to look at the code they've written and to see if it's good.
If the ability to demonstrate that they can write good code with concrete examples puts someone at an advantage over others, so be it.
Actually in this case it puts people who like git over people who like mercurial, svn, rcs, etc which is unlikely to benefit anybody.
Last time I heard git sucks on windows, svn is still extremly widely used (try writing a game with a large amount of binary assets and use git) and some of the old open source systems still use CVS.
Unfair how? Anyone can participate in open source. Those who do deserve the benefits that come with it (of which visibility is one of the most obvious).
Anyone can participate in open source.
That's not correct - plenty of employment contracts lay claim to any contributions, which means the projects can't accept them.
Let me quite honest and say that if someone Agnes an employment contract, as a developer, that prevents them from writing unrelated code in their spare time or lays claim to any code written outside of the office, that person is an idiot. I'm not a developer and on every company I've been with in the past 10 or so years I've gotten something in writing or marked up my contract/employee agreement stating that in no way does the company have rights to anything I develop on my personal time.
I'm fully willing to accept restrictions in specific technologies if it directly competes with the core business of the employer but only under very specific circumstances.
I totally agree with the sentiment here, that such contracts that lay claim to your IP that you develop on your own automatically belongs to the company. I hate that and I've actually rejected offers in the past because of that reason exactly. I also think that if you could get a high profile enough case with that as the focal point, you could probably have such a thing declared illegal, and then establish precedent that could be used to invalidate the whole, "we own you AND your thoughts" corporate thinking. Or so I hope :)
Which is why my current employement contract has an addadendum that exempts my leisure-time open-source contributions from any claims by my employer. Despite the fact that their default contract has some harsher restrictions/non-compete clauses/claims of code-owernship, this was absolutely no problem to negotiate. Admittedly this is easier in an SMB like I'm currently working for, but still.
The company I work for recently told me that all of my patches to open source projects we use can be contributed back, under my name as work for hire by the company under the original license (no projects I've got patches for are under a contributor license of any sort, so no issues there).
This has made me extremely happy, and means that in the future I can point towards those patches that were posted as proof of work I have done.
Employment contracts don't dictate what you can write in the privacy of your own home on a non-employer-owned machine and what you subsequently do with it. (Of course non-compete clauses can kick in if you're working on Oracle DB and contribute to Postgres, but there are always other OSS projects where that little restriction doesn't apply.)
The sad thing is man, some DO. I've personally seen contracts with clauses like this:
"Any code, materials, designs, patents, design patterns or other such intellectual property ("IP") created by candidate is automatically and immediately assigned, irrevocably, to Employer upon its creation without further consideration."
The legality of this withstanding, I'm just letting you know, from experience, I've seen this approach in LOTS of contracts. I've learned the hard way that just because something is illegal or unenforceable doesn't mean that a company won't TRY to get away with it anyway. Often times, they do, because "the little guy" doesn't have over $100k to pay for an attorney.
Thanks for the reply, I guess I underestimated the tricks companies try. I'd like to see it get tested in court, I want to doubt they would uphold one's ability to sign off one's brain to someone else. I know schools have similar clauses but they usually specify something like "...created by candidate using school equipment or resources", which is understandable. It's interesting to consider that not specifying means you could create something on Mars and the company would own it.
Anyway, I'll shift my stance to lusis'. My eyes would pop out if I ever saw that in a contract offered to me.
As your parents may have mentioned, life isn't fair.
As the ad in the in-flight magazine says (I think I remember right), you don't get what you deserve, you get what you negotiate.
The impact on your visibility, personal brand, and ability to find future roles should be a factor when you sign up for a job. Just as you'd consider your job title, for example.
If you're signing up for something you can't talk about or show off -- worse, if you're signing a contract that says you can't do anything that you _can_ talk about on the side -- then you'd better be sure you're getting paid extra, or in some other way getting compensated.
From what I've seen, working on super-secret trading software for Wall Street _does_ pay a lot more than working on an open source project, on average.
If the price is that you have to use references and other means to show future employers what you can do, then that's the tradeoff.
If you're not getting paid much, have no spare time, aren't allowed to code in your spare time, etc. then those are some items for the "cons" column that might nudge you to look for something new, all else equal...
Nothing about the hiring process is "fair" in the sense that it looks at you in the best possible light. It does not maximize for fairness for the individual, but for value added to the company.
Further, the disadvantage you refer to is natural.
would it be "fair" to a developer who went out of their way to give insight into their talents as a software developer by publishing their code / taking part in open source have that effort be ignored so a companies hiring process is more "fair" to people who didnt take the same effort.
that aside, a companies hiring process isnt designed to be fair, its designed to efficiently recruit the best talent.
Surely you've got something you're willing to throw up on github? No one is saying it needs to be particularly useful to anyone else; just some actually code you wrote that people can look at.
Not only that, but it puts those that contribute to other repos at a disadvantage. Additionally, it puts Windows devs at a disadvantage as Git is simply not as usable as Mercurial/SVN or heaven forbid, even TFS, on Windows.
That's not necessarily true. I prefer Mercurial over Git but I prefer GitHub over Bitbucket/Google Code. That's why the fine folks over at GitHub implemented their hg-git plugin which allows Mercurial to interact with Git repositories. That means I get to keep on using my preferred tool together with my preferred site, progress! \o/
Putting aside GitHub/Bitbucket, the tools for Git (and even Mercurial) suck when it comes to Windows. This is the case with both the Visual Studio and the Explorer plug-ins. It's a real shame too, because Git and Mercurial are massive improvements over the existing SCM tools for Windows-based developers (CVS/SVN/TFS, etc.)
Could someone explain why "being on Github" is synonymous with "contributing to open source" in some circles?
The Github projects are a very small part of the open source universe. You can easily build *BSD or LinuxFromScratch with a substantial userland without ever downloading anything from Github.
Speaking frankly, even on our slowest days, the number of open source commits being pushed to GitHub dwarfs other sites [1]. That's not to say OS development isn't happening elsewhere, but there happens to be a lot of it going on in one particular place these days.
To your second point, you're right. I'd love to be able to convince older OS projects to move to GitHub. Some do[2], but it's an uphill battle.
I think one answer to your question is "visibility". When you go to a Github project page, you're greeted with standard fork/download/commit links. But you're also one or two clicks away from viewing actual source inline.
Yes, other websites show source inline, but I've found that they are not intuitive at all, and the code (to me) feels hidden.
Think of all the good that could be done for the open source world if this led every company to expect open source contributions from their new hires.
Careers 2.0 probably isn't popular enough to change the world that significantly but it does make me want to hunt down someone for a profile invite (though I guess I should save those for people who are actively looking for jobs)
P.S. Careers 2.0 is hosted by Stackoverflow which means hosted on a .Net platform...just sayin'
Think of all the good that could be done for open source if the company requiring their hires to contribute would be required to contribute themselves or to facilitate contributing under work time.
This is true and thanks for the feedback. Do you (or anyone else reading) have any ideas for things that all talented developers would want to list on their profiles that we don't have on Careers yet? Thanks again!
While filling out my profile it struck me that I'd love a friend finding service: Find me programmers within 50 miles of my stated location who share interests and experiences in some of the many tags I chose for myself. I'd like to meet them and have a beer.
The key here is that StackExchange has a high usage rate amongst programmers and it allows me to register interests in technologies that I don't have public source code for.
Facebook has a nice social graph but no angle on programmer socialization. Github's API can let you infer which open source languages I dabble in, but not at all what I do at my day job. Good luck to you though, I'd love to see the product.
But those that have fun writing code usually do, or have done so at some point. It's some kind of filter, that's true, and there isn't any filter that's always fair.
I would think the both to be almost same as long as you can tie your name to the App/Software you deployed in Google Market. In one scenario I get to see actual code and in the other a final product that has been deployed to the market. Both, having being done as a side project should be considered equal
I agree its better than having nothing to show or talk about, but I wish hiring the right person was that easy. There is a lot of junk in Github and there are lots of smart developers outside the Github community.
I frequently fork projects on Github, add features/fix bugs, send a pull request and then delete my fork after my changes have been integrated. I've started to consider keeping my forks around for this reason alone but that strikes me as a waste of Github's disk space...
> that strikes me as a waste of Github's disk space...
Oh, and forks don't take up much disk space since they share structure with the original repository. If the changes have been merged to the mainline, then the marginal cost of your fork is close to nil; probably just a few rows in the database.
I'm going to chime in here with all the various for/against comments going on and at least TRY to make some sense out of all this - or at the very least, show others how some of us "haters" see it, and explain to other "haters" how it's just the way it is - period.
Using GitHub or other OSS contributions/commits as your actual resume, or the litmus test for, "can I have the job, boss?" has been something I think we've all seen coming down the pipe for a few years now - I know I saw it way back when. Personally, I live in the midwest, not the SF bay area, so "trends" like this are a bit slower to catch on out here, but the last several job interviews I've been at, somebody has always asked me: "Do you have a GitHub account?"
This situation has people on both sides of the argument - for and against. And I'm going on record right now as saying, absolutely, 100%, without question, BOTH sides are right.
The truth is, from an employer's perspective, this just makes sense: prove that you can do the job. A resume doesn't do that - it proves that you can hand a piece of paper, sometimes even written by some one else, and BS your way through an interview.
On the other hand, employers frequently trot out teams of developers - some as many as 15 (that I've seen personally) to pepper a candidate with lots of hard questions during an interview. Inevitably, there's always that one nerd in there with serious penis envy who tries to re-assert his "dominance" by trying to "outsmart" the job candidate to make him or her look bad by throwing some super hard core question that makes said nerd look like a badass at the poor guy doing his best, and then trying to make the interviewee look like an ass when s/he can't answer it. The truth is, these guys have time - days - to prepare these interview style "litmus tests" for candidates, but when interviewing for the job, you go in blind not knowing what to expect and have to come up with everything from memory. /rant
This makes for a craptastic experience for the candidate, and a very time consuming and costly experience for the employer. Looking at a collection of code related to the job in question is a much faster way for them to get a handle on where the candidate is at, without the need for such involved processes in many cases, saving time and money for them and the candidate, and saving the candidate some serious anxiety.
However, there's another side to this coin. From the perspective of those of us who would rather NOT go home and spend all night 4+ days per week writing MORE code, this puts us in a bad spot.
The way I see it, you have two kinds of developers (basically): those who are SUPER into what they're doing - which is great (really! no sarcasm intended) - and those who enjoy what they do, but recognize that it's work. Good, old-fashioned, hard work. W-O-R-K. Blowing up some asshole in Halo Reach or having sex with your girlfriends (yes, plural) is a hell of a lot more fun than researching "most efficient sorting algorithm". So when we're not at W-O-R-K, earning a living, we need SOME way to kick back and release, or we'll absolutely explode. That's called "common sense".
This presents a problem: those who, for whatever reason, be it inability to get a date, or absolute true "nerdvana" enjoyment of writing code, end up doing ADDITIONAL development work, strictly for work's sake, now have a somewhat (emphasis on somewhat) unfair advantage over those of us who can do the same job, and are willing to work just as hard (for pay - after all, I can't pay rent with hugs and good will), but have other obligations (kids, for example, is a big one) and just plain can't put in another 20+ hours per week required to COMPETE - yes, I said the C word - with others who can.
Some arguments I've seen or heard that I'll comment on:
"But it's not THAT hard!"
Nothing easy is really truly WORTH doing. I can write some seriously easy code in under 5 minutes that'll look bad ass from a quantity point of view - until you actually examine it close up and see that it's just bullshit. The stuff that REALLY makes you shine is finding new, interesting, and USEFUL ways to solve hard problems. Nothing else is really as worthwhile. And there's a point that you get to, after doing it for 50+ hours per week, that you just say, "enough!" and have to decompress. Other people see it differently - they still enjoy it and do it in their free time. I truly wish those people well and want to encourage them to keep doing it!
"Well, if you aren't the kind who'll do the OSS commits, you aren't a culture fit anyway."
This is 100% Grade-A bullshit. Just because a person doesn't want to spend their free time - that they'll never get paid for - creating additional software, outside the scope of their workplace, essentially doing MORE work simply for work's sake, does NOT mean s/he is a bad culture fit. _It means they have self respect._ If you're going for the super hard core, hipster silicon valley, "my shit doesn't stink" start-up environment, that may be true. But in a nice place I like to call "the real world", those companies cutting the checks GET IT - at the end of the day, you gotta get paid for your work. Even though they understand this, they'll sure as shit take advantage of other people who have no problem with playing the role of "happy little nerd behind the desk that we don't let talk to anyone and just codes all the time". They're perfectly happy to use this kind of job competition to squeeze more out of some one beyond what they're paying them for, and don't give a damn when that poor person eventually has a breakdown because they've been working 80+ hours per week for several months, maybe even years.
My bottom line on this is pretty simple: like it or not, this trend isn't going anywhere because it has advantages for parties who are interested. Unfortunately, I really think that it's going to create an even more hyper-competitive environment for people looking for jobs. We'll get to a point where we'll have maybe 20-35% of applicants who are truly really HARD CORE into what they're doing and truly, with every fiber of their being, enjoy writing code on their own time, but then we'll find a larger segment of people who do it somewhat begrudgingly, seeing it for what it is - work for work's sake. This is going to breed a very strong sense of competition in the engineering and development job market that allows companies to treat developers - especially younger ones, recent college grads, etc. - as what they'll be painting themselves as: subservient nerds who work for peanuts just for the CHANCE to have a job, even being paid in stock options that are totally worthless at Startup #1119128418911818119.2.
There's no way in hell I'm going to work 40+ hours per week doing something that, sure, I enjoy, but get bitched at by some asshole in his Armani suit that "it isn't gettin' done fast enough!", then go home and write more code just for the CHANCE to do it all over again. Fuck that.
And those who will do that? Many will end up submitting crappy OSS contributions that do nothing to move the industry forward, because they're only doing it for the sake of being able to compete in a job market - NOT because they truly love what they're doing. And that's really the major thing that irks me about this trend.
But again, it's happening and there's nothing that can be done to change it. That's why personally, I'm looking at changing job functions. Systems administration, or project management maybe. I'd much rather be the asshole in the Armani suit DOING the chew out, making bonuses of over $500k/year that keep going up, with a relatively easy job (especially compared to modern development), than the poor guy he's chewing out, despite that person doing a seriously awesome job under very difficult circumstances, for very low/poor pay that keeps decreasing due to increasing job market competition, who works twice as much and twice as hard, and STILL has to put up with assholes like "Mr. Suit".
Thats your problem right there - it is a sellers market right now, so if they start making too many demands for stupid things you can get a job elsewhere.
You are a great programmer, good companies know they need to qualify themself to you.
Do you think suit guy got his job with that attitude?
If you're a company looking for developers, you have to learn to live with developers who are simply good enough. I'm talking about guys and gals who just see programming as a way to pay the bills.
Everybody wants to hire the brightest developers, but there aren't enough to go around. It's a mathematical impossibility.
There are a lot of increasingly shrill remarks out there about how everyone should be doing open source projects in their 'spare time', so no-one has any excuse not to have a track record of FOSS contributions... frankly, it's bullshit.
I work in a closed-source shop (for some very good reasons, we can't open) and our devs do sterling work of a sophistication not seen in most projects, open or otherwise, solving a very difficult and rather open-ended algorithmic problem. On a good day, we get a lot of sophisticated work done.
Strangely, at the end of one of these good days, no one wants to go home and write a big fucking pile of code - we have girlfriends/wives/families that haven't seen us for 12 hours and probably aren't going to want to use the remaining hours (and typing time) to write MORE code. Even if that was a good idea - we are paid for full-time work here which means ideally we go home and relax, not flail away on endless side projects.