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.
"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.
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.
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.)
"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.
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.
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.
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.
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.
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).
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.
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
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...
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
Readit News
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.
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.
People forget that there are more items to maintaining a product than writing code.
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.)
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.
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.
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
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.
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
> 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.
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.
Maybe for growing your maintainer collection, with privileged access, but not contributions?
So in practice "judging the contribution" and "judging the contributor" are identical.
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.
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?
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.
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.