Two decades ago, most companies built software internally before selling it as packaged applications, like Microsoft Office.
But that wasn’t the only option for development.
Open-source software was available, but its use in recent years has exploded, thanks to Github and other services. These make it easier than ever to write code and release software to the community or find and integrate open-source software into your commercial applications.
The ease of use has opened up opportunities for developers to create software applications without the time-intensive approach of building everything internally.
Companies don’t have to reinvent the wheel every time they want to release an app. Instead, they can simply use open-source software to build the majority of the building blocks, leaving the most important innovative and proprietary work to their developers.
But while open-source software is an incredible asset if you’re looking to quickly build an app, you have to be careful when using it.
Certain issues can blindside you with lawsuits or bad code if you aren’t careful.
For instance, Cisco’s acquisition of Linksys should serve as a cautionary tale. Some of the open-source software Linksys was using violated licensing terms, but Cisco didn’t know that at the time of the acquisition. Later, the violations were discovered, and Cisco was sued by the Free Software Foundation.
Since you don’t want to end up with a lawsuit, it’s much better to play it safe and ensure your decision doesn’t come back to haunt you down the road.
Here’s what you should be looking for as you begin working with open-source software:
Check the software’s license to see if you can use or modify the software, and if you have to redistribute changes.
Open-source software usually comes with a license. There are several of them out there — GPL, LGPL, BSD, Apache, MIT, and others — all with varying degrees of restrictions.
Licenses such as AGPL, GPL and LGPL are copyleft licenses and have restrictions on changes to the underlying software or how combined or derived works are generated and distributed. Other licenses such as Apache and MIT license are more permissive.
For example, some licenses require you to release any changes you make to the software back to the community. So, if you use the software in your app, but modify it better suit your needs, those modifications have to be shared.
That can be problematic if you’re a for-profit company that wants to keep any changes and IP to yourself.
To keep out of trouble, you can use tools that scan your software and report the different licenses accompanying it, along with any possible violations.
You can also do this on your own, but the engineering and legal teams will likely need to be involved in this process — and perhaps the product team, as well.
Regularly checking your compliance with the open-source software you’re using will help avoid headaches later on.
Make sure the technical implementation is sound.
Developers often use open-source software as building blocks for their application. Unfortunately, some will see a project, think it looks good, and decide to use it without much thought.
But eventually, issues arise in the open-source component included. The real problem lies in the fact that the developer chose to use the software without thoroughly vetting it.
If you want to use an open-source project, make sure the code is technically sound before including it.
There can’t be any serious bugs or issues, otherwise your software will contain them, too.
If the project is low-quality, then all your time is spent fixing issues in that project or replacing it, instead of developing your product. So put in the due diligence to ensure the software you’re choosing is technically sound, and you won’t have to spend time fixing it.
See if the project is being developed on actively.
When you read an article on Medium or another blog, it can be difficult to determine ahead of time whether the writer is credible. So, most of us look for signs that indicate credibility — a high number of comments and shares, a consistent posting schedule, a relevant bio.
Open-source software is similar, in that you want to work with an active and vibrant community. An old and disused project may not get updates over time, which means you may have to do that work yourself in the future.
So, before you choose a project, look for the signs of quality.
First, how often has the project been downloaded? Popularity usually indicates good quality, though this is not always the case. You’re also looking for software that’s actively being used, with plenty of developers contributing to it.
If there are only one or two developers maintaining it, without anyone actively working on it, that’s not a good sign.
You can also look to see if any major organizations are backing the project. Google, Facebook, and other established companies sometimes support a promising project with their resources.
It may seem like a large investment of time to vet all the software you use, but I promise that it will actually save you time later on if you’re able to catch any of these issues before you use open-source software in your work.
Thanks for reading!
Want to learn more? Get in touch with the Chronicled team here.