Want to Recruit Better Engineers? Open Source Your Code

On the contrary, I’ve found that companies who are actually doing hardcore software engineering, where the code is the main value driver for the business, rarely open source their best stuff, but they’re great places for engineers. Google doesn’t open source its self driving car code. Facebook’s value driver is the network, not the code, so it can open source anything. Dropbox’s client is amazing and is not only closed source but heavily obfuscated.<p>When a small company open sources everything, their main value driver is in sales or marketing or partnerships or something. Not a bad thing, but not a really engineering centric place.

Anecdotally, I look at the public repos of any company advertising a job I&#x27;m interested in before I apply, so open source certainly attracts some class of developers.<p>The problem is the assumption that people who do that are &quot;better&quot; in some way. I&#x27;ve known some brilliant engineers who don&#x27;t care at all for open source code; they wrote great code that no one besides the customer would ever see or use. That doesn&#x27;t make them bad engineers.

Or just... you know, pay more?<p>Ah, but then you must raise managers’ wages too, because they <i>obviously</i> have to make more than your engineers. Okay, then I guess open sourcing your code is indeed the best option!

I was listening to a friend&#x27;s music podcast tonight and they were talking about how industry will seize on any shred of creativity so that they can use it to sell cars, and this contributes to people getting defensive about the things they like becoming popular. There is a latent fear that just over the horizon, some marketing asshole is waiting to get their hands on something that is meaningful to you, in order to abuse that connection so they can buy themselves a boat.<p>This post feels like it&#x27;s edging way too close to that. If you want to attract &quot;talent&quot; by putting repos on Github or Gitlab, that&#x27;s great. But if you are hiding bad engineering practices and&#x2F;or a shitty work environment and putting up a facade which is carefully crafted as a recruiting tool (and not truly a reflection of what it&#x27;s like to work on a project inside your company), you are making a huge mistake that will backfire and it <i>will</i> come back to haunt you.<p>That&#x27;s not to say that we don&#x27;t know that open source is a tool companies use to get more for less (everybody knows that). But if you keep a carefully-controlled open source repository around to show potential hires when there is a bonfire in the engineering team&#x27;s side of the open-office floorplan because your actual engineering practices are abysmal, you should know the &quot;talent&quot; you want to hire is no spring chicken, and they will know almost immediately that you have been duplicitous in your hiring, and word will spread. And then you&#x27;ll have <i>existential</i> hiring problems.

I don&#x27;t know about you people, but I don&#x27;t give a rats ass if the company I work for open source their code or not. I care what benefits i receive and mostly the salary and the possibility to work remotely.<p>Also it is a positive thing if what I do is fun and&#x2F;or meaningful.

Quasi-ethical business idea:<p>Sell open source software &#x27;ghostwriting&#x27; services<p>It makes an engineer look good to have solid commits to an open source project on their github profile. The people who actually make the bulk of these commits put in tons of (at times thankless) free labor.<p>Create a grey market for open source software contributors to sell their diffs (that they&#x27;ve already written and actually entail useful contributions to their project) to some rich lazy wannabe engineers to submit to the repo, and get credit for. Bulk discounts for corporations!<p>It would get OSS devs more money, which is good, but is lying which is bad.

