[lowercased]

> I suspect that, although there is a market for the products, noone is interested in taking on the software they worked on.

It may be extremely difficult to do that, for at least a few reasons.

In some cases, the tech is going to be very niche/old, and it will be difficult for people to get up to speed on it.

The business is likely built on a lot of personal contacts, and not all will want to switch to some 'newcomer'.

Many of these smaller business reliant on niche software will go out of business themselves, or be acquired by larger companies that will replace the niche software and process with something else.

The current customers may not actually want anything other than regular updates while paying minimal support/maintenance contracts. Someone established can live off that, but someone new will have to spend a lot of time learning, and the income may not be sufficient to justify all the learning.

I worked on a project in 2018 where some of the (small) company was still running on a combination of foxpro/db2, with a bunch of custom code by an indie/solo vendor who had 'retired' probably 5 years earlier. He'd 'sold' the company to another individual who ... kept it going, but couldn't easily deal with new needs (new reports, etc). Another vendor did an upgrade on the hosting server, and nothing worked after that. The upgrade was a base NT upgrade, and there wasn't any easy way to 'go back' quickly. Things ran off an RDP session to a laptop in Canada running some weird trial emulation tool under windows 7 (this was how it was translated to me from various parties).

[jaclaz]

Well, if I may, there is something that doesn't sound (to me) "rational".

I have seen quite a few of these cases where a larger company buys the old one (essentially to get a list of their current customers) and then terminates the product replacing it with some crappy new stuff that usually completely fails to work, but in this case the soon-to-retire programmer at least gets some (little) money (and knowledge is lost forever).

But if the one man company is going to shut down because the programmer is going to retire, the acquisition cost for a young, willing programmer is 0.

This hypothetical young programmer could - I believe - invest some time to understand not so much the actual codebase, but rather the workflow of the program and re-write it along that same workflow in a new language/platform/whatever.

I am pretty sure that those niche users would be ready to pay a fair amount of money to have something modern/updated that actually works and works like the old one.

What I have seen often is that the new program, for no real reason, has been written by someone that most probably is much more brilliant at programming but that knows nothing about how the program is actually used, has no idea about how to deal with some "edge" cases (that already surely happened in the tens of years of life of the old software), etc., in some ways it is like all the experience accumulated over the years is suddenly lost and the new program repeats the same (or worse) mistakes/issues that already happened (and that were already solved).

Maybe the problem is that there is not an easy way to tell to the world "I am going to retire, any taker?"

[lowercased]

> This hypothetical young programmer could - I believe - invest some time to understand not so much the actual codebase, but rather the workflow of the program and re-write it along that same workflow in a new language/platform/whatever.

> I am pretty sure that those niche users would be ready to pay a fair amount of money to have something modern/updated that actually works and works like the old one.

I don't know. My experience is, for many smaller niche things, they're entrenched in orgs and used The One Way, and any deviation - change a button label, add a menu, etc - will result in a lot of complaints from existing users. They'll have to 'retrain', etc.

No doubt some people will appreciate and welcome 'new/modern' stuff, but many won't. And figuring that out ahead of time is... time. and effort. And along with that, there's usually heaps of institutional/domain knowledge that just can't be replaced without... time in the trenches.

It's not that it's not possible, it's just not typically 'worth it' for most people. ROI is too low compared to other options.

[handrous]

> I don't know. My experience is, for many smaller niche things, they're entrenched in orgs and used The One Way, and any deviation - change a button label, add a menu, etc - will result in a lot of complaints from existing users. They'll have to 'retrain', etc.

People hate this just as much in almost any software (or, most any UI, physical or virtual, for that matter), they just often don't have a way to push back.

You wouldn't know it based on current trends, but consistency and predictability are king in user interfaces, as far as actual usability goes. So much so that high levels of severe bugginess can be preferable than less-severe and common bugginess, if the former is consistent and predictable ("if I press this button then that one, the application will crash or glitch, every single time, no matter what state the program is in—so, I won't do that") and the latter isn't ("about once a day this button takes me to the wrong screen, and the behavior seems random"). If your users are your top priority, changes will occur gradually, and only with excellent motivation. Grand re-designs are among the most user-hostile things you can do (despite their popularity).

[EDIT] to be clear, they don't have a way to push back in the modern age of rolling updates and old versions being infeasible to obtain at all, possibly broken even if you can, and, most likely, full of known vulnerabilities that will never be patched. In the old days of desktop software that you actually purchased, and that operated just fine entirely offline, the way to push back was not to upgrade, and it was common.

[lowercased]

The other pushback, in the context of the 'indie/solo' niche software stuff, is to actually call or email the original person and complain.

[spoonjim]

Yes, that young, entrepreneurial programmer can be found, but won’t have the domain knowledge. Look at the examples above. You can’t sell Marine mapping software without knowing something about marine navigation. You can’t sell beekeeping software without understanding beekeeping. Plus you need the general business operation skills. Finding a programmer who knows beekeeping and wants to take on a low growth business is not as easy as finding a programmer on Upwork.

[lowercased]

Yep. There may be 'takers', but will the existing customers want to work with them? So many solo/indie niche packages are built on the relationships, and replacing those - and the trust around them - is hard.

A client told me about someone they knew who did ballroom dancing software - it kept track of competitions, standings, etc. And... it seemed like decent money, looking at the pricing, and the size of the market. But the market didn't seem big enough for multiple players, and everyone trusted/knew/used the one main player. If/when he goes (or perhaps already has), I'm sure people will find another way to manage their stuff, but before then... who's going to come in to a market like that? How do you 'beat' the incumbent? Lower price? Who would switch? How do you convince people to switch to something unknown, potentially losing years of data, having new training costs, to ... save a couple hundred bucks maybe?

I'm sure there's hundreds of these sorts of services out there that are surviving, but don't have a huge market for competition, because the barriers to entry are too high relative to the return.

[jaclaz]

Yes, but I was talking more about "passing on" the knowledge/experience (as opposed to losing it and start anew).

Regarding your "The One Way", sometimes that one way is actually the one that works better, as it was developed and fine tuned over the years by a dedicated programmer that had constant feedback by users.

Probably that ballroom dancing software had a way to input (or present/output) data in a form that makes sense to the users.

When suddenly comes the new (otherwise brilliant) programmer that - knowing nothing on the specific field - invents his/her own way to input data or render it that the users find awkward or slower or less intuitive or whatever, with the new program that cannot import old data (or imports partially), that cannot use the same B&W printer because the output is highlighted with colours and not with bolding/underlining, etc..

No surprise that the users of the old software (if it is still working) won't jump on the new bandwagon.

[airbreather]

But that is why there were apprentiships, and I have seen docos about Japanese solo or small workplace craftsmen who take on 70yo apprentices.

But it would need planning, and a certain class of able worker who is happy to not continually be dreaming about "changing the world".

But sometimes better is just keep persisting with what works, not everything is better disrupted.