Ask HN: What are some open source projects that a beginner can work on? | Hacker News Reader

Ask HN: What are some open source projects that a beginner can work on?

131 pointsthatsnotme77 comments

Please link to the GitHub pages or the repo page, and also mention the prerequisites.

The answer is "all of them!"

ESR wrote "Every good work of software starts by scratching a developer's personal itch." You'll be much more effective working on a program that you use and want to make better, compared to a beginner-friendly project that you have no interest in.

Instead of looking externally for projects, look inwards. Think about the software you already use, and how it could be better: that stupid annoying behavior, or that obvious improvement, or your idea for a cool feature. And then set your sights on that!

An example: I was a big fan of the game Angband, which I played on Mac OS 9. When OS X came out, I wanted to play Angband again. So I "carbonized" it, so I (and others) could play it on OS X. I had never carbonized a program before, and that's how I learned.

I apologize for not really answering the question, but I have known aspiring programmers give up because they got bored. "Not being bored" is really important, more important than "not being frustrated."

This is seriously not true.

I've had experiences of projects I tried to get involved because I liked the software but where the maintainer had zero interest in involving any new people. It's lovely that developers scratch itches and create cool software - there isn't anything that implies those same people want to work with other new people.

I'm glad you had a good experience and maybe I was unlucky or whatever but I don't think mere interest in the software is enough, the project has to be in a state where the developers want other programmers involved (lots of projects would like some testers and documenters but nothing else and to an extent understandably).

I mean, I'm not sure why guidance towards accessible projects is a bad thing.

Edit: Oh I knew I'd get reactions. Counter-arguments? A lot of professional software teams have a hard time adding new people. Why would any old open source project be easy to get involved with?

Edit2: I love the idea of open source, I want to get involved again in a larger project when I have time but the "no problems" guidance approach seems itself a problem. Lots of projects are even infamous for problems. There's clearly more to what project you'd be a fit for than "what you love" and just leaving that as the advice seems like a characteristic problem of open source itself.

Well, the idea is that if you start working on a project specifically because it is noobie friendly you are likely to burn out quick since you don't have that itch you are scratching.

I think the parent is correct in that you should try to work on projects that scratch an itch. If it turns out it is a hard community to work with then fork it or move on to your next itch.

If it turns out it is a hard community to work with then fork it or move on to your next itch.

Some people might unlimited energy to program and infinitely thick skin. I think a lot of people find putting energy into a project that rejects their efforts to be somewhat traumatic and something that can impel them to give up rather than bounding on to this next adventure.

I agree that getting involved with a project that interests you should be one factor in choosing what to involve yourself with. But the OP said "any of them!" concerning what project to get involved with where as I'm arguing one should be selective and that people involved in Open Source already should be giving some guidance on the question beyond just "whatever you want".

I think this is a bit of a non issue. Wouldn't a bad community or developer become evident when you started looking around at how to help and contribute to the project?

Just recently I decided I was bored with my routine at home and wanted to challenge myself. So I set a task: pick a public repo that I don't already maintain (preferably that I use), find a bug I would like to see fixed (emphasis on would like to see the bug fixed), and to fix it.

I ended up choosing a program that I use but is written in a language I'm not familiar with. Regardless, I jumped right in.

First I looked around for any mailing lists or chat rooms where development discussion is carried out. I joined and asked how I can help, and was directed to the bug tracker and told to go nuts. I can see how this can be a daunting task, but I found the easiest way forward is to put those feelings of being overwhelmed aside and to just start. I cloned the repo and grepped for a tag I hoped would get me to the code I needed, luckily it was a good guess.

I spent the weekend reading the code for no less than three different projects and learning a lot about erlang, and by yesterday evening I had a patch created and a pull request submitted. And I feel fantastic for it and am looking forward to setting a similar challenge next weekend.