&quot;personal engineering brands&quot;<p>You do not want to hire engineers with &quot;personal brands&quot;, in the same way that hiring celebrities for anything other than showbiz, normally causes problems.<p>At a previous large company with massive opensource scheme, &quot;personal brand&quot; engineers blocked many attempts to increase security, specifically filtering git commits for keys, PII and other expensive mistakes.<p>the &quot;personal brand engineer&#x27;s&quot; solution? everyone singing a pledge to stop committing PII &amp; keys to git.<p>The argument was: &quot;well, committing 60,000 PII records to github was done by an idiot[1], not one of us, there is no way it could happen to _us_. We can&#x27;t work on private repos, because that means we can&#x27;t collaborate&quot;<p>[1]They are not an idiot, they weren&#x27;t in the trendy department.<p>If you want good engineers, don&#x27;t let your tech department be run by penises. Let me put that into a list:<p>o hard limit on work hours(rota for Out of Hours support, if needed) no more than a 40 hours week, ever (averaged over a month)<p>o Solicit feedback from everyone, more importantly, action it.<p>o Pay well<p>o only use data for decisions (HR or otherwise)<p>o keep no secrets<p>o Balance empowerment with maintainability<p>o aggressively kill legacy<p>o correct or eject bullies<p>o allow differences (live and let live)<p>o don&#x27;t all look and think the same<p>o Train the next generation<p>o don&#x27;t allow silos (rotate at least twice a year, bonus points for feature teams)<p>Its really that simple

So here&#x27;s some of the reason&#x27;s they give for why Engineers want to work on Open Source:<p>&gt; They want to work in the open because it creates some visibility to them<p>&gt; The best companies align business needs with the desires of individual contributors (Engineers) to create their personal brand<p>&gt; Smart developers like to hang out with smart code. When you open source useful code, you attract talent.<p>Some of these may play some factor when choosing a company but honestly I think its very small and&#x2F;or confounding with the underlying factors. More likely IMHO is that companies with an open and communicative culture, where people and processes are transparent, and where work is iterative and agile, tend to open source more code b&#x2F;c it fits perfectly in that culture. I think Engineers in turn are probably more attracted to that culture as opposed to classically hierarchical, bureaucratic, structured monolithic organizations (which also tend to open source less code b&#x2F;c it doesn&#x27;t fit their culture).

I&#x27;ve seen a lot of teams write code internally with the intent of open-sourcing everything once they&#x27;re done. If you&#x27;re doing this, you&#x27;re missing out on a huge opportunity. Just as important as open-sourcing the code, is open-sourcing the collaboration process. Why not make your code 100% open-source from the beginning and let contributors participate in the design process? Let your contributors join in your heated debates &amp; hear the rationale behind your design decisions.<p>At Origin, 100% of our code is open-source and everything we do is &quot;public by default&quot;. We have a culture of radical inclusion and transparency. Everyone is welcome to participate in our open-source engineering process and our product discussions. Our engineers collaborate every day in our Discord (1), we track our progress on a public project board (2), discuss what we&#x27;re working on each week in a public Google video Hangout (3), and publish our engineering meeting notes for the world to see. (4). As a result, it&#x27;s really easy for outsiders to get up to speed on what we&#x27;re building, what our current needs are, and get a feel for our company culture. While our core engineer team is only 9 people, we&#x27;ve had over 60 contributors to our codebase and we have new people showing up every week wanting to get involved. We&#x27;ve also been able to attract and hire amazingly talented people we would never have discovered if we were running a traditional hiring process.<p>Don&#x27;t just open-source your code. Open-source your collaboration process too.<p>(1) <a href="https:&#x2F;&#x2F;www.originprotocol.com&#x2F;discord" rel="nofollow">https:&#x2F;&#x2F;www.originprotocol.com&#x2F;discord</a><p>(2) <a href="https:&#x2F;&#x2F;github.com&#x2F;orgs&#x2F;OriginProtocol&#x2F;projects&#x2F;2" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;orgs&#x2F;OriginProtocol&#x2F;projects&#x2F;2</a><p>(3) <a href="https:&#x2F;&#x2F;meet.google.com&#x2F;pws-cgyd-tqp" rel="nofollow">https:&#x2F;&#x2F;meet.google.com&#x2F;pws-cgyd-tqp</a> (Every Wed at 1pm PT)<p>(4) <a href="https:&#x2F;&#x2F;docs.google.com&#x2F;document&#x2F;d&#x2F;1aRcAk_rEjRgd1BppzxZJK9RXfDkbuwKKH8nPQk7FfaU" rel="nofollow">https:&#x2F;&#x2F;docs.google.com&#x2F;document&#x2F;d&#x2F;1aRcAk_rEjRgd1BppzxZJK9RX...</a>

