Hacker News new | past | comments | ask | show | jobs | submit login
The Impact Github is Having on Your Software Career (medium.com)
382 points by kumaranvpl on Feb 22, 2017 | hide | past | web | favorite | 237 comments

I do a lot of recruiting, for both paid and volunteer coding roles. I've been hiring for about 13 years, and I've been coding professionally for about 25 years. Before that I coded as a hobby, from about age 11.

Speaking from this experience, and as someone who reviews on average 20-50 coder profiles a week, the public commit history of a coder is almost never a significant factor. I don't see any trends that indicate this is changing, either.

The vast majority just don't have much to show, having spent their years working behind walls on closed software.

Instead of relying on a public portfolio that in most cases won't exist, I rely on talking to these people directly, programmer to programmer. If we can code together, on the actual code they would be working on, that's about as good as it gets.

In other words, I rely on my experience as a coder to help make what are, ultimately, subjective judgement calls.

I can confirm from the employee side. I've worked with 40-60 people total that I at least sort of remember.

Sure, that's not many people and I'm still new to the industry, but I can tell you that of all of these people only one or two have significant public GitHub activity. All the rest have empty GitHub accounts (aside from work).

These are all well employed programmers at startups. They're doing fine. The importance of "side projects" is overrated on the internet.

Side projects are mostly important for new grads or students looking for internships, just to show - "look- I can do code that's not just my data structures homework assignment."

The biggest mishires I've experienced were generally students with a whole lot of history in their GitHub accounts. I haven't done a thorough post-mortem on what was going on there, but I wouldn't rule out plagiarism or an ability to make small tweaks but little sense for dealing with a larger, more complex project.

What we found was the way you figure out whether or not someone with a strong GitHub history is going to be a good hire looks more-or-less exactly like the way you figure out whether or not someone with zero GitHub history is going to be a good hire. All focusing on GitHub really seems to get you is the ability to cast an artificially narrow net.

You would think, I've been in the industry 25 years and my side projects are still my biggest sales tools when it comes to changing jobs or joining projects. Makes a huge difference to be able to show that I stay constantly on top of the latest changes and best practices and apis even when my current day job may be using an outdated stack.

How much extra time investment does it take you to do that?

I used to be more into having side projects, and I continue to play with things, but due to employee IP contracts it's not really feasible to release them. My employer owns my brain, and while they can give permission to release things here and there, there are restrictions and processes to go through, and it really inhibits spontaneous contributions.

And I work at a major tech BigCo(tm), with a lot of smart software engineers, the majority of which are under similar restrictions.

Frankly, any potential employer who expected to see said contributions from me and use it to judge me or my coworkers as candidates would be making a poor decision.

I've always fought such clauses, or if it's a standard contract that can't be changed, I made sure to get a written exemption stating that work done on my hardware, on my time, on my ideas (not anything the company is involved with) is mine.

I understand the company wanting to protect itself, but I have to protect myself too.

Often these intellectual property terms are mandatory conditions of employment. I always read here about people "fighting" these terms but nobody's ever willing to go into actual detail about what they did that was successful. At past employers I've tried the cute "strike the clauses out in your employment agreement and initial them" trick and that has always been followed up by a very stern "sign it unmodified or GTFO" talk from HR/legal. Responses to push-back are always along the lines of this is our policy and policies can't be changed. So how did you get this "written exemption"?

I'll chime in.

I have always asked for it politely in advance as part of the negotiation process, before there's a contract. I didn't try to strike stuff out. I specifically made it clear throughout the process that there are some things that are important to me that I wish to continue doing. It's usually never no when I ask because the outside work I've done is often the reason we're talking in the first place. When I frame it that way, they're usually able to find some exemption.

The conversation usually starts with my soon-to-be manager about me wanting to work on projects on my own time without using company resources, that don't directly compete with the company's business.

I've been fortunate enough that I've never been in a position where I've only had one offer I've had to take, though. If they said no, I was always able to go to another offer and say yes.

Some companies literally do not budge though. But I have to look out for me and my family. I do side projects mostly to learn stuff and help people. I also love writing about technology. And, for example, my current job doesn't really have a place for me to do Elm and Elixir, but I think those things are important skills for my future.

If I take a job that doesn't let me do those things, and they decide to let me go because reasons, now I'm on the market with out-of-date skills and that scares me. It also scares me to work for a company that's against me investing in my skills on my own.

I think that if I was in a situation where they wouldn't budge on that, I'd have to walk away and take my chances as a freelancer at that point. I mean, I'd rather have my risk spread out among a few clients than on a single employer who wasn't willing to negotiate.

I fought a contract clause, it was a separation agreement rather than an employment contract. I imagine you would have a lot less leverage going in than you do going out.

The first key I found is to make it easier for them to say yes than to say no. I simply refused to sign my separation agreement unless we could change the line. Like everyone else, I got the "it's standard policy" bullshit, I just nodded, said nothing, and went back to my desk.

It's an intimidation tactic, those contracts are done up by lawyers and modifying them potentially exposes them to liability, they'd have to get a lawyer to look at amended agreements and that costs $. Intimidation tactics are generally used when they don't have any real leverage to use. Just don't give in, and keep asking for the change. Works best if you're actually prepared to walk, you don't want them to call your bluff.

After it became clear to them that I wasn't going to do it, they agreed to the change, but only after a stern discussion that I was not to discuss it with anyone. If we didn't already enjoy a friendly, trusting relationship I doubt I could have gotten away with it.

If you're not willing to walk away, then of course your leverage is limited. Their BATNA was basically to fire me without cause, they had more to lose than I did.

In your case I'd appeal to their sense of decency. Assure them that you won't tell anyone about it, that's a big reason for the "standard policy" bullshit. And then say that if you'd realized how onerous the contract provisions are, you would have never even applied for the position. That lets them know you're serious. Tell them you're prepared to walk out over it but you'd really like to make a deal so you can get to work. Presumably the employer actually wants you and you have champions at the company.

Where were you working that "fire me without cause" would have been difficult for them?

Well, they were switching architectures and wanted to retain me in a contracting capacity. They'd offered to keep me on but I was ready to move on. I got a nice severance and I'm still receiving contract income from that client. Getting my final check soon.

Doing all that without a contract in place would have been tough on them to say the least. They had another Rails consultant lined up to replace me, but I was a lot cheaper.

You don't. The unwritten assumption or meme I keep hearing from the community (not necessarily here on HN) is that if you're good, you'll just keep turning down jobs with such clauses until you get an offer from somewhere without such clauses. Otherwise, too bad: you're not talented, passionate, 10x, or whatever enough. Sigh. Sucks to be tied down to a state that does enforce and seems to encourage those clauses.

I think the other way to look at it is trying to gradually engineer scenarios where you do have that flexibility to walk / take another offer.

Everyone is going to have at least one point in their life where they need to take job X because Y. But you can do things to make that the exception rather than the rule, even if you don't feel you're a wunderkind.

Continual job searching, self marketing, networking, skill refresh towards emerging areas. These all give you better odds to be on the right side of that discussion than the wrong one.

>> how did you get this "written exemption"

1. Your current job and or job situation (company not doing well, layoffs on the horizon etc) is hopefully not one which you are desperate to leave at any cost. 2. Apply to multiple companies and interview with them around the same time; this usually works out. 3. (HARD PART) Land multiple offers in hand. 4. With 3 and 1 combined, look at the offer letters and negotiate the bad clauses, after reviewing with a lawyer-friend, so that the wording is also right. If they say GTFO, you also get to say GTFO :-).

I know from experience and also that of a few of my friends, it works.

You don't sign anything without your lawyer looking at it first. Then bring up that you do volunteer work, which may include thing like maintaining the website for your home owner's association, things like that. So have your lawyer counter with language designed to protect the non-profits that you may volunteer at. Then any open source work you do, assign copyright to the FSF (them being a registered non profit), and you are covered.

Also, these employment agreements use the words "inventions, innovations, or ideas". Can any lawyer-types chime in if that implies patentable items, or does inventions legally cover copyrightable creations?

Here is how I got approval for a contributor license agreement.

I sent an email to HR asking whether my employer claims ownership of code I write outside of work. The process required several emails, a legal review of the agreement, and a meeting between our CTO and in-house counsel. The approval required a a signed statement that I wouldn't use company time or equipment for my contributions. The whole process took about 3 months.

Every contract I've had, had some clause that more or less said that any work I did in my personal time was owned by the company. Every contract has that clause removed when I requested it be removed. No company ever argued the point. (I've only been at 7 companies and ~15 contracts)

There are limitations on what employers can demand regarding assignment of employee IP in several states: California, Delaware, Illinois, Kansas, Minnesota, North Carolina, Washington, and Utah. This list was current ca. 2001, so it may be different now. https://www.ieeeusa.org/members/IPandtheengineer.pdf

If you live in one of those states and an employer demands assignment of all IP, even if created with your own resources, on your own time, using your own ideas, they are probably outside the law and you can point to these statutes as evidence. Of course funding litigation is another thing entirely, but if an employer has a very broad assignment expectation and is in one of these states, you should look for work elsewhere.