My point is that I think part of looking around the project and bug tracker should help you figure out what the attitude of the Dev team is like. I don't doubt there are sour devs our there but IMO they are few and far between, more likely is the unresponsive maintainer who lost interest in the project but still has the keys to the kingdom.

What's the worst case scenario? You create a patch and the project maintainer refuses to merge it? If he doesn't provide good reasons for not wanting to merge it, he looks bad. If he says your code quality needs improvement you can ask for specifics and learn some new tricks. If he says he just doesn't want that feature then leave your code up on github and see if other people start advocating for having your issue merged. This seems like a tempest in a teacup to me.

When you are just starting out, you don't know what is normal and you can't tell whether the project is poorly run or whether you are just bad at programming and should give up.

I think if you don't know what's normal yet, set the bar.

What I mean is, when you're trying to contribute, how do your interactions with that project and the developer(s) make you feel? At the end of the day, if you're not enjoying yourself and what you're doing, drop the project and find something you enjoy. Might be a different more-receptive project, but it might be a different hobby too, I would encourage you to try multiple project before giving up though.

> "if you don't know what is normal yet, set the bar"

What do you actually mean by this? I'm pretty sure I'm misreading you here.

What I'm reading is "when you come into a new organization and you see people doing things that make you feel bad, force them to change their culture." However, arguing against that feels like arguing against a strawman because it seems obvious to me that you can't effectively change an organization as a random novice and that trying to do so is going to make people really dislike you. Even if it would happen to work, doing it requires being the sort of person thats willing to be called an asshole.

Your level of energy for programming does sound pretty impressive compared to mine. I will admit that if everyone else has energy to churn out patches willi-nilli, worries about whether they would get pushed would not be a non-issue. I'm not so sure that's true, however.

the simple solution is to email the maintainer and ask if they're accepting contributions before you start working on things.

This is a good idea, but be sure to clarify that you are a beginner and are looking for mentorship. Otherwise you might get a response that contributions are welcome, but no guidance.

A problem is that for many projects, the maintainers don't bear any cost when someone new tries to join a project, invests a bunch of time+effort and ends up nowhere. Therefore, even if they really don't have time, energy, or inclination to spend time mentoring, they can just say "welcome to the team" and toss the new member into an ocean of code to sink or swim. Some will in fact swim. Conversely, if they do spend a bunch of time on detailed mentorship, the new contributor doesn't have to stay

Another problem is that

Absolutely,

My point is not that every programmer should be welcomed with open arms by every project. There are go reasons for the projects themselves to be selective.

But that is not a reason for a would-be contributor to be unselective themselves. It's a reason for a contributor to also be selective and not just choose any project that suits their fancy. This is my point.

I strongly agree with you. I think that selectivity should be explicit and that there are currently incentives for maintainers to merely implicitly and quietly be selective

> I've had experiences of projects I tried to get involved because I liked the software but where the maintainer had zero interest in involving any new people.

That's absolutely true, but, given that this is open-source, there's always the option of maintaining it yourself. Of course, for someone who's an absolute newcomer, it's better with a buddy.

Tell you what. I'm interested in projects in C or Python doing systems-y things and that can be compiled on Debian (think stuff in the space of GLib, NetworkManager, apt... but also anything tinier, obviously). If you find a maintainer who's wholly uninterested in adding people, you've got a new feature you want, and you want someone to work with, shoot me an email, I'll probably be up for helping out with it.

Chances are that the maintainer will be interested in the feature, just not in mentorship. And even if the maintainer is just antisocial, chances are maintainership will change, or the world at large will benefit from a fork, or the Linux distros will be willing to take your patches even if the original maintainer isn't.

You need motivation of some sort to create a feature or fix a bug. Whether it's a monetary reward, notoriety, or your own need for the feature.

I strongly recommend trying to contribute to a project that you personally use. Once you've been using it for awhile, you'll be better equipped to make changes to it + you'll maybe find bugs that you can fix. While you're doing this, mark yourself as a watcher of the project on Github, that way you can see bug reports come in and maybe fix them.

