Is there a website other than the GitHub page? You might consider a name change before you reach 1.0, given this already exists: https://www.karmada.org/ https:

Is there a website other than the GitHub page? You might consider a name change before you reach 1.0, given this already exists: https://www.karmada.org/ https://www.karmada.org/. They came up first in web search and you came up second, but they have an actual web page. Some implementation questions. First, what is this perceived to buy on top of existing systems like Helm and Rancher that use templating engines and overrides at build and deployment time to support deploying identical services to multiple clusters possibly hosted across multiple cloud providers? You remove some of the complexity of dealing with Go templates, but add an entire new control plane and a master cluster that I'm not sure is needed if all it gives you is another level of indirection regarding where you deploy to. Second, regarding the quick start guide, why use resets of the KUBECONFIG variable to control which cluster you're talking to? Your scripts can merge configs and set current-context so the user can just use contexts instead. Also, the KUBECONFIG variable itself supports multiple files, so you can do this without having to merge definitions into a single file if you want the control plane to be in the special /var/run path instead of the user's home. Last, you may want to change the output of the quick start to indicate the kubeconfig file generated for the host cluster is going to be in the current user's home, not necessarily root. I'm guessing whoever wrote the guide was simply running as root (probably not recommended, but a lot of people like to live dangerously) and copy/pasted out of their own terminal. Granted, they'll see the real location when they run the script anyway, but the README gave me the impression at first it will always put the file in root's home, which would clearly fail if you're not running as root. Lastly, your local-up script should support installing the control plane into different local cluster solutions instead of having a hard dependency on kind. People might be already using k3d, minikube, or even have a homelab setup with a fleet of NUCs or libvirt hosts and they don't want yet another kubernetes installation on their laptop. You might even prefer using something else for your own development. For instance, k3d does all that docker hackery to inject container ip as the api-server endpoint for you, so it supports multiple clusters on the same host out of the box without you needing to manually manipulate the kubeconfig after creating a cluster. Also, maybe even de-emphasize multi-cloud? All the other comments so far seem to be fixating on that as a "99% of all applications don't need to be multi-cloud" bugaboo point you see all the time posts like these happen, but this is really just supporting deployments to multiple clusters with cluster-specific overrides of api object definitions. In some cases, like storage plugins, those may be specific to a cloud-vendor, so in that case you're also buying the potential for a multi-cloud deployment. But whether or not an application is multi-cloud is a separate concern on top of it being multi-cluster. Multi-cluster is required a lot more than multi-cloud, i.e. if you scale to the size where kubernetes simply doesn't support that many nodes in one cluster, or you want to easily deploy multiple versions of the same application, or you simply want to be able to orchestrate staging and production clusters from one control plane. Maybe readers would focus more on your actual technology and not fixate on the single phrase "multi-cloud."