California protects these rights by default. And no company can take them away from you. (I'm not a lawyer, but this is my understanding of all current law).

That being said, it does not mean that you are free to earn money outside your employer, but they don't own your brain.

Make sure you can prove that your work never comes from work machines, etc. This includes not using company internet connections as well.

California protects those rights by default to the extent that they do not infringe on anything that your employer is working on. Not knowing that your employer was working on it does not protect you.

The bigger your employer, the less of a protection California's default is.

Right, so for example, if you work in one of the big places that has their finger in almost every pie, it's tough. What could you work on that's not conceptually related to something Microsoft or Google are doing? You couldn't even make video games.

I don't know what state you are in, but if you are in California, state law gives you pretty strong protections if your work is not on company time or using company resources.

Seriously, I had to stop reading this article after the ridiculous hyperbole of the first sentence.

Most things that most developers work on are private. More importantly even when the code isn't private, the context and reasoning behind it is often far more important than the code. Resumes tell a story, code is just data.

Whenever I've hired people, GitHub has never been a significant factor. It is, at best, a minor boost (if someone has a bad resume but a prolific GitHub, I'll give them an interview). It's definitely not enough to ever get hired.

Even as someone who has been relatively active on GitHub in the past, it was never an important part of my job searches. My resume is a lot more important.

I think you've hit the nail on the head here.

I also use someone's GitHub profile as a way to give me a reason to interview them, and some things to talk about in the interview. I also use their resume, and if we give them a small project, the results of that.

If this line of thinking ever takes off, it will be just another one of those meaningless rituals you have to go through to signal that you're part of the club. Polish your resume, dress up nicely, read 'cracking the coding interview' the night before. There might actually be a great idea for a new book in there: "How to fill up your GitHub account with random crap so future employers think you're really really passionate".

It already happens - there are a ton of repos out there that are just an unmodified clone of a few Javascript (always Javascript) projects.

Can confirm. I tested it out myself and created a bogus LinkedIn profile to match with it.

I got loads of recruiters to email me, wanting to have a chat.

My plan was to get free plane tickets and hotel to visit U.S, but I didn't find enough time to bullshit them before they actually invite me, but it seemed it's possible.

I'm below average programmer and from Europe. Probably I wouldn't have either attends the actual interview, lied something happened or go there and let them realize I'm shite. No, I wouldn't feel bad about it all if I'd have pulled it off.

We see this a lot. "Please look at my github". Ok, so all I see are a bunch of forks with at best some trivial commit. Now what?

Now it's expected of you to be impressed and to make a generous offer, of course! (Any further delay with any sorts of interviews is simply ludicrous, you see.)

I think this is mostly accurate in terms of using github as a way to determine someone's ability to do quality coding (though if someone didn't do well at "whiteboard" coding but had a long history of contributing quality code on github, I'd probably weigh the github code higher), but it seems to me that the benefit of github contributions is more on getting your foot in the door and establishing a reputation.

If you are a solid contributor to well-known projects, it can be very helpful in networking and it's useful in separating you from the pack in the early "resume review" stages.

I don't really know if the expected value of building a reputation in an open source software community is higher than the opportunity cost of other things you could do to help your career, of course. I'm just not sure if "I really don't make hiring decisions based on the code on a github account" is the right metric in this case.

> [..] it can be very helpful in networking [..]

This is a very important point mostly missed. My first job out of school was due to networking related to a free software project I was helping out on. Networking is the best thing you can do to help your career and working on free software projects can be a big help.

Though this is a bit off topic from the original post about having a github portfolio. I do think a portfolio can be helpful and is worth spending some time on, but I don't think it is necessary.

Here's a question for you as a recruiter, from me as a potential employee:

How do I find a recruiter like you?

Right now, I work with two different recruiters, at two different agencies local to me. Both have placed me in great positions; my current position is one (and I am not looking for a position currently).

But say, in the future, I want to find a recruiter who knows software development, from the low-level nuts-n-bolts (coding), to design, deployment, business, etc - what would be the best way I could find that person?

I think having a contact like that might be valuable, since not only could they recommend the fit, if they serve as an initial "gatekeeper" to an interview, but they might also offer tips and other advice helpful for positions. I'm not looking to replace my current recruiters; both are great guys and work well with me. But augmenting them might be worthwhile.

I'm easy to find.

Finding someone local to you, well, you'll have to ask around.

But how do you know if the recruiter is qualified to assess coding skills?

>> Pretend you're a team leader interviewing a junior coder.

>> The vast majority just don't have much to show, having spent their years working behind walls on closed software.

So how do you handle the minority who have much to show on Github? Do you use the same or different process for this minority? If the same process, then IMHO, it is a one size fits all which does not seem right. Sincerely wish to know your experience/thoughts in the minority context, a Minority Report if we can call that :-)

In the case of people with a portfolio on github, it's still somewhat hard to tell what they actually did in the projects, e.g. if they build an app from a template, it looks like a ton, you also can't tell if the resulting thing actually works.

For me, I'll certainly look at a Github if someone links it or mentions their OSS work on a resume. I'm looking for positive evidence that a candidate takes on substantive tasks and writes good code, which means looking to wherever a candidate has put their effort. It's never the only factor, so I have no problem saying I'll look to Github iff it has content.

Public work is just a bonus. Like, "oh, here's some stuff you've done. I can look at this."

If someone worked at Snapchat, you have some context about what industry they were in. If they worked somewhere unknown, it takes a couple more questions and you're at the same place

But if you have hundreds of initial applicants to sift through, the one having some open-source contributions would surely standout. Even considering that it won't affect your final say, reaching the interview stage is definitely advantageous. I don't agree that lack of Github commits would ever be a deal breaker in hiring, but having them does signal a positive factor provided that the projects and contributions are purposeful.

> But if you have hundreds of initial applicants to sift through, the one having some open-source contributions would surely standout.

If you have hundreds of candidates to sift through then you don't have enough time to look through their github history in enough detail to be worthwhile.

As someone who is about to re-enter the job market (moving cross country soon, employer won't consider remote options), I cannot tell you how happy I am to read something like this, and all the agreements. I have almost no online presence for github, partly because of the "walled software" you mentioned. This helps alleviate a lot of stress I had about not finding jobs because of my github profile.

Thank you! :)

There are two sides of the coin here, which should not be opposed in my opinion.

I've done a fair bit of recruiting for clients willing to build technical teams (developers / data engineers / data scientists): my experience is similar to yours in that the large majority of the technical candidates I've been interviewing have no visible trace on GitHub (either because they worked on closed source, or because they are out of school without not a lot of personal drive to work on OSS).

But at the same time, as a freelance consultant for the last 10 years, having work online available for everyone to see or use (OSS or other) has driven a lot of valuable leads to me (e.g. on my niche doing Ruby ETL http://www.kiba-etl.org/).

Last note is I agree with the premise of the article that we are shifting away from "week-end contributors". For me OSS is something I work during the day, even as a single-man shop, and something that is (if properly managed) bringing in a sizeable part of my income.

> the large majority of the technical candidates I've been interviewing have no visible trace on GitHub (either because they worked on closed source, or because they are out of school without not a lot of personal drive to work on OSS).

Or because they work extensively on OSS projects that don't use GitHub.

Actually no (not in my case, I mean! YMMV). Something I can tell with certainty is that in my recruitement channels for the last 2 years, people either do OSS on GitHub, or are not doing OSS at all.

That might be true in your recruitment channels, but in general it's a problematic assumption. Many prominent Open Source projects don't use GitHub; in particular, that applies to those large enough and/or old enough to have and maintain their own infrastructure. I've run into that problematic assumption a few times, and it seems worth calling attention to.

However, many prominent Open Source projects that don't use GitHub have mirrors on GitHub, and as long as you star them, they appear in your GitHub profile if you contributed to them using an email that is registered to your GitHub account.

To give examples:

- Git https://github.com/git/git,

- Linux https://github.com/torvalds/linux,

- LibreOffice https://github.com/LibreOffice/core,

- Firefox https://github.com/mozilla/gecko-dev

I've got a fair amount of code on GitHub and on my website, but judging from my most recent job search, hardly anybody ever looks at it. And it certainly doesn't seem like it does anything to get you through the first sourcer/recruiter hiring layer, which almost entirely consists of people who are not engineers.

On the other hand at the last job where I was on the selection/interviewing side of things (somewhat peripherally) I did look at GitHub projects.

Can confirm this as a hiring manager as well. Even if I do find Github activity, or even better strong OSS contributions, experience shows that those are generally terrible predictors of the candidate's ability to work in a team in a fast-paced continuous delivery style workflow.

Can also confirm that most Github accounts are made of a dozen forks of existing projects with a trivial commit or two slapped on top. Also doesn't tell me much about your proficiency.

As a person who has been recruiting software engineers for the past 12 years, and quite picky about it, there are two signals I'm looking for at the first stage of the funnel: LinkedIn (more specifically if we know anyone in common who can endorse you, and your recommendations), and your OSS profile. The only thing I use a CV for is to look up your contact details.

The next stage is all about 1on1 conversations and pairing sessions.

Probably that's how "there is huge programmers shortage!" myth starts. I don't use LinkedIn and will never use it as any other products that rely on dark patterns and disrespect for privacy. Problems with OSS I've written in my other comment. And I'm really not in minority -- most of very good programmers I know are like this. So sorry, but as a requiter you are only doing disfavor for yourself relying on minor pool of candidates.

You seem to be excluding a huge pool of highly-skilled software engineers. There surely must be a way to not do that.

Long may this continue, because otherwise the implications for privacy and anonymity rights are extreme.

In some concrete fields like web/SNS, I believe completely surrendering your persona online is already a requirement. Let's hope this doesn't spread.

The value isn't the commit history, the value is the network of people you build up while creating the commit history. That network doesn't evaporate when you change jobs. That network will likely help you land your next job.

I see having a great public profile more as a sufficient condition than a necessary one. Meaning I wouldn't rule out someone if they didn't have a good public profile, but it could help the person if they did have one.

I use GitHub only to see if someone has a side project and their interests. Never to judge their code quality. I use GitHub to store code when I'm experimenting or teaching someone else.

We use it as an initial screen, if it exists. If it does not, no problem. We fall back to more traditional means.

On a hiring and a being-hired perspective of my own, I agree with you.

I'm concerned that many programmers who use mostly OSS (e.g. web developers) never submit a single patch to any of the multitude of projects they benefit from. Clients save millions of dollars because dev agencies leverage tons of free/open-source software. If programmers do a proper job they should routinely come across bugs or incompatibilities in at least a few of the myriad gems, node modules, etc. What could be more natural than for the developer to fix the bug and send a pull request back to the maintainer?

When looking at candidates I almost always find some correlation between a meaningful public commit history and quality.

Most small open source projects ignore pull requests. So, it is not really worth it.

I'm not so sure about this. My experience with contributing to (smaller) OSS projects on github have been mostly positive. However a few projects won't review/merge patches possibly because they've been abandoned.

In that case I'd make my own fork and leave it there for anyone else who may have the same issue.

I think this guy feels this will be true because that's the bubble he lives in (an open source bubble). His bubble is not reflective of the entire software development community, however.

Sure, it'd be nice if everything I worked on was available open source, but let's just look at one example where that's not a good idea: video games.

Good luck getting the game industry to make their AAA games open source, especially before release, when hundreds of people are chomping at the bit to have a dirt easy time of cloning whatever game out there and tossing it on the app stores to make a few bucks off their broken, half-stolen mess of a game. It's a rampant problem right now (for example, 2048 and Flappy Bird both had open source versions, possibly unofficial... look how many clones of those games hit the app stores).

Not to mention, game development often is a creative one where features are tried and then have to be cut for time, while audiences assume that anything they see will be in the final game, and if not they were maliciously lied to. This leads to any information about the game being closely guarded except for planned waaay in advance marketing campaigns, for most games (indies is a little different, indies need whatever exposure they can get usually).

So no, not everyone is going to be working on open source software, and that's not going to change in the 2 year 'Mark my words!' timeline this guy has provided.

Nicely said.

As a long-time developer from the embedded world, I'll add the same sentiment. I've written 25 years of code that's 100% proprietary to my employers and my customers.

I've never touched Github and, at this point in my career, it looks like I never will.

Granted, I have a product portfolio that I can point to instead. The rubber has to meet the road sometime so yeah, in the open-source world that's the only visibility you have so you go with it.

> The rubber has to meet the road sometime so yeah, in the open-source world that's the only visibility you have so you go with it.

This seems like the real takeaway. An experienced programmer should have some evidence that they do good work, whether that's products or OSS commits or something else altogether (e.g. someone in security who can't talk about their work details but does papers and conferences). Good hiring means being able to adapt to where a candidate has spent their effort.

