I really hope this some day becomes the standard Python interface to the system shell.
I also work with Mercurial and Octave. Mercurial is a very lively and smart community. We always need more contributors, and hg is of course less popular than git:
Getting practice working with existing projects or contributing to open source is a good reason to seek out projects to contribute to, and finding lesser-known projects takes a bit of the stress out of trying to learn by contributing to high-profile projects.
I'm also a newbie like the OP, and I would say that from the outside, those high-profile projects are pretty intimidating. I would also assume that most of the "low hanging fruit" has already been picked. What am I going to be able to contribute that somebody else hasn't already done better?
> finding lesser-known projects takes a bit of the stress out of trying to learn by contributing to high-profile projects.
Can you please explain this? I don't understand. Is the fear that, say, if I contribute to Linux and Linus absolutely hates my patch, he will make a huge mockery of me and the mockery might even end up on the front page of HN? Or are high-profile projects just in general very unwelcoming? I mean, Mozilla appears to be very friendly:
I honestly don't understand, because I just send my patches wherever I can send them, regardless of their social status. I have never experienced this kind of stress.
I think that high-profile projects have a necessary tendency to default to a fairly high bar for contribution quality and a more heavyweight process for how much testing/review/rework needs to be done to get the patch in. This flows from the fact that they have a lot of users (so regressions are bad and UI changes or new features need more thought/consensus) and often a high rate of patch submission (so maintainers can be short on time to help bring less-than-perfect contributions up to standard). Within that there are of course more and less friendly projects.
You're also forgetting the biggest thing, I think, standing in the way: Intimidation. Perhaps in their minds, they aren't expert developers, and are just learning, and therefore, their contributions to a very large project like Firefox or Linux would be unwelcome--as they probably are a little too scared to start. A self-confidence issue, as it were.
Through the lens of the internet, it certainly feels sometimes like everybody knows everything--you often forget that you're getting thousands of viewpoints rather than just one super programmer doing everything. I can definitely see how this would be intimidating for newer developers.
Cutting your teeth on obscure open source projects is a way to build up your self-confidence, work with others, and see your contributions make a tangible benefit.
These two things are exactly what I had in mind. Lack of confidence in your skills while starting out and a barrier to entry (my patch very well might break something else). Not that large OSS projects are unwelcoming, but a little bit of training goes a long way.
Another interesting thing about bigger projects is that there are lots of people who want to contribute to them at the casual level, which means low-hanging fruit gets picked off really quickly. You can't find an easy little pet issue and spend a couple weeks working on it, because it's likely someone will come along and do it before you.
As a counterpoint, larger projects will have new contributors coming along more frequently, so they may be more ready and able to help the inexperienced contributor. That’s my observation in the Rust community, for example.
In a less known project, it is really easy to find an issue where I can be useful. They have lots of created issues and nobody working on them. If I understand the issue, I can just dive into the code and make a patch.
In a large project, in some cases it is even dificult to know where to start. Mozilla definitely did a good job to mitigate this problem.
Most high-profile projects have many contributors and change very quickly. Several years ago, I submitted a bug fix to git at the same time that someone else submitted a better fix for the same problem. (Junio Hamano was very nice about it.) I eventually dropped off the mailing list because that had too much traffic to follow while I was working.
Also, because of the high volume, they don't have a whole lot of time for hand-holding. I submitted a pull request to Rust which was approved but failed to auto-merge for some inexplicable reason and languished until someone cleaned up the queue. I never found out what the problem was. (And tracking master for tests, given how long it took to build, is Sisyphean.)
I try to "handhold" newbies to Rust if I notice a pull request from someone new (and I know a few other reviewers who try to reduce "jargon"/expand explanations for PRs from new people); you must've been one of the ones unfortunate enough to slip under the radar. Sorry! :(
FWIW, if it was an automerge failure (rather than a test failure), that just means there were merge conflicts which git cannot resolve automatically, and just requires rebasing the PR. (I believe Github's interface for displaying when a PR is stale has improved recently, so hopefully this situation is now less confusing!)
The list is composed of packages that need Debian maintainers for whatever reason. I realize you're looking to contribute to developing software rather than packaging it, but there may be a correlation between projects that need packagers and those that need developers.
Quod Libet [1] is a mature but "lesser known" audio project written in Python and GTK+ (3).
Whilst there are probably some quite high barriers to entry (the user community is very tech- and music-savvy, the project is fairly feature-complete, and the codebase quite complex), we're fairly welcoming and try to take care of our (large) backlog of tickets whilst welcoming useful contributions where possible, or at least discussing / explaining their considered rejection.
In particular, we could really do with a dev (or in fact buildmasters / testers) who are Mac-based ideally with some knowledge of building and testing Python and GTK+ apps on OS X. Probably best to email the list for further details.
openstreetmap, a global project, could really do with some more developers. for example, we still need a reporting framework that displays a dashboard of stats. many other projects can be found here: https://github.com/osmlab
A good open-source set of tools to assemble good dashboards and reporting would be useful in many areas, including the work I am involved in. We are looking at building some of this ourselves at the moment.
NuPIC: https://github.com/numenta/nupic.
Numenta Platform for Intelligent Computing: a brain-inspired machine intelligence platform, and biologically accurate neural network based on cortical learning algorithms.
About two years ago I got a contract to work on one project that needed to integrate a web service with a mobile app that was using Parse. I looked into the client libraries and the current one for Python was lacking. David Robinson[1] forked it and was trying to revive it somewhat[2]. I got to take a good look at the things I thought were missing and were needed to my project, and started submitting patches.
David is super open to new contributors and no contribution is too small. "Real work" stops me nowadays to contribute some more, but I sure know how good it would be to have a couple of more people focused on completing feature-parity with the API.
I don't believe Strider[1] is very well known. At least, I don't see discussion of it often despite over 1k stars on GitHub It's a continuous integration/deployment server written in JS, but with support for building projects in many different languages.
One of the cool things is that it's very easy to deploy on Heroku so you can have your own private CI server up and running in a few minutes. That said, there's tons of room for improvement, especially on the side of language support, so more contributors would be awesome :)
For the mc geeks, two node.js projects: nmp and mineflayer.
(1) NMP: node minecraft protocol
(2) mineflayer: minecraft bot API
The first project is what mineflayer uses to communicate with minecraft servers, and it's usually behind when a minecraft release comes out.
The second project is a bot API that uses it, with some interesting plugins (such as navigate, that uses the A* algorithm). Some of the things that are missing from that project are higher functioning routines, such as inventory management, a flexible work queue, a command control panel.
Some of the nasty ones are challenging, but a typical website takes only an hour or two to write the script for. So it's not as if you have to make a big investment in time.
I recommend trying to find something that you would want to use yourself to work on.
I have a neglected project at work - The Mechanical MOOC (https://github.com/p2pu/mechanical-mooc/) is a tool we use to run signups and mailing lists for large online courses.
Have a mac? I'm looking for help porting Trelby to it. I can guide/assist with anything in the code. You'll need to figure out the mac specific parts.
http://trelby.org
Contact me offline via email if you're interested.
I don't have a Mac, yet I maintain an OS X port of the TXR language. I use a VirtualBox image running 10.7.3 (Lion); host OS is Windows 7, currently. Initially, an interested user was doing the port by himself. To do it right and maintain it going forward, I grabbed a VM and took over.
Every time I make a release, I build seven binary images (all Intel): Windows (via MinGW and Cygwin), Ubuntu, Debian, Solaris, FreeBSD, and OS X 7.1.3. The regression tests have to pass on all of them. Only the Win and Deb are rolled using real machines; the rest are VM's.
Opencart? It's a very neat ecommerce solution but could still benefit from a lot more development. Eg proper eBay integration, improved reporting, responsive design...
beets? the media library management system for obsessive-compulsive music geeks.
New contributors are always welcome to tackle the growing list of issues/wishes <https://github.com/sampsyo/beets/issues?state=open> !
ownCloud is a great project. We use it in our organization across all client machines.
That being said: I've found it very difficult to contribute to the project.
I've had multiple pull requests languish for months. Currently, there are 10 open pull requests that have not been touched by the devs in months (some are from January and earlier).
However: don't let that stop you from trying to contribute! :)
I saw a presentation by some of the ownCloud team a few weeks back. They seem to be pushing pretty hard to get the new version delivered, maybe thats why pull requests are languishing. Now that its out...
I work at a school district in central Pennsylvania.
All of our staff (teachers, secretaries, custodial, etc) use ownCloud as a backup and recovery solution.
We chose ownCloud because it allows us to keep confidential records on our own servers, something that Sugarsync, Dropbox, etc did not allow us to do.
Thanks! I was wondering if it supported aggregating the extra/unused storage of all the client desktops, but it sounds like you are using it for the server stuff.
That being said, I have one project that I really would like to see thrive: sh (and perhaps give it a different name)
http://amoffat.github.io/sh/
I really hope this some day becomes the standard Python interface to the system shell.
I also work with Mercurial and Octave. Mercurial is a very lively and smart community. We always need more contributors, and hg is of course less popular than git:
http://mercurial.selenic.com/wiki/ContributingChanges
Drop by #mercurial in Freenode if hg seems like your thing.