Why is contribution to open source important?

Simply, almost all important infra in the world runs on it… Linux. Without contributors these projects wouldnt be here, or atleast not as good as they are now.

However, this is on the global level. What does it mean to you to be an OSS contributor? Well it may differ between people but it usually revolves around these things:

  1. Its fulfilling
  2. Recognition of skill
  3. Fun
  4. Like minded community

How do you go about your first ever oss contribution?

Well I heard people say “Start with documentation!!!!” and I cannot disagree more :)

Their rationale is that as a new contributor no one will trust you to solve issues or look at your pull requests, or maybe its a good first hit of dopamine thats meant to give you momentum. But lets take a step back. Do they really need you for documentation? In this ERA of AI? I dont think so. Moreover, thats not even where my main issue lies. Momentum? The most boring software engineering task I can think of is documentation. Where is the fulfilment part? Fun part?

What I found out to work (For myself atleast)

Well first pick a project youre interested in. In my case it was Burn, the leading deep learning framework in Rust.

Then ask yourself: Do I know the language? If not, learn it. In my case 2 years ago I stumbled upon burn, but I couldnt understand anything because I didnt understand rust. The first year, I stopped midway. This year I made a 2026 resolution to learn rust, and I did.

After you have learnt the language to a level where you can understand the repo, do that! Go read it, until you can use the repo.

Then use it! You never know, you may stumble upon a bug, an unimplemented functionality you need, or a missing doc…..

Then try and solve that pain point, or atleast if you think the repo is useful, give back by checking the issues marked good for beginners.

Then contribute as much as you can.

pick a project you want to usedo you know the language?read it until you can use itnow actually use it, for realhit something that annoys you?fix it, thats your first PRgrep the good first issueslearn it firstmine took 6 monthsyesnoyesno

My first real contribution

I was trying to use argtopk for an int tensor, but I couldnt, so I checked the repo, and voila! My first ever contribution idea came.

What actually happened is that I called argtopk on an Int tensor and got a panic instead of indices:

1
2
3

let device = Device::ndarray();
let tensor = Tensor::<1, Int>::from_data([1, 2, 3, 4, 5], &device);
tensor.argtopk(3, 0); // unimplemented!("argtopk not implemented for ndarray")

My first assumption was that I was holding it wrong. Thats usually the correct assumption. Not this time. Burn puts every backend behind traits, and a trait method with a default body is free for all backends while a method without one has to be written by each of them separately. int_argtopk had no default, so four backends had “implemented” it with a panic. Its float twin, float_argtopk, had a default and worked everywhere.

Before opening anything I went digging through the history to see if that was a decision or an accident, and it was an accident. Both ops were added together with no defaults, a later PR gave the float one a default and cleaned up its stubs, and the int half was never touched.

After that the code was the easy part. Five lines, written to look exactly like the float version, plus deleting the dead stubs, a native override for tch, and three tests. Opened the issue, opened the PR the same evening, merged a day and a half later.

One detail I like: while I was in there I noticed argtopk was missing a row in the book’s tensor op table, so I added it. So I did end up writing documentation. One line of it, at the end, because I was already there fixing the actual bug. That is the right order.

What actually did the work

None of the difficulty was in the code:

  1. Use the thing for real. The bug found me because I wanted argtopk on ints for something, not because I was hunting for a starter task.
  2. Read the trait, not the error. The panic tells you where it stopped. The trait tells you why.
  3. Check the history before calling it a bug. “This is inconsistent with its float twin, here are the two PRs where the int half got dropped” is a very different sentence from “this panics, please fix”.
  4. Match what the codebase already does. My impl looks like the float one on purpose. Nobody has to review a new idea.

Not one step of that involved starting with documentation.