My github is where I keep that, now. In the past, I had some example work I could pull up and show, but for the most part, all of the stuff of my past employers is behind closed doors, so to speak.

...if it exists at all anymore!

In many cases, the examples of my work have evaporated. At one point, I could point to certain websites I had a hand in developing as an employee for past employers - but those sites have since changed, moved on to other software development companies (one of my past employers folded and those clients went to other agencies for web dev work). I can still list I worked on such work, but I have no code or other proof.

So my github (and interview results/conversations/etc) are where its at - and ultimately, that's where its always been (I've been doing software development work since the early 90s, when I was coding on VT100 terminals over a serial link).

Yup, perfect example.

Ironically game development is one if the areas where tech & algo is discussed widely and openly(which is what GDC used to be before it became a bit more commercialized). Most studios are happy to share their latest pathfinding/ai/rendering techniques which is almost always held close to the chest in other industries.

Even more perfect because 2048 was the open-source clone, and we're not even mentioning Threes, the game on which it was based.

Yeah, I've always been annoyed at the lack of recognition Threes tends to get.

Threes is great, and I bought it when I realized 2048 was based on it. And the makers of Threes were right! I have never gone back to 2048, but I still sometimes play Threes.

That's an interesting point - game companies are particularly defensive of their code, but shockingly willing to share the latest shader techniques and other insights most fields treat as secrets.

I think that's just because that for the most part, their competitive edge is the creative work as a whole, not some particular technique.

Their techniques doesn't save corporations that could purchase their software time and money, for example, it just helps make one aspect of the game look or feel cool.

> their competitive edge is the creative work as a whole, not some particular technique.

Never worked in the industry (and don't have a desire - though one time I did), but I'd have to say that's spot on. You can have all the fancy shader tech and other 3d gismo engine whatever at hand, but without the story/plot and creative content, anything you made using it wouldn't amount to much.

...and that content is very difficult to make! Even a simple 2D game can have a load of content and design behind it that can't be easily replicated for a new title by a single person. Though this kinda argues against why more companies don't release their engines and tech as open source - especially once the tech has "aged out" (fortunately, a few companies have - like Id Software, among a couple others).

Even with these releases, though, you don't see a slew of others coming out with games and such based on the code.

Game dev here. People don't share engines because there is no reason to. Unless I'm trying to license my engine out like Crytek or Epic there is no reason for me to open source my entire engine. You can talks all the time about the interesting parts of engines, tools, and techniques but there is no reason for a company to just be like "here is our engine bye"

25 years ago people would have said the same thing about OS kernels, and yet here we are. Some of the underlying problems I see are that the game industry is still young and hasn't really standardized everything yet. Because of that, there is still ruthless competition between the hardware and GFX card vendors. Vulkan is a step in the right direction, but it will obviously take time for it to become adopted.

A lot of it is also driven by the popularity of consoles and mobile devices which are still largely locked-down walled gardens. They intentionally make it difficult to share code between platforms too. But, soon enough game developers will get sick of writing the same code over and over again, just as OS developers did in the 90s. Once this happens you'll start to see a lot more ad-hoc code sharing which will pave the way for more engines being made free software.

That's a pretty naive view of things, it's not the lack of GPU standardization that drives engines, it's the fact that fundamental bits of gameplay drive very diverse engine requirements.

For instance UE3 makes a horrible engine for open-world games since it's built on loading levels whole-sale and doing very little streaming aside from textures. If you need a game that requires 60FPS(racing, fighting/etc) something that is GC based won't cut it.

I've worked in in-house and external engines(UE3, Unity) and you always have to re-write large portions to make them work for your gameplay. There are fundamental tradeoffs that make it hard to do otherwise. At every project there comes a point where you no longer take unlevels from mainline, fork the code and make deliberate breaking changes to ship the game vision that was set out by the team.

That's a part of it for sure. I think another piece is that everyone I knew in the industry was there because they loved games and money wasnt a primary(but was an important) concern. For instance I knew every title locally under development long before(6+ mo) it was even leaked because there's a sense of shared community in that industry.

Games typically come with a lot of creative assets such as artwork, music, etc. that are copyrightable in their own right, but out of scope for open source licenses. Those assets could be released under a permissive license too (like Creative Commons), but a potential route for an "official", albeit open source game release would be to release the code freely, but not the assets. That could lead to clones with subpar assets, or -- just maybe -- someone/studio/whatever will create superior assets, improve on the game engine (as they're free to do so) and now you have a better game.

Rinse. Repeat...

The great thing about viral licenses like the GPL is that they effectively openly track the provenance of the original idea/implementation. If someone comes up with a really neat game (in terms of its concept and, ultimately, source code) and that gets built upon openly, the original copyright holder will still be credited. Plus, if the source freely exists, I think most would be more inclined to fork than to reimplement a clone from scratch (modulo platform support, I suppose).

Remind me how Counter-Strike got started again...

Between mods and Ludum Dare there is plenty of room to make a name for oneself in the open.

As someone who did mods for years I think it can vary widely. A mod can become as consuming as a job, yet without the benefits. While a few have hit it big there are plenty more whose creators have nothing tangible for their efforts.

> for example, 2048 and Flappy Bird both had open source versions, possibly unofficial

I know you're using them just as an example in your comment and this might lure people away from your points, but the "original" 2048 (the one we all fell in love with) really is open source. In fact, it got to the front of HN with almost 3k votes, and the author left multiple comments in that thread.

So yeah, my point is, the "original" 2048 is not only open source, but HN definitely had some sort of an impact on it becoming a thing.


The original 2048 was not the 2048 we all know and love but the non-open-source iOS game "Threes" of which 2048 was a clone. Here is their story http://asherv.com/threes/threemails/

Actually I knew that, the 'possibly unofficial' was more in reference to the Flappy Bird github repos I've encountered. I've checked the code for 2048 a few times to see how HTML5 games can be made (I used to make Flash games).

> Good luck getting the game industry to make their AAA games open source, especially before release, when hundreds of people are chomping at the bit to have a dirt easy time of cloning whatever game out there and tossing it on the app stores to make a few bucks off their broken, half-stolen mess of a game. It's a rampant problem right now (for example, 2048 and Flappy Bird both had open source versions, possibly unofficial... look how many clones of those games hit the app stores).

Your examples of AAA games with open-source versions are Flappy Bird and 2048? We have different ideas of what makes a AAA game...

No, I can't think of any AAA games that have intentionally released their code open source (unless it's years and years after the game has been released, like Quake, for example). They usually only add mod support. Probably the closest thing to a AAA game where the source code was fully available was Minecraft, but that's because it was originally written in Java and thus easily reverse-engineered.

2048 and Flappy Bird were to demonstrate the cloning problem that App stores have been dealing with, in part because of how simple those games were to recreate, but also in part because it was made even simpler because the code was easily available.

For an example of something closer to the problem that AAA would face if they made their code open, look to the shitshow that Steam Greenlight faced that Valve had to put a stop to. People were downloading some Unity assets and slapping together total broken crap as fast as they could and selling them as full games. That's the type of thing you could expect if AAA was more open with its code.

It's 2017 - we're all living in the Open Source bubble: http://www.networkworld.com/article/3120774/open-source-tool...

"The future is already here, it's just not evenly distributed yet." - William Gibson

Hi, author of the article :)

