Steve Klabnik’s Codementor Office Hours: Working on Open Source, Large and Small

Steve Klabnik recently hosted an Office Hours with the Codementor community. Steve is an active Rails contributor and is currently ranked #32 on the all-time Rails Contributors list.

In a live interactive Q&A small group discussion, Steve shared his experiences of working on large & small open source projects and how these experiences can make you a better developer.

In Steve’s own words: “I work on many open source projects. I have 273 repositories on GitHub, and am in 15 organizations. Some of them are huge, like Ruby on Rails. Some of them are small, like my own little side projects. All of them are different. Let’s have a chat about what it’s like to do a lot of open source work, and some of the things I’ve found useful, and some of the things that I’ve regretted.”

Steve Klabnik: Getting into Open Source

How do you choose what project to work on ?

You shouldn’t really look around for open-source projects to commit to, you should choose a project that you already use and like, and are somewhat familiar with. With projects you already use, you will have a greater understanding of the bugs that are being reported, and you may even have your own issues that you can try and tackle and then submit.

How can you get your pull requests accepted into a larger project ?

The main thing you can do when submitting to a larger project is read their contributors guide. Most bigger project’s will have guidelines on how they want updates to be performed in order to keep the codebase relatively uniform.

Another thing that is important is communication between you and the project’s maintainers. Many times if your pull-request doesn’t get accepted right away, it won’t simply be closed and rejected. Usually the maintainer will give you some feedback as to why it isn’t being merged and if you communicate and update your changes to comply with the feedback, eventually it will probably get merged.

How can you get started contributing to a larger project if you don’t necessarily have the skills to close bugs ?

There are a couple ways to get involved in a project without necessarily closing bugs. One that is relatively simpler but at the same time tremendously helpful is if you create a sample app using the project which can replicate the bug. Many times people will submit an issue, but it may be something that is hard to replicate, or just require a lot of setup in-order to make it happen, so creating a sample app that replicates the bug more reliably can save other contributors hours of fidgeting with it and is a start to getting involved in the project.

Another way you can get involved, is to submit a pull-request for documentation. You can go through the codebase and find a method or property that might not be well-documented and you can submit a change for that. It is a low-key way of getting into a project, and allows you to get practice with the whole process of making changes and submitting a pull-request.

How do you manage your time while working on so many projects ?

Sometimes the variety you get from working on different projects and ‘switching gears’ can keep you motivated in your work. It’s hard for some people to work on a single item straight and just being able to switch between things can actually let you get more done in total.

The other thing to keep in mind is that ‘maintaining’ many projects doesn’t actually mean you are actively working on everything at once. Sometimes you may just have started a project, or contributed a lot in the past, making you involved in a project, but you may get other contributors who really drive the project allowing you to take a step back and work on other things. Not to mention that a project (especially smaller – more focused – ones) can get to a stage where it works without many issues and just doesn’t require that much maintenance.

What are some of the pros and cons in pursuing a Job in open-source ?

It is possible to get a salary working on open-source work, and there are generous employers who value contributing to the community and will pay for this, but it won’t be as high a salary as you could potentially get working on a closed source project privately, and that’s something you have to be OK with.

One of the benefits on the flip-side working on popular projects is that people are interested in what you are working on, or what you have to say, and you get to travel the world speaking at conferences and meeting lots of great new people.

How do you start your own open-source projects ?

You can’t really go into a project knowing if it will take-off are not, because you can’t really gauge if it’s something that will interests others. Many times you will create a new repo, and no one will even pay any attention. But that isn’t necessarily a bad thing, it allows you to worry less about what people may think about your code and just create things.

The main idea is to just create something you find useful and if it solves a real need then it may gain interest, but again it’s not something you can easily gauge in advance.

It mostly comes down to how useful the project is to other people, and how it can help other developers save time in their own projects. Even if it only helps out one or two people, that should still be a win, as it served it’s purpose.

What are some of the things you learnt from working on many open-source projects ?

One of the things you come to learn is the importance of having tests in your projects. Tests allow you to make changes to your code confidently cutting down on the risks that are involved with modifying and refactoring a project. Tests aren’t full-proof and you may still break something in your codebase without actually failing any tests, but with the right coverage, you can modify something and get a general idea if you have made any breaking changes to the project as a whole.

Another thing you learn is the importance of communication, open-source projects can have many members, and a large portion of being involved in a larger open-source project is not the actual code, but communicating with others. Whenever you want to make a change to a library that is used by many others, there will be a certain amount of back and forth, debating why you think your changes should be added and how it moves the project further.

Your changes may not always be merged, but it’s important to know how to be mature about it, and to not just take it personally and get offended, but rather to keep the conversation relevant and discuss ‘the facts’ about your changes to come to a mutual understanding as to whether they should be merged in eventually or not.

How can you gain traction on your own open-source projects ?

Again knowing in advance what people will find really useful is really hard to gauge, but like most things, gaining popularity has it’s own growth curve. You probably will begin with only a handful of people knowing about your code, but popularity tends to snowball as more and more people start to use / share your project.

With that said there are a couple of things you can do to ‘advertise’ your project and let people know about it, things like sharing it on twitter, contacting development blogs & podcasts, and even newsletter curators. For example in the ruby world we have the ruby weekly newsletter managed by Peter Cooper, which is a great way to publicise a gem you created and instantly get it out there to thousands of subscribers.

How do you keep in touch with other core-contributors on an open-source project ?

Every project probably has it’s own methods of handling this, but a lot of the more popular projects will have an IRC channel on freenode for instance, where you can chat with other programmers about the project’s development. Some projects like Rails have a private Basecamp project where they keep track of development goals and discuss different updates, and another option that some projects go for is mailing lists to keep people in the loop.

But again this is very dependant on the project itself, and there is no general right answer on how this should be done.