[Length: around 900 words. Content: tips on contributing to OSS, because the world needs yet another guide to pitching in]
Getting started on open source projects can be intimidating. The questions abound: what project should I work on? What projects are in my preferred programming language? Will I be able to learn the new hot technology if I pitch in here? Will I get any benefit out this work? How much time will this require? Really, if you've ever considered contributing, you know that this list isn't even close to exhaustive.
Here's one thought on how to pitch in: just do it. Find your most local affiliate of Code for America, identify the project that's been most recently updated, find an issue, and just do it. Before you take up too much time on behalf of the project maintainers, your goal is to make a solid contribution ASAP. That means a feature, a bug fix, a documentation improvement - something that improves the lives and lightens the workloads of the primary developers - before you pitch in on smaller nitpicks like code style, commenting functions, etc.
Now, you might think that the slogan "just do it" is great for Nike, but it's actually a little deeper than that.
Indeed, I'd go so far as to call it - at least potentially - a basic psychological principle. The act of taking action, itself, generates desire and attachment to whatever action you commit to. It's incredibly easy, in our modern age, to get stuck in a kind of analysis paralysis, to get caught in the paradox of choice. So while "just do it" sounds like a silly pithy - and it is! - it's also a surprisingly deep, viable strategy for choosing how we all operate in this world.
Let's take a look at what this might look like.
Case Study: Delta Bot Three
Of course, the specific strategy I outline to making your first contributions will not necessarily be how it looks in the real world. So it goes.
That does not mean, however, that the "just do it" pithy doesn't apply. It does - it can just take a variety of guises.
Take my work on DB3, for example - a reddit bot that helps moderate the /r/changemyview subreddit (if you're not familiar with the subreddit, take a look - it's among the best online forums I've seen for tackling such subjects as it does). If you look at my PRs on the project, you'll notice that I started with a bug fix, made a few small improvements to the documentation on getting the bot up and running, and tried to keep my changes & communication levels down until I got to making a feature PR later.
I wasn't sitting there, taking up lots of time, trying to perfectly analyze where I might get started. I saw an issue, I tackled it, I moved on.
If I switch hats for a moment, to my own experience as a repository owner and team lead, this is exactly the kind of thing I like to see - someone new to the codebase getting down and dirty with the code and the real-world problems the code is trying to solve. This contributes a form of knowledge to the project that I, as the owner of the repo, no longer have - a fresh newbie look at the code! And it frees me of having to deal with a few small bugs, documentation issues, etc.
Want to know one extra tagalong feelgood to this "just do it" strategy? If you're successful, folks notice and want you to help more! It's a lovely, empowering feeling - that our work helped someone out. I shall remain grateful, in this project, to the subreddit moderator who kept us all devs engaged in working on the bot and moving things along.
Case Study: Yadaguru
At other times, the strategy works out almost exactly as described! So it was with this project. I live in Philadelphia, and lo, we have Code for Philly. After a quick pass through some of the active projects at CfP, I found Yadaguru, and I've been pitching in little bits here and there since then.
Yadaguru is a tool that helps high school seniors remember all the various deadlines they have for submitting applications to colleges. And man - there are a lot of steps! Certainly the process today seems both more electronic and - perhaps surprisingly - more complex than college applications not that long ago, in 2008, when I filed my applications. So I can see how this tool could be helpful to some folks, and it fits with the tech stack I know, and it dovetails with other things I'm doing these days.
And - did I mention? Bob - the project development lead - setup a great wiki page on setup instructions for the project. You don't always get instructions that high quality even in private industry.
Find a project - Yadaguru. Find an issue - "content on mobile gets cutoff during onboarding process". Then pitch in. Try to keep your mindset, and your changes, small, and just do it.
Wrapping Up
Remember - take action; just do it.
When you act, inspiration and motivation are bound to follow, and others just might notice. While there are no guarantees in life, when it does happen, it's an incredibly gratifying experience and is bound to get you hooked just a little bit more. I look forward to hearing your stories of your positive contributions to OSS and the world at large!