To (sadly) be fair, Travis has already been struggling mightily with tech debt the last few years. There have been a lot of issues surface and re-surface that sure seem like they shouldn't be a big deal.
For example, setting a build to use ruby 2.4 is supposed to run the latest ruby 2.4.x, but would frequently build against ancient, unsupported rubies for a while, before being silently fixed.
The extremely long lag combined with some communications from Travis developers on related Github issues strongly implied that shipping these was a highly manual process, not just a matter of updating a few Packer configs and calling it a day. I'm not arguing that it's trivial, but it should have been a week or two of effort at most.
Now, lots of their userbase could be covered by using docker environments, or by the natural isolation supplied by the language platform (virtualenv, rbenv, etc), but at the end of the day, it's frustrating if your CI environment is drifting away from what developers are actually using themselves.
This was concerning for several years now. Who knows when 18.04 will make an appearance. 2021? Never?
I appreciate what they were trying to do with their multiple versions of every language in their stock images. But, in practice there were numerous compatibility problems. If you look at the C++ tickets, you can see how utterly unusable their offering was for this language. From the outside, it looks like they painted themselves into a corner and are mired in technical debt. Quite why it took two and half years to support 16.04 is a question I'd be very interested to know more about.
One solution is to use custom docker images. But that negates any advantages Travis might have had. I can run a docker image anywhere. So when I switched over to GitLab, I use GitLab CI with docker images and custom runners to do fairly comprehensive platform coverage. Something Travis will never do.
They also made a questionable business decision in tying themselves to GitHub. Why no integrations with BitBucket, GitLab, Jenkins, and all the other hosting and automation solutions out there? I had to write Travis off purely because of its lack of availability. The above problems were also an issue, but if it doesn't integrate with your hosting solution, it's a non-starter.
On top of how late "new stuff" often was, I never understood why they kept out of date, unsupported stuff running for so long - especially for free, open source projects.
If anything, I feel like they are actually doing the open source community a disservice by supporting build environments that are no longer supported by the upstream community. They legitimize testing against ancient, unsupported environments, rather than moving forward deliberately to stay on a supported stack.
I understand there is a burden on updating software, but given all the trouble we have with breaches in old software, we need to bias the world toward staying on stacks that get security updates rather than sitting stagnant.
For example, setting a build to use ruby 2.4 is supposed to run the latest ruby 2.4.x, but would frequently build against ancient, unsupported rubies for a while, before being silently fixed.