Want to Recruit Better Engineers? Open Source Your Code
angel.co
angel.co
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.
In addition, some parts of the Dropbox sync client are open source too: https://www.dropbox.com/de/help/desktop-web/linux-commands#b...
Sure if your business model depends on selling the software then open sourcing it might be a bad idea. But if you are selling software to other companies they most likely are not interested in the software but in the service you provide, so they will require Service Level Agreements which should be the base of your business model.
However, with consumer software that doesn't work very well, since nobody gives a about service levels (even if it would solve many of their problems) ;-)
Writing a simple file sync utility isn't difficult, hell you could just wrap rsync and you'd be half way there. Making that open source is easy and low risk, because you haven't really invented anything.
On the other hand, if you can throw 100 developers at the problem, you'll come up with something _far_ beyond the simple case. Sure it might only be 50% faster? But that 50% makes your product "magic" when compared with other tools. This is where you get things like Project Infinite (https://blogs.dropbox.com/tech/2016/05/going-deeper-with-pro...). I can imagine there are some very complex optimisations for the multitude of configurations that Dropbox runs on, that I can understand a company wanting to keep "secret" if it's so core to their business.
I think you'd be surprised at the depth to which these companies are solving problems.
You can block the operation within fuse's userspace part while calling out to some helper gui program to ask for confirmation. Seems like an excuse rather than a reason to implement stuff in the kernel.
This is a major contributor to sync UX, and by no means trivial to implement.
Another example is their file stubs implementation (Project Infinite) that works across platforms, which is also no small engineering feat, that afaik no other sync software has been able to replicate yet (OneDrive has this on Windows, but no other platforms).
The Dropbox client makes just about every other sync client look like toy projects in terms of technical sophistication, reliability, and general UX. There's a reason why they're so successful. And I say this as someone who doesn't even use Dropbox on a day to day basis (I use Syncthing as my daily driver).
This really seems like a matter of the OP not knowing what they're missing and then flaunting that ignorance.
In fact, I added that I never used Dropbox to give context on my perspective. I am not sure that qualifies as 'flaunting that ignorance'.
Regarding the delta-sync feature: That is, in fact, a feature neither Nextcloud nor Owncloud posses at the moment. On the other hand, it would not be that beneficial to my use-cases since I rarely have large files within my synced folders and most of the time I have a GBit connection to my Nextcloud. So I guess I am missing not that much (at least with my current usage pattern).
Granted, for some use-cases, it is essential and bringing such a feature to all major platforms is not a trivial task. Yet I still wonder if protecting the implementation is necessary since the comments in the Nextcloud issue suggest that the primary problem the availability of the developer is (who might have an easier job if he could take a look at the Dropbox code, but ultimately he would have to write an implementation that integrates with his project).
And ultimately I wonder what makes people decide which service they want to use. For many people, it sure is the little friction you encounter during the setup of Dropbox. For me, it is not that much about the features of the client software but about the features of the larger system. Being able to host my own server is essential to me. Having an open source implementation is a nice add-on, which I value and made use of already. AFAIK those features are not available with Dropbox I seriously doubt my previous comment qualifies as flaunting ignorance.
They offer transparent syncing so all your app instances work with the same data and sadly trying to get the developers of the apps to include self-hosted solutions (with added configuration step: the IP/port) is not happening and isn't likely to happen.
And both Apple and Google aren't open to the idea of allowing cross-ecosystem app synchronization (think game you play for an hour on your iPad but then want to play it on your specialized gaming Android device when you are out and about later; in the case of games this problem is solved by using Google or Facebook as login providers on all your devices). And until that's true then Dropbox and other popular cloud storage providers (mainly Google Drive and OneDrive) will always have a place.
As in, failing at the one thing the app is supposed to be doing...
Google: Search engine? Closed source. Ads service? Closed source.
Facebook: yes, the network is important, but still: Ads service? Closed source. Data science stuff they use for harvesting relevant data from users? Closed source. Dropbox: agreed.
Some companies do seem to be ideologically opposed to open source (I'm looking at you Balmer-era Microsoft) but Google has always seemed to have had a certain commitment to it.
They defend against Facebook controlling the internet by offering an open source browser (Chrome/ium).
Microsoft defends against irrelevance in the Linux age by open sourcing .Net Core. So now you’re just writing code for .Net, not Linux.
FB open sources dev tools to both attack and defend the talent pool.
Google open sources Flutter to counter React, decides it can show FB how it’s done.
Google also puts out K8S because AWS ate their cloud lunch and they need to show they also get it. Now you’re just running on K8S, not AWS.
AWS just open sourced a JDK. Now we can all give Oracle the finger.
Apple sits in their spaceship, not giving a fuck. Chris Lattner tried to open source for the sake of OSS, with LLVM and Swift, but he left.
So "you are the product" seems to fit open source as well then, eh
Maybe there's some history here that I'm missing: but it looks like LLVM and Swift are open source. Did Chris have any trouble open-sourcing them? Was the reason for his departure related to that?
I expect in a few years (5-10) Apple will do an audit, discover that only a small amount of code isn't written by Apple, and replace that with inhouse code and then relicense to something propitiatory. Time will tell.
[1] https://github.com/apple/foundationdb [2] https://github.com/apple/cups
LLVM was open source from its beginning: it was Lattner's research project. Apple acqui-hired it/him, and they have a private fork.
I agree that it's pretty remarkable that Swift, which was conceived at Apple, was opened up, however.
Imo chrome and android are about being able to ensure ads are delivered.
The problem is the assumption that people who do that are "better" in some way. I've known some brilliant engineers who don'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't make them bad engineers.
The obvious irony here is those "brilliant" engineers will use open source code even though they don't care for it.
Not every project is web.
I didn't said that. I have just pointed that even close source developers are using open source when working daily on their closed source projects. So saying they don't care about something they use daily is ....wrong. Also I didn't said anything about their level of brilliance :)
>Not ever project is web.
The snark level, off the charts....
Its not. They just dont care if something is open source or not. Maybe they would happily use a free, closed source library instead.
When I said "entirely closed source projects" I meant that literally - some projects have no open source elements. They're written in closed source languages that you have to pay for, with closed source libraries and frameworks that you also have to pay for. They tend to be things like control systems in small industries, unusual embedded systems, and so on.
The software industry is big and hard to make general statements about. "All developers will use open source code" is not true.
Contributing back, or even announcing to the world that such packages are used is not even a thing.
A lot of people don't care about cars but will still own one to drive to work every day. It's just a tool.
They might not care about the company they are applying to opensourcing their code. Plus you have to try really hard nowadays to not use any open source code at all
Depends on the license of the OSS and wether you're distributing or hosting the code that relies on it.
Well, your argument doesn't prove that the assumption is wrong.
In my experience, everybody starts with closed source code and before open sourcing anything the developers asks himself what kind of code he wants to show as his work which in itself triggers a desire for quality and makes them better(tm) developers. Therefore, I would assume too, that the mean open source developer is statistically a better developer than the mean closed source developer (everybody). But that doesn't mean that every open source developer is better than every closed source developer. It just means that when you are targeting open source developers you have a higher chance of finding a good developer.
Ah, but then you must raise managers’ wages too, because they obviously have to make more than your engineers. Okay, then I guess open sourcing your code is indeed the best option!
This post feels like it's edging way too close to that. If you want to attract "talent" by putting repos on Github or Gitlab, that's great. But if you are hiding bad engineering practices and/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's like to work on a project inside your company), you are making a huge mistake that will backfire and it will come back to haunt you.
That's not to say that we don'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's side of the open-office floorplan because your actual engineering practices are abysmal, you should know the "talent" 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'll have existential hiring problems.
A company’s OSS is an excellent reflection of the people, decision making processes and culture that permeates it. Look at React, Go etc. They all heavily embed the founding company’s DNA, from the design of the tool, branding, blog posts, contributor engagement, build system, everything.
You kinda sorta described SensioLabs: the good team is working on Symfony proper. While the other people are on the web agency side of things and quality is usually not the same.
One, two or ten projects cannot possibly reflect people and decision making processes of an entire culture -- The best it can tell you is about that team inside the organization. You could only tell the culture of the company in aggregate, and companies where the F/OSS output is anywhere near the total of what they produce is pretty low.
Would it be completely unthinkable that a company runs an open source showcase team like Oracle runs their America's Cup boat, as an independent entity paid to project the brands name into the world? That would be far from the idea of business open source, but it might not be the worst way of funding the kind of free software that is not directly connected to a specific business case. Many of us don't exactly remember the name Transmeta for their CPUs, for example.
I can't entirely agree with that. Aside from the possibility of deliberate deception, as discussed by others here, there is always a danger with operating in the open that potentially interested people are only going to look at the latest code, without knowing the history and thought behind it. Many times in my career, I've seen "bad" things done for very carefully considered reasons by diligent and smart people, perhaps to work around identified compiler/OS/browser bugs, or to allow for sensible assumptions that unfortunately turn out not to be correct on some particular platform. The last thing an organisation like that needs is oh-so-smart developers missing the significance of a small comment at the head of the relevant code and judging based on the mustn't-ever-do-this bad practice that was, in fact, based on an entirely rational engineering decision.
What was the podcast out of interest?
Also it is a positive thing if what I do is fun and/or meaningful.
Junior, mid-level, senior, and then maybe principal. I would gauge them by a combination of time in the market, ability to write production grade code, the ability to make informed tradeoffs, ability to work independently and as a team player, and ability to work across teams and disciplines effectively. A very, very small part of that is "quick coding."
Absolutely not. Time on the market isn't an immediate indication of competence. It certainly isn't an indicator of potential. In my experience you are so much better making an objective hiring choice by throwing EVERYTHING related to programming and interviews away and simply providing a battery of personality tests. I went through this when I was interviewing with Bridgewater.
Performance is better determined by the briefness of product, the speed of execution, and minimal time of delivery. An educated person can make gross determinations of this by examination and testing of the code. Likewise, lesser souls can evaluate the product for code style, a super high dependency count, and favorite framework.
Ultimately it comes down looking for an ambitious endeavor versus looking for emotional comfort.
For a normal person, it will take time to develop expertise. Time for exposure to novel problems and time leveraged for (the opportunity of) growth.
After you get into an organization, you can level up quickly depending, to a degree, on the speed of execution. I also agree with you that it is uninteresting to gauge leveling based on code style, dependency count, and/or a favorite framework. However, discussions around those can lead to a better understanding of someones professional maturity.
Sell open source software 'ghostwriting' services
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.
Create a grey market for open source software contributors to sell their diffs (that they'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!
It would get OSS devs more money, which is good, but is lying which is bad.
In the UK, the moral right of attribution exist, but there's a specific exception for computer programs, so that programmers don't have a right to be identified as the author, or as far as I can tell any other moral rights.
You do not want to hire engineers with "personal brands", in the same way that hiring celebrities for anything other than showbiz, normally causes problems.
At a previous large company with massive opensource scheme, "personal brand" engineers blocked many attempts to increase security, specifically filtering git commits for keys, PII and other expensive mistakes.
the "personal brand engineer's" solution? everyone singing a pledge to stop committing PII & keys to git.
The argument was: "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't work on private repos, because that means we can't collaborate"
[1]They are not an idiot, they weren't in the trendy department.
If you want good engineers, don't let your tech department be run by penises. Let me put that into a list:
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)
o Solicit feedback from everyone, more importantly, action it.
o Pay well
o only use data for decisions (HR or otherwise)
o keep no secrets
o Balance empowerment with maintainability
o aggressively kill legacy
o correct or eject bullies
o allow differences (live and let live)
o don't all look and think the same
o Train the next generation
o don't allow silos (rotate at least twice a year, bonus points for feature teams)
Its really that simple
By far, the best developers I've ever worked with are quite humble.
I am struggling really hard to find a good reason why anyone would be against this change. Committing keys is a very easy mistake to make, especially for a junior dev. Github is littered with secret keys committed by college students trying to figure out web development for the first time.
I did the same thing when I was fresh out of college and new to both git and using web apis. Luckily it was just a Spotify key and not one for my Dropbox or email.
> They want to work in the open because it creates some visibility to them
> The best companies align business needs with the desires of individual contributors (Engineers) to create their personal brand
> Smart developers like to hang out with smart code. When you open source useful code, you attract talent.
Some of these may play some factor when choosing a company but honestly I think its very small and/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/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/c it doesn't fit their culture).
There are relatively few open source companies. Most companies which distribute open source do so for part of the company which is not directly connected to revenue generation.
At Origin, 100% of our code is open-source and everything we do is "public by default". 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'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's really easy for outsiders to get up to speed on what we'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've had over 60 contributors to our codebase and we have new people showing up every week wanting to get involved. We've also been able to attract and hire amazingly talented people we would never have discovered if we were running a traditional hiring process.
Don't just open-source your code. Open-source your collaboration process too.
(1) https://www.originprotocol.com/discord
(2) https://github.com/orgs/OriginProtocol/projects/2
(3) https://meet.google.com/pws-cgyd-tqp (Every Wed at 1pm PT)
(4) https://docs.google.com/document/d/1aRcAk_rEjRgd1BppzxZJK9RX...
However, companies should desire to open source code which supports their product. Libraries they'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.
1. Every company has shit code. Most of this is centered around your business domain (aka product) because that's what changes so often. Its alright to find a balance between "we're hiding skeletons in the closet" and "don't make a snap judgement based on a few Github repos, we have mentorship and you'll learn a lot about the context and intentions a lot of this stuff arose from."
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'll get really high quality READMEs, you'll get documentation, clean APIs... all of this benefits your internal team tremendously. Why doesn't this happen as often "by default" with strictly internal projects? Developers know the internal requirements, and they're usually not a strict as their perceived public requirements many open source projects live by. Crazy. True.
3. It forces your developers to think beyond just your product. This is HUGE. I cannot stress how important this is. "Evolved" companies develop everything 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'll find reusing it during one of these pivots to be very difficult. But if its open source, there's this invisible force telling you that it can'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.
I'm a former Artsyer. There, a good bit of core product code t is actually open source, including the entire website and iOS app. As it turns out, the real value in most businesses is the data, business relationships, the domain knowledge, and the processes. People can't use your code to steal your business, even if they want to.
It does, indeed, have some impact on code quality, although I wouldn't say there was major difference. Much of the closed source code was pretty critical in its need for correctness.
Another benefit is that as you blog or do conference talks, you can point to real life code, rather than contriving examples. So there's somewhat of a virtuous cycle of positive exposure.
I can also say that the CTO is genuinely enthusiastic about his engineers building their personal brands. Sure, they might eventually leave (like me), but on the whole, it gives people growth opportunities outside the company while working there, and definitely helps with recruiting.
The overwhelming commercial success of FOSS desktop software.
JetBrains sells developer tools, a very niche market, specially when a large majority of FOSS is allergic to paying for tooling.
In fact I would bet a large percentage of those Linux users are using Android Studio or Community variants.
It would be very interesting to know how many of those users has JetBrains actually managed to monetize on.
> developer tools, a very niche market
Overall yes, but on GNU/Linux, most users are still some kind of a developer.
I don't have numbers, but JetBrains did say that most users of their products use the paid version and that their Linux business is a healthy one. I am on Linux and subscribe to all their products and have colleagues and friends that do too, so we do exist.
I also paid for Githost.io when I was using GitLab.
I think this is hyperbole. Go look at, say, Atlassian's open source code: https://bitbucket.org/atlassian/atlassian-maven-enforcer-rul...
Or https://bitbucket.org/atlassian/confluence-react-components
Or https://bitbucket.org/atlassian/confluence-threaddump-plugin
The thing about "guarantees" is they only take a single counter example to disprove.
A couple of things I wanted to highlight that are not in the article and should have been.
- Pay attention to how Microsoft has used open-source to turn things around in terms of developer credibility.
- Becoming open-source by default can still be an advantage as 99% of companies don't do it. It can still fix your hiring pipeline, but that advantage won't last as it's becoming more mainstream.
AMA
Was the code your core business proposition? I doubt it but still asking.
Was there a bureaucratic blocker -- or golfer-type rich guys with strong bias who simply don't get software? Or was it something else?
I mean, I am pretty sure you guys knew for a long time that this moment has been coming. What kept you from reacting a bit earlier?
I've got a library built solely by myself that I'm interested in open sourcing.
I'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)
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't recall ever looking at eg; a Google or Netflix project and looking into the authors vs looking into an individuals Github project.
I dunno, just wondering if anyone has any thoughts. I understand legalities come into play too but for this is more of a hypothetical.
Finally look out if that project could be moved to other big OSS orgs at some point. I created some packages for the Atom editor, and when it became clear I couldn't maintain them, I found another ORGs that were able to pick it up.
Also, whenever I interview programmers, I always browse their Github (or BitBucket or whatever). Not having a Github isn't such a bad thing, but if you have a cool (or popular) project of your own there, it can help you get noticed.
(Of course, you need to be careful that your employer isn't going to freak out about you posting code openly. I have a habit of starting side-projects in-between jobs, then only do updates on the weekends after I've started a new job.)
Another option, perhaps: put it on your own repo, but track it from the company's repo on the company's webpage. (If they'll let you do it, that is.) That gives you some free visibility.
Of course if this is a side project on your own time then personal GitHub all the way - your employer doesn't deserve any of the credit at all. I always have a good look at job applicants' GitHub accounts and while contributing to open source isn't a requirement, it certainly helps.
- code: maintainability, instrumentation, extensibility, readability, testability, performance, handles tradeoffs in complexity, and the time to create the code.
- projects: can work independently or in a team, can work with individuals across teams and disciplines, can influence project direction, can architect solutions and choose designs and supporting tooling based on tradeoffs, can deliver on a reasonable time scale.
- people: can mentor and be menteed, can collaborate well, can lead or follow, and can inspire best practices.
I'm sure there is much more, but that is off the top of my head shortly after waking up.
No, open source.
All the great places I worked with valued:
- People's time. Any extra red tape was aggressively and actively hunted and killed on the spot.
- Self-sustainable business model. No venture capitalists, no investors of any kind. They walked before they ran.
- Not hiring more that they can pay for in a year.
- Less people doing more in exchange for hefty salaries and job security. As business needs grow, the company's leadership turns inwards and people seriously discuss how can they optimize people's time and efforts better without burning them out. I've seen 5 juniors replaced with 1 senior a number of times.
- 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.
---
Open-sourcing your code serves a number of goals:
- Shows that you are open to be vulnerable and that you are ready to do better. However, sometimes it's just a PR stunt and no pull requests or comments are ever addressed.
- 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/50 here.
- Shows that you care about your ecosystem even if you don't actually open-source your own product but a number of libraries that you managed to extract from your monolith over time.
...and a few others. But open-sourcing stuff in a corporate setting is mostly a PR move.
So really, this article is not at all valuable nor does it even give an interesting side perspective.
Know this as YSFlight[0] (free flight sim) dev drama aka "New things from Soji"[1]
> Following style conventions for names, whitespace, etc.
> Replacing private information with environment variables
> Commenting your code to contextualize snippets within your broader codebase.
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'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't do this first.