Determine if open source code has quality and will fit your software project requirements.

Is it a good idea if I use this open source code for the (enterprise) software project I am working on?
  • Created on: 17/4/2017
  • Edited on: 17/4/2017

Determine if open source code has quality and will fit your software project requirements.

Many times I have been asked to take a look at some code in some github repository with the following question. Is it a good idea if I use this open source code for the (enterprise) software project I am working on?

Lets start with a bit of context. The architecture principle Reuse before buy. Buy before build is used by lots of organizations and government endeavours driving open source adoption. This principle aims to Reduce Costs, Improve Interoperability, Reduce Risks and Reduce Time To Market. Using and writing open source code is one of the methods used by organization to achieve more reuse. The open source community has been growing steadily in the last couple of years. There are more than 350,000 npm modules on the public npm repository. 135,000 php modules available on packagist (composer). 4M open source projects on github. This means that there are a lot of options for solving almost any problem. To my surprise less than 30% of the company’s have a formal screening process in place that tracks open source code they have created or use.

Documentation

The amount of documentation required for open source is tightly coupled to the scope. A minimum requirement would be a readme file. The readme is intended to quickly orient readers as to what the project can do. Wikis are a place where you can find long-form content about the project, such as how to use it, how it’s been designed, api references, manifestos on its core principles. An example of a wiki can be found here.

Other documentation that can be useful:

  • Forum (for finding solutions to common problems)
  • Some reference projects (a great example of this is TODO MVC).
  • Stakeholder documentation (benefits and drawbacks in non developers lingo).

Activity

Modern repository management systems offer its users with activity and usage statistics. This is great for analyzing open source project adoption. Do not be fooled by a good search name of a project. Look at the statistics that are available online. If a project has minimal downloads or has not had an update in the last year then you should probably not start using the code in question. Check if the project owners are responding to pull requests. Sometimes you can even find how many other open projects have decided to depend on it. Indicated as parameter Dependents. An example can be found HERE.

Scope

The general trend is that repository’s scope is getting smaller. Large open source system solutions are getting rid of core parts opting for plugin structures. The idea is to do one thing and do it extremely well. Another advantage of small scope (modules) is that it should have less impact to replace one module with another one. Multiple large scope dependency’s are a bad practice. Make sure your team will be using more than 85% of any large dependency. Unused code is something i see quite often and is referred to as dead code. To me scope is one of the most important things i look for when deciding to use a piece of open source code. If you are able to read and understand the code in a couple of minutes then all other discussion subjects mentioned in this article become less important.

Tests

Testing inside a project can give you an indication of maturity. Not that you should always look for mature code to use. Below a list of the types of software testing from simple to implement to hard. Code linting for open source code more than 1500 lines would be a minimal requirement to me. Unit tests would make me extra happy.

  • Code linting
  • Unit testing
  • Intergration tests
  • Load testing
  • In-service testing (a/b)

Dependencies

It’s increasingly difficult to build any kind of non-trivial app without leveraging external dependencies. Looking at it from the other side of the table. Dependencies pose a threat to the long-term stability and viability of any application. It is good as product owners and developers to be aware of dependencies and to make sure that the dependency tree is not deep. Analyse the dependency tree of your application and of the open source code you are investigating. Consciously decide if introducing a dependency at a level (see code dependency graph level 4 image) is a good idea. Try to have no or minimal Third-party code dependencies unless it is a (paid) service that has good support in place.

Types:

  • Dependencies in control This is code written and maintained by your organization.
  • Dependencies out of control This is code that is out of control but vissable for inspection.
  • Third-party code dependencies These are the code dependencies out of control and not visable for inspection.

More reading material

To find more reading material about this subject search for “open source maturety model”.