Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Want to Recruit Better Engineers? Open Source Your Code

angel.co

Post reply on HN
Print view View original

71–80 of 146 posts

Re: Want to Recruit Better Engineers? Open Source Your Code

#71

Post by danpalmer »

arendtio wrote: post #53
fipple wrote: post #42

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 clos…

Seriously, the Dropbox client? I mean, I never used it but I can hardly imagine anything that makes it so special. I use Nextcloud and from what I can tell, there is nothing that sets the Dropbox client apart from the Nextcloud sync client (which is 100% open source). 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 bu…

> Seriously, the Dropbox client? I mean, I never used it but I can hardly imagine anything that makes it so special. I use Nextcloud and from what I can tell, there is nothing that sets the Dropbox client apart from the Nextcloud sync client (which is 100% open source).

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.

Re: Want to Recruit Better Engineers? Open Source Your Code

#72

Post by Jyaif »

KaiserPro wrote: post #58

"personal engineering brands" 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 eng…

For me the problem is that to create a brand around yourself you need a pretty damn big ego, and ego is just bad in a team setting. The best engineers I know have zero ego.

Re: Want to Recruit Better Engineers? Open Source Your Code

#73

Post by Silhouette »

sudhirj wrote: post #16
fapjacks wrote: post #3

I was listening to a friend'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 a…

It’s really difficult to have your engineering quality or culture NOT reflected in your open source projects. What are you going to do, keep the regular coders locked in the basement working on CRUD apps and a penthouse full of cool evangelist programmers writing OSS for no good reason? A company’s OSS is an excellent reflection of the people, decision making processes and culture that permeates it. Look at React, Go…

It’s really difficult to have your engineering quality or culture NOT reflected in your open source projects.

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.

Re: Want to Recruit Better Engineers? Open Source Your Code

#74

Post by kurtisc »

cwkoss wrote: post #17

Quasi-ethical business idea: 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 usefu…

A lot of the 'development' is discussion over emails, cue a copied-homework moment when the maintainer asks why you chose to do it this way.

Re: Want to Recruit Better Engineers? Open Source Your Code

#75

Post by Silhouette »

hashr8064 wrote: post #13

So here's some of the reason's they give for why Engineers want to work on Open Source: > 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 pla…

This is the classic paradox of employing developers, though. Of course those developers want to establish a good professional reputation, because it makes it easier for them to find new gigs later on. However, encouraging "resume driven development" practices and high staff turnover is hardly in the interests of the employers. Obviously it's good to have an engaging work environment that is interesting for your team where you can, but ultimately it's a business and you're all there to get a job done, not to pad your resume so you can hop to the next one in a few months for a 10% pay bump. In a few strange bubbles like SV, where the crazy money available is barely correlated with the value or efficiency of the businesses spending it, maybe you can overlook this for a while, but I'm not sure it's a healthy, sustainable culture in the industry.

Re: Want to Recruit Better Engineers? Open Source Your Code

#76

Post by klwilson »

cwkoss wrote: post #17

Quasi-ethical business idea: 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 usefu…

You can already get credit in open source projects without doing anything. Be on the mailing lists, present at conferences, claim ideas that weren't yours, treat actual code as a "solved problem".

Re: Want to Recruit Better Engineers? Open Source Your Code

#77

Post by pferde »

spondyl wrote: post #31

I have a question for some other HNers that is kinda related to this topic. 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…

Was it done on company-paid time, or on your own? What does your work contract say about writing software?

Re: Want to Recruit Better Engineers? Open Source Your Code

#78

Post by austincheney »

aaaaaaaaaab wrote: post #30

Or just... you know, pay more? 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!

https://news.ycombinator.com/item?id=18461563

Re: Want to Recruit Better Engineers? Open Source Your Code

#79

Post by megous »

danpalmer wrote: post #71
arendtio wrote: post #53

Earlier quoted context omitted.

Seriously, the Dropbox client? I mean, I never used it but I can hardly imagine anything that makes it so special. I use Nextcloud and from what I can tell, there is nothing that sets the Dropbox client apart from the Nextcloud sync client (which is 100% open source). 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 bu…

> Seriously, the Dropbox client? I mean, I never used it but I can hardly imagine anything that makes it so special. I use Nextcloud and from what I can tell, there is nothing that sets the Dropbox client apart from the Nextcloud sync client (which is 100% open source). 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 l…

> In order to innovate on the user’s experience of the file system, as we are with Project Infinite, we need to catch file operation events on Dropbox files before other applications try to act on those files. [therefore we need a kernel driver]

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.

Post reply on HN