I’m currently looking to reverse engineer at least some support for OneTouch Verio and FreeStyle Optium devices I own (more on that once I have something to talk about I guess.)
While doing this I figured out that there are at least two more projects for handling glucometers in the open source world: GGC, which despite its ‘90s SourceForge website seem to be fairly active, and OpenGlucose. I know about them, and I looked at their websites, but I’m not particularly keen to look into, or contribute, their codebase (except for the build system.) The reason is to be found in my own glucometerutils project.
When I started working on it, I very explicitly wanted to license it with the most permissive license that I was able to. I should probably have documented why I wanted to do that, but I guess it’s better late than never.
The Python code I wrote is designed to support multiple glucometers, although it realistically supports only a couple, but it’s very rough, as it only allows you to download the data off the reader, clear it, or set the time (the latter being probably the most useful part of it.) I was really hoping that by adding support for multiple reader, someone else with more of an UI/UX background than me would help by building a proper analysis UI for the data it downloads, but this has not happened (while I see GGC at least has some UI, though in Java, and I expect OpenGlucose to have something, too.) Unfortunately, the fact that even LifeScan stopped providing the protocol documentation for their meters makes it very unlikely to ever take off.
But even after that, my idea was still to be able to build a permissive low-level access library for different glucometers, and the reason is mostly philosophical. While I love Free Software, I think that enabling anybody to build a better diabetes management software, whether Free or not, is a net win in the fight against diabetes.
Sure, I would be enthusiastic if such a software was to be built as Free Software, but I don’t want to hold my breath to that: the healthcare industry is known not to be spending much time to care for the final user (more on that in future posts.) On the other hand, having a base interface that can be contributed to without having to open any business logic could entice some company to give back at least the base interface for the glucometers.
Two years in, I’m thinking I made the wrong decision. Right now this difference in philosophy makes it just very fragmented, with GGC having the most device support (but relying on Java, which is a real problem for people like me who are banned to have it installed on their work computers), and a decent UI, even though it’s very hard to find out about it, and has a website that reminds me a lot of the ‘90s as I said earlier.
I think what I should be doing now is translating that Python code into human-readable specifications (since the official specs coming from OneTouch that I used to implement it are overly complicated), and release those under CC0. After that, I can probably contribute support for those meters to OpenGlucose.
As for the stuff I’m reverse engineering now, I think I’ll essentially do the same: my Python script would be a nice proof of concept for the results, then I can write the specs down, and contribute it back to have at least one less project intending to be fully functional.