There is a line you can draw in the sand here. I usually define it in terms of the Product; I don&#x27;t believe companies should feel compelled, or even desire to, open source code which directly relates to the product they&#x27;re trying to sell. The number of companies which actually do this are few and far between (Red Hat, Gitlab, others of course).<p>However, companies should desire to open source code which supports their product. Libraries they&#x27;ve written internally to do important things. Services. Infrastructure tooling. These are all great things to open source. There are many reasons why this is a great idea, beyond just recruiting and marketing.<p>1. Every company has shit code. Most of this is centered around your business domain (aka product) because that&#x27;s what changes so often. Its alright to find a balance between &quot;we&#x27;re hiding skeletons in the closet&quot; and &quot;don&#x27;t make a snap judgement based on a few Github repos, we have mentorship and you&#x27;ll learn a lot about the context and intentions a lot of this stuff arose from.&quot;<p>2. It forces your developers to think beyond just their team. Now, suddenly, anyone can see this. Woah. I mean, its pretty likely only a couple dozen people will, but I guarantee you&#x27;ll get really high quality READMEs, you&#x27;ll get documentation, clean APIs... all of this benefits your internal team tremendously. Why doesn&#x27;t this happen as often &quot;by default&quot; with strictly internal projects? Developers <i>know</i> the internal requirements, and they&#x27;re usually not a strict as their perceived public requirements many open source projects live by. Crazy. True.<p>3. It forces your developers to think beyond just your product. This is HUGE. I cannot stress how important this is. &quot;Evolved&quot; companies develop <i>everything</i> with the little voice in the back of their head that it could just be thrown away tomorrow. Because, whether you like it or not, pivots happen. Maybe small, maybe big. If all of your code is intricately intertwined with your latest Uber for Canaries idea, you&#x27;ll find reusing it during one of these pivots to be very difficult. But if its open source, there&#x27;s this invisible force telling you that it can&#x27;t be like that. It forces you to find the right APIs to work with both your product and Generic Use Cases. This takes longer. You should find a balance. But its worth it.

Artsy CTO here. I am excited to see this article and, putting aside that it quotes me :)<p>A couple of things I wanted to highlight that are not in the article and should have been.<p>- Pay attention to how Microsoft has used open-source to turn things around in terms of developer credibility.<p>- Becoming open-source by default can still be an advantage as 99% of companies don&#x27;t do it. It can still fix your hiring pipeline, but that advantage won&#x27;t last as it&#x27;s becoming more mainstream.<p>AMA

One obvious benefit of open sourcing the code, or at least important parts of your code, is to identify developers who are really interested in that part of your product. This goes both ways. As a developer, I have a list of open source software I use and have used. Some of the software I selected because I had a specific problem to solve at a time, but a a large part of that list is software I keep reusing across projects and which I am actually fond of. So, if I were to look for a new job, of course, those software packages would make their main maintainer very attractive to me as a potential employer. And for the employer, who is better to hire than an engineer who already took interest in the software before even being paid for it?

At all companies I&#x27;ve worked the code has been a big legacy mess and showing any of it publicly would scare off even the most junior engineer.

I have a question for some other HNers that is kinda related to this topic.<p>I&#x27;ve got a library built solely by myself that I&#x27;m interested in open sourcing.<p>I&#x27;m tossing up between putting it on my own Github account, where it probably blends in with the rest, or putting it on the OSS page for the company I work for which, honestly, is a bit of a wasteland (numerous unused forks mainly)<p>I guess I just wonder what looks nicer on a resume. I would assume having something on an OSS Github org looks better but is it really? I don&#x27;t recall ever looking at eg; a Google or Netflix project and looking into the authors vs looking into an individuals Github project.<p>I dunno, just wondering if anyone has any thoughts. I understand legalities come into play too but for this is more of a hypothetical.

