Open Wearables - Open infrastructure for wearable-powered health products.

@piotreksedzik - This is great. I have done POC with ow in my app and is much more economical as compared to the alternatives. Just waiting for the full fitbit integration available on openwearables. Thank you!

@piotreksedzik This is exactly the kind of infrastructure problem that needed solving. The fragmentation across wearable platforms has been a real tax on teams trying to build meaningful products rather than spending cycles on data plumbing. Opening up the scoring logic is particularly smart—clinicians and product teams actually need to understand what's driving recommendations, not just trust a black box.

@ben_gend hey Ben, we specialize in healthcare so solving the wearable data fragmentation problem was the natural one to solve for us. This can be the use case one day when we extend the platform, but for now for the broader roadmap we aim to cover personal (health) data, biomarkers etc.

@ben_gend Interesting take. Maybe it's worth to give a shot as a forked project for now? idk, would be interesting to start a discussion on Github Discussions also.

@ben_gend Ben - fragmentation is the universal pattern, you're right. We picked

health because that's where Momentum lives every day, and going deep

on one domain beats going wide on five. But the architecture isn't health-specific - it's "unify messy

provider APIs into one schema." Same engine could absolutely sit under personal/relationship data.

@ben_gend the parallel is real - fragmentation + privacy sensitivity + no unified view. same problem, different domain

the health focus was a deliberate bet. health data is time-series, physiological, needs domain-specific reasoning

to mean anything. going broad too early usually means going shallow

what are you working on exactly? curious

@janusz_hain Good question, it's difficult to predict what possibly can change in the future, but our architecture was designed from day one to support many providers and make it easy to add or swap them out and this helps a lot in such situations. Every integration is a replaceable module, so when an API changes or gets deprecated, it's a bounded migration and the rest of the system stays stable.

For Android specifically, Google Health Connect acts as a standardized aggregator, so OEM-level schema changes are largely absorbed by Google. Our native Android/iOS SDKs (plus Flutter and ReactNative wrappers) use WorkManager for background sync, making them resilient to battery optimization and permission changes.

@janusz_hain it's a real concern and we won't pretend otherwise

our approach is to abstract at the provider level - when Samsung or Google changes something, the fix is in one place. but manufacturers do break things, we've seen it firsthand

the bet is that an open-source shared layer catches and patches these breaks faster than every team doing it in isolation. community maintenance vs. solo maintenance

Android (Samsung Health, Google Health Connect) is live, but it's not zero-maintenance. nothing in this space is

@janusz_hain Janusz - operator angle: across the Momentum portfolio we've watched teams burn 1-2 sprints per quarter on OEM-level breakage alone. The shared open-source layer doesn't remove that cost - it just makes it absorbed once, not n times.

@pawel_glowczewski That reaction is exactly why we made every algorithm open source. All scoring models (sleep, HRV, recovery, strain, and more) live in the repo. You can read the logic, see the thresholds, and know precisely what shifts each number. No black boxes.

@pawel_glowczewski Fun fact, our algorithm makes the scores very similarto what whoop calculates.

@pawel_glowczewski same here

@pawel_glowczewski yeah once you see it you can't unsee it

a number between 0-100 with no explanation is just vibes with a UI. you change your behavior based on it and have no idea if the model even supports that conclusion

that's the whole reason open algorithms matter

@pawel_glowczewski I feel exactly the same - it’s one of those things you don’t question until someone points it out, and then you can’t unsee it.

I’ve also been relying on these kinds of scores (sleep, HRV, etc.) for quite a while without really knowing what’s behind them. It’s a bit strange when you think about the fact that decisions are often based on those numbers.

It would be great to at least have some basic visibility into how those scores are calculated - or a way to interpret them more consciously.

@qtvinsky yeah that's the pattern - you pay to solve the data problem before you've even validated the product

let us know how it goes over the weekend, happy to help if you get stuck: https://discord.com/invite/qrcfFnNE6H

@qtvinsky And here Open Wearables go ;) Free and self hosted, great advantage.

Of course you still have to pay for you hosting, but I guess nothing is really free.

@qtvinsky 100% agree. Same here

@qtvinsky Jacek - those monthly bills usually start at $200-500/m before you've even shipped, then scale per user. Self-hosted you're paying $10-30/m for a small VPS until traction forces you up. That delta is why we did it this way. Ping us in Discord if Saturday gets weird.

@qtvinsky Same here!

@kamil_zadlo1 Honestly, reading it yes: it's thresholds and formulas, not a neural net. Editing still takes a developer, so it's collaboration between domain expertise and code.

@kamil_zadlo1 Yeah I think so. It's thanks to our detailed documenation.

@kamil_zadlo1 yeah I think so too

@kamil_zadlo1 I’ve been wondering the same - it sounds great, but I’m curious how accessible it really is for a non-developer.

