Trialling new technologies and integrating them into your technology stack is essential to keeping relevant in the ever-changing world of software development. Individuals who refuse to try anything new all eventually wake up and realise their skills have rusted and the world has moved on. Organisations that refuse to modernise risk falling behind hungrier, more agile competitors who are finding more efficient, faster or simply better ways of doing things.
The trick is to pick which technology to trial, and which ones to avoid – which ones are going to become ubiquitous pillars of software engineering that you should adopt early, and which herald a frightening descent into madness.
Having a solid framework to decide whether a technology or library is right for your business can help save you a lot of pain. Is it right for your team? Does it fit your product and brand?
And if it’s an open-source project, there are additional risk factors. Here are 10 things to consider before integrating an open-source library into your tech stack:
1) How is the software licensed?
If the project doesn’t have a licence that is compatible with your project, it’s an easy way to remove the software from your list of technology to try. No matter how excited you get about it, there’s no point integrating an amazing open-source technology if the licensing is incompatible with your plans.
2) How often is it updated?
Integrating a project with a stale codebase can be a significant risk. Open-source projects naturally go through cycles of activity, but if the project was last updated several years ago, or if it was updated last week, but that was the only commit in the past several years, then you might want to see if you can find a more actively maintained alternative.
3) How many open issues are there?
If you take a look at the issue log and see a long string of open issues with no sign that anybody is paying attention to them – it’s a red flag.
On the other hand, if there are no issues at all, that’s also a red flag. Having no issues logged doesn’t mean there are no problems with the software. It could mean that nobody cares enough about the project to open an issue, or that nobody is actually using the software.
What you want to see is people opening issues, and that the maintainers and contributors are responding to those issues. That’s a positive sign for a vibrant project.
4) How good is the documentation?
I have found a direct correlation between the quality of documentation, and my overall satisfaction using a library. If the documentation is weak or non-existent, you might simply be better off moving on.
5) Who is behind the project?
Is it an individual effort, or an organisation? Adopting technology developed by an individual has significantly more risk, whereas technology that is being actively developed by a large organisation is much less likely to be abandoned – at least not without warning.
6) How many contributors are there?
If there is only one contributor to the project, and they have a change in their life circumstances, the project can easily stall.
On the other hand, if a project has multiple core maintainers, and they are actively assessing and integrating pull requests from other contributors, then the project has much less risk of stalling and going stale. A large number of contributors also indicates that the project has widespread interest.
In addition to code commits, you can also consider the number of people contributing to documentation and feature requests, and responding to issues.
7) Who else uses it?
When you look at a software engineer’s resume, and you see they spent several years working for a big-brand company, it tends to elevate them in your eyes. We tend to assume that because they got through the hiring process at Brand X, and because they spent several years working there, at the very least they must have been up to a standard that passed the entrance requirements for Brand X. Whether consciously or subconsciously, we use information like that as a shortcut to making our own decisions about their competence.
Software projects work the same way. If you know that a particular technology has been adopted by a tech giant, then you can assume that it has passed their criteria for inclusion into their development ecosystem, and must be at least a certain standard. Just a word of caution – don’t let this be the only criteria you use to judge a project.
8) How popular is it?
There are a number of different metrics that can be used to determine how popular something is. If it’s on GitHub then you can look for the number of stars, forks and watchers. If it’s distributed via a package manager, you could check how many weekly installs the package has.
Alternatively, you can use Google Trends to see how often people have been searching for the project over time.
Go with the crowd – the more popular it is, the more likely the project will last.
9) Does the project have a history of abandoning releases?
Many years ago – before the era of the headless CMS – I had the misfortune of working on a software project where the decision had been taken to use Umbraco, a .NET CMS. It was 2011 and Umbraco 5 had just been released. We built our project using Umbraco 5, and shortly before the project was scheduled to go live, Umbraco made the decision that version 5 – which was a significant change from version 4 – was a mistake, and that they would kill it. All support for Umbraco 5 was abandoned, and then Umbraco essentially rolled back to Umbraco 4. They eventually released Umbraco 6, but it was nothing like the dead-end version our project was then stuck with.
I can’t say how good or bad Umbraco 6, 7 or 8 are, because having been burnt once I have never again trusted Umbraco enough to use it.
10) Is it quality code, or a dog’s breakfast?
If the project collapses, would you be willing and able to step forward and maintain it? Ultimately that’s the question you may need to answer, and the best way to decide is to take a look at the code. If it’s logically structured, you can understand the application architecture, and if it uses common conventions and design patterns, then maybe maintaining it wouldn’t be so bad. On the other hand, if it’s filled with anti-patterns and confusing logic, you may be better off moving on and finding another way to achieve your objectives.