So Angellist don&#x27;t want better Engineers?

A side effect of open sourcing is that programmers might be a bit reserved to do stupid things in the code. This might be both advantage or impediment I guess.

What is a good engineer? Seriously, what makes a good engineer? Good at coding? Helps out his colleagues? Arrogant?

And here I sit, thinking that competent middle management that can actually evaluate people based on results delivered instead of attendance and therefore allows more flexible remote work instead of commuting 3 hours would help.<p>No, open source.

I don&#x27;t think open sourcing code will necessarily attract better developers. <i>Better</i> is highly subjective. If anything it will attract more compatible developers.

Do not do this unless your code is reasonably well constructed. And make sure you’re not fooling yourself. Otherwise you’ll scare away good engineers.

This seems mostly like a Silicon Valley filter bubble talk.<p>All the great places I worked with valued:<p>- People&#x27;s time. Any extra red tape was aggressively and actively hunted and killed on the spot.<p>- Self-sustainable business model. No venture capitalists, no investors of any kind. They walked before they ran.<p>- Not hiring more that they can pay for in a year.<p>- Less people doing more in exchange for hefty salaries and job security. As business needs grow, the company&#x27;s leadership turns inwards and people seriously discuss how can they optimize people&#x27;s time and efforts better <i>without</i> burning them out. I&#x27;ve seen 5 juniors replaced with 1 senior a number of times.<p>- Respect and appreciation. Be it a few days off after a lot of work, or 20-50% extra salary that month, or just a collective thank you from several people -- all of these go a VERY long way towards loyalty and sense of camaraderie that make people stick around for 10 years.<p>---<p>Open-sourcing your code serves a number of goals:<p>- Shows that you are open to be vulnerable and that you are ready to do better. However, sometimes it&#x27;s just a PR stunt and no pull requests or comments are ever addressed.<p>- Serves to attract young and enthusiastic programmers which is often times not such a good thing -- the company might need people who they can guilt-trip into 17-hour coding sessions to get N projects off the ground in a short time frame. Sometimes they actually need the fresh perspective though. So 50&#x2F;50 here.<p>- Shows that you care about your ecosystem even if you don&#x27;t actually open-source your own product but a number of libraries that you managed to extract from your monolith over time.<p>...and a few others. But open-sourcing stuff in a corporate setting is mostly a PR move.<p>So really, this article is not at all valuable nor does it even give an interesting side perspective.

&gt; <i>Want to Recruit Better Engineers? Open Source Your Code</i><p>Know this as YSFlight[0] (free flight sim) dev drama aka &quot;New things from Soji&quot;[1]<p>[0] <a href="http:&#x2F;&#x2F;ysflight.in.coocan.jp&#x2F;main&#x2F;e2018.html" rel="nofollow">http:&#x2F;&#x2F;ysflight.in.coocan.jp&#x2F;main&#x2F;e2018.html</a><p>[1] <a href="https:&#x2F;&#x2F;forum.ysfhq.com&#x2F;viewtopic.php?f=167&amp;t=6036" rel="nofollow">https:&#x2F;&#x2F;forum.ysfhq.com&#x2F;viewtopic.php?f=167&amp;t=6036</a>

If you’re good at something, do it for free.

Nah. Just need more hacker rank.

&gt; Refactoring your code to be as simple as possible<p>&gt; Following style conventions for names, whitespace, etc.<p>&gt; Replacing private information with environment variables<p>&gt; Commenting your code to contextualize snippets within your broader codebase.<p>While I do wish more software was released under a FOSS license, I also wish that these points were a given for any codebase regardless of license or source disclosure policy. I really don&#x27;t think you can be agile no matter how many agile-trademarked tools and processes you pile on top of your project if you don&#x27;t do this first.