I don't deny that open source is now more prevalent than it was in the past, I just don't think it's on the verge of taking over the world, where every sector will be open source, especially in the ridiculously short timeline of 12-24 months you stated in the article. There's too much value for certain industries, sectors, or companies to keep some, or even most things close to the chest, and there are plenty of companies that haven't been convinced that opening up their codebase would be worth the extra time and effort it would take to do so.

You didn't even address my example of the game industry, so I have no choice but to assume you either agree with me for that industry or just don't have any way to disprove it.

Yes, Microsoft, once known as the chief closed-source proponent, is now embracing open source more, but that's a single company with completely different management than it had ten years ago and in an environment where they're no longer the king of the development world. And in particular for developers, being more open is usually a good thing because it gives us more freedom when developing. But that's only one sector of the programming world.

I have worked for at least a dozen companies over the years, and while I've incorporated at least little pieces of open source software or libraries in most of those jobs, the resulting codebases for those companies was never opened up, nor was there ever any talk about possibly opening it up. We were generally always too busy working on the next iteration to worry about opening our software up or dealing with that. Additionally, at least once I recall us rewriting our application to remove an open source portal software (uPortal) it relied heavily upon because uPortal was just a convoluted, restrictive mess to try to do any real customization with it.

And quoting William Gibson, is cute, yet proves nothing. He's a talented writer who tells good, believable stories about future technology, but he's hardly a prophet.

This way of looking at things is so corruptive. Does everything we do have to be about reputation? About our CV and how we're hired? About competition? How many commits does it take to compensate for that state of mind, for what it does to people? Whenever you bring those things, they only leave a scorched plain in their wake and the community is forced to move somewhere else.

> One of the principles of open source is meritocracy — the best idea wins, the most commits wins, the most passing tests wins, the best implementation wins, etc.

Have we learned nothing?

"When a measure becomes a target, it ceases to be a good measure." - Goodhart's law

"The most commits wins" and "the most passing tests wins" are pretty disturbing sentiments. That's not a way to write good code, it's a way to take on low-effort tasks for commit count or write 10,000 happy-path unit tests.

"Best idea" and "best implementation" are fine, but that's because they're subjective. Goodhart's Law is a great thing to reference here - the only thing you can't game is "actually producing good outcomes".

I haven't heard that before, but that is a great quote.

Closely related ideas:

"The more any quantitative social indicator is used for social decision-making, the more subject it will be to corruption pressures and the more apt it will be to distort and corrupt the social processes it is intended to monitor." - Campbell's law (1976)

"It is naive to try to predict the effects of a change in economic policy entirely on the basis of relationships observed in historical data, especially highly aggregated historical data." - Lucas critique (1976)

Sounds like perverse incentives[1] in general.

[1] https://en.wikipedia.org/wiki/Perverse_incentive

> In Hanoi, under French colonial rule, a program paying people a bounty for each rat tail handed in was intended to exterminate rats. Instead, it led to the farming of rats.

LOL. Thank you.


A modern incarnation: High incentives for the destruction of a harmful chemical stimulates it's production.

France is hardly the only colonizer to experience the problems of perverse incentives: https://en.wikipedia.org/wiki/Cobra_effect

The opinion represented in the article is based on top of several false assumptions.

1. GitHub represents the major part of software development world.

No. It's a tip of an iceberg. I don't think I have to elaborate this one.

2. Open source software development model is an absolute winner.

No. It's just one model of development which fits some kinds of projects better than the others. Companies tend to open-source tools. Product's code is usually closed source. Obviously there are a lot of developers who spend most of their time on closed source projects. Some of them also have life.

3. Your open source projects contribution helps recruiters to evaluate you performance for any kind of software development project.

Not true. A lot of jobs are either legacy projects work, niche technologies work or both. Some niche technologies are closed source. Some legacy technologies predate open-source culture. The problems you face doing open source projects are very different from those you face doing b2b, b2c projects.

Having said that the author's opinion looks invalid to me.

Disagree totally. There are gazillions of software developers quietly plugging away at gigantic companies with over 50k headcount whose contributions will never make it into open source. Think business intelligence software, accounting software, embedded systems developers, etc.

Exactly. I currently work in financial sector and if my employer found out that I post code to GitHub, I would get fired instantly. Also, I don't like doing for-free programming during my spare time -- I have more in life than crunching code all the time. Yes, I do have some programming related side projects, but I don't feel like posting them publicly as they are not polished to my usual coding standards. If some companies see programmers as some robots that write code 24/7 (even better - for free), I don't mind them skipping my CV as we probably are on different boat anyway.

Fired, sued, and perhaps arrested if Aleynikov is any guide. I don't see any problem with employers looking at a candidate's OSS/free-time programming if it exists, but that's very different standard than requiring it.

Plus, a lot of programmers just don't have/want to spend the time packaging things to be placed online, going through legal, or make blog posts about their code.

I spend 40 hours a week developing software.

I enjoy my job, but simply want to do other things in my off time.

It is still having impact, but in a negative way.

Being rejected as a candidate because of a lacking Github profile is not unheard of.

I wouldn't sweat it. Employers have been rejecting great tech candidates for dumb reasons for decades. I'd argue that if someone won't hire you because you don't have an account on some Internet service, you probably dodged a bullet and would not have wanted to work there in the first place.

Though of course it can't /hurt/ to have a kick-ass Github profile, but I also doubt we'd be at a stage where it'd be required to get a job in the industry easily.

Being rejected as a candidate because of a lacking Github profile is not unheard of.

File that one along with requiring CVs in Word format, requiring applications via their own custom online form, proposing "we own everything you ever do" IP clauses in employment contracts, proposing multi-year non-compete agreements, and interviews full of brain teasers and/or questions about obscure technical details you probably won't ever need to know and could readily look up if you did.

They're under "handy signs that I probably shouldn't accept an offer from this business".

Is it worse than being rejected as a candidate for not having crammed on algorithm mind teasers before the interview?

Probably. I imagine it's on the same level as having the right combination of buzzwords on your resume - you're unlikely to make it to the brain teaser round without it.

i can chip in. I was rejected at least a couple time because of that.

Exactly. I work at a very conservative B2B telecom. Nothing we do is open source, and having worked at another B2B telecom in the past that largely avoided open source, I have a feeling the entire industry is like this.

I'm honestly much more comfortable in enterprisey environments than in companies that try to be hip and cool, so if a company cares about my GitHub, they're probably not a company I'd want to work for.

Not just gigantic companies... plenty of startup employees have empty profiles as well and are doing fine. Companies that open source are actually pretty rare.

True story, but recruiters don't know much and Github is one of the few sources of valuable information for them.

I always send a link to my github repos when I apply for a project, this removes most of the dumb "can you really code"-style questions.

> About me: I’m a Legendary Recruiter at Just Digital People; a Red Hat alumnus; a CoderDojo mentor; a founder of Magikcraft.io; the producer of The JDP Internship — The World’s #1 Software Development Reality Show; the host of The Best Tech Podcast in the World; and a father. All inside a commitment to empowering Queensland’s Silicon Economy.

The Software industry needs more humility and less magicians.

I believe that strong engineering skills are worth far more than a Github profile, and good recruiters will know how to spot this.

If however you are looking to be hired as the new "Rockstar developer" of the latest trending startup running buzzword architecture, then a good public brand might be useful indeed.

What is doesn't say in that is that they every contributed to an open source project.

