2018-08-27 Update

Using open source code in your project development life cycle can speed things
up tremendously. At the same time, it is also one of those moments where we
developers need to exercise some caution. Typically, many useful helper
libraries, frontend frameworks, UI toolkits, and so on, can be added to the
application that you are working on with ease. For example, if you are working
with Node.js and node package manager, adding a package is only an npm
away. So it’s not surprise that looking at the
npm homepage will reveal that some of the packages,
like express, are downloaded up to 5 million times a week — and others even
more often.

In our team, when we evaluate whether an open source library, we try to answer
a few questions first. Usually, we come across a library in three different
types of situations:

  • Someone posts something interesting on a developer-related news site like
    Hacker News.
  • We have a specific problem that we are trying to solve and google for
    “node.js http promise library” to find an await/async friendly,
    Promise-based JavaScript library,
  • Someone we know recommends a library expressing their delight that it solved
    some problem that they had quite nicely.

It goes without saying that using a module or library to solve your problems
has a lot of advantages. You can

  • benefit from the experience of someone who has had your problem before,
  • use code that is well-tested and stable,
  • advance the project together with an enthusiastic community of open source

The amount of time and effort you can save when using an existing solution can
be tremendous. Of course, at the same time, it is important to consider that
your maintenance burden might increase when using an external dependency in
your project if

  • after a refactor or feature change it becomes not needed anymore,
  • it is not maintained anymore and critical bugs are not fixed, or
  • it uses or switches to an OSS license that is not compatible with your

Especially in the last case, finding out that a project you have been using is
not compatible with your project can slow down your development. It can happen
that the maintainers decide to switch to a license with questionable patent
clauses. Then, hoping for a change becomes an exercise in patience and you are
often better served switching to something else. If this concerns a fundamental
piece of your application, such as a frontend framework, then the tremendous
effort behind switching away can impact productivity and developer morale.

So, I therefore recommend to put in some deep thought before using open source
in your project, and ask yourself 3 simple questions:

  • Is this library implementing some functionality that we can not implement
    ourselves in a reasonable time frame? (1 hour, 1 day, 1 week, …)
  • Is this library maintained well enough and is it compatible with the
    different build and run time environment configurations that we use?
  • Would switching away from this project impact our development in a
    fundamental way?

Of course, if your whole web application is based on Ruby on Rails, it becomes
almost impossible to just switch away. But on the other hand, if you can answer
more than one question out of those three with a yes, you might want to
carefully evaluate whether using a specific open source library will be worth
it in the long run.