11 ms·

Want to Recruit Better Engineers? Open Source Your Code

272 points by kapilkale 8y ago

blocked_again 8y ago
So Angellist don't want better Engineers?
fapjacks 8y ago
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 abuse that connection so they can buy themselves a boat. 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.
- gnarbarian 8y ago
  Boats are awesome but you will always want a bigger one.
- sudhirj 8y ago
  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 etc. They all heavily embed the founding company’s DNA, from the design of the tool, branding, blog posts, contributor engagement, build system, everything.
  - fapjacks 8y ago
    I can think of many open source projects that are very tightly controlled by a small number of people. You're describing a situation that is now the default: You put good programmers in a room with a good engineering manager and good engineering practices and whatever else you think makes the magic happen (time, money, tools, etc), and out the other side comes a well-engineered open source project. Nothing I said disputes that chain of events. But if you step back from the individual trees to take in the whole forest, this article is written in a way that suggests the reverse: How to make an open source project look like you have all this engineering sugar hidden on the inside of your company.
  - edem 8y ago
    I know a company where they have this exact same setup. Ivory tower "elite" team + countless wtf teams writing crappy code.
    - jakecopp 8y ago
      I'd love to know who they are!
  - arkh 8y ago
    > 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? 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.
    - nellyspageli 8y ago
      Square is also like this on the Android side of things. The Square Cash team is the penthouse of cool evangelist programmers and the rest of the company is locked in the basement.
  - hardwaresofton 8y ago
    Why wouldn't they do this? It's good marketing, you can tally it up as a recruiting expense, same way/reason companies sponsor conferences and send people to speak. These days I see the term "developer evangelist" bandied around a lot -- it seems like they basically get paid to hang out in the dev community, make cool things with the product (tm), and then talk about it at conferences. These days I also see more and more ~1 hour informercials for product X at conference Y. 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.
- andystanton 8y ago
  > 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 abuse that connection so they can buy themselves a boat. What was the podcast out of interest?
  - fapjacks 8y ago
    It's called I Hate Music. [0] I really enjoy it, and I think some folks around here would, too, but I'm really a poor barometer of what others might enjoy. My assessment is also maybe a bit clouded by my affection for the guy. [0] https://hatepod.podbean.com https://hatepod.podbean.com
_pmf_ 8y ago
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. No, open source.
- ReptileMan 8y ago
  Increased pay also helps. Flexible remote work is just not enough - you are still tied to incredibly expensive housing. You need full remote - so you could live uncommutable distance away.
onion2k 8y ago
Anecdotally, I look at the public repos of any company advertising a job I'm interested in before I apply, so open source certainly attracts some class of developers. 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.
- deleted 8y ago
  [deleted]
- mariusmg 8y ago
  >I've known some brilliant engineers who don't care at all for open source code The obvious irony here is those "brilliant" engineers will use open source code even though they don't care for it.
  - onion2k 8y ago
    If you go through your dev career thinking only people who write and use open source code are brilliant you'll miss out on the opportunity to learn from some of the industry's best developers. There are loads of people working on entirely closed source projects who are very, very good engineers. Not every project is web.
    - mariusmg 8y ago
      >If you go through your dev career thinking only people who write and use open source code are brilliant 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....
      - thecatspaw 8y ago
        > So saying they don't care about something they use daily is ....wrong. Its not. They just dont care if something is open source or not. Maybe they would happily use a free, closed source library instead.
013a 8y ago
There is a line you can draw in the sand here. I usually define it in terms of the Product; I don't believe companies should feel compelled, or even desire to, open source code which directly relates to the product they're trying to sell. The number of companies which actually do this are few and far between (Red Hat, Gitlab, others of course). 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.
- deleted 8y ago
  [deleted]
- acjohnson55 8y ago
  I challenge the notion that product is so precious that there's a benefit to it remaining closed source. If there is a line, I'd draw it at business process, not product. 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.
