[HN Gopher] What contributing to Open-source is, and what it isn't
___________________________________________________________________
What contributing to Open-source is, and what it isn't
Author : thunderbong
Score : 167 points
Date : 2024-04-27 04:16 UTC (18 hours ago)
(HTM) web link (suchdevblog.com)
(TXT) w3m dump (suchdevblog.com)
| beckthompson wrote:
| 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.
| bawolff wrote:
| 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:
| 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.
| Dunati wrote:
| 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.
| philipwhiuk wrote:
| > 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.
| Alpha3031 wrote:
| 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.
| gus_massa wrote:
| 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:
| Yeah your right, after re-reading the article that was the
| point the author was trying to get across!
| atoav wrote:
| 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.
| ticoombs wrote:
| 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.
| lukan wrote:
| "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:
| 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.
| ozim wrote:
| 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.
| vbezhenar wrote:
| 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.
| ozim wrote:
| 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".
| atoav wrote:
| 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.
| xorcist wrote:
| > 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.
| sgarland wrote:
| > 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?
| atoav wrote:
| 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:
| https://en.wikipedia.org/wiki/Egoless_programming
| kevincox wrote:
| 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.)
| gruntwork wrote:
| The contributions appear to be to Horizon EDA:
| https://github.com/horizon-eda/horizon.
| atoav wrote:
| 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.
| simonw wrote:
| "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.
| bawolff wrote:
| 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:
| but this can be solved
| dartos wrote:
| How do u think?
| prepend wrote:
| 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.
| JTyQZSnP3cQGa8B wrote:
| 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.
| pauby wrote:
| > 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:
| Attacking the authority of people who start their article
| with an appeal to said authority isn't really far-fetched.
| erikbye wrote:
| Another red flag is "I use Arch Linux, btw"
| janosdebugs wrote:
| 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:
| > 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:
| 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.
| mfuzzey wrote:
| 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)
| spacechild1 wrote:
| > 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:
| My bad, I didn't know that that term was so established.
| lelanthran wrote:
| > 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:
| 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:
| Now that you post this it puts things in a totally
| different light
| datascienced wrote:
| 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.
| firesteelrain wrote:
| 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
| notresidenter wrote:
| 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.
| imtringued wrote:
| 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.
| david_allison wrote:
| > an empty GitHub repo
|
| Eh? This is more than reasonable.
| https://github.com/samuelfaure/
| BeetleB wrote:
| > 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:
| 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.
| jackcviers3 wrote:
| 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.
| noufalibrahim wrote:
| 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.
| globular-toast wrote:
| 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.
| rvz wrote:
| 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:
| 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:
| 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:
| 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:
| 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:
| 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
| kzrdude wrote:
| 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.
| Levitz wrote:
| 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?
| johannes1234321 wrote:
| Is that bad in any way? People do their projects for their
| own motivation. If nobody else cares so be it.
| kzrdude wrote:
| 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.
| sgarland wrote:
| 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.
| slothtrop wrote:
| 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.
| palata wrote:
| 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.
| gwd wrote:
| This is pretty much exactly what the article says.
| palata wrote:
| We have a pretty different definition of the word "exactly",
| then :-).
| markx2 wrote:
| "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:
| >> 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:
| Ah, this is my misunderstanding.
|
| Apologies.
| datascienced wrote:
| What about when the lead maintainer has written 100 issues
| themselves with clear instructions and tagged with "great first
| issue" and such like?
| dmezzetti wrote:
| 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
| (https://github.com/neuml/txtai), an open-source vector database
| + RAG framework
| imtringued wrote:
| 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.
| snowstormsun wrote:
| 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...
| arp242 wrote:
| 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:
| 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.
| dartos wrote:
| 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:
| 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?
| dartos wrote:
| > 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.
| keskival wrote:
| Accounts aren't always faceless. They can have real names,
| long histories and connections to other profiles.
| klysm wrote:
| Contributors are humans, so it doesn't work like that.
| BeetleB wrote:
| 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.
| indymike wrote:
| After seeing several decade-long, slow supply chain attacks,
| maybe knowing _who_ is contributing might matter a little bit.
| pfdietz wrote:
| 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.
| brainzap wrote:
| respect
| lagt_t wrote:
| Do you recommend any bug report template?
| pfdietz wrote:
| There's a bug tracking system associated with this project
| https://launchpad.net/sbcl
|
| 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: https://bugs.launchpad.net/sbcl/+bug/2063205
| johngossman wrote:
| 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:
| 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).
| newswasboring wrote:
| 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
| oooyay wrote:
| 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.
| erikbye wrote:
| 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.
| 8372049 wrote:
| Did you read the last 2/3 of the article?
| bee_rider wrote:
| 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?
| kelnos wrote:
| 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.
| newswasboring wrote:
| 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.
| erikbye wrote:
| 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.
| 8372049 wrote:
| 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.
| kelnos wrote:
| 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:
| 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).
| _wire_ wrote:
| 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
|
| https://m.youtube.com/watch?v=uyXE4saB6RU
| thomk wrote:
| 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?
| ericyd wrote:
| 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.
| supernikio2 wrote:
| 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:
| Absolutely, but it does feel bad when you know your
| negligence is impacting real people.
| cjpearson wrote:
| 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.
| rikroots wrote:
| 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.
| keskival wrote:
| Doesn't the same thing apply to corporate software? Pass a
| LeetCode hard and bring a backpack full of bricks, and go for it?
___________________________________________________________________
(page generated 2024-04-27 23:02 UTC)