This is due to a combination of things:
That being said, there are some things that have not changed about the #OpenAPS movement:
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 (da...@openAPS.org) and @ScottLeibrand (sc...@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.)