We're collaborating with the kubebuilder[0] project upstream, which is a subproject of SIG API Machinery that focuses on generating the best scaffolding for controllers. Myself and some Googlers also proposed creating a SIG focusing on platform extensions to Kubernetes, such as operators tooling[1]. The steering committee is currently not convinced that it merits a dedicated SIG, despite the many projects in the wild experimenting without organization. We're fully committed to taking well understood, community-accepted opinions from our tooling and upstreaming the work, if the community can agree on that aspect of the framework. A great example of this is the Application Definition Working Group, which has leveraged many ideas from our Operator Lifecycle Manager; our CRDs are practically the same! Now that things are open source, we should see things like these converge entirely.
As to whether this or other similar projects will become part of Kubernetes core, my guess is probably there will be resistance to it as it will mean choosing one particular way of how Kubernetes can be extended over others. And this will be against the overall philosophy of Kubernetes that components in it are optional and pluggable[1]. On the other hand, some standardization will mostly likely evolve around the end-user experience of consuming multiple Operators in a single Kubernetes Cluster.
