Design principles

Foundational principles that guide the OpenSDDC ecosystem technically.

1. Open interfaces

Platform behavior should be understandable and manageable from outside the vendor. Management, telemetry, and automation surfaces should build on open standards—gRPC APIs such as gIMI and common protocols like OpenTelemetry are preferred.

2. Portability

VM, volume, telemetry, and automation layers should be portable across platforms where possible. Storage models (e.g. SLTV) and Kubernetes integrations (e.g. CSI drivers) embody this directly.

3. Separation of concerns

Compute, storage, and network should remain consciously separable. SAN, HCI, or hyperconverged choices should be architectural decisions—not closed, one-way doors.

4. Protect existing investment

SAN, FC, iSCSI, NFS, KVM, Kubernetes, and existing enterprise footprints should be considered together. OpenSDDC targets complementing current investment with a new open layer—not restarting from zero.

5. Operational simplicity

Open source is powerful, but if it isn’t usable and operable, it won’t stick in organizations. An opinionated host profile like dc(e)OS and a unified management layer like OpenSDDC Manager apply this principle.

6. Security and auditability

Open source also means auditability: SELinux hardening, immutable host OS, security disclosure processes, and secure defaults.

7. Feedback-driven progress

The roadmap, architecture, and API designs are open to community input. Decisions are recorded as ADRs (Architecture Decision Records).

8. Reducing dependency risk

OpenSDDC does not mean “no vendors.” You can keep using vendors—but you should retain the ability to change vendor or move to a non-vendor alternative when you need to.