I am an OpenWrt developer but not part of the core team by far. We&#x27;ve been developing a platform to manage OpenWrt devices from the cloud for the last 18 months.<p>We struggled with this since day zero. As a startup, we didn&#x27;t have the luxury money to build our own boxes with loads of memory. Plus we we wanted to support all OpenWrt devices. Ultimately, we took the logic of auto upgrades (and everything else for that matter, separate story) off the aps directly and now do everything in our platform.<p>Currently we only support a minimal set of devices - about 15 in total. However building &#x2F; maintaining the firmwares for all of these, making sure they&#x27;re up to date etc. is a huge burden.<p>Upgrading a box for a user poses so many challenges, I can&#x27;t see why this is actually OpenWrt&#x27;s responsibility?<p>What to do about testing? New releases can (do) have bugs. Again, since we&#x27;re bootstrapped, we don&#x27;t have a lab so we have separate development modes and test these on customers willing to have the bleeding edge.<p>The Netflix Syndrome as we call it. What if someone&#x2F;thing is connected - do we still upgrade? I work late, and before sleep, I usually watch some Netflix. However, our nightly upgrades pushed from our platform were ruining my enjoyment! Shock. We had to introduce a feature to disable auto upgrades if there is a device detected.<p>What about stragglers? Customers with very outdated firmwares were not only vulnerable but also holding our development back. In the end we upgrade all boxes that are 2 months old between 4am and 5am local time every day. Some people refused to upgrade, they like the status quo, they&#x27;re used to the gotchas in a particular release.<p>Ok, OpenWrt is becoming hugely popular but there&#x27;s still a huge knowledge gap. If people struggle to understand the difference between WiFi and broadband, how can we expect them to understand firmware let alone, why it needs to be updated.