"WhY nOt MaKe An OpEn SoUrCe CoNtRiBuTiOn?", they say

Because it's almost never worth it, you fvcking dumbass.

The context

I could have ended the whole blog post there, but I being the benevolent person I am (?) decide to tell more about the story. This reddit post, one day, showed up in my feed. (now that I think about it this is actually pretty messed up to post in r/learnprogramming). Now, if this does not sound like those not-junior-anymore-but-not-quite-senior-enough feel-good mediocre's bullshittery, I don't know what else is.

Everyone with a rudimentary understanding of human society's navigating strategies would almost certainly (if not definitely) agree that if something is certain to yield a profit, then everyone would start thinking about doing it; and if the thing in question is easy, then everyone would definitely be doing it. Profit, in this case, with "getting hired" being a competition, can have both ways:

• If you do this you're more likely to get hired than others; a profit in this case is simply a profit.
• If you don't do this you're less likely to get hired than others; a profit in this case would be a profit to cover a potential loss.

Now, with the rules said above, we can conclude two reasons why people aren't doing that much "OpEn SoUrCe CoNtRiBuTiOn" as this "hiring manager" would like to see:

• It seems easy but it's actually not.
• The contribution, if any, either barely hold any significant value, or extremely taxing till the point of not worthing the effort.

The "Too Long; Didn't Read"

To conclude:

• People do things because the things are easy (or at least within reach) and yield a profit (at least with a fairly certainty).
• To contribute to a code base you have to learn about it, which costs a lot of time and in most case not worth the cost at all (in terms of getting a job).
• Those that are easy (e.g. typos) usually did not help that much at all for anybody. Documentations can be helpful, but that requires one to spend time learning about the code base, etc..
• Big open source projects are likely to have an well-established internal coordination, which often (if not always) requires you to at least be a frequently-seen member of their community (or their mantaining team, especially for those projects backed by companies) to have a chance of getting your pull request accepted.
• Contributions to smaller-sized open source projects, while having roughly the same amount of mental strain, are actually never that impressive from an employer standpoint.
• People are not gonna do it just because you said it should be this way (especially when your idea is out of touch). If you reject their job applications they'll just go somewhere else with absolutely zero fvcks given about your opinions. While you're choosing between candidates, they are also choosing between you and other at-least-probably-more-sensible companies.

The problem of reading other people's code

Because the person in question is a "HiRiNg MaNaGeR", chances are he/she/they are already far away from the dev work for a long time. Maybe back in the junior years he did the same thing and somehow succeeded with serious luck, got his job with serious luck, got promoted with serious luck, did not have to read big code bases without any kind of previous knowledge all on his/her/their own (like I did^[1]) with serious luck, thus somehow believing all of that luck is his/her/their own abilities and everybody should be able to do the same thing. What kind of serious cluelessness is that!?

Listen well. To contribute meaningful work on a code base requires you to firstly understand the code base, which has always been a pain in the ass without exceptions, especially more so if there's not enough documentation. People write shitty code all the time, no matter how good they are. Code base quality deteriorates all the time. Code readability is fundamentally a myth, because code does not represent knowledge of any kind, code is merely artifact. Creating something anew almost always cost less than fixing things in this industry, that's why it's always the case that everybody wants to rewrite an old existing project but nobody dares to refactor, and if all you do is hiring people chances are you never had any sensible idea about all this.

The greatest common divisor

Strategies of the employees are shaped by the requirements of the employer. If we *are* talking about getting a job - if one becomes a software dev solely for the money, you can bet your uncultured ass he/she/they will "pick the low-hanging fruits" to maximize the chance of them landing a job in the most efficient way possible, which currently involves grinding LeetCode (bleh), memorizing interview questions and - surprise, surprise - "turtorial projects" built with the most popular, the newest shiniest languages and frameworks - because instead of some random open source project out on the Internet, companies actually use these techs for their projects! When the extra effort does not necessarily translate to a higher chance of employment, good luck having anyone truly believing and following your self-entitled employment "aDvIcEs".

But let's consider the most impossible case, the case where the stars aligned. To effectively execute all this, it requires:

• An (at least) half-decent dev so that it won't cost too much time on getting familiar with the code base, or a junior dev (or student) so willing to devote his/her/their life on one such code base that it doesn't matter if it's almost always not efficient.
• A true motive to contribute, a sense of urge, a sense of "I will not find other solutions and I require this to be done to this code base no matter what".
• The time and the energy to learn enough about the code base (which you'll never know how much you're required to learn if for this particular code base it's an one-off thing to you) and sometimes enough domain knowledge about the code base's "topic" (e.g. if it's a machine learning library you'll have to know machine learning), while hoping they won't fix the issue themselves either planned or not planned.
• The time and energy to actually write & test the code while hoping the maintainers won't become so impatient that they fix the issue themselves.
• Wait until the maintainer(s) merge your code while hoping they won't fix the issue themselves either deliberately or by accident so that your pull request would be considered valid.

Then, and only then, did all the time and energy spent on every single aspect of this whole process produces something that you can put in your CV. That surely looks like something that happens all the time, just waiting for students freshly graduated from CS school to find out about!

Jesus fvcking Christ.

Addendum

From a dev standpoint, I sincerely doubt that these "mAnAgErS" had any kind of experiences in development or even serious talks with any software dev, and if they did, that's even worse, and I would absolutely go as far as to suck some ugly bastards's dicks just to make sure that I don't have to work with people with this amount of cluenessness.

Now to be clear I'm not saying everyone needs to be a core maintainer on ReactJS or something. But if you graduate and don't have the ability to make any contribution, then you may not have the ability to work a full time job.

Seriously? If they did not have "contributing" GitHub profiles they look like incapable of coordinating to you? FUCK YOU. GO TO HELL.

Hiring is almost always a retrospective thing: you can never accurately summarize a person & his/her/their skill in time as short as a quick read of something that's already a painful oversimplification of him/her/them. You can always try your best but no rule based on CV can give you a perfectly good candidate filter - you are bound to filter out the "right people" and letting the "wrong people" in sooner or later.

To determine whether a candidate did do his/her/their own thinking or not when doing the "TuRtOrIaL pRoJeCt"s is, in fact, not as hard as some people might think: you can pick out a design problem that requires a certain amount of problem solving skills, and ask them why they chose to do things the way they've chosen. But that requires actually giving a chance for the candidate to be interviewed with a real person (instead of some soulless rule machines like "HaViNg OpEn SoUrCe CoNtRiBuTiOnS") and the interviewer to have decent tech fluency, which for some MaNaGeRs might just be too high of a hurdle.