You can try to contribute to just any project someone here suggests, but I find it hard to get motivated + be skilled enough in that language/project to just start contributing. Can you talk about your current skills and what kind of languages/libraries you're using now, or are interested in learning?

I know C and also Javascript/jQuery/CSS/HTML and I want to work on a project, so as to apply what I've learnt into something that is actually useful.

I strongly agree with MaxGabriel. I find it difficult to make meaningful contributions to projects which I don't use or have some familiarity with. I am significantly more motivated to make contributions to projects which I have invested my time in.

My advice is to start small. Look into making documentation updates and fixing bugs you find in projects you currently use. Expand your open source toolset as you build more and repeat the process.

I see a lot of good general advice, but not too many specific examples. Here's a very specific one...

If you want to do C and get an introduction to a bit of arm assembly, you may want to contribute a new model build to CHDK, the Canon Hack Developer Kit. There are always new models out that need support, like the Canon PowerShot Elph(US)/Ixus(EU) 160.

See http://chdk.wikia.com/wiki/Category:Porting for some hints to get started.

The CHDK core devs are really friendly and often available on IRC and forums. That helps a lot.

Does anyone have a good writeup on the workflow for contributing to open source Python projects? I often fix small bugs, but it's a pain because I usually install via pip, then when I realize there is a bug, and fixing it myself is the fastest way to resolve it, I have to go out of my way to do so. I have to remove the pip package, fork the original repo, clone it into the repository of my current project (where I would rather it not be) and load it directly as a module. Then I can edit the source code, find the bug, fix, commit, and pull request. But at that point my project's code depends on its own local copy of the buggy repo until the upstream repo finally merges the fix (if ever).

If anyone has a better workflow for fixing ad hoc bugs you discover while integrating an open source library into your project, I would love to hear it.

If you have a public repository anywhere (e.g. you've forked a project on github) then you can add a specific git commit to the requirements instead of pypi version.

See https://pip.pypa.io/en/latest/reference/pip_install.html#vcs...

Exactly what I was looking for. This is why I come to HN. Very clever. Thanks.

The Servo project[1] has a constantly maintained list of bugs and features appropriate for new contributors, and several people willing to mentor if needed.

There is so much low hanging fruit building a new browser engine, that there is plenty of stuff to work on even if you aren't yet an expert on browser engines.

Also, you get to use a new programming language :)

[1] https://github.com/servo/servo

