Future of CloudSlash: Architecture, Plugins, and Licensing

I've been thinking about the future direction for CloudSlash and wanted to share some early ideas to see if this is the right path or not.

1. Core Architecture & gRPC

I'm currently exploring a significant architectural shift: decoupling the core engine from hardcoded AWS dependencies and transitioning to a plugin-based architecture using gRPC, similar to HashiCorp's go-plugin model. The primary goal here is to make the core engine entirely provider-agnostic. This would allow any cloud provider—whether it's AWS, Azure, GCP, or others—to operate as an independent, dynamically loaded plugin.

This change would not only simplify the core codebase but also dramatically improve extensibility, allowing the community to build and maintain provider integrations independently. I'd love to know if this direction aligns with how you envision building and scaling with the tool. Does this flexibility sound valuable for your use cases?

2. Algorithms & Policies

We are currently using algorithms like Dinic's Maxflow for network partition proofs and CEL for policy rules. While Dinic's algorithm is effective, we are also exploring alternatives such as the Push-Relabel algorithm or the Edmonds-Karp algorithm to see if they offer better performance for our specific use cases. Are there specific algorithms or policy engines you would rather see integrated?

3. Dual-License Model

The current plan is to maintain the core engine under the AGPLv3 license, which ensures that the fundamental technology remains open source and accessible to the community. At the same time, we intend to offer the Plugin SDK under the more permissive Apache 2.0 license. This dual-license approach is specifically designed to provide you with the flexibility to build and distribute proprietary plugins without being constrained by the copyleft requirements of the core license.

We want to make sure this model supports your business and development needs. Does this licensing split work well for your specific use cases, or do you foresee any challenges with this structure?

---

These are just a few things that were on my mind, and I wanted to ask: what should CloudSlash actually do? I'd love to hear your feedback on these directions. What are we missing, and what should be prioritized?