As documented at https://dev.cancel.fm/wiki?name=OpenSSL+Linux+Issues, Ripcord does not start up on current Debian systems. Apparently, multiple users experienced this bug already. I describe the symptoms in the following so that others can associate the symptoms with the root cause. When starting the current AppImage on Debian (testing), a window appears but closes immediately. Terminal output is the following:

raphael@home:~/Downloads$ ./Ripcord-0.4.26-x86_64.AppImage 
qt.network.ssl: QSslSocket: cannot resolve SSL_set_alpn_protos
qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_alpn_select_cb
qt.network.ssl: QSslSocket: cannot resolve SSL_get0_alpn_selected
Auto configuration failed
140072629958400:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:185:filename(libssl_conf.so): libssl_conf.so: cannot open shared object file: No such file or directory
140072629958400:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:244:
140072629958400:error:0E07506E:configuration file routines:MODULE_LOAD_DSO:error loading dso:conf_mod.c:285:module=ssl_conf, path=ssl_conf
140072629958400:error:0E076071:configuration file routines:MODULE_RUN:unknown module name:conf_mod.c:222:module=ssl_conf
QMutex: destroying locked mutex
QObject::~QObject: Timers cannot be stopped from another thread

The workaround suggested by https://dev.cancel.fm/wiki?name=OpenSSL+Linux+Issues is to start the application with an environment variable set:

OPENSSL_CONF="" ./Ripcord.AppImage

It seems that the developer does not believe this to be an issue with the software but with the operating system. I would disagree. From the perspective of an end user, it is Ripcord that is not working. I would appreciate if Ripcord would automatically recover from a missing/problematic library instead of failing (almost) silently. This is especially bad because for these users, the first - and probably only - experience is that Ripcord does not work at all.

If the developer believes that it is not reasonably possible to fix this bug, I would strongly suggest improving documentation and error messages. A warning on the download page and/or an error message if startup fails would be very helpful.

No. It's Debian that broke it. It used to work. I tried to find a workaround and gave up. No way to detect this before it happens, and I don't want to spend time developing some complicated meta-meta-launcher-detector-relauncher-wrapper thing on top of AppImage just because Debian alone is messed up. I won't let them take any more of my time on this earth.

OK, let me add a little more. If someone does know of a way to fix this that isn't complicated or difficult, let me know, and I'll do it.