hajderr 8y ago
What is a good engineer? Seriously, what makes a good engineer? Good at coding? Helps out his colleagues? Arrogant?
- rataata_jr 8y ago
  Good at problem solving?
- sethammons 8y ago
  Off the top of my head, a good software engineer is not just a coder. They develop solutions to problems that provide value. They do so under constraints of time and resources. Beyond that, you then can get a feeling of the level of the engineer depending on the following: - 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.
  - hajderr 8y ago
    Yes and I'd like to put an emphasis on the last point, soft skills are really important.
hashr8064 8y ago
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 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).
- watwut 8y ago
  Is there really a reason/data to think that open source companies are better places (better culture) to work at compared to another company of the same size? Or is it just assumption?
  - eesmith 8y ago
    As a note, "open source companies" != "tend to open source more code". 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.
- zmmmmm 8y ago
  I don't really care about any of those things. The reason I want to create open source as part of my job is it means I can take it with me when I leave. What's the point in building up deep expertise in something that you just throw away and never see again if you shift jobs? When I'm working on open source I see myself accumulating a lifetime resource / skill compared to something that is relatively ephemeral.
- Silhouette 8y ago
cwkoss 8y ago
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 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.
- navaati 8y ago
  I don't know about the rest of the world but in France you cannot sell (or give, or transfer in any way) attribution rights, only copyright.
  - jlokier 8y ago
    I thought this didn't apply to computer programs, but I looked it up and you're right... In France, authors' moral rights are quite strong. 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.
- kjullien 8y ago
  This is already a reality and has been for long before "open-source" was even a thing. Can't remember exact details but recently (a couple years ago), a very high placed tech exec at some big corp was discovered to have been employing people to write his code for over 10 years.
- oever 8y ago
  A slightly more ethical alternative is to add sponsor messages to your commits.
  - deleted 8y ago
    [deleted]
deleted 8y ago
[deleted]
deleted 8y ago
[deleted]
aaaaaaaaaab 8y ago
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!
- austincheney 8y ago
  https://news.ycombinator.com/item?id=18461563 https://news.ycombinator.com/item?id=18461563
spondyl 8y ago
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 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.
- andy_ppp 8y ago
  Maybe do the other thing - if it's a really useful project with the potential of a community around it, name it well and make an organisation just for your work.
- leipert 8y ago
  Put it under your account, in case you stop working for the company. If that library gains traction, you can move it to its own ORG, which makes it easier to manage other contributors. 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.
- spin 8y ago
  I would definitely put it under my own name, if I were you. Like another commentor mentioned: if you leave the company, you still control your own repo. 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.
Kiro 8y ago
At all companies I've worked the code has been a big legacy mess and showing any of it publicly would scare off even the most junior engineer.
- C1sc0cat 8y ago
  Exactly especially for those just out of university who probably have not worked on any system of scale.
mscasts 8y ago
I don't know about you people, but I don'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. Also it is a positive thing if what I do is fun and/or meaningful.
- austincheney 8y ago
  Open sourcing the code is important to me because its frustrating being a senior hired onto a team of all newbs. By senior I mean a person who can write code quickly. By newbs I mean people with high insecurity that just want to dick around with code style and framework tooling.
  - sethammons 8y ago
    I would not define "senior" as "one who codes quickly." I also would not define a software developer's level as "newb." So there is that. 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."
    - austincheney 8y ago
      > I would gauge them by a combination of time in the market, 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.
CathyWest 8y ago
> Refactoring your code to be as simple as possible > 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.
fipple 8y ago
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. 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.
- arendtio 8y ago
  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#build 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) ;-)
  - GlitchMr 8y ago
    Dropbox Nautilus Extension is open source because it has to be - GNOME Files is licensed under GNU LGPL. The amount of code in that extension is minimal, the proprietary Dropbox client pretty much does all processing, the extension is only responsible for displaying icons in a file manager.
  - fipple 8y ago
    How about you use it before assertively making claims about it. Just a good practice for life.
