Ask HN: Best OSS Projects for Beginning Contributors | Hacker News Reader

Ask HN: Best OSS Projects for Beginning Contributors

55 pointsbegriffs36 comments

I am building a curriculum to teach people to code through meaningful, mentored open source contributions.

My first step is to find projects that would be a good fit. The students who are most interested are dev bootcamp grads who want to build portfolio pieces. They know the basics of (generally) Rails, Node and Git, but need experience in a bigger codebase than what you find in example bootcamp projects.

So what projects are appropriate? Is there a way to discover them algorithmically so that there is never a shortage of meaningful work for students?

I used the Github API to generate this list: http://upward.io/help

These are projects that have no readme, but have decent ongoing commits. What are other ways to identify projects that have low-hanging fruit for would-be contributors?

View on HN

I'm terrible at open source because I usually fix things that don't need to be fixed (aka refactor). Then people yell at me to go away.

You're dealing with terrible project maintainers then. Refactoring is super, super important and any project that rejects it must have a strange codebase.

Either that or the project owners/maintainers have a lot of pride.

That strikes me as a bit of an odd stance to take. While refactoring is certainly a portion of the work done to most any project, I wouldn't think that refactoring would be attractive as a first commit for someone who may be viewed as an outsider to a project.

Even if you overlook that getting code that matches a projects style guides might be rarer than it should be refactoring (at least in most cases that I need to deal with it) requires a good understanding of how everything fits together and a better idea of how it should work. There are some simple cases in which this might not be the case at all, such as grouping together a whole bunch of copypasta style code, but even under those circumstances any refactoring is likely to yield a fair bit of work for the maintainer to verify (regressions/style/changed organization) with fairly limited benefit.

As such it doesn't really seem that effective to try to impose something like this on a project without a good justification. If a good justification can be made, then sure refactor away, but otherwise the maintainer would logically think that the work was a waste of everyone's time.

From experience, I get really excited receiving small refactoring changes from newcomers, usually with the message "Hey this is my first time contributing to an open source project!"

I guess "small" is key. I agree a large refactoring would be troublesome to verify.

What does make a good first commit? I ask because I'm just starting to try to work on open source. The first commit I made on the one project I've already started getting involved with was adding more content (especially where there was a "TODO: more of this" comment), and correcting spellings. I wouldn't know how to start on something less content-based, though.

I'd say bug fixes, tiny typo fixes, documentation additions, unit test additions, performance enhancements, and relatively minor features are all good candidates. The actual scope of any set of changes that will be quickly accepted can vary wildly depending upon how well defined the project is and what group of individuals is maintaining it. I'd say the defining characteristics would just be easy to read the diff and understand how things are exactly altered and that the benefits are proportional to the risk and time for integration. An adequately written documentation addition for instance would be a easy to check for consistency and structure in one pass and the benefit is generally obvious after reading the diff. Large changes for a first commit can be reasonable, but some extra time has to be expected with some discussion on those changesets.

Docs are a good place to start. In the projects I've worked on, new contributors usually enter when they've found a bug/desired-feature and worked out a fix for themselves. Aside from that, good first commits are usually smaller, so it's easier to review, and address a single concern. After you get a commit accepted, you can start claiming commits.

Answering questions on Stack Overflow / mailing lists / issue trackers can be a good way to build up trust in your abilities and a working relationship with other contributors.

Often projects label things that are "good for a first commit" and you should check out those.

All that said, most projects are eager to include new people, and personally I enjoy helping new contributors feel comfortable and get their commits accepted.

Write tests.

Tests are a way to delegate trust. Instead of trusting the developer, you trust the code. It's a huge huge relief. If you can remove that burden from the shoulders of the maintainers, I guarantee you will be welcomed with open arms.

The side-effect is that you don't need to _add_ content/functionality, so the maintainers don't have to think about your new shiny feature. And if you fix something that was supposed to work in their own view of the project, then you start being noticed.

Or the refactor doesn't make sense...

http://tirania.org/blog/archive/2010/Dec-31.html - "Open Source Contribution Etiquette"

Every good open source project I've seen will happily accept and merge refactoring pulls, as long as the refactoring:

-Actually makes the code cleaner.

-Reduces redundancies.

-Above all, actually results in there being less code than there was before.

If you can achieve clean code + negative lines of code after a refactor, with identical functionality, they'd be fools to not merge it.

It's possible the refactors you submitted didn't meet these requirements. Or the project owners simply were too possessive of the code they wrote with their own fingers.

The project lead explained that he didn't accept unsolicited commits. My code ended up getting merged with some other guys refactored code which eventually made it into the code base.

> The project lead explained that he didn't accept unsolicited commits

Isn't that sort of contrary to OSS?

> Isn't that sort of contrary to OSS?

No, OSS is a licensing model not a development model. With OSS, if the existing project has a dev model you don't like, you can always fork it and start a project with a dev model you do; with proprietary software (even if the source is available), if you don't like the development model (among other things you might not like) you're, well, forked.

Code Combat (YC W14) is a game that teaches people to program. It's been entirely open sourced and the devs/community make it extremely simple for new comers to contribute. I strongly recommend you check them out!

https://github.com/codecombat/codecombat

You might want to take a look at: http://www.codetriage.com/ which is build precisely to help you find out OSS projects to contribute to.

OpenHatch tries to solve this problem - help people find a good project, and in general, make it easier for new people to get into OSS.

http://openhatch.org/

