An Experience in Contributing to Open Source
stillflowing.net
An Experience in Contributing to Open Source
1–10 of 25 posts
Re: An Experience in Contributing to Open Source
#2Awesome dude! I've had similar experience and wish to echo this for all the hackers with questions about how to get involved.
Re: An Experience in Contributing to Open Source
#3I look forward to seeing your music site on Show HN sometime!
Re: An Experience in Contributing to Open Source
#4This is exactly how I felt when working with OSS. I wanted to increase my rep by contributing to OSS projects but most times I was looking for a problem that fits my solution. I was barely useful to a project as a result. Later on, I was working on a friends app (testing it) and I noticed bugs here and there. Fixed them and kept finding bugs on other projects that I was actually interested in.
Re: An Experience in Contributing to Open Source
#5That's precisely how I stumbled into LibreOffice :-)
Re: An Experience in Contributing to Open Source
#6That's pretty much how it happens, in my experience. Contributing to OSS projects generally happens when you need it, and often stops when you don't / it isn't your job anymore. My most significant contributions to projects always happened when I was using them in my day job. It's inevitable that a project will have bugs, or you'll want a feature it doesn't have yet.
I love it when people contribute instead of just opening issues; we're all busy, many of us maintain a dozen or more projects and it's hard to keep up when there is family, a day job, and so on. I usually merge PRs with passing tests within an hour - without tests, it could take weeks, and more open-ended "should we do X?" issues can be open for months or nearly a year.
I see this all over the OSS ecosystem in so many projects. The best way to keep a project going is to give a few people who are using it every day commit rights or encouragement to submit PRs as often as possible. If the main collaborators stop using the project, it can easily stagnate and die.
It's okay; generally, a project will eventually be picked up by someone else. All I ask of project maintainers is that they are willing to give the reins to someone else when it becomes clear that they no longer have the time for the project. Most maintainers are very good about it; some seem to have disappeared off the face of the earth. So it goes. You can always rename the project.
Re: An Experience in Contributing to Open Source
#7I tried to participate in 24pullrequests this year but failed on the first day for exactly the reason mentioned in the article; I was forcefully searching for issues to fix in projects where I had no real knowledge of the codebase, the procedures in place or the context of issues raised.
It feels like you'd need to have a wide breadth of knowledge of multiple projects to be able to submit a worthwhile pull requests each day for 24 days.
It'd be interesting to hear from people who did complete the challenge though.
Generally my contributions to other projects have been similar to the OPs, they've come naturally as I've hit stumbling blocks in third party libraries.
Re: An Experience in Contributing to Open Source
#8[deleted]
Re: An Experience in Contributing to Open Source
#9I've pretty much an identical experience; spent ages looking for open source Go projects to contribute to so I could a) improve my Go chops and b) finally contribute back after all these years. The feeling you get when your pull request is accepted with a big thumbs up is unlike anything I've had working as a developer during the day. I think it because you clearly respect the author of the project your contributing too (otherwise you wouldn't use the library in the first place!), and the acknowledgement that you are a "peer".
Just makes you hungry for more!
Re: An Experience in Contributing to Open Source
#10Reading this made me think about where the easiest place to contribute to OSS is.
Either you build code to hook up two things where there is no existing hookup (or do something someone else has done in a different language, framework, or you address a bug or add a feature to something you are familiar with. Occasionally there is low hanging fruit... like as I get better at languages, I can submit a pr for cleaner or more idiomatic code.
But honestly, If you want to make OSS better, don't code, clean, format and add to documentation/comments/examples/distribution methods. Because often useful code lacks the documentation that tells you what it does and how to use it effectively. Often it doesn't provide a simple explanation of how to install, much less a way to install directly.
The best way to get people interested in a project is to show how it can benefit them and make it easy to use.
If you are just learning, then reading and interpreting code is a skill you need to build, because much of professional software development is about reading and understanding existing code.