[content:roadmap] Stated general goals, added celery related ideas

Author: nemesifier

general/roadmap-2030.rst

@@ -1,11 +1,52 @@
 Roadmap to 2030
 ===============
 
-This document outlines the primary goals of the OpenWISP project for the
-period 2026-2030.
+This document describes the strategic evolution of the OpenWISP project
+through 2030. Our objective is to consolidate OpenWISP as the most
+versatile, enterprise grade, open source network management system and
+controller available.
 
-If you are interested in a specific feature and would like to collaborate
-with us, please refer to :doc:`help-us`.
+As networking environments continue to become increasingly heterogeneous,
+the focus shifts toward reducing the barrier to entry while expanding the
+technical reach of the platform.
+
+The primary objectives for the 2026 to 2030 period are:
+
+1. **Frictionless deployment**
+
+   Move toward a day one ready approach by simplifying installation
+   workflows and providing clear, sensible default configurations that
+   work out of the box.
+
+2. **Refined user experience**
+
+   Improve the interface of core modules so that frequent operations such
+   as device onboarding, configuration, monitoring, and firmware upgrades
+   are intuitive and accessible, including for users with limited
+   technical background.
+
+3. **Community driven feature parity**
+
+   Address long standing feature requests from the community and reduce
+   functional gaps compared to proprietary network management solutions.
+
+4. **Ecosystem agnosticism**
+
+   Expand support beyond OpenWrt by improving compatibility with other
+   operating systems and by adopting standard protocols such as NETCONF
+   and YANG, as well as TR-069 and TR-369. This will allow OpenWISP to
+   manage a wider range of hardware and software platforms, becoming
+   useful to a larger audience.
+
+Read on for a detailed description of the technical goals.
+
+.. note::
+
+    If you are interested in a specific task or would like to help shape
+    the future of open source networking, please refer to:
+
+    - :doc:`help-us`
+    - :doc:`../developer/contributing`
 
 **Table of Contents:**
 
@@ -91,8 +132,9 @@ Firmware Tools
 --------------
 
 - **Pre-configured Firmware Images**: Provide ready-to-use OpenWrt images
-  for all supported targets, pre-configured to connect to the OpenWisp
-  demo instance.
+  for all supported targets, pre-configured to enroll into the
+  :doc:`OpenWISP Demo System <../tutorials/demo>`, which would allow
+  testing most OpenWISP features quickly.
 - **Custom Image Builders**: Supply image builders for all targets to
   allow users to generate custom firmware locally.
 - **Automated Build Pipeline**: Automate the compilation and publishing of
@@ -238,21 +280,9 @@ Firmware Upgrade UX
   that remain queued for offline devices, executing automatically once
   they reconnect.
 
-Mesh Networking
----------------
-
-- **Atomic Group Updates**: Improve mesh stability by synchronizing
-  configuration changes across groups. This prevents connectivity loss
-  during rollouts (e.g., coordinated radio channel adjustments).
-- **Dynamic Topology Mapping**: Utilize monitoring data from mesh
-  interfaces to generate real-time topology maps of the active network.
-
 Monitoring Improvements
 -----------------------
 
-- **Release Milestone**: Address outstanding issues identified for the
-  `Monitoring 0.3 release
-  <https://github.com/openwisp/openwisp-monitoring/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22OpenWISP+Monitoring+0.3+Release%22>`_.
 - **Database Compatibility**: Implement support for `InfluxDB 2.0
   <https://github.com/openwisp/openwisp-monitoring/issues/274>`_.
 - **SNMP Support Finalization**: Complete and refine SNMP monitoring
@@ -262,6 +292,24 @@ Monitoring Improvements
   provide an immediate drill-down view to identify the specific root
   cause. Ensure full feature parity for these diagnostic insights via the
   REST API.
+- **Asynchronous core refactoring**: Refactor core Django components to
+  support asynchronous execution. This transition enables the use of the
+  ``gevent`` execution pool within the Celery distributed task queue. By
+  moving away from synchronous, blocking operations, OpenWISP can achieve
+  higher concurrency and throughput, allowing it to manage a much larger
+  number of concurrent device operations while reducing overall CPU and
+  memory usage.
+- **Adaptive task orchestration**: Implement an intelligent and adaptive
+  Celery worker and consumer model that automatically adjusts concurrency
+  based on available hardware resources.
+- **Priority aware scheduling**: Introduce a scheduler that supports multi
+  queue topologies with explicit priority handling. This ensures that time
+  sensitive tasks, such as configuration changes and reactive network
+  operations, are not delayed by resource intensive background workloads,
+  such as those generated by the monitoring module.
+- **Release Milestone**: Address outstanding issues identified for the
+  `Monitoring 0.3 release
+  <https://github.com/openwisp/openwisp-monitoring/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22OpenWISP+Monitoring+0.3+Release%22>`_.
 
 Networking Features
 -------------------
@@ -284,3 +332,12 @@ Networking Features
   - Management support for TR-069 / TR-369, NETCONF, and CAPWAP.
   - Integration with proprietary vendor firmwares, including Ubiquiti and
     MikroTik.
+
+Mesh Networking
+---------------
+
+- **Atomic Group Updates**: Improve mesh stability by synchronizing
+  configuration changes across groups. This prevents connectivity loss
+  during rollouts (e.g., coordinated radio channel adjustments).
+- **Dynamic Topology Mapping**: Utilize monitoring data from mesh
+  interfaces to generate real-time topology maps of the active network.