"How can I help?"

We get asked this question a lot. It's often asked by engineers who have a vested interest in solving these problems, usually because they or a family member have type 1 diabetes. And we definitely can use some help. But what kinds of help?

Tidepool's goal as an organization is to help as many people as possible — to have a real impact on the experience of managing type 1 diabetes. The best way for us to do that is to get our systems approved by the FDA so that we can get them into the hands of as many people as possible. Without FDA approval, we are only useful to the tiny fraction of hackers who want to reproduce our work on their own systems for their own use.

Consequently, that means that the help we need most is to achieve that goal of FDA approval. Most of it is not sexy work. It's not new visualizations or new apps; it's not integration of new forms of data like exercise or meal data. It's just the hard work of taking the product we have been working on and pushing it over the finish line.

If you want to see the kinds of things we're working on, please take a look at our developer microsite as well as our public Trello boards:

• The blip board contains our current front-end tasks.
• The platform board contains our current back-end tasks.
• The blip product backlog contains everything we're thinking about for the next year or so and quite a few things we'll probably never do.
• The Platform Roadmap contains the things that we expect to do on the platform (back-end) over the next 6-12 months.

Most of the things we need right now require a bit of collaboration and coordination. They typically won't just be the sort of thing you can run off and do for a few weeks and come back when you're done. We do hope to get to that point once we're more stable, but right now things are moving so fast and changing so often that it's best to stay in contact so we can make sure your work isn't wasted. That's why everything below says "please contact us" so we can coordinate.

So let's answer the question "How can I help?"

What we need most

Help with user testing

Until we have FDA approval, Blip is not approved for distribution or use, so please DO NOT USE BLIP TO MAKE THERAPY ADJUSTMENTS. However, you can help us out by building it locally, testing it and giving us UI and functionality feedback. Instructions are on our developer microsite.

Please give us all kinds of feedback -- tell us what works well, what's hard, what's easy, and what doesn't work right.

Help with test automation

If you're an engineer, help us write test code that exercises our platforms. It's pretty easy to get set up with our development environment and to run our acceptance tests. The acceptance tests aren't nearly complete enough — please help us write more of them.

If you can help with this, please contact me (kent at Tidepool org) so I can point you at particular repositories that are high on our hit list.

Documentation and tooling

It's pretty much a given that developers rarely write enough documentation. We started out building out API documentation using Apiary but it has now fallen behind because it's not integrated with the code in a useful way. We need a documentation system that is part of our source code so that keeping it up-to-date is part and parcel of maintaining the code.

We have some ideas about how to achieve this but it has not yet risen to the top of our priority list. If you think you can help, particularly with respect to writing RESTful API documentation in the Go language, we'd love to hear more. Please contact me (kent at Tidepool org) and let's start talking.

Help with the Universal Uploader

One of the things we think is really important is our concept of a Universal Uploader. At the moment, retrieving and analyzing data from a given device (pump or glucose monitor) requires that you use proprietary software, and to put it charitably, that software isn't usually very good. It's hard to use, visually crude, and frequently fails to run on newer computer systems.

We believe we can do better. At Tidepool, we are building a Universal Device Uploader; when complete, this will be a system that runs on modern Macs and PCs and knows enough to communicate with a variety of USB-connected devices. It will fetch information from devices and upload it automatically to Tidepool's cloud-connected data platform.

Today, we have a proof-of-concept — we have the beginnings of an application that can communicate with a number of different devices (to start, we are working with device manufacturers who have agreed to give us the specifications to communicate with their devices, beginning with Asante). There's a lot still to do.

I am currently the only one working on this project. If you have background in hardware, in communicating with serial devices, in building cross-platform applications, or in building client-side applications, we can use some help.

Depending on your expertise, we could use help in:

1. Defining and building out a flexible application architecture that can talk to USB-connected hardware. Our ideal would be something that is cloud-based, completely cross-platform, can talk to all devices, and can be updated automatically. But that may be unachievable. Let's talk about what our alternatives are. Currently we're working with a Chrome App, but this has unfortunate restrictions, including the fact that block-mode devices (ones that resemble a disk drive on USB) can't be inspected this way, which will force us to use a difficult UI.
2. Once we have a good understanding of how we're going to achieve number 1, we need to move on to building plug-in drivers for particular devices. We already have some functional code for a few devices but most of that has been experimental. Ideally, if you want to do this, you have access to at least one instance of the device that is in active use by a person with T1D. We are currently trying to avoid doing reverse engineering; we prefer to work directly with the organizations making these devices to get a proper set of specs for them.
3. Fleshing out a nice UI for the system. The current UI is a quick hack but someone who can take a design (which we haven't yet created) and implement it would be helpful. This is also dependent on the decisions we make for number 1.

All of these will require relatively close collaboration with me to coordinate tasks, especially until the architecture of the whole system has settled. But if you have expertise in app development or hardware interfacing, this could be an exciting way for you to contribute. Please contact me (kent at Tidepool org).

Other code projects

We also have a lot of other code under development. If the things listed here aren't appropriate for you, we encourage you to contact us and we'll see what we can find that might suit your interests and abilities.