I would look at the list of projects Google has accepted for Google Summer of Code (https://www.google-melange.com/gsoc/org/list/public/google/g...). They should all be mature enough to have established protocols for newcomers, and with luck they'll be friendly enough for you to feel welcome. (Drupal is on that list, and as a contributor I can certainly vouch for it in both those areas.)

Even better, I would recommend looking at the Google Code-In organizations. Those communities are specifically set up to deal with new inexperienced contributors whereas many GSoC orgs simply are not: https://www.google-melange.com/gci/org/list/public/google/gc...

The GCI orgs all have loads of tiny tasks spelled out that can be completed in less than a day too.

I have an online friend who contributes to firefox. They are fairly beginner-friendly, though you probably need to have some C++ skills.

https://www.mozilla.org/en-US/contribute/

I contributed to Firefox. The Mozilla guys are awesome.

But if you are used to Github/PRs their Bugzilla/Hg-Patches workflow feels like going back in time... way back to the old days.

Ignore anything about MQ. They have old docs on using MQ that we've been trying to wean them away from.

Modern hg is far better than MQ, and in some situations, better than git. You can edit, you can rebase, you can amend, you can evolve.

MQ?

Mercurial queues. I thought that's what you meant with "patches".

Ah yes. MQ was the plugin used to create those patches, now I remember.

They stopped using? Even on the main Firefox repo?

Like git, Linux, Mercurial, and gcc development, they have a patch-based code review flow, but MQ is not needed to produce the patches that they expect. You can do the same without MQ, and they will never know the difference on their end.

I actually rather like email-based code review. It's really easy to keep editing and rebasing your patch while people comment on it. If Mercurial Evolve picks up, this will be an awesome new way to work, especially if Kallithea or Bitbucket grows the features to support it.

However, current Mozilla development, AIUI, is moving towards ReviewBoard, although I have heard a growing mutinous group in Mozilla who just wants to chuck all homegrown solutions and slap all of their code on github like everyone else.

We know. One of those things that was established 10+ years ago and has a lot of built-up inertia keeping it going.

It's part of my job role at Mozilla to bring this process into modernity. We're getting there. Slowly. GitHub pull requests will be supported in some form. Hopefully by July.

You absolutely don't need C++ skills to contribute to Mozilla. They are of course required to contribute to gecko, but that's only one possible contribution option. Others are:

* Firefox UI and devtools. Written in a combination of js, HTML and XUL, with some C++ in the backend.

* Automation and tools. Mostly Python-based, this is the infrastructure used to test Firefox and related projects.

* Servo. The next-generation browser engine being written in Rust.

* Gaia UI. The Firefox OS interface and associated apps. All written in JS + HTML.

* Firefox for Android UI. Written in Java like other android apps.

* Various web tools. Typically written in HTML + JS + Python, but backends differ (there's an increasing amount of node.js, Bugzilla is in Perl, etc.)

* QA and testing. Writing testcases for the web platform and other browser features. Typically requires HTML and JS skills, and well as the ability (for Platform tests at least) to read specifications.

* MDN. Documentation of Mozilla projects and the Web platform. Requires writing (not necessarily in English!) and good technical understanding.

That's just off the top of my head, I'm sure that there are a bunch more projects someone will be annoyed I've missed ;) There's a more detailed list of the projects by technology at [1].

I like to believe that Mozilla is quite good at welcoming new contributors; it's certainly something we work at, although there are of course always opportunities to improve. There's a page of getting-started tutorials at [2], a database of bugs with assigned mentors grouped by technology at [3], and a dedicated irc channel #introduction on irc.mozilla.org.

It is true that not every Mozilla project uses a familiar GitHub workflow, but it true that many recent projects do. For example Servo and Gaia are both fully GitHub-centric. For the more aged projects using Mercurial, we are in the process of moving from a patch-based workflow to a more modern branch-based one, with review in ReviewBoard. So there is still a learning curve there, but it's at least getting better.

And finally — because this is my own special interest — if you are tired of web browsers having troublesome incompatibilities and want to be part of the solution, consider contributing to the open-source web-platform-tests testsuite at the W3C [4], [5]. This is a expanding repository of tests covering the open web that are being run against every single commit to Gecko (and Servo!) so that the developers are aware of implementation errors before they become interoperability issues.

[1] http://www.whatcanidoformozilla.org/

[2] http://codefirefox.com/

[3] http://www.joshmatthews.net/bugsahoy/

[4] https://github.com/w3c/web-platform-tests

[5] http://testthewebforward.org

http://www.openhatch.com A website for ongoing opensource projects in python.

They're a great resource, not limited to python projects though. Besides providing help on choosing a project, they also coach you on how to approach an open source project and what to expect in the open source world. They have a bunch of talks regarding the same which are worth checking out.

I find Mercurial very easy to work with. You just need to know some 2.x Python.

Here's the repo:

http://selenic.com/hg

And here's their list of easy bugs:

http://bz.selenic.com/buglist.cgi?keywords=easy&list_id=5790

Contributor guidlines:

http://mercurial.selenic.com/wiki/ContributingChanges

If you're interested, I could mentor you through some of it.

Edit: Oh, and this appears to be our April Fool's Prank:

https://www.youtube.com/watch?v=qtAuQXeQrMQ

Ned Batchelder has a good page with "Kindling projects" http://nedbatchelder.com/text/kindling.html

The Assembly (http://assembly.com) community is a great way to get involved in building products. The community builds businesses together, and everyone shares ownership based on what they've contributed. (also, it's all open sourced under AGPL).

It can be a great way to expand your skills as a developer and also to gain experience working with designers and solving problems around growth, product positioning, pricing, and all sorts of other things.

[disclosure: I work at Assembly -- happy to answer any questions: austin@assembly.com]

Ruby gems are a good example, especially gems that provide hooks into an API.

Even if you're just adding another parameter to an existing endpoint (which is largely a copy/paste exercise), it's a great way to learn the structure of a gem, learn your way around API documentation, and check out others' best practices and unit tests. I contributed to the official Instagram gem during my first few weeks of learning Ruby.

https://github.com/Instagram/instagram-ruby-gem

Prereqs: Ruby, API basics

Start with a project you use or depend on in your own projects. It's probably best to start by enhancing or adding a feature on that project.

Other things to look for is a project that is managed by people who a receptive to pull requests and have accepted them routinely. Also look for projects that have lot of issues open and closing on a routine basis--this will mean the project is in active development.

This will keep you motivated and provide you with some good mentors who may accept or suggest improvements to your pull requests.

Along the way you will probably learn about forking repos, writing good commits, sending pull requests and most of all, contributing code.

More mature projects have a lot of tooling such as running unit tests, adhering to coding standards, etc which can create hurdles to entry bfor beginners but if you do venture forth with these you'll develop some great habits.

The open source projects that participate in Google Code-In (GCI) cater to beginners with little to no experience: https://www.google-melange.com/gci/org/list/public/google/gc...

For GCI, they have to maintain lists of tiny tasks that can be completed in just a few hours. You don't have to be participating in GCI to work on those tasks. They will also have people in their community interested in helping you.

Source: I'm the admin for one of the GCI orgs.

I am the author of pgcli. (https://github.com/amjith/pgcli/)

It is written in Python and it is being actively developed.

You can find some notes on getting started with development here: http://pgcli.com/develop

It is a command line client for Postgres database.

I'll be more than happy to answer questions or help you get started. My email is amjith.r [at] gmail.

Feel free to get in touch.

Mozilla.org is always looking for web developers to contribute and beginners are always welcome. This wiki page gives an overview of how to get started and a list of "good first bugs."

https://wiki.mozilla.org/Webdev/GetInvolved/mozilla.org

If you read something in Pro Git that could be better, or if you find a mistake, we're taking contributions at https://github.com/progit/progit2. The only requirement is that you agree to license your contribution under the CC BY-NC-SA license.

https://www.openhub.net/ it's a great site to search projects in any language

This Hacker News app for Android is relatively small and readable, plus it would be great to get some more contribution going.

Look into it.

https://github.com/dinosaurwithakatana/hacker-news-android

http://www.freesbd.org/ A fun open source operating system.

Some C knowledge required.

Your link is off[1]. For their guidelines on submitting and viewing existing bugs start here[2].

http://www.freebsd.org https://www.freebsd.org/support.html

You say some C knowledge required when we are talking about a complicated UNIX kernel.

right..."some"knowledge is really required...

There is a userspace too, if you find kernels scary. In reality though, the kernel is simpler than userspace in some ways.

The website could also use work. That's HTML/JS, you don't need kernel or C experience.

For GitLab we have a list of items that are marked 'accepting merge/pull requests' on http://feedback.gitlab.com/forums/176466-general/status/7964...

There are more than 180 items, including things that should be relatively easy for a Rails programmer. For more information see https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBU...

http://www.codetriage.com/ lets you view projects by the number of open issues. I'm not sure how to gauge the beginner-friendliness of the projects.

We are building a collaborative platform for creating open educational resources, called Crowducate. We have many ways to get involved such as testing, planning new features, outreach, translation, and a few JavaScript tasks.

Our sourcecode is on Github:

https://github.com/Crowducate/crowducate-next

Planning documents are on Hackpad:

https://crowducate.hackpad.com

I sometimes put a `help-wanted` tag on GitHub issues I think are especially well-bounded items someone could contribute. It looks like other people use that tag, too: https://github.com/search?l=&p=2&q=state%3Aopen+label%3Ahelp...

You can further filter that by language, or other criteria.

My first experience with an open source project was just a small github repo for a library I wanted to use. I noticed some TODOs in the code and fleshed them out. Even now, the repo only has four contributors, but the others were quite helpful when I had questions.

I have yet to move onto a big project, but it was a nice introduction to that kind of distributed coordination needed for open source repos.

I strongly recommend taking a look to bugs ahoy maintained by some amazing people at the Mozilla Foundation. It's a great way to start contributing to a large codebase by solving some "easy" bugs. Check it out http://www.joshmatthews.net/bugsahoy/

One thing a lot of people don't realize is you don't have to be a developer to work on open source products. You can do design work (logos, branding) and lots of other stuff. Documentation is endless, and not just technical documentation there are a lot of features that just need to be explained in plain English (or plenty of other languages as well)

I'd suggest projects based on Javascript or a similar easy to learn language, which lowers down the barrier to entry. You may want to check Countly (http://github.com/countly/countly-server), a mobile analytics and push notifications platform.

I agree it can be difficult getting into the social conventions of a project.

I try to keep a list of places that people can contribute effectively in the readme for my project. https://github.com/Semantic-Org/Semantic-UI/#places-to-help

If Python is your thing, I found the code for the Graphite software easy to browse through and understand. https://github.com/graphite-project

As a bonus, it's a tool that will come in handy for future projects, whether as a nice-to-have or as a core part.

I've had a lot of fun working with Code For America brigades. It's social, low pressure, very newbie friendly, and a great way to meet other people who are passionate about tech.

http://www.codeforamerica.org/brigade/

I was asked this same question awhile back and I recommended Fluentd:

https://github.com/fluent/fluentd

It's in ruby, very easy to understand, and also extremely useful.

You can also extend it with plugins, which is simple for a beginner to pick up.

I'd first learn git basics and start my own 'testing' repos. Then, I'd start contributing to certain frameworks, libraries, modules/gems I use in my own side-projects.

Regardless, the rule of thumb is to not be afraid of contributing. As a beginner, that's usually the biggest issue.

Web2py Python framework was in fact originally created by a professor to assist in education. I'm a total novice and my contributions have been welcomed warmly.

https://github.com/web2py/web2py/

This could be a pretty good idea for a recurring post, a la Who's Hiring. Probably less regular I guess.

If that is something that interests you, I would recommend Django and it's "easy pickings":

https://code.djangoproject.com/query?status=!closed&easy=1

https://github.com/kevinohashi/php-riot-api

Like League of Legends? Enjoy PHP enough to contribute? Right now it's a very simple wrapper, there's few outstanding issues. It could use better documentation, examples, a global rate limiting queue and more functionality could be added. It's mainly just me maintaining it, I get a few contributions here and there. I'd love more developers who are interested in building LoL sites to use and help extend/maintain it.

GovCode helps you find US Government open source projects at https://www.govcode.org/

You can filter by language and see open issues.

If you have some knowledge of web-apps, you can work on:

https://github.com/autolab/Autolab

Anyone interested can reach out to us at Taiga.io, we've built an Open Source, Free agile project management tool. We were named lat year as one of 2014's top Open Source Tools by opensource.com (http://taiga.io) and our Github repo is here: https://github.com/taigaio.

Is there a reason you want to work on an open source project?

If you're a beginner, why not start your own project based on something you personally need?

What are you interested in? What languages have you used before? What OS do you run on your desktop?

Come and work on mine. Realty Manager on Github

hedgewars.org

So many years of fun from this game.

Reply on news.ycombinator.com