Contribute to Open Source without Being a Programming Genius (2012)
blog.smartbear.com
blog.smartbear.com
Many open source projects (definitely those at Mozilla) even have specially-labeled bugs in their database that are good for beginners. For example, in Servo we mark those issues "E-easy" and provide support for them on our IRC channel:
https://github.com/mozilla/servo/issues?labels=E-easy&page=1...
I know the Firefox team is even better than we are, with a split into Mentored bugs (with an identified owner you can contact for help!), Easy bugs, and Good Student Projects:
https://developer.mozilla.org/en-US/docs/Introduction#Find_a...
Rust itself also has its own E-easy bugs, many of which are in libraries that do not suffer from the same kind of heavy optimization that we've done in Servo:
https://github.com/mozilla/rust/issues?direction=asc&labels=...
I recently ran a questionnaire for potential and new open source contributors, pretty unanimously the responses were split between
People who havent contributed: had maybe tried, were nervous about getting started, lacked good guidance from the project and in general
People who had: Found life a lot easier once they got over the initial hump, were extremely grateful of the help they got, were hugely positive about the impact OS had on them
Did a small writeup about it @ http://arandomurl.com/2013/10/24/problems-getting-started-in...
I was originally planning to do a project to help first time contributors (goodfirstpatch.com), however realistically I dont have any time right now. I found openhatch.org to be a good place for people to get introduced, there was definitely improvements it can make but it was a real help for an open source workshop I ran.
Point is: I can work on documentation and bugs, but if you behave like an asshole, how can I even do that? People are not contributing much to OS because many programmers reject the idea of mentoring. But think about it: it gives you more 1 hr of mentoring and then 10 hours of work of an hobbist programmer or 1 hr more of programming?
E.G. the Ubuntu manual project at
looks like that on their mailing list...
So basically avoid the less responsive projects.
Ultimately if a maintainer isnt showing interest in taking your contributions then it just isnt a project you want to carry on attempting to, it takes some a little time and maybe experience to find a suitable project.
Certainly dont make sweeping statements about nobody contributing to open source because programmers dont like helping each other, there may be exceptions but the people contributing to OS is growing faster than ever
but sometimes the net cost to the senior/mentor person is actually negative, if the other party, the newb is sufficiently junior or incompetent. there are plenty of cases where somebody delivers one "fix" or "improvement" which then itself introduces other problems. save 2 hours, cause other people an additional >2 hours of work afterward, sometimes multiple of that. (time to add a bug? a few seconds. time to discover/home-in/fix/test that bug later? hours/days/weeks.) that's... not good. and experienced folks try to minimize it. the nice thing about the Internet is how we can all talk and learn and collaborate together more easily now than ever before. the bad thing about the Internet is folks who are still but wee infants, skill-wise, who, say 20 years ago would have had a long gestational period working in private and relative isolation, on their boxes before they emerged into the larger ecosystem (at a job or university, etc.) are instead often almost immediately jumping into forums, channels and repos and trying to "contribute" while they're still in that gestational stage. It's like there's now an army of cute fuzzy wittle lion cubbies who now try to tag along with the adult lions when the latter slink off to hunt for prey -- it impairs both parties and does not actually "help" either.
Finally, if a push from a total stranger can mess up your code base, I wonder if you know what you are doing. We do test driven development for a reason.
P.s. I am giving you an up 1 so I make sure you read this.
Also, not all projects have automated tests. Not all those with automated tests have 100% perfect coverage of everything that could possibly break. If anything I'd argue that the rise of unit test culture and TDD culture has actually increased the incidence of allowed sloppiness in some cases by folks having the mindset of, "I can deliver any diff I want. If no existing test failed, or the project has no tests, I did nothing wrong." This mindset too I've seen evidence of repeatedly.
And there's nothing wrong with a person being new to programming. I can only reiterate the core point of my original comment to which you replied.
Previously I'd always felt like I wouldn't know where to start or wouldn't be able to contribute in a meaningful way. In the end, I decided to just get over myself and do it.
I think everyone should try to aid open source projects in some way, especially when they use open source on a daily basis.
There is a huge disconnect in that these people don't feel empowered to jump in, fix those defects and make it the desktop they have always wanted. I think blogs like this will help point them in the right direction.
And that sucks. I don't even use KDE I just wanted to help, to not even get a "hey sorry we're full" or something, that sucks.
Like the article says, you can also answer support questions, report bugs, help manage bug reports (verifying reports, marking duplicates), write publicity blog posts, etc. These tasks are important and often understaffed on projects, and they help you become more familiar with a software project and more prepared to become a productive contributor to code.
I do non-code software work like that, and I've been happy to find a project that invited my kind of help: OpenHatch (http://openhatch.org/), conveniently relevant because it's about helping people who want to contribute to open source projects.
And it's not that easy to find a project, especially not for inexperienced developers. You don't want to pick an unmaintained project - you need somebody around to help you when you get stuck, ideally at least a few people so that you don't burn them out on answering questions. Hopefully you manage to find a project that has reasonably friendly people, some way to talk to them, a language you're familiar with, relatively easy tasks to get started with, and is interesting to you in some way - not really a simple Github search.