"This is why I think no one should trust companies that sell you software, that you can't host yourself, for something as critical as documentation and source control."
Omniref founder here. Please try not to think this way, particularly if you're a small team. I realize that this is kind of an impossible request (especially given the source), but one of the things that makes it immensely difficult to start a software tools company is the unwillingness of developers to use hosted tools, particularly if those tools are new and/or different.
When you're a small team, you can only do so many things at once. Supporting hosted users, even in the best-case scenario, takes a lot of time and effort. It's (sometimes) worth it if you can land bigger clients who are willing to pay a premium for that effort, but often those bigger clients won't pay until you have a reputation with smaller teams, or they require lots of custom development that takes even more of your time. So you have a chicken-and-egg problem. It's not impossible to make it work, but it's harder than it should be.
If you're running a small/medium team, try to realize that innovation can only exist in this area if we're willing to support startups when they're younger. I've personally used lots of startups' services over the years for my dev work. Some succeeded, others failed, but trust has never been an issue.
Yes, because tools hosted elsewhere have the problem your shutdown is exemplifying. A definite expiration date /sucks/. Even if it is a month out, that means having to do a lot of retooling to pull out all the bits and pieces that have been built in that rely on the third party. Were it a hosted solution, a transition plan could be made that isn't a mad rush to make sure all the data that's in those annotations is saved once the lights go out.
What format will the data be in? Will it be given in a format usable as the way your service provided? That either speaks to the fact that the service wasn't needed (which doesn't sound right) or that the users will need to do a lot of sword sharpening to fix the gap in their tooling now that you are gone.
In effect, people are going to miss you.
Also, for the kind of work that some people do it's impossible to use any outbound network stuff that looks at the source code. That's off the table. That's also a huge client base.
"but one of the things that makes it immensely difficult to start a software tools company is the unwillingness of developers to use hosted tools, particularly if those tools are new and/or different"
Rather than see this as a fault with developers, perhaps this is an indication that hosted services aren't the best model for development tools. (or really any tools that are "mission critical" to someone's daily operations, whatever they may be.)
For that reason, when I choose dev tools I strongly prefer to stick with open source when it exists, or if purchasing something, a product that is perpetually licensed and runs locally. There are occasional exceptions, but they have to provide some notable benefit from being a service. (Github is a good example)
I get why SaaS is nice from a startup's perspective (not to mention being the trendy thing, and probably what investors expect to see), but if it doesn't work for your customers, maybe it's time to look at other approaches.
"when I choose dev tools I strongly prefer to stick with open source when it exists, or if purchasing something, a product that is perpetually licensed and runs locally. There are occasional exceptions, but they have to provide some notable benefit from being a service. (Github is a good example)"
This stuff isn't a "trend". It's rational. People who use your software but don't pay you money are not your customers. They're your users. Customers are the users who pay the bills and make you a business.
GitHub is definitely an interesting example. I remember hosting my own SVN and Git servers at companies. It wasn't fun, and GitHub offered an easy-to-use alternative with a nice UI. That's why teams paid for GitHub. But now you can provision a data center with a mouseclick. The market has changed, and with a number of free clones out there, code hosting is becoming a commodity. It's a race to the bottom.
The "notable benefit from being a service" that made GitHub a compelling purchase (i.e. backups, stability, availability etc.) is the same core benefit that any SAAS product offers. But in a world of cheap virtual hosts, it's harder and harder to make that sale. Especially when your closest competitor is your own open-source code.
My point is, it isn't surprising that you'd choose the cheapest tool you can find that does the job. That's what everyone does. But it doesn't make a great business to be offering your source to the world and hoping to differentiate on features. That's why people are trying to thread the needle with "self-hosted" offerings...which cost a lot of money.
Paying customers aren't a trend, but only allowing customers to pay on a monthly subscription for service model does seem like one to me. And I agree it may often be a rational decision for the service provider, but I think it's not as often a rational choice for the customer.
Price isn't my main requirement, I'm perfectly willing to invest some cash in a better tool when it exists. I do have some ideological and practical leanings towards open source, but I'm also pragmatic about it and willing to purchase commercial software that provides enough value.
My concern here is about my ongoing right and ability to continue using a tool. Beyond any price I might pay to license it, I am also going to invest time and effort incorporating it into my development process, and would incur significant switching costs to undo, replace, and repeat that when a service provider goes out of business, pivots to a new product, removes features I depend on, raises prices to a point I can't afford, etc...
Open source avoids some of those concerns, and provides me with another option if the others happen; So does a commercial product that I operate myself; But with a hosted service any one of those things can become a "my way or the highway" decision that is forced on me, often with little warning or planning.
"GitHub offered an easy-to-use alternative with a nice UI. That's why teams paid for GitHub....The "notable benefit from being a service" that made GitHub a compelling purchase (i.e. backups, stability, availability etc.) is the same core benefit that any SAAS product offers."
It's an interesting take on our different perspectives that those weren't the things I had in mind at all when I brought up GitHub. I agree those were the draws that got users initially, but as you mention, they have been devalued by technical improvements in their competitors and infrastructure in general. I see GitHub's value now in their huge base of users and "social" features, and the network effects that creates. You can't easily replicate that in a free alternative, even if you were to perfectly clone (or even improve) GitHub's features.
Omniref founder here. Please try not to think this way, particularly if you're a small team. I realize that this is kind of an impossible request (especially given the source), but one of the things that makes it immensely difficult to start a software tools company is the unwillingness of developers to use hosted tools, particularly if those tools are new and/or different.
When you're a small team, you can only do so many things at once. Supporting hosted users, even in the best-case scenario, takes a lot of time and effort. It's (sometimes) worth it if you can land bigger clients who are willing to pay a premium for that effort, but often those bigger clients won't pay until you have a reputation with smaller teams, or they require lots of custom development that takes even more of your time. So you have a chicken-and-egg problem. It's not impossible to make it work, but it's harder than it should be.
If you're running a small/medium team, try to realize that innovation can only exist in this area if we're willing to support startups when they're younger. I've personally used lots of startups' services over the years for my dev work. Some succeeded, others failed, but trust has never been an issue.