zby 8y ago
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.
_ph_ 8y ago
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?
app4soft 8y ago
> Want to Recruit Better Engineers? Open Source Your Code Know this as YSFlight[0] (free flight sim) dev drama aka "New things from Soji"[1] [0] http://ysflight.in.coocan.jp/main/e2018.html http://ysflight.in.coocan.jp/main/e2018.html [1] https://forum.ysfhq.com/viewtopic.php?f=167&t=6036 https://forum.ysfhq.com/viewtopic.php?f=167&t=6036
KaiserPro 8y ago
"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 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
- Jyaif 8y ago
  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.
  - matwood 8y ago
    This is a great point. The best engineers are the ones working with their teams to get shit done. If someone on the team is more worried about their OSS contribution than getting work done, it can be a red flag that they are more concerned about themselves than the team.
  - gered 8y ago
    This is a really important point. I work with someone who has quite a bit of an ego. Definitely cares far too much about his personal brand, which has been built up over the years through open source projects. Any time you work on a project with this person you basically need to use all of his open source libraries if any of them are at all relevant for the project, regardless of if they are the best option for the task or not ... sometimes they are, sometimes they aren't. By far, the best developers I've ever worked with are quite humble.
joshfraser 8y ago
I've seen a lot of teams write code internally with the intent of open-sourcing everything once they're done. If you're doing this, you'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 & hear the rationale behind your design decisions. 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 https://www.originprotocol.com/discord (2) https://github.com/orgs/OriginProtocol/projects/2 https://github.com/orgs/OriginProtocol/projects/2 (3) https://meet.google.com/pws-cgyd-tqp https://meet.google.com/pws-cgyd-tqp (Every Wed at 1pm PT) (4) https://docs.google.com/document/d/1aRcAk_rEjRgd1BppzxZJK9RXfDkbuwKKH8nPQk7FfaU https://docs.google.com/document/d/1aRcAk_rEjRgd1BppzxZJK9RX...
austincheney 8y ago
I don't think open sourcing code will necessarily attract better developers. Better is highly subjective. If anything it will attract more compatible developers.
robbywashere_ 8y ago
Nah. Just need more hacker rank.
wellpast 8y ago
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.
dblock 8y ago
Artsy CTO here. I am excited to see this article and, putting aside that it quotes me :) 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
- pdimitar 8y ago
  Why didn't you open source before ElasticSearch invented something better than yours? 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?
effnorwood 8y ago
If you’re good at something, do it for free.
pdimitar 8y ago
This seems mostly like a Silicon Valley filter bubble talk. 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.

272 points by kapilkale 8y ago

So Angellist don't want better Engineers?

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 abuse that connection so they can buy themselves a boat. 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.

gnarbarian 8y ago
Boats are awesome but you will always want a bigger one.
sudhirj 8y ago
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 etc. They all heavily embed the founding company’s DNA, from the design of the tool, branding, blog posts, contributor engagement, build system, everything.
- fapjacks 8y ago
  I can think of many open source projects that are very tightly controlled by a small number of people. You're describing a situation that is now the default: You put good programmers in a room with a good engineering manager and good engineering practices and whatever else you think makes the magic happen (time, money, tools, etc), and out the other side comes a well-engineered open source project. Nothing I said disputes that chain of events. But if you step back from the individual trees to take in the whole forest, this article is written in a way that suggests the reverse: How to make an open source project look like you have all this engineering sugar hidden on the inside of your company.
- edem 8y ago
  I know a company where they have this exact same setup. Ivory tower "elite" team + countless wtf teams writing crappy code.
  - jakecopp 8y ago
    I'd love to know who they are!
- arkh 8y ago
  > 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? 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.
  - nellyspageli 8y ago
    Square is also like this on the Android side of things. The Square Cash team is the penthouse of cool evangelist programmers and the rest of the company is locked in the basement.
- hardwaresofton 8y ago
  Why wouldn't they do this? It's good marketing, you can tally it up as a recruiting expense, same way/reason companies sponsor conferences and send people to speak. These days I see the term "developer evangelist" bandied around a lot -- it seems like they basically get paid to hang out in the dev community, make cool things with the product (tm), and then talk about it at conferences. These days I also see more and more ~1 hour informercials for product X at conference Y. 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.
