Yes. Would you rather have ice cream or get punched in the face?
> Would you maintain it?
If maintaining it means scheduling updates through my host's package manager or running docker pull, and not "hey it's thursday, time for a new configuration format", then sure.
> How much is your time worth?
Enough to never host Elasticsearch, not enough to go SaaS-only.
Any service with any level of client integration will a) version their APIs, and b) keep things sufficiently stable so that clients aren't constantly breaking.
I currently maintain about 280 different API integrations. I have a team that does constant maintenance. Usually 1-2 API breaking changes per day is what we see after you get past the stable big ones. Even versioned APIs kick you off the old version pretty regularly. In the upcoming months we have 3 scheduled version bumps that are mandatory as they will discontinue the old version completely. Not "use the new version for more features", like completely 100% "we are not supporting v2 any longer. You won't get responses in 60 days. Good luck."
It's easy to say, "they're doing versioning wrong" but it's the reality.
Everyone does oauth wrong. Everyone does versioning wrong. Everyone adds or removes fields that were once critical to someone's workflows. Maybe 25% of our integrations are a joy to work with. Once you get to the smaller players, things start to get weird.
One thing I notice is how some do the constant refresh token and most don’t.
And if I was trying to self-host software that integrated with 280 different APIs, I'd probably have that problem, too.
Most people don't need 280 different APIs. Then need a half dozen? Maybe a dozen? Most of which are likely to be the "stable big ones" that you refer to.
So the rate of breakage in your experience just isn't applicable for anyone doing anything at the hobbyist level.
That's not to say it's maintenance free! But I've been running my own automation with Huginn for a year now, and for what I need, I could not justify $120 per year.