This is probably the most controversial dimension to consider, but also one of the most important ones to pay attention to when dealing with new technologies. While it is absolutely true that popularity does not equate to technical merit, it can be assumed that:
- More people using a particular tool will be able to provide better integration help.
- Solutions to problems will be easier to find.
- If the codebase is open source, the project will be more likely to have fixes and features added to it.
In another way of describing the problem, can you afford to risk weeks/months/years of integration work on a tool that is unproven or on track to be abandoned in the next couple of years? If you are a really big shop with massive budgets this might not be an issue but in most cases, you will not have the opportunity to play with integrating different competing technologies to see which one is the best. While there are times that there are perfectly valid cases where taking a calculated chance with a new tool is warranted and desired, in the majority of cases due to the sheer complexity and longevity of cloud systems the cost of failure is extremely high, so a pragmatic approach is generally recommended but your individual requirements may vary, so choose accordingly.
To evaluate this aspect of a project there is a variety of tooling that can be used, but the simplest and the easiest are the GitHub project forks/stars (for OSS projects), Google Trends (https://trends.google.com) projections, and general social media feedback from people that have used said technology. By looking at movements and shifts in these values, extrapolation of long-term viability can be made with a relatively good accuracy and combined together with comparisons against existing tooling can create a good picture of the general pulse of a project as well. Upwardly-mobile projects generally have been indicative of superior technological base but in some cases, this was spurred by rejection of existing tooling or a big marketing push, so don't always think the popular option is better when evaluating a tool.
In the preceding screenshot, you can see a distinct increase over time in interest in Kubernetes that somewhat mirrors community adoption and acceptance of that orchestration tooling. If we were to implement this technology ourselves, we could be reasonably sure that for some period of time that we would be using a tool that will be easier to work with and get support for.
When comparing Kubernetes against Marathon and using the same technique, things get very messy as Marathon is also a very common long-distance running activity, so the results get muddled with unrelated Google queries. In the following screenshot, we overlaid the results versus a couple of other cloud-related keywords and you can see that there's something wrong with our data:
However, taking a look at the top-right side of their GitHub pages and the forks/stars we can see how they compare (3,483 stars and 810 forks versus 28,444 stars and 10,167 forks):
Compare the preceding GitHub page with the following page:
In this particular example, though, it is very hard to see long-term trends and we've mentioned that these two do not solve the same kind of problems, on top of which these two tools have vastly different setup complexity, so proper evaluation is really difficult.
Something that is really important that we should mention before moving on to the next dimension: a common and highly-recommended risk mitigation for immature tooling (this scenario is much more likely than you might think) is that your own developers can be used to fix bugs and add features to relevant upstream projects if they are capable and allowed to work on them. If a tool is such a good fit for your infrastructure and you can throw development resources behind it, it will not make much of a difference if it is popular or not as long as you can make it work for you in the way that you are satisfied with.