Helpful (http://helpful.io). Ruby on Rails helpdesk software trying to make things like ZenDesk & Desk.com suck less. Github: https://github.com/asm-helpful/helpful-web. There is always a list of things to do (https://assemblymade.com/helpful/wips) and a community around to help. We also share the ownership (and profit) of the app between the contributors. Anybody is welcome to be "Helpful" and join in building it.

Full disclosure, founder

This is not open source.

https://github.com/asm-helpful/helpful-web/blob/master/LICEN... ?

That looks pretty open source to me. It's not the most permissive license, but neither is the GPL...

From their license:

> Any redistribution or use is for noncommercial purposes only and is not redistributed or used in connection with any application that is substantially similar to the Selected App Idea.

From the open source definition [1]:

> 6. No Discrimination Against Fields of Endeavor

> The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

This is "visible source", not open source.

[1] http://opensource.org/osd

I would focus on larger, well known established projects covering a variety of interests. For me, personally, I wont get much out of just pushing code or documentation to a project I don't care about. Second to that, is not working with asshole. I'm not sure how I would script that.

OpenMRS was my first true OSS introduction, even though at the time I knew nothing about java. It's in my field of choice, and large enough I got some decent mentorship and appropriate projects. Doesn't hurt that they also regularly participate in GNOME/FOSSOPW, so I knew there would be people interesting and willing to mentor.

Large amount of stars/following with a handful (or less) of contributors?

Rebuilding dead projects from other languages into modern languages?

I was working on something similar and would like to restart my effort to get folks building up real projects. Perhaps we could work together if interested (unless you're driven by profit, which I am not).

What about contributing to writing docs instead? yes i'm serious. When it comes to writing documentation for opensource projects, suddenly,there is no developper available. Yet documentation is central to any opensource project.

Maybe I should launch a "Please write help us write docs" plateform.

This is ultra important! I can't even begin to count the number of times I've come across great open source projects with ZERO documentation. I tend to read the code (if the project is in a language I know well..) but that's not an option for many people looking to quickly integrate.

Maybe OSS contributions should actually start with writing the docs, sort of like how interns start with fetching the coffee ;) Of course, you can do more if you like but writing docs is a great starting point to learn more about the underlying code anyway!

PouchDB is a fairly up-and-coming JavaScript library, and the maintainer makes a good effort to mark issues as "goodfirstpatch" or "goodstudentproject": https://github.com/daleharvey/pouchdb/issues?labels=goodfirs... .

I've been on the project for a couple months, and I find folks to be very friendly and quick to respond on Github/IRC/etc. Plus it's part of the bigger Apache CouchDB ecosystem, so it's a good crowd to run with!

I have found the mozilla community to be very helpful and each project has a very good list of mentored bugs. The community has found http://www.joshmatthews.net/bugsahoy/ to be a very good tool for beginning contributors to get the right first bug and step into the whole community. Best way to get involved remains to ping to #introduction on IRC (irc.mozilla.org)

Regarding discovering them algorithmically tends to be quite an interesting idea actually, should think more on this.

A very easy way to contribute is to help keep jsDelivr updated. People can submit new libraries they find and update older ones (at least until auto-update will be ready) https://github.com/jsdelivr/jsdelivr

My approach is to work on bugs I encounter and that I am capable of fixing. So far that has lead to contributes to SimianArmy, Ganglia, Anemometer, and Logstash. Just be a good community member and get in where you fit in.

Hey begriffs!

I'm a volunteer with OpenHatch, which egor83 mentions below -- a non-profit to help people get involved in open source. At our Open Source Comes to Campus events, we aim to find great projects to connect newcomers with. (More info on the event series here -- http://campus.openhatch.org/ )

Your question struck a chord with me, since I think your curriculum and the curriculum we use for our weekend-long events would have some overlap: https://openhatch.org/wiki/Open_Source_Comes_to_Campus/Curri...

But the hard part is helping find great open source projects to contribute to.

To help with that, we wrote a guide for projects: http://opensource-events.com/

and are trying to reach out to project maintainers to help projects become "OpenHatch affiliated"; https://openhatch.org/wiki/OpenHatch_affiliated_projects -- maybe one great next step is to take this list of goals for projects, and work together in reaching out to projects to become OpenHatch Affiliated. Then you can have your students join the collection of people reaching out to those projects.

We find that having a specific person in the project care about the newcomer experience matters more than what we could find algorithmically. We still have the automated tool here: https://openhatch.org/search/ , in case you're interested.

Semi-sorry that this is a long comment, but I wanted to fill you in on a bunch of things, and I'm about to go to bed, so this has a higher chance than usual of being rambly.

OpenHatch-y people who care about outreach like this convene on the "Events" mailing list <http://lists.openhatch.org/mailman/listinfo/events/> and I hope you'll join us there and say hi! And/or reply with your thoughts here.

I'd love to collaborate on this, as it's something that we're always interested in improving for our students, too. I'm based in SF, in case you want to meet up for coffee etc.

P.S. The OpenHatch web app is itself is an open source project, in Django & Javascript, and we are always welcoming contributors. (-: Also, oppia is the project that we're furthest-along with in terms of OpenHatch affiliation.

Any of the KDE Community projects. http://community.kde.org/Getinvolved

We'd love the help on Huginn!

https://github.com/cantino/huginn

I would like to add a couple of filters to the OP (for personal use): The project is mainly in JavaScript, preferably uses Node.js

elementary OS, an Ubuntu based GNU/Linux distribution. We use bala for the programming language which is very similar to C# but compiles to C.

Most of the contributers are students including me and we have a very welcoming environment.

Just drop I'm #elementary-Dev introduce yourself and join the effort.

if you're interested in creating small, modular browser modules, feel free to contribute to any repo in https://github.com/component. most work with browserify as well, and bower support is trivial.

It's a pity you don't teach C++, the LibreOffice team are amazing!

Reply on news.ycombinator.com