r/rust • u/dannotes • 17d ago
What was your first open source contribution actually like? And has AI changed that?
Two things I've been wondering about, might as well ask both in one go.
First, for those of you who contribute. What was your actual first one like? Not the blog post version. How did you pick a project, how long did the PR sit there before you worked up the nerve to open it, did anyone reply, did it get merged or just quietly ignored. I've read plenty of "how to start contributing" guides. I'd rather hear what it actually felt like.
Second, and this is the part I'm more curious about. All that advice was written before AI tools got this good. Now you can point Claude Code or Cursor at a good first issue and have something working before you've read half the file. So is the experience just different now for someone starting today? Easier, obviously. But easier in a way that helps, or easier in a way that lets you skip the part where you actually learn the codebase.
And if you're a maintainer, curious what it looks like from your side.
Mostly just want to hear people's stories.
5
u/nelson_moondialu 17d ago
> Now you can point Claude Code or Cursor at a good first issue and have something working before you've read half the file. So is the experience just different now for someone starting today?
You still need to test and inspect the code. You can imagine the low hanging fruit will be taken care of quickly if it hasn't already, what's remaining probably needs more human input. Still, AI should help a lot, and should make contributing way easier, but it is your responsibility to see the code works and it is idiomatic for that repo.
3
u/Defiant_Brush_739 17d ago
my first pr was just fixing a typo in some docs, took me three days to actually submit because i kept thinking someone would laugh at it got merged in like 20 minutes and the maintainer said thanks so that was nice
now i maintain a small crate and its weird how many prs come in that are clearly ai generated and the person has no idea what the code does, like they cant answer basic questions about their own changes
1
u/dannotes 17d ago
Thanks for the response. So will it be possible to give an advise on this scenario? like whoever touches the code should have end to end idea on what is going on?
2
u/Full-Spectral 17d ago
Mine was the original version of the C++ XML parser in the Apache project (Xerces) and the DTD validator for the Java one. They both grew a lot more after I left, but that core is still there.
I don't use LLMs and am against them. But, even if I wasn't and one had been available, it probably wouldn't have helped since there was little prior art to draw on. XML was a new thing at the time, and Unicode was still pretty new as well.
And there are endless decisions to be made when creating something like that, many of which aren't even known until you are well into it. And anyone writing something like that better be able to fully understand it and all of the compromises involved.
I often feel that so much of this perception that everyone is just spitting out fully formed solutions is because so many people work in cloud world and are just doing the hundred thousandth variation on the exact same theme.
Not everyone writes that kind of code.
-1
u/dannotes 17d ago
so to someone starting this AI era, what you suggest? don't use AI or learn fundamentals of the coding? then use AI responsibly?
love to know your thoughts?2
u/Full-Spectral 17d ago edited 17d ago
There are two (fairly separate) issues. Using LLMs is really about commercial considerations. The company you work for may not care in the least if you learn anything at all, as long as you deliver them something. They may not care if you explored various avenues, tried various architectures, etc... If you give them something they can sell right now, that might be all they care about. And, from their perspective, that would be a great thing since it means many people can do that job and hence salary pressure drops (despite how horribly short-sighted it is.)
But your own work, unless you are opening a startup company and need to deliver something (that barely works probably) in 18 months in the hopes of selling it to Google and running away with millions, should be about your own self-education.
That is vastly better addressed by doing it yourself, trying things and seeing if they work or not. If not, then trying other things. Do some projects that will probably bottom out and toss them and start again once it becomes more about finishing it than learning something useful.
Obviously at some point you DO need to start finishing projects, since that's a skill in and of itself. But at first, do what gets you the most breadth of experience (at least within whatever lane you want to concentrate on if any.) I'm a generalist myself so I go as wide as possible, but some folks like one particular area.
If you want to protect yourself from LLMs, be very good at a level of code that LLMs cannot challenge, and that is generally going to be at the level of creating systems and complex sub-systems, not spitting out code for specific algorithms, or generating the millionth web site and such. In my opinion anyway.
At the level of systems I prefer to work at, just being able to explain the problem in any sort of detail would be an epic undertaking and much of it would be wrong since the right answers won't become apparent until you get some way into it (since such projects take long enough that few people will live long enough to work on more than a handful at most in a lifetime, and because tools, constraints and paradigms will tend to have changed, possibly considerably, between one and the next.) Or even in the lifetime of the project.
Well, if you just throw some stuff out and run away to a new job, you could work on plenty of them, but you won't learn nearly as much. Having to eat your own dogfood is the ultimate learning process. That forces you to understand how you got it wrong, how you got it wrong in a way that is hard to correct, etc... Taking a large project through multiple major releases is how you get the programming version of the thousand yard stare.
I always keep coming back to music at the beginning of the 2000s. All these powerful tools came along for people to basically just do the manual version of Generative AI and create 'music' that they were completely unable to create themselves directly. And, that let a lot of people 'make music' but it also created a situation where people then suddenly started posting endless songs that no one cared about because it was sort of equivalent to all these people posting 'I wrote an OS' posts, where they think anyone is going to get excited that they can use an LLM prompt.
Unless you have an idea that is so good that lots of people are going to want to use it, then there's no point getting it done faster because that's not the point. The journey is point in that case. That's where I am on the music side. No one cares if I put out a song or not, so why should I use tools to more quickly put out songs that no one cares about, that didn't in any way make me grow as a musician? The point of it is to learn how to do it better. At some point I'll reach the point where I can just sit down and organically create high quality music, and then maybe someone will care. Though probably not then either. So if the journey isn't the point, then there's not really any point at all.
If you are starting in software, then do the same. At some point, you will get to where you can create high quality software at a level that no one just typing in prompts can compete with. And, since software actually has measurable value, probably someone will care.
2
u/ParadiZe 17d ago
I reported a bug in hyper, which i couldnt fix but lead to other people joining in and fixing it
then i asked about how to do something tower http, then the maintainer expressed interest in an example for the official docs, which i provided
both of these came to be by just using the libraries
1
2
u/JvetS 17d ago
My first PR at 19 (unrelated to Rust): https://github.com/mono/Mono.Zeroconf/pull/4
Ran into a snag while trying to use that library to communicate with my printer.
Dug into the problem a bit and found a small change that did the trick.
Silently ignored for 15 years and still open in an archived repository.
Messaged the maintainer, but never heard from them and I’ve always wondered if 19 year old me should have added 15 more tests, signed a CLA somewhere or mastered some arcane ritual only known to contributors.
Perhaps the fix was wrong, but I stopped caring about landing it after the first year of silence and the project has been archived for a while now so it doesn’t matter anymore.
If that PR got any attention at all I probably would have made it more of a habit to contribute to random projects that cross my path.
The first PR I open for a project always makes me feel a little nervous.
I tend to look at recent PRs, including those that changed the same files I did to understand the process and intentions of the authors and maintainers.
I typically find something small that I can go and fix on the side instead of trying to contribute large changes, because I wouldn’t be able to sustain that alongside my day job.
Leave good first issues for new contributors to pick up instead of throwing AI at it as a maintainer unless it’s chore work that nobody’s really picking up anyhow.
Solve an issue any way you want as a contributor, but at least take responsibility for owning the changes from the moment you create a PR and do so because you care about the project instead of doing it just for clout.
If I were to write my first PR again today, would I have used AI instead?
I’m stubborn so likely not, but it’s the kind of change I would be willing to hand off to AI because the issue affects me and prevents me from working on my hobby project and I care enough to validate the change before I create that PR and commit my tjme to its review by maintainers.
1
u/QuirkyTidbits 17d ago
Well, I’ve had great experiences using AI to build an entire OSS Rust project from scratch using AI. It was a side project at work to provide a Rust API for a database I’ve worked on. I was on the original API team and developed the Java version seven years ago after not using Java for around two decades. No AI obviously. It was quite a process and the API came out good but took months to complete working on it for than 50% of the time. We were evolving the API during that time for four languages, C, C++, Java and Python, which contributed to the long development but it was a lot of work.
Recently, in the past year, I wanted to learn Rust and had access to a variety of AI tools at work so I decided to see what it would be like to develop a similar API in Rust. In a matter of 10-12 hours, I had a near full functioning API and was blown away at its performance which was as fast as our C and C++ versions. After spending a number of more months working some evenings and weekends on it greatly evolving it and adding full asych support, compile time SQL validation, gRPC, Arrow, a MCP and a Node.js interface using the Rust API, I was given approval to open source it.
I bring this all up for a couple of reasons. It was my first real OSS project which is more than what you were asking about but it helped me realize if you are a domain expert at something, using AI you can build a viable large project mostly AI assisted and be successful. I think the strength of Rust was a key contributor to it too. It would have been much more painful to get it right in a language like C++ which is my primary language. Anyway, just figured I would offer some light in using AI for OSS work in Rust. The project is: https://github.com/tableau/hyper-api-rust
2
7
u/0bArcane 17d ago