Evaluating Open Source Projects: A Brief Overview

In my first few blog post, I discussed why open source software development shouldn’t be scary. After reading it, maybe some of you were inspired to attempt contributing to open source yourself. Maybe you even found an interesting project you wanted to work on. But I am sure that at least some of you when looking at that large project had feared of where to begin (like I did). I know how overwhelming it can be to see the codebase, all the tabs, the complex file structure, for the first time. Don’t worry though, I won’t let you get discouraged! Here in this post, I will give a brief overview of how to evaluate an open source software project.

The first thing that you need to do is to check the license of the project. It is almost always called LICENSE.md. The point is to see whether it is open source or not. If it isn’t open source (or doesn’t have a license) you should, of course, find a different project. Additionally, you should check what year the project started, to see how old it is

After checking if it is open source make sure you also look into the licensing to make sure you can fork and modify the repo. Or even to check what rights you have. Don’t worry too much about this part though, You don’t have to be a legal scholar or read every single line or anything like that. Just look it up on Quora or StackOverflow to get an overview and you are good to go!

Next, check what language the project is in. Github has its own algorithm to evaluate the primary language of a repo, which is displayed outside of said repo. This can be helpful to quickly see the most popular language of the project. That being said, it is important to remember that most projects have more than that one language. To see the other languages, unfortunately, you need to navigate through the directories a bit more.

After this, try to find out how to download the project and what it would require to build and test it. Don’t do it just yet though! It is just a good indicator to see how difficult the project will be in general to work with. While you are at it, take a quick glance to see how complex the code looks at a high level. See if it is something that would be do-able or if it would be completely out of reach.

Next, we want to evaluate the activity level of the project. This is really important to gauge things like how friendly the community is, how often people are committing, and how long it takes to get responses on issues & pull requests. The Github insights tab gives great information about this, like who contributes, who the maintainers are, how much people commit per week, and various other useful pieces of information. Also if you wanted to find out more about the project, you could always send a nice message of interest to someone who contributes frequently!

After that, it is useful to check out the pull request and issue tabs. This will give information about how quickly people get back to you, how friendly people are, and generally how active the community is. One particularly useful exercise is to take a set of closed pull requests or issues and see how long it took to get a response from each and then take the average. That is the amount of time you should expect to get a response (within reason, of course).

After having evaluated quite a few projects this way, it personally taught me a few things. For starters, it took some of the mystery and fear out of open source software development, which is always good. I know I have been saying this in every blog post I write. It is embarrassing to repeat myself so much, but I can’t stress it enough. Fear is generally the biggest thing holding people back from things that are good for them and I don’t want that to happen to any of you!

The last thing I wanted to mention is something extremely valuable I got out of this exercise. It made me notice some aspects of software development I am weak in. This, to me, is huge because it is impossible to know what you don’t know until you don’t know it.

If you are having trouble evaluating your weaknesses, a strategy that I use is to see what aspect of something makes me insecure, and instead of getting defensive (which, of course, is the natural reaction), know that it is probably something that you could use improvement in.

For example, if a project has lots of low-level code, and you immediately go into a rant how no one uses C++ anymore, it might be useful to instead bite your tongue and accept you could probably use some work in lower level performance languages. This tip, in general, can be generalized to lots of other aspects of your life.

Here are a few things I noticed I was weak in to wrap things up for this week.

• Evaluating file structures. I tend to only look at a few files and don’t yet have a system to evaluate large projects.

• I need to work on my confidence in learning new languages (or any language other than javascript and python for that matter). There were lots of interesting projects I saw in Java, Scala, and Go, so picking up a new language that I am totally not comfortable with would be great.

• Lastly I would like to work on staying things through until the end, especially when people don’t respond or aren’t the friendliest. I have a tendency to withdraw when that happens, and I wouldn’t want to lose an opportunity because of it.