Originally published on forbes.com.
You’d like to use open source software, but you’re not sure what criteria you should use when deciding whether to rely on it for a specific project or not.
I have a long, complicated history with open source software. I use open source libraries every day in my work, and I’ve developed several criteria for evaluating projects.
I got my professional start in tech as the technical co-founder of a news startup. My co-founder had chosen to use WordPress. I volunteered to maintain the tech since I had a strong background in HTML and high school-level understanding of Pascal and figured that would be enough.
WordPress, as it is for many, was my gateway drug into tech — and open source. When I had any questions, I quickly found solutions from the robust and supportive WordPress community.
That’s the ideal open source — a ubiquitous platform with a helpful and supportive community.
Several years later, at another startup, I got entangled with a different open source community. Having used WordPress during my initial experience with open source, I trusted open source. I was tasked with managing an online community, and I chose this open source solution without fully understanding what had made the WordPress choice so successful with my previous endeavor.
Customizations were expensive, if they were even possible. Updates didn’t update smoothly, nor were they timely. The community using and supporting the software was very small at the time and not very helpful.
That’s where open source can go wrong — a project that’s not properly maintained or supported with an unhelpful community. Even when open source goes wrong, you are not necessarily going to do better with a proprietary solution.
Many development firms try to sell their proprietary systems so they can lock in clients. Every new feature the client needs costs an additional work fee. That’s clearly in the interest of the development firm — not the client.
If you opt out of working with them for future developments, then you are responsible for developing the core codebase. You have to constantly monitor the core codebase for security risks because you have purchased a proprietary system. You are on your own.
With open source systems, you get all the infrastructure for your site from the community. The same goes for Flask, Drupal or ExpressJS — all projects I’ve leveraged at one time or another. User management, community plugins, security and data structures are all taken care of, leaving you to focus on the features your company needs.
How To Vet An Open Source Project
Knowing which open source projects you can rely on is an acquired skill. If you choose wrong, it will cost you. I’ve thought a lot about this topic over the years and have come up with the following criteria for evaluating a project:
1. Who is developing and maintaining the project?
Does the company have a good track record for keeping open source projects going? Sometimes a company will open up a tool it uses in-house. This is a good sign that it is likely to keep developing it further. Other companies don’t want to actually kill projects, so they offload them to an open source platform and cease development. You can adopt such a project, but just assume that its maintenance will most likely be entirely on you.
For example, Facebook has a fairly good track record for supporting its open source projects. It has a department dedicated to open source tools. I can’t vouch for its non-open source services, because each one is a different case. But I happily incorporate projects like ReactJS into my site, knowing that it will be maintained.
2. How popular is the project?
The more people rely on the project, the more likely it is to be maintained — if not by the original development team, then by others who need it and take it over.
The popularity of a platform is an argument that can be used against incorporating some open source projects. WordPress powers roughly 28% of the internet; some see that as a security risk. But any systems administrator worth their salt knows how to mask and lock down WordPress. Not to mention, because of its ubiquity, security issues in WordPress are detected and patched quickly. In contrast, if you run a stagnant system, do you really know what security skeletons are hiding in there?
3. How often is it updated?
When a project stops attracting regular contributors, it’s a strong indication that that project is going to die. Similarly, if there are a lot of open issues on their GitHub repository, it means that the team behind the project is neither active nor responsive to the needs of the community.
4. What does the codebase look like?
Code that is clean and well-thought-out is a good indication that professionals are behind the project. Even if it was left to die, it might be a project a company would happily take in-house and maintain further for its needs.
If you are debating whether you can incorporate a project into your codebase, remember the following: A good open source project is maintained by a core group of people who rely upon it. It will likely be used by a lot of people, and it will be updated often. Finally, a good project, open source or not, will have clean code that is well-maintained. If you do incorporate it into your codebase, you will benefit from the expertise of the entire community using that project.