@ramack Thank you for your honest feedback. If this is alright for you, then I would prefer to keep the discussion generic / FOSS centric and not app specific.
In your original request you were interested in Bluetooth speed and cadence sensors - as I wrote, most speed and cadence sensors implement the standardized Bluetooth speed and cadence profile. Heartrate (HRM) is another standardized profile that is generally available for “normal” Bluetooth based chest belts. (FOSS ok)
There are however several devices, which only communicate via Ant+ and then the FOSS model might not work, because the libraries seem to remain proprietary. (As I have pointed out) Dedication to F-Droid would currently eliminate any support of ANT+ devices. (Feel free to have a look at the Ant+ device directory - and yes, you will there find many bike computers, bike power meters etc. which other cyclists apparently find relevant: https://www.thisisant.com/directory/ - another proposal would replace ANT+ software with a dedicated device bridging ANT+ and Bluetooth. Example: O’Synce Coachsmart) (FOSS ?)
If you are really interested in cycling, navigation, endurance sports, performance measurement and analytics, then you will eventually notice, that for instance elevation or weather can have quite a significant impact on your ride, which many cyclists - contrary to your opinion - would classify as relevant. For those requirements, other limitations can arise (third party data / Apis) , as I have clarified previously. (FOSS not ok)
If you wish to integrate data from additional sensors, wearables or fitness trackers, if you wish to integrate such data into specific fitness platforms or health care systems, then you will find, that most of these devices / platforms require dedicated Apis / Api keys, NDAs, NDKS, licensing fees etc. which might pose a challenge for F-Droid (as I understand it). (FOSS not ok)
Granted, your initial inquiry was about an app based solution, but you might find, as have many other athletes, cyclists, triathletes etc., that there are activities, where the app might prove useful for processing and analyzing the data, while dedicated devices are more appropriate (swim in triathlon, long bike tours vs. cellphone based tracking / battery constraints, etc.)
While in general the FOSS idea is absolutely admiring, honorable and convincing, and this is why we are looking for ways to participate - when users (at least currently) loose access to many available devices, miss third party data or functionality, then I am not always certain, if this improves the user experience, if this is in the interest of the user.
Sometimes the picture is unfortunately not always black and white and the development decisions can be more complicated, balancing different, partially opposing needs. In our case the decision was made, to include open / free solutions whenever possible (As I indicated previously) - allowing a user to make a “free”, conscious decision (free = freedom), between for instance Bluetooth and Ant+, between Google Maps or the several maps provided by Open Streetmap, or between Google Drive and NextCloud -
all of these choices are literally just one click apart. We simply aim to empower the user by providing these alternatives - forcing the user to accept one solution only is not unfortunately not compatible with our coding preferences I am afraid.
The next point also does not render your argument invalid, but Signal Protocol library used by WhatsApp is open-source and published under the GPLv3 license. (Signal Protocol - Wikipedia) Hyperledger is published under the Apache 2.0 license … etc. etc.
A cycling / fitness app providing similar features to those offered by commercial / proprietary solutions is quite complex, and thus includes a diversity of specifications, interfaces, and data sources, which are (unfortunately) not (yet) all available for free / as FOSS. I have provided a few of these challenges in a previous response - if you personally do not need all functions, the better.
Sidenote: Just to be clear: If FOSS alternatives would be available for these requirements, we would be delighted to implement them right away. I hope, that these alternatives will be created shortly.