In today’s product development environment, developers are looking to open source software to help them solve their design challenges more than ever before. Open source software has the potential to dramatically accelerate development and save costs, but as I often see in industry and with my clients, it can also become a thorn in a team’s side that causes project delays and budget overruns. I often write about the pitfalls and dangers that come about from using open source software but in today’s post, I am going to explore several tips that developers can follow in order to use open source software successfully.
Tip #1 –Test and Verify
Before ever attempting to integrate an open source library into your code base, you should first isolate that library and run it through a battery of tests. The tests should run the library through
- general use cases
- boundary conditions
- claims about what the library can do
I was recently working with a SPI flash library I had found on github that would create a simple filesystem and appeared to be a perfect match for the project I was working on. Before jumping into integration, I first created a simple project that would allow me to run the library by formatting the disk, creating and writing a file and then deleting the file. I quickly discovered that there were several severe deficiencies in the library that weren’t mentioned in the write-up such as not being able to write a file as a stream. Had I gone forward with integration immediately, I would have wasted time when the deficiencies showed up in my application and may have even wasted time debugging.
Tip #2 – Perform a code review
Performing a code review on an open source piece of software is highly recommended, but it’s not always practical. For example, the Linux operating system is open source, but no one is going to review millions of lines of code before using it. However, if you are using an open source library such as FatFS, it would make a lot of sense to spend a few hours reading through code.
Performing a code review can reveal important characteristics about a code base such as:
- How well documented it is
- The general code quality
- Overall complexity (higher complexity will most likely have more defects)
- General architecture which can affect integration and scalability
If you see things in the code that you don’t like, it may be a sign that the open source code is not the right one for your project.
Tip #3 – Verify the open source license
There is a lot of open source code out there and many different licensing schemes that are used to protect it. Not all licensing schemes allow the software to be used in a commercial product and the ones that do might require modifications or the source code they are used with to also be released! Obviously, this is a potential nightmare for a commercial product where the source code could be considered confidential intellectual property. To successfully use open source, developers should first review the license to make sure it is okay to use and then second have the company’s attorney also review the license. I can’t tell you how many times I’ve caught developers trying to use an open source library that was not appropriate for a commercial product simply because of its license.
Tip #4 – Select active and supported open source
If you browse around github or your favorite repository for open source software, you’ll quickly find that there are a lot of individuals out there who are sharing some very useful code bases. The problem though is that a lot of those projects are just posted by one individual who at some point will most likely lose interest in the project and stop supporting it and / or answering questions. It’s imperative that if you use an open source code base in a product that you make sure the code is being supported by multiple people and that they have an active forum for questions. There is nothing like being under a deadline and having to patiently wait, possibly forever, for a response about how something works or is behaving with an open source library.
Tip #5 – Isolate in your architecture
When you start to use an open source piece of software, you want to make sure that your software does not become forever dependent upon that code. Open source libraries quickly come into and out of style and if you are designing a product that will be in production for years that will require updates, you don’t want to depend on that code. In your software architecture, isolate the open source code so that it is abstracted through an interface to your application code. If you later discover that the open source code needs to be replaced, you won’t have to go back and change your application code. Instead, you’ll have successfully hidden the library code and can make changes behind the interface which will minimize rework, costs and time.
Conclusions
Open source software has helped countless developers successfully prototype and develop commercial products that might otherwise have been impossible to do otherwise. Open source software isn’t the solution to every problem and if developers aren’t careful it can become the problem that developers need to wrestle with. If you follow the tips we’ve discussed in today’s post, you should find that your chances for using open source software in your next project will be much more likely to succeed.
