Eclipse Che

The eclipse-che/che repository is licensed under the Eclipse Public License v2.0, confirmed both in the LICENSE file and in the repository metadata as of July 2026. This is the cleanest open source story of the four platforms in this directory. There is no open-core split, no thin open client wrapped around a commercial server, and no license key gating the platform.

Is the open edition production-viable? Technically, yes - and that genuinely distinguishes Che. What upstream lacks is not capability but assurance: no support contract, no security errata process, no certified upgrade path, no tested component matrix. That is exactly the gap Dev Spaces fills, and it is a legitimate thing to buy. Plenty of organizations run upstream Che successfully; they simply staff for it.

The governance point deserves precision rather than enthusiasm. Eclipse Foundation stewardship is real and formal - the trademark, the license, and the intellectual property process sit with the foundation, not with a company. That protects you against the specific failure mode where a vendor relicenses its project or moves it behind a source-available license, which has happened repeatedly elsewhere in infrastructure software. But governance is not the same as contributor diversity, and the two get conflated constantly. See the next section for what the commit history actually shows.

Devfile is worth noting as a separate portability asset. The specification is governed independently of Che, so the environment definitions you write are not a Che-proprietary format. If you migrate away, the devfiles are among the artifacts most likely to carry over.

Installation is operator-driven. The operator manages a CheCluster custom resource that configures the platform's components separately - devWorkspace, cheServer, pluginRegistry, devfileRegistry, dashboard, and imagePuller. Workspace lifecycle is handled by the DevWorkspace Operator, which ships as a versioned component of each release rather than as part of a monolith.

Isolation is per-user namespace, and it is automatic. Red Hat's administration guide documents a default namespace template of <username>-che with auto-provisioning enabled, and supports administrators pre-provisioning namespaces labeled as workspace namespaces instead. Workspaces then run as ordinary Kubernetes pods within the user's namespace, with configurable resource limits, node scheduling, tolerations, and security contexts.

Traffic reaches those workspaces through a gateway deployment that bundles the gateway itself alongside a configuration reloader, an OAuth proxy, and a Kubernetes RBAC proxy. Authentication and routing therefore sit in front of the workspace rather than inside it, which is the right shape and is one of the more mature parts of the design.

The same caveat applies here as to any pod-based platform, and it should not be glossed over: namespaces plus RBAC plus network policy is a strong administrative boundary, not a kernel boundary. Pods on a node share a kernel. For internal engineering teams this is standard and accepted. For genuinely hostile multi-tenancy, or for compliance regimes that require hardware or hypervisor separation, you must solve that at the cluster or node layer - Che will not solve it for you.