Hacker News Reader

Comment by orijing | Hacker News Reader

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.

View on HN

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.

Isn't this part of the reason for references, but more importantly: probation period ?

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.

I've heard this for years, but have never been able to find out what references someone gave for me in an employment situation. Is it common?

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.

Companies may not like that idea, however.

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.

But it is. Anyone can participate. It's a choice, just like the choice to sign the employment contract.

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.

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 :)

Congrats, you've called everyone working at Google an idiot :-)

http://news.ycombinator.com/item?id=1969979

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.

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.

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.

>Of course I have my own personal projects, but for most of them, I am not about release their source.

Any particular reason?

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.

I do, but they aren't particularly large projects nor anything that involves complex algorithms or systems design...

That would be private code that's in Facebook. (I didn't work on Hive, Thrift or anything open source)

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.)

Reply on news.ycombinator.com