If it’s mostly code or complex logic, it’s probably hard to truly understand without a technical background.

Ideally, I’d love to see a simpler, more readable explanation of what drives the scoring, without needing to dig into code.

@kamil_zadlo1 As a running coach (not a developer), I can read the logic fine, thresholds, weights, conditions. It's closer to reading a training plan than reading code. What matters to me is being able to say to an athlete: "your recovery score is low because HRV dropped AND sleep was short AND yesterday's load was high", not just "the algorithm says so." When the logic is open, I can actually explain the number. That's the real value for coaches. What do you think?

@kamila_kuc Garmin exposes quite a bit through their API: sleep stages, HRV, body battery score, stress, SpO2, workouts, and heart rate time series all flow through. The body battery value itself is Garmin's proprietary calculation, so you get the score but not the formula behind it. That's why we also ship our own open recovery algorithm: same inputs, visible math, adjustable thresholds.

@kamila_kuc I would say, garmin (next to Apple) expose the greates volume of different statistics.

@kamila_kuc Good question — I’ve always had the same assumption about Garmin’s metrics being pretty locked down.

@kamila_kuc Body Battery is Garmin's proprietary score, they keep the inputs closed so we can't touch it

but everything Garmin shares via API - HRV, sleep stages, stress, SpO2, activities, heart rate - we expose. and our own open scoring algorithms compute recovery, sleep quality and strain on top of that

so you lose Body Battery, gain full visibility into what's underneath it

@kamila_kuc Congrats 😊 I’m in a very similar situation - also using Garmin and always assumed Body Battery was a complete black box.

From what I understand, Garmin exposes quite a lot of data like sleep, heart rate, stress, and even the Body Battery score itself. But the actual logic behind it is still hidden.

So you get the numbers, but not really the “why” behind them, which is the most frustrating part as a user.

@tomik99 nobody fixes the data layer first because it's unglamorous. but you can't reason over garbage -sequence matters

the reasoning layer is honestly what we're most excited about. raw numbers mean nothing without context, that's the whole point of building this

and "but open" is what changes the Stripe analogy - you can audit, fork, run it yourself. that's a different relationship with infrastructure entirely

"Stripe for health signals but open" - we love that, might steal it

@tomik99 Thanks Tomasz, the "AI in health without fixing the data layer first" frustration is exactly what pushed us to ship this. Most health AI demos break the second you put real, multi-device, multi-format data behind them.

@tomik99 Tomasz - "quietly unlocks entire categories" is exactly the read. From the ops side I kept seeing portfolio teams burn 3-6 months on the same Oura/Garmin/Whoop plumbing before they could even start the actual product. That's the tax we got tired of paying. Open part isn't a marketing flourish - it's the only way infra like this actually compounds across companies.

@tomik99 Exactly. The most interesting part is - after 6 months of work we are just starting with implementing AI. So much of old school software work has been done before.

@sylwia_kustrzycka Exactly the observation we built around. Garmin users generate some of the richest longitudinal data out there and most platforms surface maybe 20% of it. We pull the full range: sleep stages, HRV, body battery, stress, workouts, SpO2, and more.

@sylwia_kustrzycka But Garmin is still among 1st classers tbh. Check out Suunto for example, that's a hidden gem ;)

@sylwia_kustrzycka That’s a fair observation — Garmin users are often the “serious end” of tracking, but a lot of apps still optimize around Apple Health and Oura first.

Garmin’s data depth is definitely there, but it tends to be fragmented across metrics, so the value often gets lost unless something actually consolidates and interprets it well. If an integration can do that cleanly, it’s probably a big unlock for endurance athletes and coaches in particular.

The real gap has always been less about access and more about making the data usable in a consistent way across different contexts.

@sylwia_kustrzycka Garmin users are seriously data-rich and somehow always the afterthought

the API is painful but the data depth is real. glad we got it right

@sylwia_kustrzycka Noticed the same - Garmin often gets overlooked, even though the depth and quality of data is actually really solid. It just rarely gets used properly.

@krzysztof_kundys this is exactly why we built it

"own your data" is marketed everywhere but the export is usually a CSV with 12 columns and no context. that's not ownership, that's a file dump

the goal is that your health data actually does something - feeds AI, triggers automations, gets reasoned over. not just sits in a folder

glad you upvoted, means a lot on launch day

@krzysztof_kundys Exactly! Whoop charges me $30/month and won't let me export my data in any useful format. I didn't realize this was a solved problem. Congrats to the team on shipping this.

@krzysztof_kundys That’s a pretty common realization after switching — the “you own your data” message sounds straightforward, but in practice the export layer is often just raw logs without much structure or context.

@krzysztof_kundys "own your data" as a feature that doesn't actually let you own your data - that's the whole problem in one sentence

glad you upvoted, means a lot today