We’ve reached a point where we are surrounded by an abundance of goods, ideas and services. Whether we are trying to choose one of the fifteen brands of peanut butter found at the grocery store or trying to determine which pizza restaurant to have dinner at, we are bombarded with a variety of choices and decisions all the time.
Having all of these options are great but can often overwhelm us. What if we choose a subpar can of peanut butter or a pizza joint that’s not that great? Making a bad restaurant decision isn’t the end of the world but choosing the wrong spouse or stock to invest in could certainly cause some problems for you. Choosing the wrong open source library for your software project can be problematic in the long run too.
Not All Projects are Equal
Your software app you’re building will have different needs based off of what type of project it is. If you are building something for a school project, you can take more risks with the types of open source projects you utilize. If you’re building software for a medical pacemaker, your project will need to be 100% reliable and fully tested. As your project increases in consequence, your use of open source software should also be more selective.
Knowing about certain open source classifications will help get you started on selecting the right project for the job. By matching up an open source project’s intended use with your project’s intended use will be your first step down the right path.
The first thing you’ll want to look for in an open source offering is a project that uses complementary technology to the project you are working on. For example, if you are building a Java app, you’ll probably want to stick with open source projects that are built in Java. This will make integrating the open source project much simpler. After all, the whole point of using an open source project is to make your life easier and provide functionality to your project so you don’t have to implement it.
Most all open source projects are setup with a specific type of license. You’ll want to pay attention to this because it can have implications on how and where you can use the open source project within your own project. Open source projects will typically use one of the following licenses.
- GNU LGPL - You can copy, distribute, modify and use the software for free but you need to include the copyright, license, state changes made, disclose the code and include install instructions. You also can’t sub-license.
- Apache License 2.0 - You can basically do what you want with the code but you need to include the copyright, license, required notices and list any major changes to the code.
- MIT License - You can do whatever you want with the code and simply include the copyright and license. Less restrictive than Apache License 2.0
Frequency and Age
How well maintained and up to date an open source project is can be determined by how long it has been around and when the last update to the project occurred. Projects that have been around for five years tend to have a bigger community, documentation and public support than projects that have only been around for a month or two. You can’t solely use age though. Projects that are five years old but haven’t had any commits for four years means that the project is most likely not maintained anymore and hasn’t kept up with dependent changes. Look for projects that have been around the longest and still have recent commits happening on the codebase.
Every year the software community gains more and more open source projects and offerings. The plugins, tools and frameworks at your disposal is truly amazing. Make the most of what’s out there by running through this simple checklist every time you evaluate open source code.