Introduction

Open Source tools and libraries are widely used in enterprises today. While a few years back companies were somewhat reluctant to allow the use of open source tools, there are very few companies today that don’t have open source as part of their technology stack.

We are often surprised to see how tool decisions are made in the first place — and also what kind of open source tools can be found deeply engrained into an enterprise’s technology stack.

And this brings us to a few thoughts about open source components. What should be the criteria to choose open source components, especially as a large company?

As a company (also operating in the open source space) we advise our customers to look at the following:

Functionality

This one should be a no-brainer. Of course you would only bring an open source tool into your tech stack after you’ve done some in-depth evaluation (other than just reading a blogpost and trying out the Hello World example). Make sure the tool actually does what it claims to do, works in your environment and fullfills the requirements of your use case.

 

Last commit

Now this one may not be so obvious. You want an actively maintained project. Check when the last commit was done. If it was 6 months ago, chances are pretty high that the project is dead and there will be no further updates to it. This is especially the case when you see no recent commits but there are issues and pull requests piling up against the project. Which means, you’ll be stuck and will need to find yet another tool for your purposes.

 

Number of maintainers

This is typically, the most overlooked criteria. While a project might be actively maintained, make sure it is more than just a couple of people that do so. There are tons of examples where someone created a really cool project, maintained it for years but then got bored / moved on / wasn’t allowed to do it any longer by their employer / etc… and then stashed the project. And from one day to the next, you as a user of the project are stuck and need to find a replacement.

For example, the project below may look like it has more than 20 committers on Github, but there is actually only one person actively involved in the project. What do you think will happen, when that person moves on?

(BTW: this is one of those projects that a lot of companies have deeply engrained into their technology stack)

 

License

Not all open source projects have the same license. While many of them are licensed under an Apache license, which you can easily incorporate into your tech stack, there are also other license types. With some license types though, you potentially have to make the source code of your entire commercial application available (which is most likely not in your interest).

 

Summary

Open source is great. But you need to do some homework before deciding which tool to bring into your enterprise toolchain. Take a few days, do a proper proof of concept, browse through Github and look at the committers and the commit frequency. And last but not least — check the license!