by kapilkale on 11/19/18, 8:28 PM with 136 comments
by fipple on 11/20/18, 9:24 AM
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.
by onion2k on 11/20/18, 7:17 AM
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.
by aaaaaaaaaab on 11/20/18, 8:38 AM
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!
by fapjacks on 11/20/18, 6:55 AM
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.
by mscasts on 11/20/18, 9:10 AM
Also it is a positive thing if what I do is fun and/or meaningful.
by cwkoss on 11/20/18, 7:58 AM
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.
by KaiserPro on 11/20/18, 10:03 AM
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 hashr8064 on 11/20/18, 7:46 AM
> 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).
by joshfraser on 11/20/18, 10:42 AM
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...
by 013a on 11/20/18, 7:20 AM
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.
by dblock on 11/20/18, 2:08 PM
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
by _ph_ on 11/20/18, 9:48 AM
by Kiro on 11/20/18, 8:47 AM
by spondyl on 11/20/18, 8:41 AM
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.
by blocked_again on 11/20/18, 6:52 AM
by zby on 11/20/18, 9:30 AM
by hajderr on 11/20/18, 7:40 AM
by _pmf_ on 11/20/18, 7:08 AM
No, open source.
by austincheney on 11/20/18, 10:55 AM
by wellpast on 11/20/18, 1:54 PM
by pdimitar on 11/20/18, 6:58 PM
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.
by app4soft on 11/20/18, 9:58 AM
Know this as YSFlight[0] (free flight sim) dev drama aka "New things from Soji"[1]
by effnorwood on 11/20/18, 6:18 PM
by robbywashere_ on 11/20/18, 1:49 PM
by CathyWest on 11/20/18, 9:17 AM
> 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.