At least in Finland (don't know about the rest of Europe) the information must be collected from the applicant and not by doing internet searches [0]. If a company wants to use any other sources, they must ask the applicants permission first.

[0] http://www.finlex.fi/en/laki/kaannokset/2004/20040759

    > Over the next 12–24 months
    > — in other words, between
    > 2018 and 2019 — how software
    > developers are hired is 
    > going to change radically.
Just in time for Linux on the desktop

I recently read a novel called "A Fine Balance" by Rohinton Mistry. One character, Ashraf Chacha, is a man who works as a tailor. He is extremely grieved by the death of his wife. He talks about how when she was alive it never bothered him to spend all of his time reading or sewing - just knowing she was there in another room was enough. But after she dies, he regrets all the time he foolishly spent away from her.

I don't want to look back on my life with that feeling. As adults, we have very little free time and spending it on software seems like a gross misallocation of resources, even if our careers would benefit. There's more to life than work.

I used to agree with that, but competition for employment has gotten so cut-throat that when you spend time not being productive, not learning, not building your network, not adding to your resume, you can be assured that your competition (people wanting your job or the job you also want) ARE doing these things. Thanks to AI and robotics, we can expect things to get more and more cut-throat as time goes on. When you're out of work and a few months from insolvency, you're not looking back and saying "Man I wish I spent more time slacking off with my friends and family".

When I look around me I don't see that much competition, rather endless mediocrity punctuated with occasional sparks of competence.

If I was out of work I would be leaning on my friends and family for moral and even practical support. Doing nothing but work is a waste of a life.

Sounds like you have a great life and great network of people around you so maybe telling someone what they love is a waste of life is probably not a good use of your life.

Maybe realize that some people struggle to find happiness and will constantly be struggling. Not everybody can have a family. Not everyone can find a job after school. Not everything is easy.

Maybe keep that in mind.

I'm sorry if I have offended you however I stand by my response.

Congrats on the easy life I guess?

> competition for employment has gotten so cut-throat that when you spend time not being productive, not learning, not building your network, not adding to your resume, you can be assured that your competition (people wanting your job or the job you also want) ARE doing these things

That is not a life I want to live in the slightest. I mean it: I'd rather kill myself than live that kind of life. I only work so I can fund my personal life. No personal life, no reason to work.

I'm just an inherently noncompetitive person, and I'm not career-minded in the least.

I've been like that my whole life. When I was in high school, people told me I had to take a ton of AP classes and do a ton of extracurriculars if I wanted to get into a good college. I refused. I took a tiny handful of honors classes -- just the ones that interested me, I coasted through all my regular classes and made more As than not with minimal effort, and I was involved in exactly one club which had very little time commitment. In the yearbook, all the other seniors had this long list of clubs below their pictures, my entry looked almost empty because I had exactly one. After high school, I went to a state university, got my CS degree, and got a job out of college at a fairly conservative B2B company.

TBH, even though I'm lesbian, solidly aromantic, and an extreme introvert, I wish I was straight and able to tolerate living with other people so I could eventually marry a man and spend the rest of my life as a housewife. I'm like the total opposite of career-minded.

But, really, I think you're overstating it. There's a certain segment of the industry that's really competitive, and the rest of the industry isn't like that. Yeah, sure, you need an impressive resume to get into the Big Four or to join some Silicon Valley startup that's pioneering emerging technologies and has dreams of changing the world. But for every company in that mold, there are dozen conservative, enterprisey corporations with headquarters in "flyover country" (I hate that term) that just want interchangeable fleshy cogs to maintain 20-year-old legacy software or a colossal J2EE stack filled with FactoryFactories and the most enterprisey enterprise piles of code you can imagine (or both, with a legacy backend and a J2EE portal). And a decent chunk of them aren't tech companies but are banks, healthcare companies, local governments, etc. You're not going to find them automating software engineering with AI; the managers probably think AI doesn't exist outside of Terminator.

I appreciate your thoughtful comment. I don't think any sane, well-adjusted person _wants_ to live that life. But I think the unstoppable forces of globalization and automation are slowly forcing that kind of life onto everyone.

I read about those laid-back enterprise shops, and think about the coal miner who just wants to live his life, mine some coal, and retire, all the while not competing with anyone. Or the factory worker who just wants to put in a solid 8 turning a wrench and go home to get on with her life, not worrying about the robot that will do the job 25% more efficiently and with 85% fewer errors. Or (very soon) the truck driver. Or (also sooner than we think) the generic white collar paper pushing office worker... Fortunately, so far software has been safe. Software does not yet write itself. But it's only a matter of time. We are all slowly being forced to compete ever more fiercely, with more people, for fewer and fewer jobs. The trend is inevitable and irreversible.

I'm not naturally a competitive person, but over the years I felt I have had to train myself to be so, and I will teach my (now infant) daughter to be _ruthless_. It's a matter of career security for me--it will be a matter of survival for her.

I'm not trying to be dismissive of your concerns, but do you think the truck driver will keep his job when automation comes because he spent every waking moment trying to rise to the top of that industry? The world's best buggy-whip makers probably did not make a graceful transistion to more modern transportation.

Maybe your github contribs are different from mine, but all the projects I can see myself working on now would just make me a better buggy-whip maker.

And yet there's a tech shortage and nobody can find anyone to hire.

I have a strong suspicion the so-called tech shortage is just an excuse employers use to justify their own shortcomings.

Programmers generally want, in no particular order: - a good work environment - good pay - interesting things to work on

If you don't provide one you'd better make sure you well compensate with the other two. In practice, employers just say "meh, tech shortage" instead of taking responsibility and admiting "yeah, we kinda suck, the people we'd truly want working for us don't even consider applying so we're stuck with the rest".

If most recruiters are in a bubble like the author of this article, no wonder they can't find any talents.

> As adults, we have very little free time and spending it on software seems like a gross misallocation of resources

Well programming is one of the most entertaining thing that exists. It can be a great hobby, just like some others will do wind surfing, build RC vehicles or go to the club. Even if you are already paid for it during the day. Contributing to common goods and exploring new stuff is very fulfilling.

I used to feel like that. But now, 10+ years into my career, with a wife and 2-year old son, plus a full time programming gig, I just don't have the time or energy to dive into new projects after work or on the weekends.

"programming is one of the most entertaining thing that exists."

Yes, I totally agree. But doing it 40 hours a week is enough for me and after 5pm I want to do other things as well.

A Fine Balance is an absolute masterpiece of a book. There's many lessons to be learned from it.

“All the work you do here will be in the open. In the future you won’t have a CV — people will just Google you.”

Interviewer: I see you have a impressive profile on Github, but can you write an algorithm for quick sort on the whiteboard?

There should be a rule that any formulation of "In the future, you won't... You'll just..." is guaranteed to be wrong.

It's right up there with predicting that no one will ever need ${product}, or writing news headlines with yes/no questions.

Actually, as a security and privacy advocate, I'm proud that you will get exactly 0 results (not counting person of the same name) entering my real name to Google search and I'm actively keeping it that way.

Would you like to be judged by the number of lines of code you submit? It's not much different than being judged by your commit graph on GitHub. If we judge ourselves, and others by this ridiculous metric, we're cheapening our profession.

We are knowledge workers. We work by thinking and acting. A graph captures none of the first. The most valuable code I've ever written for an employer was about 100 lines that took 2 weeks to write. Would the commit graph capture that?

I have gotten into arguments with my boss about hiring based on commit graphs and commit counts. I lost. We hired someone who checks in a lot of stuff, but often has to fix it with other changes. His graph and change count looks great. It's a nightmare working with him.

In my experience, commit graphs are bogus.

> For software developers coming from a primarily closed source background, it’s not really clear yet what just happened. To them, open source equals “working for free in your spare time”.

> For those of us who spent the past decade making a billion dollar open source software company however, there is nothing free or spare time about working in the open.

> [...]

> The way to get a job at Red Hat last decade was obvious. You just started collaborating with Red Hat engineers on some piece of technology that they were working on in the open, then when it was clear that you were making a valuable contribution and were a great person to work with, you would apply for a job. Or they would hit you up.

Actually, this sounds exactly like working for free. You do some spec work and if they like it maybe they'll hire you.

> Actually, this sounds exactly like working for free. You do some spec work and if they like it maybe they'll hire you.

Except the difference is that the with your doing is also applicable to you (presumably that's the reason you decided to hack on it). I got my job at SUSE in a similar fashion, but I never assumed I would get a job out of my contributions -- I was just a high school student at the time, playing with container runtimes.

All of that being said, hiring people solely based on their online profile is a shitty idea. It might be useful to get leads that way, but if you have an applicant who has no online profile you should consider it an opportunity to convert them to a free software developer (not as a candidate who doesn't want to work in the open).

Well, the thesis of the piece linked seems to be that we're entering a brave new world where this isn't just an option but the way to get a job.

Sure. But I'm arguing that "contributing to free software is working for free for some company, in the hopes you get a job" is not really fair -- especially when you consider that many free software projects are run by the community (or that you might be a user of the project).

I agree that there are other possible motivations, but they're beside the point given the article content.

This kind of free work is not unheard of. If you haven't heard of StackOverflow Moderator Elections[1], You'd be blown away by the amount of free work people are willing to do for getting internet reputation.

[1]: http://elections.stackexchange.com/#stackoverflow

I know it's not unheard of, but that hardly makes it good. http://www.nospec.com/

At least in SO's case there's not a promise of possible employment being dangled in people's faces though -- it's all upfront.

15 years ago, you went to Freshmeat or SourceForge to find open source projects. Now it's Github. In 5-10 years, a different open source repository might be more popular.

The author seems unconcerned about a particular company having so much control. Note that he compares not having a Github account to not having email or a cellphone in general, rather than to not having e.g. Gmail or an iPhone in particular, which would be a more apt analogy. It's a disheartening reminder of the trend of the internet moving away from decentralized protocols to centralized services.

That chestnut is getting a bit old now.

For those of us who do have open source code on Github, the consensus is clear : despite the hype, most employers don't really look at Github in any depth. They mostly prefer to grill candidates, rather than look at what they've actually done. I guess it must be more enjoyable.

>> They mostly prefer to grill candidates, rather than look at what they've actually done.

When I interview people I like to grill them on what they've actually done. All evidence you may find on a CV or on github is secondary to what they can actually speak to. That's my opinion of course, everyone has their way of finding good people.

> Previously privileged developers will suddenly find their network disrupted.

Good god.... I love GitHub and what it allows for but let's not paint this as the "commoners" knocking down the walls that protect the "elites" in their ivory castles. Commiting to GitHub does not, on it's own, make you a better developer or a better person. In the same way that not committing to GitHub does not, on it's own, make you worse developer or a worse person.

I've met people who don't have single commit to a public GitHub repo that are FAR better developers (and people in some cases) than ones I've know that are deeply ingrained in a public project. In some, not all, cases there are different skillsets required for OS work vs working at a "closed source" company. And while we are on that subject I'm quite sick of some of the attitudes I see on HN sometimes around "closed source" like it's some evil thing. It's not, people have to eat, have to pay rent, have to support their families and anyone that thinks you can do easily that while working for a for-profit company are living in a dream world. How many times have we seen posts here about how little money is actually given to OS? Sure I'd love to be able to only work on OS or work for a company that is open but there are very few success stories in that area. The cognitive dissidence the HN crowd expels when they fawn over the SasS companies or various other SV unicorns (all closed source) here and then derides closed source is astounding.

All of this to say the message of "Your GitHub profile will mean everything for your career" is simply bullshit. CAN it give you a leg up? Of course, but experience working for a company and in that kind of setting is much more valuable to the vast majority of companies. Take a look at Linus Torvalds, undoubtedly a genius and a person who has done immense good for the OS community, however his temper/attitude are legendary with HN periodically posting links to his smack downs on mailing lists or the like. That said do you think many companies are looking for that kind of an employee? I think not (No disrespect meant to him at all, it works for him and I doubt he is looking for a job at those kind of places anyways).

Most of the companies I've worked for or interviewed with have either not cared at all about my GitHub profile or even if they say they do care they don't give it more than a passing glance at best. Focus on being good at what you do and if that happens in public on GitHub/GitLab/etc then all the better but don't bend over backwards to make your profile look good at the expense of actually knowing your shit.

> Good god.... I love GitHub and what it allows for but let's not paint this as the "commoners" knocking down the walls that protect the "elites" in their ivory castles.

If you're able to fuck around with projects on Github, you are the privileged elite.

I'm quite sick of some of the attitudes I see on HN sometimes around "closed source" like it's some evil thing.

Proprietary software generally leaves society worse off than if that same software were free and open source. In that sense, it is some evil thing.

It's not, people have to eat, have to pay rent, have to support their families

There are plenty of people who think of stripping, porn and prostitution as some evil thing. The argument that strippers, porn actors/actresses and prostitutes need to eat, pay rent, etc. does not detract from that. However, I do not think that there should be laws against porn nor against proprietary software.

I do agree with you that it is much easier to find a job doing proprietary software development. I would be a hypocrite if I suggested that people should not take those jobs. Companies will fund open source if and only if it furthers their business objectives. You are correct in saying that open source projects are, in general, woefully underfunded and the open source company success stories are few and far between.

I would like to think that the "closed source software is evil" crowd is mutually exclusive to the "fawning over SV unicorn" crowd.

Focus on being good at what you do and if that happens in public on GitHub/GitLab/etc then all the better but don't bend over backwards to make your profile look good at the expense of actually knowing your shit.

I agree. If you happen to do good work on GitHub, it can give you a leg up. Any effort poured into making one's profile "look good" is probably better spent actually doing good work or, failing that, studying for those silly data structures & algorithms whiteboard questions.

> I'm quite sick of some of the attitudes I see on HN sometimes around "closed source" like it's some evil thing.

>> Proprietary software generally leaves society worse off than if that same software were free and open source. In that sense, it is some evil thing.

I can agree with that but it also must follow that the choice is "closed" or "open" when often the choice is "closed" or not at all. It reminds me of the piracy arguments that equate 1 downloaded movie to 1 lost movie sale when in fact if the pirate was unable to download it for free they would not have paid for it at all and just gone without

>> I would like to think that the "closed source software is evil" crowd is mutually exclusive to the "fawning over SV unicorn" crowd.

You are probably largely right here. I wouldn't go as far as to say "mutually exclusive" as it's easy for people to get caught up in the hype of the moment and chide someone for not OS'ing something or complaining that more stuff should be OS minutes after they commented about how great Uber/Lyft are (or similar). I know that I have, at times, felt the "righteous anger" against something being closed source or been ready to jump on the commenting bandwagon before stopping to think about it.

Proprietary software generally leaves society worse off than if that same software were free and open source. In that sense, it is some evil thing.

The correct counterfactual to argue is, would the software exist at all if it weren't proprietary? Usually the answer is a resounding "No."

"Proprietary software generally leaves society worse off than if that same software were free and open source. In that sense, it is some evil thing."

No, it does not.

This almost seems like more of a hype article for Github than reality. It's certainly an extreme version of some truths (good and bad), but this is not how things are going to become for developers, certainly not as soon as 2018-2019.

I saw the reality of this on a job posting the other day, the recruiter wrote that applicants with github work will be given preference. This is pretty stupid really, a lot of really good developers are working on projects that cannot be shared or discussed or open sourced. Just because you haven't had the time between 1am and 3am to contribute to an open source project doesn't mean you suck as a developer.

No, it doesn't mean you suck. But it does mean that those with full GitHub profiles usually spend every waking our programming. If they have e that much passion and programming hours under their belt, and you can see their code examples, the chances of hiring a false positive is a lot lower. It's all about mitigating risk. No one is saying you are worse, but hiring you is more of a risk than hiring someone such as I just mentioned above. It's harder to really know how good/passionate you are.

>It's harder to really know how good/passionate you are.

Sorry, but I have to really object to this idea that programming every waking hour with great passion is a positive job qualification. Sounds more like a recipe for burnout.

It is exactly that. Ask me how I know.

We interviewed a guy and without prompting (that's probably off limits anyway) he told us how he's divorced and has no real social life, so working long hours for us would be just fine by him. I wasn't impressed by him to start with, but that just put the final nail in the coffin for me. Not only did it sound a bit desperate, I'd prefer someone with a healthy attitude toward work and life. The other hiring managers felt the same way.

I'm glad to hear that attitude still exists among hiring managers. I'm working at an otherwise great company that doesn't give a rat's behind about work/life balance. I.e., if you're not still here at 6:30 or 7:00 PM you must not be a team player. Never mind if you have a wife and small child that you'd like to get home and have dinner with.

Edited for clarity.

Marital status certainly is off-limits, and I've found a good general rule to be that anything that's impermissible for me to ask an interviewee is something that also doesn't merit mention when I'm on the other side of the table, both because to raise it puts my interlocutor in an uncomfortable position, and because such things really are not relevant in any case.

But it does mean that those with full GitHub profiles usually spend every waking our programming.

i.e. at significantly greater risk of burnout. I'd prefer to hire staff with a healthy work/life balance

I agree to a certain extent that seeing examples of work reduces recruiting risk, but I disagree that looking for people spending "every waking hour" programming is something positive.

If I am interviewing people then I would try to avoid this line of thinking (i.e. how much time is spent out of work programming) as it strikes me as unfair. My reasons are that not all candidates could spend every waking hour of their time even if they wanted to for various legitimate reasons. For example if you are a parent looking after a baby/toddler, it would be totally unreasonable to expect you to be coding "every waking hour".

If you had two candidates that were 100% equal except one had no real non-work-commitments of note and spent their evenings messing around on github, and the other was a parent who wanted to code all night but had to look after their kids in the evenings, which would you pick? If you picked the non-parent based only on the non-work github commits are you descriminating someone based on the fact they have kids? I dunno - but I thinik it would need careful consideration.

As I said - I dunno, but it strikes me as this would be an unfair thing to look for. Afterall, you're recruiting fill a role, not recruiting a lifestyle.

> I agree to a certain extent that seeing examples of work reduces recruiting risk

Not really. It doesn't tell me how well they play with others, or how well they work to someone else's requirements. Finding obnoxious pricks who know how to write code but stink up the workplace with a terrible attitude isn't particularly hard.

It's dumb. I lost my GitHub profile on my resume and I have yet had one person ask me about anything I put up there. It seems that having open source contributions is a check mark for you but is a pretty pointless piece of data for making a hiring decision. Nobody is reading through all your code to figure out if it's actually good or not.

You don't need to make your source public. Just check it in as private repository and your contribution graph is going to be filled. Some recruiter can now see that you work a lot - probably also on weekends and so on.

A good looking github contribution graph looks kind of professional, also if you have starred some repositorys (which probably means you are active and love what you are doing)

> Some recruiter can now see that you work a lot - probably also on weekends and so on.

WTF how is this a good thing?

A developer who loves his job/hobby also codes in his free time (because it is also a hobby)

Of course, if being a develoepr is only a "job" - this sucks.

For example, I am coding 8h+ a day during my fulltime job. When I am back at home/weekends, I also spend a lot of my time to code private projects instead of playing games

What complete BS.

Someone can certainly enjoy their job--and software development is certainly nothing special--without also wanting to spend their nights and weekends doing the same thing. For that matter, I'd probably take such a narrow set of interests as something of a disqualification.

I realized that passion to your work has a huge impact to your application. If you are software developer (what I excect) and have a job - yeah it is a valid opinion. If you don't want to code in your free time it is up to you.

It doesn't mean that you have a narrow set of interests. It just mean I use a part of my free time to code. Others are watching tv, playing games or doing other time wasting stuff.

And others are spending time with friends, families, taking care of their sick relatives, their kids, going hiking, reading, volunteering, etc.

There's no need to say X is "wasting time" in such an objective tone. For many, spending hours on the weekend doing programming is a waste of time (and it can be, most of the time). For you, it's fun. For others, they just don't have time to do it. No need to judge or expect others to live the same life as you.

The fact that the only non-coding activities outside work you can list fall under "other time wasting stuff" speaks volumes.

I only just noticed that you can make private contributions show up on your contribution graph- still there are lots of reasons stuff might not show up on there.


No, there is a option to enable also private activity :) https://help.github.com/articles/publicizing-or-hiding-your-...

GH definitely shows private contributions. Maybe you're using a different email for those commits?

Another case of the overachievers ruining everything

> Smart people will take advantage of this — they’ll contribute patches, issues, and comments upstream to the languages and frameworks that they use on the daily in their job — TypeScript, .NET, Redux.

Yeah except for the tiny niggle that an overwhelming majority of contracts stipulate that you can't actually contribute to OSS either on or off the job due to the fact that every single thing you think of while employed (and sometimes for a period after your employment ends) belongs fully to your employer.

I still can't understand how this doesn't fall into the abusive clause group.

Employers do not care about your open source work beyond it possibly demonstrating a commitment on your part to performing unpaid (and unappreciated) labor--which they euphemistically describe as "passion." That's it. Do not expect job offers from it. You'll get ample recruiter spam sent to whatever email address you associate with your projects, and possibly feature requests or complaints from entitled corporate users, but little else. In fact, it's apparently too much to even expect marginally less painful job interviews with fewer hoops to jump through as a result of your open source portfolio.

Companies (and VCs like YC) not only do not adequately compensate those who produce the free software they use to build and grow their businesses, but they show no greater inclination to hire them, despite using their software. (Zed Shaw has written about his.) Absent a clear monetization strategy, I think the time developers spend working on open source side projects would be better spent building personal wealth, especially considering how many of them will effectively become unemployable once they turn forty.

"It’s not your code on Github that counts — it’s what other people say on Github about your code that counts."

In the near future all of our problems will be solved by minor celebrities of fashionable Github repos.

Here is some career advice: do not describe yourself as a "JavaScript Magician, Story-teller, Code DJ". That really doesnt play well to a recruiter who is looking to put together a team of people who like to work together.

But what if I really am a ruby ninja and a node hero?

The last 3 jobs of mine have been in a large part influenced by my OSS projects (one of them was ENTIRELY due to one of my projects).

But I've always made a point of writing OSS code the same way I write closed projects: Well structured, documented code, proper tests, user guides and API documentation, architectural diagrams if necessary, and a professional attitude when dealing with users. Every major repository or sourceforge or sunsite tarball is a public statement to how I write real products that people use.

Over the past 20 years I've written close to 500KLOC of finished OSS code. It's honed my skills, kept me sharp, helped others, and gotten me jobs.

A self proclaimed "Legendary recruiter" Kssshh

>One of the principles of open source is meritocracy — the best idea wins, the most commits wins, the most passing tests wins, the best implementation wins, etc.

This is so wrong that it's hilarious. Lots of garbage gets popular and there's tons of gems that go unnoticed. The meritocracy myth needs to die.

Towards this end, is there a place that matches developers with small projects needing just a small amount of help? Say, a few small bug fixes or enhancements? I'd be happy to contribute but I don't want to commit too much of my time nor do I want to navigate the maze of a larger project.

For software developers coming from a primarily closed source background, it’s not really clear yet what just happened. To them, open source equals “working for free in your spare time”.

I'm guessing that would > 80% of all software developed globally?

A decade ago when I was teaching computer programming full time at the community college, I told my students that their online portfolio would be the most important thing to differentiate them from their classmates.

I'm actually slightly less sure of this today... It's probably true for startups/"tech" companies; but many, many programmers work LOB in non-tech companies and I haven't heard/seen much that the hiring process has changed. If anything, we've come closer to the consensus that a small "work sample" is the best possible kind of interview - show up, here's a laptop and a small CR or project, implement. This has the advantage of being do-able remotely too, of course.

Pull requests back to languages and frameworks works if you're at the skill level and motivation to work at the framework level (e.g. Google, Facebook, Microsoft; the companies making the mainstream frameworks). But it's a dis-service to ignore many, many programmers working successfully at a lower level. It seems like the portfolio-as-key to being hired is still not very true for that category.

The recruiting industry being what it is, I'm sure that the future holds plentys of job opportunities for people who can invert binary trees on whiteboards. Or, on a more serious note, there will also be jobs for anyone with skills and experience in the field. The job market is good for developers.

I'd recommend OSS and GitHub not as a prerequisite to landing a job, but as a means of adding direction to your career. At your day job you don't always get to pick the technologies and sometimes you drift into the backwater of old legacy code (which the companies, understandably, need to maintain). Doing OSS can be a way of getting your feet wet doing exciting stuff of choice, building experience for your next job and maybe even build a network. Doing fun stuff. That should be the main reason IMHO.

> Eventually a vast majority will be working in the open, and it will again be a level playing field differentiated on other factors.

Haven't people been saying this for like, 10 years now?

I read a lot of resumes, and interview a lot of developers.

The times I've looked at Github it was either "meh, this doesn't tell me much" or "Holy shit, run away". And about 5X in favor of running away.

So it's been useful, in a sense, but not as a positive signal.

What would the "run away" signs be on a GitHub profile?

Abject clones of other projects with no local commits, or minimal ones. Projects that just mashed together some other projects in a package. Projects that had a bunch of README content, but no actual code, or code that was minimal. (The few times I've seen school projects, they've been terrible . . . which is fine for a school project, but why make that public on github?)

My guess is that, in general, the submitters wanted to look good to people (e.g., HR) who were not technical. They sure didn't pass a "I want to continue looking at this person" filter.

He writes about network of connections, 1st, 2nd, 3rd degree and so on being lost when you change companies, but that is incorrect.

Enough people I know and respect have moved on to other companies that my own network has actually grown. If I chose to apply elsewhere the first thing I'd do is reach out in my own network, not spam recruiters with my Github account.

Your Github reputation can be used in addition to your network, or as a substitute if you have no network, but it will not replace the impact of having others already in the industry/company personally vouch for you.

"Who you know" is still the best way to get your foot in the door, because we are all still social animals.

*Countries. When you change countries.

The main logical failure of this article is the wrong assumption that the code published some time ago does always reflect current skills or relevant to the current needs. What you have written even couple years ago is quite often no longer important: progress is fast, new design patterns, new libraries, new, more advanced coding approaches become popular, you learn, you continuously improve your skills only to be judged by what?..

Sometimes, in some cases, it makes sense to filter candidates by looking at their GH. But I would not bet on that: the better filter is the code being written today, which is unlikely to be available for most of the developers.

So you are basically saying that for example 3 years of experience is as good as 20?

Yes, they can be as good or even better, because not every experience is equal in relevance or quality of results.

If this becomes more true I'm glad that I choose electrical engineering over software whatever-you're-called-now.

I can't imagine spending three years of weekends developing x companies software for a chance at an interview.

One thing not mentioned is that the reputation of the programmer is tied to contribution quality. MOST programmers make low quality contributions because they are hired en mass to develop a project at a price point. They code for a buck. They are the outsourced projects, the rushed projects, and the tools made by people who obviously have no clue what they are doing.

Github will allow the cream to rise to the top, sure, but those "Just a job" programmer roles are going to exist for a long time. This is because many companies simply want contract fulfilling crap, not quality code.

The vast majority of programmers are not competing for magic internet points. It was a few years ago there was this massive craze to create good looking Stack Overflow and GitHub profiles. Most people are not giving away their time for free... if they are contributing to open source it usually benefits their company or hobby project somehow.

Another issue is what happens to GitHub if they are not successful as a company. There was a story a few months ago here about how the company itself is losing money. How much will your profile be worth if GitHub goes out of business?

If a recruiter checks my github they'll find a project to internet-enable some bathroom scales.

Hire or No Hire?

Hired my good sir! When can you start? Good thing you posted it on GitHub, otherwise how else can we know you can code. /s

I don't think most people doubt the utility of Github, but this writing seems to be from a person living in a bubble.

Most people don't get the time and resources to work on open source. Some times, you can't even open source something, despite wanting to. For example, when I was in academia, I wanted to open source some worthwhile projects I had completed, but was never allowed to by superiors, because they considered them as competitive advantage IP.

I think that looking at a GitHub profile is tricky. Very few people get to work on open source projects. And quite frankly, Linux's model of "trying to get noticed by the admins" doesn't scale well at all. There is a lot more to it than he's suggesting.

If you want to interview people effectively try this crazy formula:

0. Ask for a remote tech screen. Ask for a simple piece of work that you can evaluate and that resembles real work. Make sure it can be built and tested imperially (the best way is automatically). This should be simple and not 8 hours of work. Don't ask people to code on a whiteboard or do their best algorithmic design in a high stress interview session, you won't get it.

1. Be prepared. Know what you're interviewing for and list out he skills. Read a candidates resume and review the prior work they offer. Read their code first.

2. Code review their tech screen.

3. Make sure to ask questions about their approach to work, leadership and projects. Encourage them to ask you similar questions.

4. Have a broad cross section of your company interview. Mix up who does this, diversity is a plus here. Also, make sure designers and HR folks get a bit of time, not just engineers.

5. If the position is senior tech, whitebiarding is acceptable for architecture or planning or diagrams.

Am I the only one who thinks that writing code is only one aspect of a software developer's job? Sure you can write good code and submit cool patches. How about talking to product owners? How about learning the ins and outs of an industry? How about identifying how to evolve a product in the real world? How about mentoring other developers?

OK, a nice GitHub profile is a plus, but as a hiring manager it is never a make-it-or-break-it kind of thing.

I do a lot of interviews and I tell the interviewee that a github project with a clean commit history is worth the same or more then a college degree. Been burned many times by people who can do tricky CS stuff but don't actually do anything on the job. It doesn't have to be a large project, just enough to show me you know the basics of source control work flow and also how to communicate.

> just enough to show me you know the basics of source control work flow

Does this really take that much time to teach on the job?

I haven't used source control outside of work, but I had no problem figuring out CVS, SVN, SeaPine Surround SCM (What a flaming pile of crap), or Perforce.

Likewise, I've never used a bug tracker before work, but figuring out Jira/Bugzilla/(Whatever garbage HP sells) is much easier then reversing a linked list... Or explaining the *Nix everything-is-a-file model - both of which are parts of the typical CS degree.

I have to say that this post was inspiring to read. It's everything that software developers had dreamed of and idealized. Owning your own career. Building your own brand. Doing your work in the open. Your career progress being decentralized and determined by the trust you've built in your network of colleagues, and not by some pointy haired business guy.

Unfortunately, I don't think any of the above is realistically going to happen at any point in the next 10 years. The majority of paid-for-code is proprietary, meaning that your 9-5 work-product can never be "googled" by outsiders. As a consequence of this, recruiters and hiring managers will continue to treat open-source work as second-class-indicators, behind your resume, CV and references. It's going to take a major paradigm shift in engineering/business culture, before any of this changes.

That said, the author might be wrong about the timeframe, but he does paint a noble vision for the future. One that I'm sure future generations will be working in, and one that I hope I can experience one day.

"You just started collaborating with [insert your open-source choice] engineers on some piece of technology that they were working on in the open, then when it was clear that you were making a valuable contribution and were a great person to work with, you would apply for a job. Or they would hit you up"

Clear to whom and to what degree or how exactly? Then even getting over this stratagem, they might ...or not! Maybe not, most likely. I understand that this might hurt some feelings or dispel some fantasies, but this is exactly the way you (as workforce asset) are encouraged to think, and not in your best interest, really. The reality, more likely than not, is that a business has to be run and the people responsible for it have to cover the business model's needs with some X number of engineers. If the business is doing well and the men with the ropes see real benefits in hiring more, than there you go -- green light for the lucky department for getting a new pal along. The circle of developers in that area already know the contributors and just open the gate for one(s) they like. That, of course, has nothing to do with absolute quality of the contributions. It's not necessarily the best of open-source contributors that get hired, it's not even the best contributors of some specific open-source commercial project like Red Hat, it's just the best (read "convenient") in the area they need at the moment. Realizing that we're talking about an entity living under business laws of survival, you also have to assume it has to employ some of the same prosaic principles in order to survive, just like anyone else. The rest is propaganda. Be assured that your position as free contributor suits the recipients a great deal already and they won't change anything about it just because.

That being said, I agree that the exposed work works very well for engineering, just as for any other portfolio-based enrollment.

What tools and changes do 'we' want for how 'we on github' is perceived as part of our identity?

'We' is including a domain of engineers, students, employees, employers, scholars, bug complainants, star-ers, watchers, forkers, and jobCreators...

'Our identity' is including a domain of identification, participation, faithfulness, ownership, responsibility, responsivity, lineage, heritage, autonomy, unity, temporality, follows, followed-by, and profile pictures...

Them 'perceiving' may now be an employer, fellow engineer, or utility algorithm, but I would like to plan for possible futures with higher orders of transparency in all these products.

I ask HN because I know this community will be a transforming force that anneals or explodes the potent artifacts of github. My opinion may be that github is a value, but my observation is that it has given me value. Now, what may we hypothesize together?

I miss the HN I grew up with (2017ish). This post's comment thread is the most important and maybe consequential so far, that I've read, of 2017. [comment bait]

The article is both very true and not yet completely true. Some developers still believe having a large community or online social media presence is important. It might very well be, but it has no bearing on code.

Code is objective. It solves problems, passes tests, does something new, and performs better.... or it doesn't. Social media presence has no bearing on this at all. Yet, each impart a type of online trust. One is capabilities (competence) trust and the other is marketing or branding trust.

For people who don't know the difference or don't understand the value in the code marketing/branding trust is the only thing that exists. For everybody else trust in branding loses value quickly and must struggle to compete with the other more objective trust factor. It should be noted this "everybody else" category is the minority but is more influential on things get built of prioritized.

When asked for a github profile or evidence of contributions I immediately apologize in advance on the application (I actually use bitbucket and have no public repos). I explain that every side project I have ever done outside of school is aimed to help the public user but also serves as a means for financial side income. Therefore, it is confidential and professional code that I will not share.

This creates 2 things as a byproduct:

- It keeps my standards high as it's a paid for product

- It forces me to actively maintain the projects and even provide a tiny bit of customer service

I really don't care if people have a problem with this. It's their problem at that point, not mine. I have no issue demonstrating anything or talking about it, but we're not going over lines of code in my stuff. I choose not to treat my code hosting platform as a social network.

You could put it in a private repo on Github and have the contribution graph visible.

If you work for someone else you can advocate for this. If you employ coders you can use it as a talent attraction piece, or just do it because it's a good thing to do for them.

I find it difficult to imagine doing extensive web work (Rails, Django, PHP, JS) without ever touching GitHub.

Surely, in the course of your daily work using giant open source projects you'll file a bug, comment on an issue or even submit a pull request. Most large applications are built off of dozens, or hundreds, of open source libraries—all of which have bugs at various times.

I don't expect all web developers to have side-projects or libraries, but I would expect they'll interact with open source projects in some way. This way of thinking clearly doesn't apply in more closed source worlds like games, finance or giant enterprise—but it certainly holds for startup/web work in my experience.

My day job involves extensive web work. I've found plenty I could contribute, but I'm at an oldschool corp. that just isn't going to approve open source contributions on company time, using company resources and source code. On the flip side, they also don't care what I program outside work. It's just that my personal projects aren't web related and don't lend themselves to being open sourced.

It would be awesome if that was something everyone was able to do, but often company policy makes it really hard.

I've worked at multiple companies where the red tape involved in having my contribution merged into a public repo was such a pain that it just wasn't worth it.

No thought your digital visibility helps to get through a job interview.. but it's hard to generalize.. if you get the job, your past disappears pretty fast and all that matters is the current sprint.

I've building a team of about 70 sw engineers and one of my best hires was an art student who learned code a few years earlier and the other had just finished his graduation. Both are not really what one would consider as social skilled.

If you give people a chance, a challenge, a good environment and respect them.. they will surprise you.

I'm in the UK. Over the last decade I've spoken to hundreds of recruiters that are looking for developers. I've never felt that any have technical knowledge. None would know what Github is, or care. They have a list of keywords and use them to search LinkedIn for candidates. If Github was one of those keywords then they'd care about it, but not enough to learn what it is.

Github impact on software is only having to know yet another source control management tooling.

Everything else only matters to the startup scene in Silicon Valley, or startups in other parts of the world that want to look cool and pretend they are actually located there.

Or students believing the hype and trying to create a portfolio to cater to such companies.

Many of us work with software that isn't allowed to go outside the virtual walls of the intranet and the last thing we want to do after 8 - 10 h work, is to sit again in front of a computer.

I don't agree with the premise that people will be contributing back to the open source software they use.

Most consumers of Typescript for example, would be unable to contribute to the core codebase, the same goes for Rails, Redux, React, etc.

The actual percentage of consumers vs contributors I would reckon at less than 0.01%, possibly lower.

As a developer looking for a job, I would use GitHub to build a small project end-to-end to demonstrate competency, but that's just me and the slice of the programmer world I live in.

I agree that in principle a strong portfolio is a great way to communicate software development skill. What I don't understand why he feel "now" is different.

Github isn't exactly new and there is plenty of time for others to innovate in this space. Why haven't we seen this effect already? If it could happen fast it would already have happened. Why won't it be a slow taking a decade or more like the proliferation of Social networks?

What about those of us who have no interest in their githib profile, who instead use their spare time to build their own products/services. In my case, I make a significant percentage of my total earnings from side projects yet prefer to stay a full-time employee. To me, working for free on someone else's project on github is an opportunity cost I simply cannot justify.

Code commits do not reflect quality. And GitHub is not the only one side singular open repo (thinking of GitLab where I also contribute a lot).

What a wonderful bubble author must be living in. I work in game development, and most of the tools I use are close sourced - and outsourcing anything of our own code is almost always out of the question.

Please, please stop assuming that "software development" is a thing that you personally are inside of.

What is it with posts on Medium and people making these broad proclamations? Calm down folks, have some humility...

This article is a kind of half-truth. Sure, RedHat may reach out to you if you're consistently providing value, though that's probably the exception.

Look at how much OpenBSD code gets used in highly profitable commercial products, then compare it to the level of donations they get from the same companies...

So what do you do when someone else already has your name on Github? My name is not that common, and someone Googling me could reasonably assume that the code they find on Github is mine - but it isn't.

For somebody on their first or second job, GitHub might matter.

Once your time is actually overcommitted by all the things you can do for your employer, half of which aren't even code, GitHub is the wrong priority.

I know job posts where having a Stack Overflow account with a certain amount of reputation was a must-have. Surprised to see the article not mention that :)

Yawn, another one of these? Sure some companies look at your GitHub profile, but this post is just conjecture based on one person's very small bubble.

Commits are like hits (of the late 90's fame), or time of possession in football (aka soccer). That is a pointless metric.


ok but the actual impact on my career is that github distributes for free something that I sell.

Private repos with visible contribution graph.

This is such a double edged sword - GitHub as the central node in the network of trust, means GitHub has unprecedented control over developers in that network.

Someone doesn't like you or your repo, and can convince GitHub to evict you - you're off the network, and all your contributions are gone.

If a potential employee contributed to an open source project that is a plus and something to talk about. But I would NEVER expect it. 99% chance their previous employers would have kept all of their source code private and not public on github.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact