There should be a corollary to NIH Syndrome[1] that takes into account 3rd party APIs. The way I see it, it's not about reinventing the wheel, it's about having your house in order.
Whether a developer (or business person) made a business decision to outsource CI has nothing to do with technical competence.
Using SaaS for any business data has a risk, but usually it's worth it. I'm sure you use slack, slack could be breached, and I'm sure no one at your company has ever slacked a password to someone else.
Developers tend to trivialize this: we tend to only consider the initial setup time, and pretend no further work is necessary.
you can say that they are 'doing it wrong', but without execption the shops I've been in that use CI tools
o have one guy, maybe no longer with the group, that set up the CI deployment and no one else knows how to deal with it
o dont have a firm control of their development build and dependencies and the different CI environment is a constant source of shear
o are running a service with its own deployment chain, which differs in environment from the CI server and should arguable be used for tests
o dont have a decent way of running the tests outside the CI environment at all, which makes debugging CI failures pretty problematic
o because of the single maintainer issue, new tests often dont get integrated into the CI, which is really conterproductive
o for distributed services and services with runtime dependencies, the CI isn't really providing the whole picture (meaning we should really be using the delopment tools to spin up transient test instances anyways)
o the state in the CI often tool doesn't get packaged up with the repo, so it doesn't transition easily to other development teams
I'm very sympathetic to avoiding wasting time on home grown solutions (even if they are as trivial as 'run these 50 tests and collect status). but if the development effort is sufficiently small, or sufficiently complex, I think external CI is actually costing more than its worth, or giving people a false sense of comfort about their testing and dependency management. thats all without considering any trust issues.
That said, the same could be said of any piece in the stack: Why use a framework? Why use Github? Why use hosted email? Why use cloud? Why not hand new hires a blank laptop and a USB key with the latest Ubuntu?
That's what I got at my last two jobs (minus Ubuntu), and I loved it.
The important point is that there are now 8 attack surfaces instead of 1. Whether they're analytics or pad-string doesn't really matter.
That's the best case scenario. What if these 8 companies also give the source code to other companies?
Pusher is a SaaS product for websockets and push notifications. I think it's reasonable that a company like CircleCI might outsource this instead of maintaining the infrastructure for it in-house.
Launch Darkly is a feature flagging service. While I feel the value is much less than Pusher (and I'd be inclined to just build an in-house solution), I think it's still a relatively reasonable tool to use to create a better user experience.
Intercom when used for customer communication is also something that I feel I'd want as a user, although this could perhaps only be loaded when requested by the user.