github.com/operator-framework/operator-lifecycle-manager@v0.30.0/doc/design/design-goals.md (about)

     1  # General Design Goals
     2  
     3  Whether designing new features or redesigning old ones, OLM should maintain these general design goals:
     4  
     5  ## Build (reasonably) small, sharp features
     6  
     7  All designs should be kept as simple and tightly scoped as is reasonably possible. Where possible, attempt to follow the [unix philosophy](https://en.wikipedia.org/wiki/Unix_philosophy) for writing small, sharp features that compose well. Additionally, when writing a new proposal, always remember to [keep it simple ...student!](https://en.wikipedia.org/wiki/KISS_principle)
     8  
     9  ## Upstream first
    10  
    11  Before adding a feature, check to see if an upstream Kubernetes community has a project that we can extend, adopt, or contribute to that attempts to solve the same or similar problems. If such a project is found, but for some reason cannot be used in lieu of an OLM-specific solution, make the community aware of OLM's usecase and attempt to open a dialog on the matter. Additionally, any OLM-specific proposals should avoid relying on the features of downstream Kubernetes distributions.
    12  
    13  ## Operators should remain agnostic of OLM's APIs
    14  
    15  Be cautious when adding any feature that requires operators to know about an OLM interface. This promotes lock-in and makes adoption more difficult, usually requiring code changes to operators. Generally, a proposal of this category should only be accepted when all of the following are true:
    16  
    17  1. The feature cannot easily be designed in a way that operators are agnostic of its interface and that interface is straightforward
    18  2. The feature is likely to be accepted upstream
    19  3. The feature is optional
    20  
    21  ## Adhere to Kubernetes API conventions
    22  
    23  Ensure new APIs adhere to the [Kubernetes API conventions](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md). When making changes to an existing API, make sure those changes follow the [corresponding backwards compatibility rules](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md).