andystanton 8y ago
> 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 abuse that connection so they can buy themselves a boat. What was the podcast out of interest?
- fapjacks 8y ago
  It's called I Hate Music. [0] I really enjoy it, and I think some folks around here would, too, but I'm really a poor barometer of what others might enjoy. My assessment is also maybe a bit clouded by my affection for the guy. [0] https://hatepod.podbean.com https://hatepod.podbean.com

_pmf_ 8y ago

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. No, open source.

ReptileMan 8y ago
Increased pay also helps. Flexible remote work is just not enough - you are still tied to incredibly expensive housing. You need full remote - so you could live uncommutable distance away.

onion2k 8y ago

Anecdotally, I look at the public repos of any company advertising a job I'm interested in before I apply, so open source certainly attracts some class of developers. 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.

deleted 8y ago
[deleted]
mariusmg 8y ago
>I've known some brilliant engineers who don't care at all for open source code The obvious irony here is those "brilliant" engineers will use open source code even though they don't care for it.
- onion2k 8y ago
  If you go through your dev career thinking only people who write and use open source code are brilliant you'll miss out on the opportunity to learn from some of the industry's best developers. There are loads of people working on entirely closed source projects who are very, very good engineers. Not every project is web.
  - mariusmg 8y ago
    >If you go through your dev career thinking only people who write and use open source code are brilliant 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....
    - thecatspaw 8y ago
      > So saying they don't care about something they use daily is ....wrong. Its not. They just dont care if something is open source or not. Maybe they would happily use a free, closed source library instead.

013a 8y ago

There is a line you can draw in the sand here. I usually define it in terms of the Product; I don't believe companies should feel compelled, or even desire to, open source code which directly relates to the product they're trying to sell. The number of companies which actually do this are few and far between (Red Hat, Gitlab, others of course). 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.

deleted 8y ago
[deleted]
acjohnson55 8y ago
I challenge the notion that product is so precious that there's a benefit to it remaining closed source. If there is a line, I'd draw it at business process, not product. 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.

hajderr 8y ago

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

rataata_jr 8y ago
Good at problem solving?
sethammons 8y ago
Off the top of my head, a good software engineer is not just a coder. They develop solutions to problems that provide value. They do so under constraints of time and resources. Beyond that, you then can get a feeling of the level of the engineer depending on the following: - 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.
- hajderr 8y ago
  Yes and I'd like to put an emphasis on the last point, soft skills are really important.

hashr8064 8y ago

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 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).

watwut 8y ago
Is there really a reason/data to think that open source companies are better places (better culture) to work at compared to another company of the same size? Or is it just assumption?
- eesmith 8y ago
  As a note, "open source companies" != "tend to open source more code". 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.
zmmmmm 8y ago
I don't really care about any of those things. The reason I want to create open source as part of my job is it means I can take it with me when I leave. What's the point in building up deep expertise in something that you just throw away and never see again if you shift jobs? When I'm working on open source I see myself accumulating a lifetime resource / skill compared to something that is relatively ephemeral.
Silhouette 8y ago

cwkoss 8y ago

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 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.

navaati 8y ago
I don't know about the rest of the world but in France you cannot sell (or give, or transfer in any way) attribution rights, only copyright.
- jlokier 8y ago
  I thought this didn't apply to computer programs, but I looked it up and you're right... In France, authors' moral rights are quite strong. 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.
kjullien 8y ago
This is already a reality and has been for long before "open-source" was even a thing. Can't remember exact details but recently (a couple years ago), a very high placed tech exec at some big corp was discovered to have been employing people to write his code for over 10 years.
oever 8y ago
A slightly more ethical alternative is to add sponsor messages to your commits.
- deleted 8y ago
  [deleted]

deleted 8y ago

[deleted]

deleted 8y ago

[deleted]

