The Operator Framework needs a Mission Statement

[awgreene]

It's come to my attention that the Operator Framework has never formally released a mission statement.

The Operator Framework's mission statement should define why the organization exists, our core goals, and serve as a rallying point for all that we do.

I've created a Mission Statement to kick things off:

The Operator Framework is committed to promoting the adoption of the Kubernetes Operator pattern by developing a suite of open-source tools that simplify the development, distribution, and management of Operators. Our mission is to create a world where the power and flexibility of the Operator pattern can be harnessed to automate any application, service, or workload.

[fgiloux]

the Operator pattern can be harnessed to automate any application, service, or workload.

IMHO the operator pattern is for specific use cases and may not be suitable for any application, service, or workload.

[awgreene]

Agreed, I generated this with CHAT GPT and called this out as something we ought to remove during our community meeting. Have any suggestions on how you'd like to change the wording?

[fgiloux]

giving it a try:
"Our mission is to create an ecosystem where the power and flexibility of the Operator pattern can be harnessed to make complicate systems easy to use"

[awgreene]

In today's community meeting, @bparees and @joelanford lead the discussion on whether or not the operator framework should be limited to managing the installation of operators. I would love to continue that discussion here.

[fgiloux]

Not in disagreement but what do we intend to provide that is not already possible by largely adopted tools like helm, kustomize, ksonnet, skaffold, etc? What are the differentiators, the specific value adds for "things" that are not operators?

[bparees]

what do we intend to provide that is not already possible by largely adopted tools like helm, kustomize, ksonnet, skaffold, etc? What are the differentiators, the specific value adds for "things" that are not operators?

dependency management and upgrade orchestration(including upgrade graph maintenance/enforcement) are the two that usually come to mind for me. (non-operators can have dependencies and upgrades)

[fgiloux]

upgrade graph is a good one, although I believe it is more useful with complex systems, which is where operators shine. With helm, kustomize and others you can declare dependencies or compositions. Doing real dependency management with conflict prevention is for sure a bigger undertaking, which requires the control of a complete realm.
I was also thinking of the capability to provide a trusted supply chain, although helm can offer the same by storing charts as OCI bundles and it is bound to the bundle delivery mechanism.

[bparees]

helm's dependency management seems to be much more constrained to depending on a particular additional chart, whereas OLM is pursuing a more generic concept of "dependencies" (constraints/requirements is perhaps a better term)

[fgiloux]

I agree. My point is: where this more generic concept of "dependencies" will bring significant value, enough value that people may decide to replace something that they have been using for years and are comfortable with even if it has little deficiencies here and there or start using another tool on top of it? My current feeling is that we will see that more with complex systems: multi-tenants, using CRDs, cluster scoped resources or having specific requirements like GPU, ARM-arch.
The target audience may not be as large as the one for helm and kustomize but these are systems driving a lot of very valuable workload, which in my opinion already makes a very good mission.