It’s been a busy few months for the #OpenAPS community, going from n=1 to (n=1)*7! (And as of 11/19/15, (n=1)*16.) And there are several people working on their implementation, so it might be possible to see a dozen OpenAPS implementations live by the end of the year.

This is due to a combination of things:

• More tools in the OpenAPS toolkit
• A growing series of documentation to help people understand the above mentioned tools
• Some awesome media attention around the #WeAreNotWaiting movement and #OpenAPS
• Excellent support from community members to help those who are new to #OpenAPS

That being said, there are some things that have not changed about the #OpenAPS movement:

• OpenAPS remains an open and transparent effort to make safe and effective basic Artificial Pancreas System (APS) technology widely available, to help reduce the burden of Type 1 diabetes.
• #OpenAPS is still not intended to be a “set and forget” APS system for two key reasons:
  • To maximize safety, #OpenAPS only doses basal insulin (not boluses), so patients still need to bolus for meals as they do today.
  • This is a DIY implementation and it requires constant monitoring and testing to make sure the system is working as expected.

Everything in the OpenAPS community (including commentary on social channels or pieces of tools in Github) is intended to be part of a set of tools to support a self-driven DIY implementation and any person choosing to use these tools is solely responsible for testing and implement these tools independently or together as a system. We can’t say this enough: the DIY part of OpenAPS is important. While formal training or experience as an engineer or a developer is not required, what is required is a growth mindset to learn what are essentially “building blocks” to implement an OpenAPS instance. This requires diligent and consistent testing and monitoring to ensure each piece of the system is monitoring, predicting, and performing as desired. The performance and quality of your system lies solely with you. Some people are willing to take this on, and accept this responsibility, while others are not – and that’s fine!

(By the way, Nightscout is still a fantastic tool that’s got complete setup instructions if you’re looking for things like remote BG monitoring, alerts, “bolus wizard preview” (similar to #DIYPS’s original alerts!), and some other great features. If you’re not ready for #OpenAPS, but aren’t yet on Nightscout, you might want to check it out. Ditto for joining the “CGM in the Cloud” Facebook group to keep up with the latest from the #WeAreNotWaiting community.)

If you are looking to get started with #OpenAPS and haven’t already, please sign up for the OpenAPS-dev google group and look for my (Dana’s) most recent “Getting Started” thread. It will point you to our draft documentation that’s a constant work in progress as well as give you some other tips.

Even if someone doesn’t get all the way up and running with the loop, we learn something new and add new documentation and tools every time someone joins the community. This comes from asking questions about our documentation; making suggestions; supporting fellow community members through a prior step that they have mastered; identifying new use cases and building unit tests; and more.

Please contact us at @DanaMLewis (dana@openAPS.org) and @ScottLeibrand (scott@openAPS.org) if you have questions or ideas about how to contribute to #OpenAPS – we’d love to hear from you! (You can also follow the community on Twitter at #OpenAPS and @OpenAPS.)

9/21/15 Added note: Right now, the only pumps currently working with #OpenAPS are the pumps listed on this page of the documentation. If you’re interested in working on communication for another pump (Omnipod, etc.), click here to add yourself to the collaboration group focusing on alternative pump communication.