Utilizing GitHub

While looking at starting new projects earlier in my career, I was obsessed with trying to build everything from the ground-up. As a new software engineer, I was ready to build everything I could with the attitude that I don’t need to rely on anyone else’s code or tools since I could build my own. One of the projects I took on was to build a media server at home where I could host all of my music, movies, and books and access them from any device anywhere. I started by asking around all of my friends and family to send any unwanted, old computers my way so that I could use the hardware to build up a server machine. I was surprised to get so many old computers from so many people. I started working on a bootloader to be able to build the operating system that would run the media library, and I’m sure as anyone reading this probably already thinks, I did not finish the project. I had a lot of fun building a server machine out of spare parts and working on a bootloader — I didn’t even get to actually writing the operating system, but that all took a lot of time and research to get tested and working.

The point of the above story is that since I was focused on building everything from the ground-up, I was focusing on problems outside of what I was really trying to build — a home media server. I am still definitely interested in operating systems and bootloaders, but I have found more value in being able to build a new system quickly (not necessarily at the sacrifice of quality, but I need a project that has a reasonable lifetime — not something that will take 10 years to complete). In my story, the problem I was actually looking to solve was to build a media server. There are plenty of tools and systems in place that can be built on top of so that I only need to focus on the problem that I’m trying to solve.

This is where GitHub becomes a great resource for every software engineer and IT professional (or even a technically inclined hobbyist). Firstly, there are plenty of open-source tools and frameworks that we can pull off GitHub and build on. For example, I wanted an operating system to run on my server, the obvious answer is to use a flavor of Linux (my favorite is Ubuntu — mostly because that is what I’ve learned on and used the most, but there are plenty of others out there). In addition to Linux, there are tons of other open-source projects that provide tools and frameworks that are great to use when building a system. This can also be a great place to find a project similar to what you’re working on and can be a great way to build a system off of something that already exists rather than doing everything from scratch. (Sometimes I like to build things from scratch to learn more, but taking a GitHub project to, at the very least, serve as an example of something you want to build can really help cut down on the time it takes to build new software). GitHub really is the “software shop” that I go to first when looking for something I need.

Beyond the obvious ability GitHub gives to download and install open-source software, the next great use for GitHub, particularly for a software engineer, is to get a gauge on popular coding styles and design patterns for particular kinds of projects. For example, when I started learning React with Redux (they are two separate frameworks, but they are often combined together), GitHub was a favorite place for me to go to see the design patterns and coding styles other software engineers were using. Understanding the prevailing design patterns and coding styles for these frameworks really helps in understanding how the overall system comes together and actually works. I will always recommend to anyone learning a new language or framework to find a popular GitHub repository to see how they are used in the real world.

While I have talked about the great things of GitHub, there are some cautions that should be included as well. There are tons and tons of open-source projects that people upload to GitHub and make public, and as such, there are plenty of repositories that are not well maintained and do not at all represent good design patterns (or even actually work). I have some of them myself from when I first started writing code and just putting any random project online. There are plenty of examples of these. The other big thing to consider is security. When downloading and running software from somewhere, you really need to make sure you can trust that it’s not doing something bad (i.e.: collecting your data and sending it to hackers). 

Some of the first things you can look at when judging a GitHub repo are the number of active contributors, the commit and merge history, the number of forks, and the number of watchers. Looking at these, you can determine if a repo is actively being worked on, and if it is widely used. The more widely used it is, the more likely it works as expected and represents code that is used in practice and is well-maintained. There are always exceptions to this, but it’s a decent first step to evaluate the repo you’re looking at. (This is also not to say that a repo that is not actively being worked on is necessarily bad, but I also wouldn’t necessarily rely on it to get a gauge on the current design patterns and styles used by the majority of software engineers either).

To evaluate a repo to determine if it’s malware, depending on the size, I often start by looking through the code. You can clone the code and not run it and be safe. (Though for an extra layer of safety, I often use a sandbox — a machine that is disconnected from the network and one that I don’t care about — to clone a repo on and evaluate). I often search for things in the code, like what servers it may be calling, if it runs in the background and tries to disguise itself as a Windows service, etc. That being said, trying to put malware on github in the hopes that someone installs it, is not going to be typical since anyone can look at the code and determine pretty quickly if it’s malware. Again, I have not found anything problematic in all of my usage of Github, but there’s always a first, and it’s never a bad idea to be careful.

Lastly, if using open-source software, it’s a good idea to give back. Either build tools and make them publicly available for someone else to use or contribute to more popular projects. The open-source community is an awesome place to be able to collaborate and share code. Therefore, most people who take from this space give back to keep the community going. Furthermore, there is plenty of money to be made in open-source software. While it seems counterintuitive to allow your software to be visible to the rest of the world and that it somehow makes your contributions not valuable, there are plenty of massive open-source projects that businesses have built on, and they then hire people to either maintain that repo or create a fork where the business directs the features and defects that are addressed first. This is very common. So it may be that if you spend enough time in the open-source community, you might find that a business will want to pay you to help maintain a repo you have spent time contributing on.

Long story short, GitHub is an essential resource when building up new systems and learning new languages and frameworks. It is my number one “shopping” location for software, and I highly recommend anyone else interested in this take some time to really get to know GitHub. Lastly, I did finally finish my media server, but I did so utilizing a lot of the items from GitHub, but that is a story for another time.