A how to guide for working with open source software
At Novvum, a big part of our success has come from working with open source tools. This paradigm is a distinguishing characteristic of the software industry and it’s like nothing I’ve seen before. Everyone from hobbyists to massive enterprises contribute to open source for FREE and everyone benefits from it.
As a boutique software agency, we had very little capital to work with when my co-founder, Raj, and I first started.
Having access to high quality software built by experts was a game-changer for us.
When I first started using open source software, it was overwhelming and sometimes intimidating. It took a lot of time and effort to figure out how to effectively navigate and utilize this vast ecosystem.
Whether you are trying to build an application or play around with machine learning, you need to find the right tool. This process can be overwhelming due to the sheer number of choices out there. So, how do we filter out the noise and use the tools effectively? Here’s what worked well for me:
First, decide which programming language you feel comfortable working with. Some languages are better suited for certain types of projects than others, so it is a good idea to educate yourself on that.
Next, do a simple google search and compile a list of options that seem to do what you would like. There are also a number of repositories on GitHub which are named awesome-[topic] which can be found here. They provide a curated list of awesome frameworks, libraries and software around the topic.
There are also passive ways of coming across new tools from places like Twitter and google news. I’ve found a lot of success coming across new libraries this way and there are many other options. The advantage of using Twitter is that if you follow the right people, they will check the quality of the tool before they post about it which could save you a lot of time. We do not necessarily have to go out looking for libraries — we can setup channels to receive new information as well.
One big lesson I’ve learned is that a tool’s description might make it seem like it would to do exactly what is needed, but after further exploration, it is not flexible enough. The way to move forward from there is either to request the author for the new functionality or look for a different tool. Although there is no silver bullet for solving these problems, we can mitigate them early on. Here are a few quick things we could look out for ahead of time:
Once we have taken the basic first steps of vetting the tools and narrow our choices, it is a good idea to dig into the documentation. We don’t need to read the documentation cover-to-cover, but it helps to skim over the different features that the tool offers to verify that it fits our use case and that it is easy to use. The technique I use here is that I keep my project’s requirements in the back of my mind as I read through the documentation while imagining how I would implement the features for my project. The key thing to note here is that -
This process might take a little while and probably not something that can be done in one sitting. There are a couple of different ways to effectively utilize the documentation .
Going through this process will help find any blatant issues which might not work with the project and it might give you ideas on how to get started.
Reading the documentation can be very helpful, and if the tool seems to fit what you need, you can dig a little deeper. You can try out the tools in your project to see how it actually works. Another option is to make a mini project to test out the tool if it is too time consuming to incorporate into your main project.
This step is a lot more involved than the others and you may run into a few roadblocks. For instance, the documentation may not give you a full idea of how to implement certain features, so you could always dig into the source code. Peeking under the cover had answered many questions I’d had and it is definitely not as difficult as I first thought.
The source code may be too complex at times and it is not a plausible solution for understanding how to use the tool. Which brings us to our next section.
There are many times when I’ve run into roadblocks during my implementation where either the documentation was not very clear or I did not have enough of an understanding of the tool. In those cases, it is very helpful to reach out and ask for help. There are a few different options to explore:
OpenSource software is what it is today because of the tremendous amount of involvement from the community. If you haven’t found a tool that fits exactly what you need, then it is a great opportunity to contribute. The contribution could be something as simple as posting a GitHub issue, or as involved as implementing the feature yourself. This step might feel intimidating at first, but if you’ve gone through all of the above steps to get here, then there is a very valid use-case and other people might also benefit from your work. Hereis a detailed guide on contributing to open source.
Contributing to an OpenSource software and displaying your work for the whole world to see and scrutinized may be scary for some people. I was certainly one of them. Having contributed anyway, I can say that the people scrutinizing your code are very friendly more often than not and they are just trying to help keep the quality of the tools they are using up to the highest standards. The perspective to take here is that we are all helping each other out to build awesome stuff. So have fun with it!
If you guys enjoyed reading this article, but feel like you need more details, please post a comment below. I am considering making this into a series where I go into more detail on each of the steps.