aaaaaaaaaab 8y ago

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!

austincheney 8y ago
https://news.ycombinator.com/item?id=18461563 https://news.ycombinator.com/item?id=18461563

spondyl 8y ago

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 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.

andy_ppp 8y ago
Maybe do the other thing - if it's a really useful project with the potential of a community around it, name it well and make an organisation just for your work.
leipert 8y ago
Put it under your account, in case you stop working for the company. If that library gains traction, you can move it to its own ORG, which makes it easier to manage other contributors. 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.
spin 8y ago
I would definitely put it under my own name, if I were you. Like another commentor mentioned: if you leave the company, you still control your own repo. 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.

Kiro 8y ago

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

C1sc0cat 8y ago
Exactly especially for those just out of university who probably have not worked on any system of scale.

mscasts 8y ago

I don't know about you people, but I don'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. Also it is a positive thing if what I do is fun and/or meaningful.

austincheney 8y ago
Open sourcing the code is important to me because its frustrating being a senior hired onto a team of all newbs. By senior I mean a person who can write code quickly. By newbs I mean people with high insecurity that just want to dick around with code style and framework tooling.
- sethammons 8y ago
  I would not define "senior" as "one who codes quickly." I also would not define a software developer's level as "newb." So there is that. 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."
  - austincheney 8y ago
    > I would gauge them by a combination of time in the market, 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.

CathyWest 8y ago

> Refactoring your code to be as simple as possible > 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.

fipple 8y ago

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. 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.

arendtio 8y ago
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#build 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) ;-)
- GlitchMr 8y ago
  Dropbox Nautilus Extension is open source because it has to be - GNOME Files is licensed under GNU LGPL. The amount of code in that extension is minimal, the proprietary Dropbox client pretty much does all processing, the extension is only responsible for displaying icons in a file manager.
- fipple 8y ago
  How about you use it before assertively making claims about it. Just a good practice for life.

zby 8y ago

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.

_ph_ 8y ago

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?

app4soft 8y ago

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

KaiserPro 8y ago

"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 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

Jyaif 8y ago
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.
- matwood 8y ago
  This is a great point. The best engineers are the ones working with their teams to get shit done. If someone on the team is more worried about their OSS contribution than getting work done, it can be a red flag that they are more concerned about themselves than the team.
- gered 8y ago
  This is a really important point. I work with someone who has quite a bit of an ego. Definitely cares far too much about his personal brand, which has been built up over the years through open source projects. Any time you work on a project with this person you basically need to use all of his open source libraries if any of them are at all relevant for the project, regardless of if they are the best option for the task or not ... sometimes they are, sometimes they aren't. By far, the best developers I've ever worked with are quite humble.

joshfraser 8y ago

I've seen a lot of teams write code internally with the intent of open-sourcing everything once they're done. If you're doing this, you'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 & hear the rationale behind your design decisions. 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 https://www.originprotocol.com/discord (2) https://github.com/orgs/OriginProtocol/projects/2 https://github.com/orgs/OriginProtocol/projects/2 (3) https://meet.google.com/pws-cgyd-tqp https://meet.google.com/pws-cgyd-tqp (Every Wed at 1pm PT) (4) https://docs.google.com/document/d/1aRcAk_rEjRgd1BppzxZJK9RXfDkbuwKKH8nPQk7FfaU https://docs.google.com/document/d/1aRcAk_rEjRgd1BppzxZJK9RX...

austincheney 8y ago

I don't think open sourcing code will necessarily attract better developers. Better is highly subjective. If anything it will attract more compatible developers.

robbywashere_ 8y ago

Nah. Just need more hacker rank.

wellpast 8y ago

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.

dblock 8y ago

Artsy CTO here. I am excited to see this article and, putting aside that it quotes me :) 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

pdimitar 8y ago
Why didn't you open source before ElasticSearch invented something better than yours? 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?

effnorwood 8y ago

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

pdimitar 8y ago

This seems mostly like a Silicon Valley filter bubble talk. 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.