In relation to being a CTO of a small startup, yea OSS maintainer risk is tough. You want to use projects that are used by hundreds of companies and actively maintained. In my case, I am the primary maintainer and it's used for a cloud service called M3O - https://m3o.com. I think it will take a while before we're in a place to warrant more buy in but my hope is eventually it'll get there or at the very least people will come to use the APIs serviced by M3O.
On architecture, I mean you're quite literally talking about software "build vs buy" tradeoffs for the entirety of all software you ever write. In this case, do I integrate something else or write it myself. I think that comes down to the same assessment of whether you should offload to some other piece of software versus your own. When it comes to domain specific services this is always tough yet we see the adoption of the likes of Twilio for SMS, Sendgrid for Email and Stripe for Payments so I'd argue we're getting closer to blurring the lines now.
On cost, you can use the hosted offering - https://m3o.com - but at this point the reason I'm sharing the open source services is really because I think that adoption curve to a cloud service takes a lot longer especially with domain specific services. I would argue these services while on the surface appear a commodity, the development time and integration cost of using bespoke independent APIs or services has a much higher cost. Everyone internally ends up writing proxy/shims to SaaS products to try eliminate this risk for themselves. I just think we should standardise a lot of our business logic service consumption.