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.
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.
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.
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.
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.
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”.
> 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?
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.
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).
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.
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.
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).
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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)
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.
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
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?
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.
"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.
>> 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.
Yeah that's a good question. I am personally not a big proponent of those tags because "great first issues" are simple by definition, but if the maintainers did not fix them it means that they are low priority. Do you really need to fix a simple bug that hasn't been fixed in 2 years and that doesn't affect you?
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.
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.
"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
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.
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.
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
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.
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.
> 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".
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.
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"?
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.
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.
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.
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"?
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.
> 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.)
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.
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.
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.
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.
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.
https://en.wikipedia.org/wiki/Egoless_programming
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.
> 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.
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.
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.
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”.
> 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?
The contributions appear to be to Horizon EDA: https://github.com/horizon-eda/horizon.
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.
but this can be solved
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.
How do u think?
example: apply typo-fix PRs as commits by the maintainer, so that only those who are genuine will submit those.
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.
Do you recommend any bug report template?
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
respect
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.
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?
> 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.
Accounts aren't always faceless. They can have real names, long histories and connections to other profiles.
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.
After seeing several decade-long, slow supply chain attacks, maybe knowing who is contributing might matter a little bit.
Contributors are humans, so it doesn’t work like that.
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.
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?
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.
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.
Is that bad in any way? People do their projects for their own motivation. If nobody else cares so be it.
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.
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
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.
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.
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).
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.
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?
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.
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.
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.
Did you read the last 2/3 of the article?
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.
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.
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.
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.
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.
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?
Absolutely, but it does feel bad when you know your negligence is impacting real people.
If they really need it, they'll fork it.
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.
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).
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.
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?
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.
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)
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.
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
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?
Doesn't the same thing apply to corporate software? Pass a LeetCode hard and bring a backpack full of bricks, and go for it?
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.
"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.
>> 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?
Ah, this is my misunderstanding.
Apologies.
What about when the lead maintainer has written 100 issues themselves with clear instructions and tagged with “great first issue” and such like?
Yeah that's a good question. I am personally not a big proponent of those tags because "great first issues" are simple by definition, but if the maintainers did not fix them it means that they are low priority. Do you really need to fix a simple bug that hasn't been fixed in 2 years and that doesn't affect you?
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.
This is pretty much exactly what the article says.
We have a pretty different definition of the word "exactly", then :-).
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.
> 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?
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
Now that you post this it puts things in a totally different light
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.
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.
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
> 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.
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.
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.
> 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".
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.
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)
> 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.
My bad, I didn't know that that term was so established.
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.
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.
> an empty GitHub repo
Eh? This is more than reasonable. https://github.com/samuelfaure/
> 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.
Attacking the authority of people who start their article with an appeal to said authority isn't really far-fetched.
Another red flag is "I use Arch Linux, btw"
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.
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"?
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.
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.)
Yeah your right, after re-reading the article that was the point the author was trying to get across!
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.
> 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.
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.
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