How do you find the right open source project to jump into? Here's a guide based on my journey to find the right fit.
In the guide, I wrote about doing your research by casting a wide net, then evaluating yourself (your skills, your goals, and your time). In this evaluation to find the right fit, I looked at my motivations and skills, made a list of goals, and named a few target projects. Because this isn’t my first rodeo, I take a good, hard look at my track record. What can I learn from the ones that didn't stick to find the one that will? I notice patterns I can avoid and see how they line up against my new list of goals and skills. Then, I evaluate four open source projects and their communities to see if they might be a good fit. See the winner at the end!
My track record
Fedora Infrastructure
I joined the Fedora project as a contributor a few years ago without doing any of the evaluation work I’m doing this time around. And it shows. I joined for the right reasons, I want to give back to a project I use, but I didn’t figure out what I could offer first. I wound up trying to find an edge to peel back and wasn’t very successful. I joined the infrastructure team after poking around the edges, but while I had some hours to use at work, it was hard to apply them.
Issues: Didn’t gain traction because I didn’t find a good place to fit in; thus, I didn't manage my time and expectations.
Spaceclone
I spend a fair amount of time using Red Hat Satellite and looking at the upstream Spacewalk project on the developer and user lists. At one point an announcement hit the list about a new tool to manage channels and lifecycles. This was a problem that I’ve had and that my customers have, so I thought it was interesting and took a look. I've written in Python, hosted in GitHub, and it was fairly easy to dig in and write a new feature for caching auth tokens. That challenged me some, and there’s some bad list comprehension in early versions, but it went well. Until we both got busy with our day jobs. You see, there were only two of us. Two busy people does not a successful project make.
Issues: Time for contributions and project health issues caused the project to lapse.
Liquidprompt
In my day job, I’ve spent a good portion of this year working with and in OpenShift. One of the things that I ran into was keeping Python virtualenvs and software collections straight when developing apps. That itch scratched, I poked around at the open issues on GitHub. There’s a fair amount of activity, they have a contribution policy, and the main maintainer got to my pull request fairly quickly, so this looks like a healthy project. So, I submitted another pull request for an enhancement on the issues list, but nothing else really caught my interest.
Issues: Traction still comes from engagement; if you aren’t interested in the problem domain, you probably won’t keep coming back.
Netflix OSS
While at OSCON, I took a tutorial from the good folks at Netflix on some of their OSS tooling. My config was a little different than the expected setup, so I did a little extra work to get the examples working and submitted a pull request on GitHub. That pull is still awaiting review.
Issues: While ‘patches are welcome’, this probably isn’t really a project for someone like me. We may use it internally to poke at a few things, but it really only mattered for OSCON and I missed the mark.
Key takeway from this history list: In order to get traction and continue contributing, I need to be interested in the domain of the project, find the time, and make sure I pick a project that is actively taking input from the general public. I’ve already solved for time with my company, so it’s down to interest and project health.
Which way to go?
OK, you’ve seen the good, bad, and ugly about my open source software (OSS) history. The boxes checked so far are:
• time = aligned with $DAYJOB, handled corporate IP issues
• skills = BASH, python, architecture, documentation
• goals = skill sharpening, true believer
It's time to look at some projects with the new lens I've built. There are four that I checked the health and well-being of that may be a good fit for me.
Jumping into a new project
OpenStack
This one definitely hits the goals. Much of OpenStack is in Python and will definitely cause me to stretch my skills. I’ve met a few folks in the community at various conferences and know there’s a lot of ways to contribute. One of the potential issues is this is a really large project so finding an edge to peel back may be tough with a lower skill set. Also, the amount of time I’ve negotiated my not be enough to meaningfully contribute. But, on the list it goes.
Evaluation: My initial impression of OpenStack held. There are a lot of projects which made it easier for me to try to find that edge. The project has a very comprehensive and easy to find guide for new contributors be they developers, testers, writers, UX folks, security specialists, what have you. They use a tag in launchpad to mark easy bugs to help find an entry point for coders. Mailing lists and I couldn’t find an edge to try to peel back. Given the amount of time I have available and the interrelated nature of even the easy fix tickets, I don’t think I can make any headway here. So, as cool as it would be to say “I work on OpenStack,” I’m going to set that one aside for now.
OpenShift Origin
This project is definitely a true believer project for me, and having worked with the tools I can see some features that I could address. Looking at the issues list, my feature isn’t there so this could be an uphill “commit” and the project is mainly in ruby, so there’s a pretty steep learning curve there.
Evalution: Initial impressions of OpenShift Origin weren’t quite as accurate. Adding a new feature to the CLI may not be that tough, since there’s a public ideas submission page in the support area for OpenShift Online. Finding the entry point for the community was a bit tougher. The contributor page puts an emphasis on adding cartridges (new frameworks and language options) over working on the core code. I’m basing that simply on the amount of digital real estate given to each method. Once you dig in there are some good resources with ways to contact the teams and use the tools. There are also coding guidelines and methodology docs up front. All that said, the amount and quality of time I have comes into play. Learning Ruby, the OpenShift best practices, and creating and championing a new feature will all require a much more consistent amount of effort than I have available. Unfortunately, my new feature may be dropped on the public ideas board and left on its own.
Fedora Infrastructure
Since I first attempted to get involved with Fedora Infrastructure, the team there has made huge strides in making it easier to get involved. There’s an apprentice program and some “easy fix” tickets, all about getting new folks up to speed. I’ve already got some contacts and channels, and the community is used to working with folks that have “spiky” contribution time. There’s a lot I can do and learn here.
Evaluation: Since I’ve previously been involved with the Infrastructure team, I’m already on the mailing list, I’ve got the IRC channels bookmarked, and I know how to use Trac and work with the team. The new Apprentice program and easy-fix tickets make an good entry point for the mentoring system. There are a lot of different things that team deals with, from running mirrors and an internal cloud to developing internal apps. They work on things that are in my wheelhouse and I could find something interesting to do. I lost traction last time based on my application of time, which is came up as a common theme. With my schedule, I come back to something I can work on at my pace, being part of an infrastructure team I would want to be a steady contributor. Nota bene, this is my feeling, but I’m sure the team doesn’t mind small gaps in participation.
Project Atomic
Who isn’t looking at Docker these days? And, Project Atomic is building a really interesting hosting platform for containers. Project Atomic is a bit like OpenStack, as there are a few different upstream projects Atomic relies on to become Atomic. Any one of those projects have their own contribution path, added to the contribution path for Project Atomic. There’s also a minor personal crusade here since the documentation on the website has some holes. And if the project is hard to evaluate, then it’s overall health could be compromised. Open source projects need good docs as well as good code. There’s nothing more frustrating to a new user of a project than hearing about an awesome project, getting the code or binaries, then having absolutely no user documentation to trying to start using it. Self-documenting API man pages aren’t enough.
Evaluation: Docker is the new cool kid on the block, and Project Atomic is even newer. It’s not quite ready for prime time, but easily poised to become a solid and vibrant project. It’s easy to find the community contact page and that has all of the info you’d need to get started contributing. There are links to the upstreams where they use one, a public Bugzilla, IRC, mailing lists, etc. Unfortunately, not all the documentation is good. There’s a circular link in one of those contribution channels, and the getting started stuff is bad. That’s probably the place for me to start rather than trying to contribute code. Documentation like demos and labs is what I work on now, it’s fairly asynchronous, and it can improve the face of the project to draw more users and contributors.
Winner, winner, chicken dinner
Getting started with Project Atomic
First, I’ll check out what the project page says about contributing documentation. This looks like a “fork-and-go” contribution style that has gotten popular as of late. I can start there and make sure I can get the tooling setup, and I know the basic style before going any further.
The docs are mainly in Markdown, so there shouldn’t be any issues. I don’t know HAML or Middleman, so that might complicate things because I know Ruby. HAML is an ERB replacement, so that may not be an issue. We’ll have to see how things go. A replacement markup for something I don’t already know means it’s just a new markup syntax. And there's a Dockerfile for the Middleman server, so I don't need to worry about learning the server.
No big red flags anywhere, so I’ll go ahead and fork the website project on GitHub so I can start poking around locally. Now, I don’t want to start chugging away without getting in contact with the team and seeing what the current plans are for the documentation. This is about community contribution not me running off in a direction and presenting my ‘new better fixed’ view of the docs in a vacuum. There’s a developer mailing list and an IRC channel listed on the contribution page, so that’s where I start.
I figure out who owns the docs, send off an email to the team to say I'm going to take a look, and submit a pull request for a simple update. Then once that pull gets comments or accepted, I'll submit a bigger picture on what I think the docs could look like.
If you'd like to follow along as I go forward, you can check out the mailing list and my GitHub repo. Feel free to keep me honest!
Comments are closed.