What contributing to Open-source is, and what it isn't
suchdevblog.com
suchdevblog.com
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.
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.
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.
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.
The less meaningful a change is the more people dare to voice strong preferences.
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”.
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?
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).
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?
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.
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.
Edit: Spelling and typos
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.
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.
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?
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.
Edit: Changed author to contributor as it can be confused as the author of the article.
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.
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.
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.
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.
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.
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.
Which is a great point - how are we actually mentoring the junior engineers so that they can take over some day?
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.
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.
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.
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.
> 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?
Apologies.
What I have seen is people trying to fix a "great first issue" for the sake of contributing something, and not actually needing it or caring a lot about it. Many times the fix was obviously not sufficient, and I ended up spending more time reviewing and supporting the new contributor than it would have taken me to write the fix myself. That would be fine if those people became regular contributors afterwards, but they didn't, so I basically lost my time.
Really, the best contributions I have received were from people who actually needed them. And those people did not need an existing issue (with or without the "great first issue" tag) because they were the ones affected by it. For simple bugs they would just open a PR directly, for others they would open an issue offering to contribute and asking for help. I was always happy to help them of course: my point was that they did not need my guidance to find what to contribute.
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.
Is this a reference to the author? How can you tell that he has a fake degree?
"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
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.
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
It's hard for me to listen to anyone who judges people based on their Github repo.
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.
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".
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.
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)
Drive-by PR simply means that the PR author is not a known community member resp. doesn't plan to become a regular contributor.
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.
Even with free (in both senses of the word) products, the market will always work itself out.
Eh? This is more than reasonable. https://github.com/samuelfaure/
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.
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.
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"?
> 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.
> 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.)
The problem is the 'if' is a big barrier.
But hey, it triggered this HN discussion, and I see a lot of replies here which seem more useful for that kind of thing.
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