_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI What contributing to Open-source is, and what it isn't
keskival wrote 5 hours 7 min ago:
Doesn't the same thing apply to corporate software? Pass a LeetCode
hard and bring a backpack full of bricks, and go for it?
ericyd wrote 7 hours 37 min ago:
Building your own thing is great, but one unintended consequence is
that if your thing actually becomes popular, you'll be expected to
maintain it forever. If your interests or preferred tech stack change,
you are stuck with a mountain of your own tech debt. Chances are no one
will ever rescue you.
For juniors who barely even know that their own preferences are, much
less their long term career goals, this can be a serious downside.
When I was just starting, I had a side project that got reasonably
popular but I never expected to be maintaining it years later, and it
became a serious mental burden. I think the author is correct that you
know you're doing it right when it feels like a chore, but it is kind
of a bummer if a junior gets sucked into this maintenance burden
without understanding the consequences. As a more senior developer, I
think long and hard before seriously committing to a new open source
project, and ask myself if I want to be maintaining it in several years
before I write a line of code.
rikroots wrote 6 hours 39 min ago:
It's not just the code base that needs to be maintained. I'm about to
do a big release for my (not at all popular) JS canvas library and
I've spent the best part of a week just updating the documentation
surrounding the library: it is mind-numbing boredom, and far more
(non-?) technical debt than I ever wanted to deal with.
But I have to do it - it's like a "pride" thing now; I'd feel ashamed
of myself if I did a breaking release and left the surrounding
documentation to rot.
cjpearson wrote 7 hours 14 min ago:
This is a good point and thanks for sharing.
I would add that in my experience the bar for "reasonably popular" is
much lower than people would typically expect. One or two issues a
month may not be much if you're actively using and maintaining the
project, but it can easily become a burden if you've moved on from
the project. You either spend a few hours a month keeping it up to
date, or feel like you're letting someone down.
There isn't really a good solution to escape. Someone may submit
patches on their own or offer to take over maintenance, but I'm not
willing to ship code that I haven't reviewed or tested and would not
risk transferring it to someone unknown. (We've seen what can happen
there.) Deleting the project is an option, but that also negatively
impacts existing users in a drastic way. The best approach I think is
to clearly indicate that the project is no longer maintained and
suggest creating a fork if they need to make changes.
supernikio2 wrote 7 hours 16 min ago:
Doesn't the very nature of open-source mean you can just abandon it
and have someone else take up the torch when you're done maintaining
it?
ericyd wrote 5 hours 32 min ago:
Absolutely, but it does feel bad when you know your negligence is
impacting real people.
thomk wrote 8 hours 44 min ago:
Id like to contribute to a large project like Linux or python by
writing docs, testing or some other non development activity. Is that
possible or needed? How would I go about doing that?
_wire_ wrote 9 hours 11 min ago:
When is a title not a synopsis of the article?
Here's the rundown:
- I am wearing a hacktoberfest t-shirt.
- Some things are good, some are bad, including hacktoberfest.
- Trying to contribute to a project you know nothing about is bad.
- Unnecessarily belabored "build a school" homily with digression into
importance of listening to parents and teachers.
- A weirdly a-contextual Viking comic that injects the word fuck for no
reason.
- Something about Arch Linux.
- Wanting something not getting it... "infuriating!"
- Note to self: Contracting for the French gov. can be a good gig.
OK THANK YOU FOR THE INSIGHTS
All of this jibber-jabber can be reduced to a simple point:
Contributing comes down to being helpful.
If what you are doing is helpful then you are contributing.
â
What it is and what it ain't
URI [1]: https://m.youtube.com/watch?v=uyXE4saB6RU
newswasboring wrote 10 hours 39 min ago:
Does anyone else find the sentiment of this post a bit... gatekeep-y?
The way I read it, the author discourages people from just going out
and trying to contribute to a random project. The reason given is
because you would be bad at it as you don't know anything. But then the
author gives the example of maintaining an AUR package and they got it
to work because they needed it. From my point of view both these paths
lead to the same result, a person arrives at a project with objectives
they don't have the skills to build. (Unless the argument is to only
try to contribute when you have all the skills needed, and that is just
straight up gatekeeping).
Edit: Spelling and typos
kelnos wrote 8 hours 31 min ago:
The difference between those examples is that the author already had
experience with that software package, and presumably already knew at
least a little bit about what taking on maintainership of its
packaging would entail.
A drive-by contributor who "wants to get into open source" will often
have no experience with a particular project, and may not even have
used the software before. People like that don't have the necessary
context to start contributing, and their first (and sometimes only)
PR is more likely to be counter-productive noise.
newswasboring wrote 7 hours 58 min ago:
I don't get this. People who don't use the software can't hack on
it? Since when did software engineering not get repetitive? I have
contributed to langchain, for example, without ever doing as much
as an "import langchain" outside of debugging. I feel like people
are making a heuristic out of negative recall bias here. And why I
am so concerned is, it destroys an entire gateway into open source.
An entire gateway which is pretty common for people from developing
countries. They don't have local mentors, open source would
probably be the first time they will have access to real
programmers (I've personally been there).
8372049 wrote 9 hours 13 min ago:
I think you are misunderstanding his rationale and message.
The message, the way I read it, isn't just that you don't know the
random project, but you don't really care about it. He says to not
just bring a brick, but to build a great school. The AUR example is
relevant, because it is a problem you (he) cares about and continues
to nurture, not just add a brick/PR and leave.
It's not gatekeepy because it doesn't say "don't contribute". It says
"contribute to something you care about and want to succeed, where
you will put in more effort than just a one-off, for the sake of the
project and not for the sake of learning".
Most projects can find use for a junior developer contributing
consistently if the dev will learn the project and domain. It's not
gatekeeping.
erikbye wrote 9 hours 22 min ago:
I found the article to be terrible, and his school building analogy
falls flat on its ass. Both junior and senior developers can and
should contribute to open source, for a variety of good reasons and
there are good ways to go on about it.
kelnos wrote 8 hours 24 min ago:
I think you missed the point, and didn't actually read (or, more
charitably, understand) what the author said. Your last sentence is
actually a good summary of the article!
The problem is when someone wants to contribute primarily because
they think it will be good for their resume, or even just for a
more amorphous "I feel like I should give back" type reason. These
sorts of motivations often result in contributions that end up
being a drag on a maintainer's time, with little upside. People
coming at it from this angle usually don't become dedicated
contributors who grow and improve over time. They become a time and
energy sink.
I've unfortunately witnessed this firsthand many times in my 20+
years of open source involvement.
erikbye wrote 7 hours 31 min ago:
It's more that I don't agree with what he considers the four or
so proper ways to contribute. I also know of longstanding and
highly valued contributors who started out in ways the author
disapproves of.
newswasboring wrote 7 hours 55 min ago:
why are we inspecting the intentions of the contributor so much?
Why do we need to show this piousness in our reasons to get a PR
merged? Don't you see the unnecessary barrier here?
Edit: Changed author to contributor as it can be confused as the
author of the article.
bee_rider wrote 9 hours 6 min ago:
I donât think the article is terrible, but it does lean on that
analogy a little bit too much IMO. It is worth inspecting where
schools and programs differ.
If you could clone a school essentially for free, and also a poorly
constructed school was not at risk of killing a bunch of kids, I
guess weâd be much less skeptical of amateurs building schools.
I do think people write programs best when they are the primary
audience, so the idea of just, like, going around with the explicit
intent of finding open source projects to contribute to seems a bit
misguided. But the stakes are not very high. If nothing else I
imagine most open source projects must be able to ignore non-useful
contributions, right?
8372049 wrote 9 hours 12 min ago:
Did you read the last 2/3 of the article?
oooyay wrote 10 hours 7 min ago:
I don't know that gate keeping is the right word, but I think it's
doing a lot in the way of speaking for a number of projects (near
infinity) that the author can't possibly represent. I comaintain a
piece of infrastructure software that is fairly complicated - it fits
the analogue of a commercial building. Setting some arbitrary bar for
when to commit would frankly put just a few of us ever working on the
project. When newcomers have a thing they want to do we spend a while
talking it out in issue comments, then we modify that strategy on the
actual PR as needed. To be quite honest, there are parts of this
codebase I forget the nuance about all the time, so I'm really only a
step or two more familiar than someone that knows the language and
can write to the problem they desire to fix at any given time.
Most of my job is reasoning about, "should this feature be in this
project" and maintaining some bar for quality in merges. I can always
push the latter along if worse comes to worse.
johngossman wrote 12 hours 36 min ago:
The author seems to have forgotten that most schoolwork is also not
something the student is passionate about, and the value of
apprenticeships. Of course it would be better for students to work on
something they love, but that needs to be weighed against working in a
community, on a codebase, that will maximize learning.
johngossman wrote 12 hours 11 min ago:
Thought about it so more. Iâd say it is more important who you work
with than what you work on (thatâs also important).
pfdietz wrote 13 hours 26 min ago:
I contribute to an open source project by doing extensive testing.
I've been doing this off and on for more than two decades. I don't fix
the bugs I find; the people who do are much better at that than I am.
But I like to think I've gotten good at finding bugs, and try to find
new ones as soon as possible so they can be fixed before formal
releases.
lagt_t wrote 9 hours 45 min ago:
Do you recommend any bug report template?
pfdietz wrote 9 hours 28 min ago:
There's a bug tracking system associated with this project [1] I
include (1) minimized input that can reproduce the bug, (2) a copy
of the error and stack trace, or of an incorrect output, and (3)
identification of the specific version of the software (a git id)
and the architecture it was compiled for (typically x86-64).
Example:
URI [1]: https://launchpad.net/sbcl
URI [2]: https://bugs.launchpad.net/sbcl/+bug/2063205
brainzap wrote 13 hours 11 min ago:
respect
snowstormsun wrote 15 hours 35 min ago:
Open Source Maintainers shouldn't judge the people trying to
contribute, but the contributions. If the contribution is misguided or
not good, it's their responsibility to reject it. On the other side, if
the contributor's intention is to boost their resume, but the
contribution is also good and an improvement, so be it! Good
contributions are too rare to only select the ones done with selfless
intentions...
indymike wrote 8 hours 37 min ago:
After seeing several decade-long, slow supply chain attacks, maybe
knowing who is contributing might matter a little bit.
BeetleB wrote 11 hours 16 min ago:
As one communications book said (paraphrase): "Should is a word for
the lazy. Eliminate it from your vocabulary."
> If the contribution is misguided or not good, it's their
responsibility to reject it.
Arguably, they do not have a responsibility to even look at it. They
definitely do not have a responsibility to accept/reject it.
All good rules fail when confronted with constraints. If a maintainer
had infinite time and resources, your advice is good. Because they
don't, utilizing heuristics is necessary. What the author is hinting
at is being clear about turning away people seeking to boost their
resume is a useful heuristic.
Same reason why employers reject people whose main goal of joining
the company is to boost their resume.
If I'm an open source maintainer and I feel the contributor is an
annoying twit, I find no problems in ignoring him altogether (i.e.
implicitly rejecting his contributions). If you want to be an
intermediary and take the time to judge his contributions, and report
to me which ones are worth my time, I'll be happy to have you do it.
klysm wrote 12 hours 44 min ago:
Contributors are humans, so it doesnât work like that.
dartos wrote 13 hours 44 min ago:
Judging by the Jia Tan situation, I think maintainers should judge
contributors as well.
Itâs the maintainerâs job to be defensive of their projects and
prevent them from being abused. Itâs not necessarily their job to
build and foster a community.
hirsin wrote 10 hours 40 min ago:
What does it mean to judge a contributor? They're a faceless
account, maybe a dog on the internet. Isn't the contribution the
defining piece of work?
Maybe for growing your maintainer collection, with privileged
access, but not contributions?
keskival wrote 5 hours 9 min ago:
Accounts aren't always faceless. They can have real names, long
histories and connections to other profiles.
dartos wrote 9 hours 43 min ago:
> What does it mean to judge a contributor?
It means whatever the maintainer wants it to mean.
Weâre all humans.
Open source isnât a structured corporation.
I think itâs perfectly fine for a maintainerâs opinions to
affect the people and contributions to the project that theyâre
maintaining.
arp242 wrote 14 hours 4 min ago:
This is one one of those things that sounds nice in theory, but falls
down in practice, because in reality the overlap between "spammy
junk" and "contributions done purely to boost resume" is very close
to 1:1. I'm sure there's the odd exception, but it's rare.
So in practice "judging the contribution" and "judging the
contributor" are identical.
nrabulinski wrote 13 hours 52 min ago:
They arenât really. Even if the overlap was completely perfect
and all spam contributions were the ones done to boost resume, you
still shouldnât judge the contributor for trying to boost their
resume but judge the contribution by how useless and spammy it is.
imtringued wrote 16 hours 30 min ago:
I don't know how you managed to do it, but you slipped in a critique of
classical and neoclassical savings theory in this blog post with your
school article.
In classical economics, people must build the bricks before they can
build the school. This sounds like the obvious and correct way to do it
from a thousand miles, but as you pointed out, bricks produced by an
uncoordinated group of people is going to result in a bad outcome.
On the other hand investment preceding saving sounds impossible, right?
How can you invest something that doesn't exist? The bank gives you a
loan using created money that does not exist. You use this money to
order bricks from the brick factory. You then wait for the bricks to be
produced and delivered in the future. The bricklayers get paid and save
the money created by the loan. This way, the bricks meet the
specification of the architect. The money held by the bricklayers is an
implicit claim on the school. Each dollar represents a brick in the
school.
This is how the organisation of labor is coordinated in a market
economy. The problem with open source software is that there aren't
organisations from which you can just "hire" contributors from. Instead
you must already have the skills and then get lucky they don't reject
your contributions before you can even think about becoming a member.
It's the speculative brick problem all over again.
dmezzetti wrote 16 hours 40 min ago:
I tend to agree with this sentiment. Many junior devs and/or those in
college want to contribute. Then they feel entitled to merge a PR that
they worked hard on often without guidance. I'm all for working with
people but projects have standards and not all ideas make sense. In
many cases, especially with commercial open source, the project is the
base of a companies identity. So it's not just for drive-by ideas to
pad a resume or finish a school project.
For those who do want to do this, I'd recommend writing an issue and/or
reaching out to the developers to engage in a dialogue. This takes work
but it will increase the likelihood of a PR being merged.
Disclaimer: I'm the primary developer of txtai ( [1] ), an open-source
vector database + RAG framework
URI [1]: https://github.com/neuml/txtai
palata wrote 17 hours 11 min ago:
That's a lot of words, but I'm not sure what I get from them. Here's my
take:
If you want to contribute to open source, start with using open source
software even if there is a better proprietary alternative. Only when
you use code can you contribute meaningfully to it. Maybe it's a bug
fix, maybe it's a small feature you need. Maybe it's a package for your
distro. Whatever you need. And if you actually need it, then the best
way is to do it in a fork and use it. When you feel like it works for
you, offer to contribute it back upstream. It is fine to ask guidance
to the maintainer while you do it, but don't expect them to work for
you.
Avoid meaningless contributions just for the sake of contributing, like
making a package for a distro you don't use ("I use Ubuntu myself, but
let me contribute an Arch package I won't ever test"). Or features you
don't need but think would be cool. And stop opening 10 feature
requests per day: either you code them or you don't, but nobody cares
about what you think would be good features. Bug reports are fine if
you give proper instructions to reproduce ("sometimes it fails for me
plz fix" doesn't qualify as "proper instructions").
And always remember: whatever the maintainer(s) merge becomes their
burden, meaning that they don't do it lightly. If they don't want your
contribution, don't take it personally: maybe they can't commit to
maintaining it, or just don't feel like maintaining it. It's their
right, you don't pay them. Just keep your fork in that case.
datascienced wrote 15 hours 53 min ago:
What about when the lead maintainer has written 100 issues themselves
with clear instructions and tagged with âgreat first issueâ and
such like?
markx2 wrote 16 hours 20 min ago:
"Only when you use code can you contribute meaningfully to it."
I disagree.
I started using WordPress in January 2004. I was invited to join
Automattic in 2006. I never once wrote any code or even tried.
What I did do was a huge amount of Support in the wordpress.org
forums, and I write the first guides covering everything from
changing your password in the database (there was no other option at
the time), how to insert adsense, lots of CSS stuff and more. I know
of other current Automattic employees who came that same forum route.
Code is needed obviously, but you also need people who will support
others in using the program you create.
When I started in the forums I would see the then current WP devs
replying to questions. Matt in particular would reply, but he replied
as a dev would talk to another dev. He was always technically correct
but he wasn't really good at explaining. I - and others - could
explain in a way that people understood.
I would like to think that the very positive and helpful way the
forums were run was a helpful step when people were looking to what
blogging software to use at that time.
palata wrote 15 hours 42 min ago:
>> Only when you use code can you contribute meaningfully to it."
> I disagree.
I am a bit confused, because then you go on talking about
contributing to support and documentation. I never said anything
about those, I was talking about code. Only when you use code can
you contribute meaningfully to the code.
Obviously you don't need to know the codebase to help people use
the software.
Or did I misunderstand what you are saying?
markx2 wrote 15 hours 5 min ago:
Ah, this is my misunderstanding.
Apologies.
gwd wrote 16 hours 57 min ago:
This is pretty much exactly what the article says.
palata wrote 6 hours 7 min ago:
We have a pretty different definition of the word "exactly", then
:-).
kzrdude wrote 17 hours 27 min ago:
The best advice for starting out is just to start hacking on your own
projects. This is the first stepping stone for being able to jump in
and positively contribute to other's projects later, I think.
slothtrop wrote 11 hours 47 min ago:
I'm leaning this direction as it would allow me to get a ground-up
familiarity with certain stacks and technologies, whereas with open
source at the outset I never know where to look or what to
prioritize. It's obtuse. You have to sift through an overwhelming
number of projects, most of which I have little interest in, then
look at issues for bugs or features with no context.
Levitz wrote 13 hours 21 min ago:
Is it really? I'd posit this isn't even really "open source" 99% of
the time.
Github is absolutely littered with hundreds of thousands of repos
that nobody but their original creator has ever looked at. "Make your
own project" sounds good, but in practice it almost always means
"Make a personal project and make it public". You don't reach the
point in which you have to handle issues, or contributions, or pull
requests or anything because the vast majority of the time, projects
get nowhere, it's open source only in the most literal sense.
Also I'm not sure I see the logic even if the expectation is to make
a successful project. How can someone who has a hard time
meaningfully contributing to a project possibly manage a whole
project?
sgarland wrote 8 hours 24 min ago:
Yep. Most of the stuff I make is this way. It is open source
(usually MPL-2.0), but itâs also highly opinionated and designed
for me, and my specific need. If someone wants to fork it for
themselves, I am all for that.
The one and only time I built something that got a PR, the
contributor wanted to make breaking changes that suited them. I had
to politely decline, and explain the above.
kzrdude wrote 11 hours 52 min ago:
Yes it is really, I think.
The self-motivation is one thing. If you build it yourself it's
because you either need it or want it enough. If you build
something you get self confidence based in reality and experience
based in something. It is expected that only few of the personal
projects are ever interesting to someone else.
Maybe hacking on some small stuff for four years is what you need
to be able to graduate to know enough real world stuff to
contribute to bigger projects in practice, then that's just how it
is.
Now I think of neovim and it's ecosystem right now because I'm in
that phase, but most of the small plugins are driven by single
people alone, and they can still have a ton of users. Is it still
open source? Yes, it's open source if it has an open source
license. You are correct that an open project and open source are
not the same thing and don't need to be.
johannes1234321 wrote 12 hours 11 min ago:
Is that bad in any way? People do their projects for their own
motivation. If nobody else cares so be it.
rvz wrote 17 hours 35 min ago:
The only valid advice given by the author is that open source
contributions work much better if the person is paid or sponsored to
maintain it. Other than that, do not listen to the authors advice.
95% of this article is terrible advice and at this point wastes the
studentâs time for free work, which is not sustainable for open
source at all.
They are better off building a startup and making money out of that to
fund open source projects whilst getting paid or paying others for it.
The majority of companies are already doing that.
Otherwise you will end up with a wave of unmaintained packages,
abandonware and no community picking it up for the long term
maintenance.
Overall this is another article pontificating âa right wayâ for
students when open source is already a thankless ecosystem where
maintenance is paid in time with little to nothing in return.
This is why lots of open source developers complain that no-one is
paying them as they are extremely bad at pricing their own time and end
up doing free work for yearsâ¦
â¦Because companies want you developers to be happy to rip off your
valuable time for free whilst your scream: âx company is using it!â
yet they are exploiting you by them not paying for your time.
firesteelrain wrote 17 hours 28 min ago:
The way I thought the article was going was that itâs pointless to
contribute to open source if you donât know what you are doing. The
contributor needs someone to show them.
Which is a great point - how are we actually mentoring the junior
engineers so that they can take over some day?
mfuzzey wrote 15 hours 31 min ago:
That's not what I get from the article.
More that it's pointless to contrinute to an open source project if
you're not interested in improving the software the project is
building for a reason that matters to you. That's true regardless
if you know what you're doing or not.
So if your objective is just to "get a PR merged" that's not really
helpful. Rather it should be to "fix this bug" or "add this
feature" because those things somehow matter to you.
The "you" can also mean your employer. So if you use some software
as part of your job and it's got a bug or is missing a feature that
matters enough to you then fixiing it and contributing it back is a
perfectly valid and great way of funding open source. It's also not
normally philantropic, because when you make the effort of getting
your changes merged upstream it also reduces your own long term
maintenance burden of having a private fork.
firesteelrain wrote 15 hours 29 min ago:
Itâs also not realistic because many businesses would prefer
you not give back because itâs like giving away IP. It stays in
house. You would be breaking your employment contract if you do
so (speaking for the US)
mfuzzey wrote 7 hours 10 min ago:
You need to get permission from your employer obviously but I
think most are fine with that these days.
I'm not talking about open sourcing something your company has
made from scratch and is their core product but just
contributing (usually small) imporovements made to some open
source used so the "giving away IP argument doesn't really hold
water".
In my experience that's an easy sell to the company on purely
practical / selfish terms ("we can keep it in house and have
to spend time reapplying our changes to each new upstream
version that comes out or we can submit it upstream and have
easier updates in the future").
Look at all the companies contributing to the Linux kernel in
each release, most of them do it for precisiely this reason.
firesteelrain wrote 6 hours 18 min ago:
I am reacting to the latter as well. Not sure how many
corporate lawyers / attorneys you have dealt with but itâs
brutal. And they usually are not technically savvy. Better
off keep reapplying
globular-toast wrote 18 hours 20 min ago:
Totally agree with this. Been a free software advocate my whole life.
It's all about freedom to tinker and contribute should you wish to. If
you use computers you'll know when the time comes to do that. It's
usually when the software doesn't quite do what you want or there's
something you need that nobody has thought of yet. It's up to you
whether you just hack it for your own purposes or put in some extra
effort to get the code merged upstream. Definitely recommend the latter
if you want to learn how to contribute to a live codebase (free or
otherwise). But don't go in with the goal of getting something merged,
it's got to start with your problem.
Anecdotally, some of the best hackers I've known have started off as
kids building things like game mods and chatbots and the like. Then
later they've learnt how to do it "professionally". The worst are the
ones who know how to make a pull request etc but have never been
through the trenches solving a problem that nobody else has.
noufalibrahim wrote 20 hours 37 min ago:
Many of these efforts work best when they are consist of a small group
of competent elites. There is a path to get in there for everyone but
the bar is high.
I get the good intentions behind democratizing this but that, coupled
with companies using contributions as a metric, leads to the original
(fragile) system being damaged.
In spirit, I agree with the article.
JTyQZSnP3cQGa8B wrote 20 hours 42 min ago:
The whole thing is ridiculous. He compares a curious nerd with the
hacktoberfest disaster in order to discourage people, and then
describes what happens in a professional context where you are paid to
code.
A "senior" developer with less than 10 years of experience, an empty
GitHub repo, and a fake degree should be more humble.
Sorry for the rant but heâs not helping anyone. There are abuses, but
we should encourage juniors, not describe the open source world like
that.
jackcviers3 wrote 8 hours 49 min ago:
Gatekeeping is part of running a project -- you have the right to
refuse the contributions for any reason you'd like. They, likewise,
have the right to fork your project and run a new one how they see
fit. Do it too much though, and you'll drive the popularity of your
project way down and nobody will use it.
Even with free (in both senses of the word) products, the market will
always work itself out.
BeetleB wrote 11 hours 12 min ago:
> A "senior" developer with less than 10 years of experience, an
empty GitHub repo, and a fake degree should be more humble.
It's hard for me to listen to anyone who judges people based on their
Github repo.
cjpearson wrote 7 hours 6 min ago:
Typically, yes I agree. But if you're evaluating someone's
expertise in open source contributing, looking at their open source
contributions is fair game.
david_allison wrote 12 hours 59 min ago:
> an empty GitHub repo
Eh? This is more than reasonable.
URI [1]: https://github.com/samuelfaure/
imtringued wrote 16 hours 15 min ago:
Coordination is real work. I have spent way too much time working on
something only to realize the developer of the project knows it
better than me, writes the code quickly and by the time I am about to
send a pull request the developer already came up with a better
solution.
The problem is that most developers don't really have a "hiring
strategy". People who want to commit to a project for three months or
so don't really have a place to go, so they throw pull requests up
and then get mad when they get rejected.
lelanthran wrote 19 hours 25 min ago:
> A "senior" developer with less than 10 years of experience, an
empty GitHub repo, and a fake degree should be more humble.
Is this a reference to the author? How can you tell that he has a
fake degree?
notresidenter wrote 19 hours 13 min ago:
GP, There's no need to attack the author?
"42 School" which is the "school" his degree comes from is a
glorified boot camp. It's one of the popular ones (in France)
It's an immediate red flag for many French tech companies when
hiring.
Rant: I dislike this boot camp for what it does to parents of
teenagers who are promised their child will have a career in tech,
but then are not taught the skills they need to grow, so they come
on the job market with -2 years of experience because they have to
relearn everything (but often don't want to put the effort to do
so) because they are attracting lost teenagers that like playing
video games, not teenagers that actually want to learn CS and/or
Software Dev.
So, you get unmotivated people with a bad attitude and no useful
skill, as they need babysitting.
Source: I've interviewed many ppl coming from this school and
talked with n>10 founders about their experience hiring from there
firesteelrain wrote 17 hours 24 min ago:
Now that you post this it puts things in a totally different
light
datascienced wrote 15 hours 48 min ago:
OTOH it is gatekeeping you need a degree to code. And a
bootcamp completion is not a fake degree. No more than a CS
degree is a fake programming vocational qualification.
notresidenter wrote 13 hours 50 min ago:
I'm not saying 'all bootcamps are bad' here, I'm saying 'this
particular bootcamp is bad'.
I think there's a clear distinction between CS and Software
Dev.
The latter _can_ be self-taught, or learned with a bootcamp,
if it's good. It's essentially a trade which means practice
is everything. And also includes a good bit of project
management.
The former is a scientific field, much like physics,
sociology, etc. and having a CS degree is useful for doing
research (which in CS could mean coding, and could mean
writing software, e.g a new type of database/algorithm/other)
hence the confusion between the two. And some/most Software
Devs need to understand/improve/adapt artifacts from the
field of CS, so a CS degree is often beneficial for software
devs, but not needed.
So, I don't think it's fair to say that it's a 'fake
programming vocational qualification', it's not what it's
for, and people that say the contrary misunderstand what a CS
degree is.
firesteelrain wrote 15 hours 18 min ago:
Computer Science is and was never intended to be a pathway to
programming. If you want a career in software engineering
then you should get a degree in Software Engineering and also
a Masters in Systems Engineering.
Coding bootcamps arenât bad but in my opinion they should
accompany a CS/SWE degree + Masters.
You should have systems thinking skills and be a lifelong
learner. Itâs not a one shot
janosdebugs wrote 19 hours 31 min ago:
Open source can be a wonderful thing when people come together and
build something cool. Unfortunately, maintainer burnout has been a
thing recently and part of the reason is that IT and open source are
seen as a way to get a lucrative job. Some (and by no means all)
people disregard the consequences of their actions to get there.
Juniors should absolutely be encouraged to either build a project on
their own or collaboratively, or to start by joining the community
and listening before starting to write code. This is something that's
lost on many and "drive-by PRs" happen a lot on high profile projects
from people just wanting to say "I'm an X contributor" on their CV or
get a coveted t-shirt and never come back again.
These drive-by PRs come in a variety of forms. Some are just absolute
nonsense, some rename things for no good reason, some refactor a part
of the code that nobody asked for, and some do add a tiny bit of
value, but are extremely bad quality to the point where rewriting it
would take less time than going through several (dozen) review rounds
explaining to the budding contributor how to write code. (Or how to
even use git. Rebasing a PR is a problem for a lot of people, for
example.) Maintainers of open source projects typically didn't sign
up for being mentors to people who barely know how to code.
More than that, these random PRs increase the noise level in the
project by a lot and take away time from the contributors, junior or
not, who put in way more effort that a drive-by PR author did.
Leaving PRs to rot is bad because they will start having conflicts,
so not reviewing them is not an option. Each of these PRs needs to be
properly reviewed because they have a maintenance cost later that
rests on the shoulders of the maintainers, not the contributor. Each
PR carries the risk of someone introducing malicious code. Answering
these PRs politely but firmly also takes quite a bit of effort.
Yes, juniors should be encouraged, but realistic expectations should
be set. Contributing code to a highly complex project probably isn't
going to happen. They should try and contribute to small projects
that they themselves know and use. That way they understand what is
good an what is bad for that piece of software. Also, they should
"read the room" and the contribution guide before jumping in. The
best way to start is with small things: reporting issues, fixing docs
bugs, and once they are comfortable with the workflow, move up to
writing code.
Unfortunately, communication is hard and getting this message across
("be considerate") to the right people is harder. This post has a
good analogy for that with the bricks.
lelanthran wrote 18 hours 41 min ago:
> This is something that's lost on many and "drive-by PRs" happen a
lot on high profile projects from people just wanting to say "I'm
an X contributor" on their CV or get a coveted t-shirt and never
come back again.
I have a fairly controversial take on drive-by PRs: They're great
IFF the submitter is an experienced developer.
I did a drive-by PR on LucasChess.
I tried to use LC on a Linux desktop, and there were showstopper
GUI bugs. I tried on a few different distros with the same result.
I looked into the code and found that a few Qt values in the
Python-GUI portion had "wrong" values (i.e. they were ignored on
Windows, but were honored on Linux). I made a fix. I did a few
tests. I submitted the PR with a message about the bug, how to
reproduce and how exactly the patch will fix the problem, and went
on with my life (the very definition of a drive-by PR). The project
accepted the PR as is.
That's literally how projects get better: someone takes the time to
diagnose a problem, make a fix, submit the fix and move on whether
or not the fix is accepted. When enough people are doing this the
project maintainer might be using all their project time only
reviewing PRs, but at some point there's just too few bugs left in
the product to take up much time on the maintainer's part.
The problem is when an inexperienced developer makes a PR. Odds are
good that they didn't diagnose the root problem, didn't chase down
the docs (for Qt, in this case) for explanations, didn't try to
replicate on different systems, didn't document what the bug is,
didn't explain in the PR how to reproduce the bug, didn't test the
fixes and/or never used the product themselves (I still use LC
almost daily).
"Experience" means "I know how to do all of the above, and have
done so in the past".
janosdebugs wrote 16 hours 36 min ago:
To me, what you are describing doesn't constitute a drive-by PR.
You used the software, saw a bug, fixed it. This is the very best
part of open source. (I hope the text in its entirety made that
clear.)
The kind of PRs I'm talking about are from people who have never
and likely never will use the software, but want the badge of
questionable honor of having contributed to a well-known project.
The only reason they looked at the code is because they saw it in
the news or someone told them to "go contribute to open source"
to help their career. I don't mind a junior going to fix a but
that they themselves found and know how they want the software to
work. I do mind if someone goes randomly looking for something to
contribute without understanding the software, how it's supposed
to be used, and proceeds to expect maintainers to hand-hold them
through the process of getting their contribution in so they can
put it on their CV or satisfy a teachers assignment.
I think what's rarely spoken about is the fact that each PR needs
maintainer time. Maintainers are typically few and their time
should be used to further the project, not for personal gain.
spacechild1 wrote 13 hours 44 min ago:
> To me, what you are describing doesn't constitute a drive-by
PR.
Drive-by PR simply means that the PR author is not a known
community member resp. doesn't plan to become a regular
contributor.
janosdebugs wrote 12 hours 36 min ago:
My bad, I didn't know that that term was so established.
mfuzzey wrote 15 hours 54 min ago:
I think you and GP (about Lucas Chess) are using the term
"drive-by PR" differently.
I agree with the GP's definition. I consider a drive-by PR to
be one made by someone who doesn't intend to become a regular
contributor to the project but does have real motivation as a
user of the project to get their "itch scratched" (a bug fixed
or some feature that matters to them added).
I also understand the type of PR you're describing (and agree
with you that it's a bad idea) but I think it needs another
term to describe it. Maybe "non user PR" or "CV driven PR" or
"Vanity PR"?
(edit sp)
pauby wrote 19 hours 43 min ago:
> A "senior" developer with less than 10 years of experience, an
empty GitHub repo, and a fake degree should be more humble.
This says more about you than it does about them.
The author is offering an opinion. You can disagree without resorting
to this. You need to be better than that.
BoingBoomTschak wrote 14 hours 6 min ago:
Attacking the authority of people who start their article with an
appeal to said authority isn't really far-fetched.
erikbye wrote 9 hours 12 min ago:
Another red flag is "I use Arch Linux, btw"
bawolff wrote 20 hours 48 min ago:
As someone who has done open source work, i sadly agree. People who
contribute because they want it on their resume or want "experience"
without caring about or using the software usually make terrible
contributors.
brainzap wrote 15 hours 56 min ago:
but this can be solved
prepend wrote 13 hours 40 min ago:
I agree. It can be reduced through PR review and since itâs
public, people who make low value contributions are easier to spot
than in non-OSS projects where the same vanity contribs are harder
to see.
Iâd say that if I saw bullshit open source contribs on a resume
it would be counterproductive. So I think people may do it for
t-shirts, but to list as experience seems like it doesnât happen
as much as it seems it may.
dartos wrote 13 hours 44 min ago:
How do u think?
atoav wrote 20 hours 57 min ago:
My best open source contribution (judged by the fact that its founder
wanted to meet me specifically when he was in town) was to a project
that I use and deeply care about, yet I couldn't contribute as I am not
fluent in the programming language used.
So I did the next best thing and made an effort to collect a list of
UI/UX papercuts and logical inconsistencies, each with a list of
proposed options to fix it, sometimes including mock ups how I imagined
it could look like. And posted it in multiple well sorted issues once I
felt it had a certain level. I did this after giving the maintainer a
friendly hint of the things that I planed and told them to not feel
pressured to resolve any of that quickly (or at all).
He still did and that lifted the software from a usable but rough piece
of software to another level.
Then as I was already very familiar with the UI I went and write the
documentation for the usage.
The worst open source contributions are the once where you quickly
"fix" a thing that has never been broken all while not coordinating
with the other people on the project.
simonw wrote 14 hours 36 min ago:
"So I did the next best thing and made an effort to collect a list of
UI/UX papercuts and logical inconsistencies, each with a list of
proposed options to fix it, sometimes including mock ups how I
imagined it could look like."
I love that so much!
It's very hard to judge the usability of your own software because
you know it better than anyone else in the world.
Pointing out sharp edges like this is just incredibly useful.
Attaching research into options that can help is huge too - much more
valuable than proposing a single fix without acknowledging that there
might be multiple ways this could go.
gruntwork wrote 17 hours 30 min ago:
The contributions appear to be to Horizon EDA: [1] .
URI [1]: https://github.com/horizon-eda/horizon
atoav wrote 17 hours 15 min ago:
True : )
Still working with that software, although lately i didn't
contribute much, partly because of day-job reasons (not enough
time), partly because the software is already pretty darn good.
ticoombs wrote 19 hours 55 min ago:
UI is honestly what a lot of open source projects need work on. The
fact you took the time, made mocks and contributed to the
documentation is amazing!
People forget that there are more items to maintaining a product than
writing code.
kevincox wrote 11 hours 11 min ago:
I agree. I have lots of projects that work very well but definitely
need some UX work. Often times even features that are implemented
but not exposed because I don't know how to make the UX work.
Designs or a frontend developer would be amazing.
But it always feels easier to a slide into a project with a bug fix
or a small feature as opposed to redoing some UI that the owner
did. It isn't always obvious if the owner things their design is
great and is protective about it or if they would love someone to
come in with some ideas. (And even then it may be a lost cause of
you both have different tastes.)
lukan wrote 19 hours 35 min ago:
"UI is honestly what a lot of open source projects need work on."
I agree, but I would assume many maintainers themself would not
agree. So the sensitive approach atoav took, (asking first) is
probably the right thing to do.
bawolff wrote 19 hours 23 min ago:
I think UI can be hard because it is hard to be objective about
it. It is critical work, but at the same time if someone came out
of nowhere, totally re-arranged all the UI elements, and was
just, "trust me bro, this is better", i would be extremely
doubtful.
atoav wrote 17 hours 21 min ago:
I was working as a freelance designer both for print and web
before and went through what was essentially a graphics design
bootcamp by an old grumpy typographer. Then I worked as a
camera operator/DoP for films, so my intuition for composition,
how to communicate things visually etc. is pretty good.
Contrary to what many people think about design, good design is
mostly about structuring the importance and grouping of
information, clear typography, good color choices, etc. with
the goal of making that information apparent on first glance
for most people, while still retaining some sense of character
(where/if needed). So this wasn't about them having to trust
me, but about me having to explain my rationale behind each
design decision in a way that convinces them it is worth the
work. Design in open source projects often has the problem that
it is made by "someone who knows how to use inkscape" and not
by people who necessarily have the eyes/experience to reason
these changes on a grand overarching level, hence the often
very mixed up non-uniform UI look of open source projects.
As a former freelancer I learned to detach myself somewhat from
my work â not in the sense that I make things I dislike, but
in the sense that I find the rational reasons behind a design
more important than the fact that it was me who did it, so if
someone has a better idea I'd happily go for it and if
priorities are not shared, that helps adjust that reasoning
etc.
Many graphical contributers in open source projects don't have
that humility. They want their taste to be represented, not
necessarily to put their skill into the service of the project.
And that runs into the danger of becoming bike-shedding, where
totally subjective aspects of a design (e.g. matters of taste
when it comes to color choices) take a lot of energy â
because these changes are so devoid of real meanign it is safe
for everybody to have an opinion here â this is where you
should just add theming and let them do it themselves..
So I tried to do the opposite of bike-shedding, because every
"help" I offer produces a cost on the other side.
pfdietz wrote 13 hours 23 min ago:
URI [1]: https://en.wikipedia.org/wiki/Egoless_programming
ozim wrote 19 hours 7 min ago:
At work for company product problem is that everyone has an
opinion on UI/UX.
It is just super hard to get people agree on one way or the
other.
No one has opinions on my database design or architecture.
I can see how OSS project leaders that are developers not
really wanting to deal wit UI/UX drama where everyone can make
up something and you have to fight for every small detail.
sgarland wrote 8 hours 30 min ago:
> No one has opinions on my database design or architecture.
As a DBRE, I have many opinions about schema design.
Unfortunately, they are often not well-received, because Some
Grifting Blog told them their way was fine, and who am I to
argue?
xorcist wrote 13 hours 52 min ago:
> No one has opinions on my database design or architecture.
Oh dear, if you only knew ...
I have personally seen both those things gridlock entire
teams, to the point where people would rather quit than
continue working.
vbezhenar wrote 17 hours 20 min ago:
Does everyone have reasonable opinion? Like do they present
an objective reasons for their opinion? If all they can say
"I don't like it", this opinion means nothing. Rarely people
can meaningfully argue about UI changes.
atoav wrote 12 hours 36 min ago:
The relationship between the perceived importance of the
thing and the amount of people who have strong opinions it
is inversely proportional.
The less meaningful a change is the more people dare to
voice strong preferences.
ozim wrote 16 hours 56 min ago:
Even if their âI donât like itâ doesnât add value
it still that they are business people or other devs or QA
that we work together on daily basis.
I still have to manage emotions and validate their feelings
and I canât just say âfuck off, we do it my wayâ.
Which of course is taxing emotionally especially when I
have to deal with my own emotions not to feel attacked when
presenting something and gettin people âon the spot,
ideasâ.
beckthompson wrote 20 hours 59 min ago:
Unless I missed something the article never really explained how to
contribute to open source software the "right" way so its kind of
silly. According to the article there are four ways:
1.) Use open source software (Fair enough but not helpful)
2.) Take over a unmaintained package (If your a brand new developer
probably not the best idea!
3.) Make your own thing (Not really what most people want to do...)
4.) Get paid to do it (Not really possible for new developers)
I don't feel like any of those are reasonable solutions. I'm not a
particularly good programmer but I have just recently been trying to
contribute to an open source project (Apparently doing it the "wrong
way" according to the article!) and its going amazing! Everyone is very
helpful pointing out issues with my PR and helping me understand what
to do better.
Is it the most efficient use of the maintainers time? As of right now,
probably not! However, if I continue to help develop the project them
training me now will certainly be worth while as I become better at
contributing.
gus_massa wrote 13 hours 38 min ago:
Your first point is backwards:
> 1.) Use open source software (Fair enough but not helpful)
It should be
> 1.) Send PR to projects you already use.
The idea is that you understand how the sofware is used before
triying to fix or improve it. It also work for propietary software,
dogffod it yourself and use hallway usability test.
(There are some examptions like fixing typos or transforming the
automatic test suit to be run in github actions, but most of the
times it's very useful to already use the project to understand what
is the correct fix.)
beckthompson wrote 11 hours 41 min ago:
Yeah your right, after re-reading the article that was the point
the author was trying to get across!
Alpha3031 wrote 15 hours 23 min ago:
I feel like the article documents the author's own experiences
(which, to be fair, is a valid thing to do) without emphasising, or
really even trying to emphasise, the how. Which really makes it less
useful for anyone looking for learnable takeaways.
But hey, it triggered this HN discussion, and I see a lot of replies
here which seem more useful for that kind of thing.
philipwhiuk wrote 16 hours 15 min ago:
> However, if I continue to help develop the project them training me
now will certainly be worth while as I become better at contributing.
The problem is the 'if' is a big barrier.
Dunati wrote 18 hours 48 min ago:
Regarding the package maintenance item, that is just an example of
something that was right for the author, not a suggestion for the
general public. It was something they found useful, used regularly,
and happened to be unmaintained. This put them in a position to make
a meaningful contribution, beyond padding their work portfolio. This
is the whole point of #1. You are in a better position to understand
the flaws in software you use, and you have a vested interest in
fixing them. Picking a random bug on a random project isn't going to
give you the same insight.
bawolff wrote 20 hours 40 min ago:
I disagree. I don't think the article is saying that.
The article basically says you should have some connection to the
project. This is very much the traditional view - you should
contribute to open source by scratching the itch you have.
> I'm not a particularly good programmer but I have just recently
been trying to contribute to an open source project (Apparently doing
it the "wrong way" according to the article!) and its going amazing!
Why do you think the article is saying you are doing it the "wrong
way"?
beckthompson wrote 11 hours 41 min ago:
Hmmm after re-reading the article I think you might be correct!
> Heck, with proper supervision the kids themselves can help too.
You can do open source as a beginner, you don't need to be a senior
for that.
> But you need to be involved in the project and act accordingly,
you don't just go and throw bricks around.
I guess I am doing it the correct way! I think the author should
have also mentioned this point in the how to contribute the right
way so its more obvious.
DIR <- back to front page