Developed by UCLA, SDSC, and TACC
OneSciencePlace (OSP) builds on the rich legacy of many research computing platforms, each successful in its own right. Comparing them is not straightforward — capabilities overlap, scope varies, and much depends on local deployment — yet it is a question institutions and research teams reasonably ask. This matrix is a concise, good-faith attempt to surface the practical differences that matter.
What to know before reading:
- Capabilities reflect typical deployments and selected planned items.
- Trend signals are based on development activity, adoption announcements, and community presence — not marketing claims.
- The matrix emphasizes user-facing features, runtime support, integration scope, identity and access, and operational burden.
- OSP builds on the foundational work of several platforms listed here, including Hubzero, CIPRES, Airavata, and Tapis.
Use this as a decision aid, not a verdict. It should help you narrow options and identify where deeper, site-specific evaluation is needed.
Legend
| Symbol | Meaning |
|---|---|
| ✅ | Fully supported or strong capability |
| ⚠️ | Partially supported or limited |
| ❌ | Not supported |
| ★ | Category leader for this specific capability |
| * | Customizable or extensible |
| H / M / L | High, Medium, Low: effort, skill, or capability level |
Section 1: Platform Characteristics
| Platform | Hosting | SaaS | Tech Stack | Origin | Trend | Extensible | Dev Overhead |
|---|---|---|---|---|---|---|---|
| OneSciencePlace | Self (planned) / Managed | ✅ | PHP, Drupal | 2022 | New, Active | * | L ★ |
| Open OnDemand | Self | ❌ | Ruby, Node | 2017 | Active | * | M |
| JupyterHub | Self / Cloud | ❌ | Python, K8s | 2015 | Active | * | H |
| Tapis (used by OSP) | Self / Managed | ✅ | Java, Python | 2013 | Stable | * | H |
| CyVerse | Managed | ✅ | Java, iRODS | 2008 | Stable | ❌ | M |
| CIPRES | Self | ❌ | Java | 2005 | Legacy | ❌ | H |
| Hubzero | Self | ✅ | PHP, Joomla fork | 2006 | Legacy | ⚠️ | H |
| Airavata | Self | ✅ | Java, Python | 2011 | Stable | ⚠️ | H |
| 2i2c | Managed | ✅ | JupyterHub, K8s | 2019 | New, Active | ⚠️ | M |
Notes:
- OSP's low dev overhead is its most distinctive characteristic in this section — most comparable platforms require significant custom engineering to deploy and maintain.
- Open OnDemand and JupyterHub have strong adoption trends but require self-hosting and ongoing institutional engineering investment.
- 2i2c offers a managed JupyterHub model but is narrower in scope — focused on interactive computing rather than full gateway or repository capabilities.
Section 2: User-Facing Features
| Platform | UI | Workflows | FAIR Publishing | User-Contrib Apps | Low / No-Code |
|---|---|---|---|---|---|
| OneSciencePlace | ✅ | ⚠️ Planned | ✅ ★ | ✅★ | ✅ ★ |
| Open OnDemand | ⚠️ | ❌ | ❌ | ❌ | ❌ |
| JupyterHub | ✅ | ❌ | ❌ | ⚠️ | ❌ |
| Tapis (used by OSP) | ❌ | ✅ ★ | ❌ | ✅ | ❌ |
| CyVerse | ✅ | ✅ | ✅ ★ | ✅ ★ | ⚠️ |
| CIPRES | ✅ | ❌ | ❌ | ❌ | ❌ |
| Hubzero | ✅ | ⚠️ | ⚠️ | ⚠️ | ⚠️ |
| Airavata | ❌ | ⚠️ | ❌ | ❌ | ❌ |
| 2i2c | ✅ | ❌ | ❌ | ⚠️ | ❌ |
Notes:
- OSP leads on Low/No-Code UI building — no comparable platform offers this capability out of the box without custom development.
- OSP leads on FAIR Publishing as an integrated capability — most platforms require separate repository infrastructure.
- CyVerse has a mature user-contributed app ecosystem within its single hosted environment — all users share one global catalog. OSP supports user-contributed apps and systems per tenant, giving each community control over what is shared within their own environment without cross-community exposure. The right model depends on whether a community wants a global shared pool or a curated per-deployment catalog.
- Tapis leads on workflow orchestration — OSP leverages Tapis for this capability rather than building it independently.
- OSP's workflow support is planned — this is an honest gap relative to Tapis and CyVerse.
- OSP is the only multi-tenant platform in this comparison where each tenant community can independently contribute and share their own apps and compute systems — enabling grassroots innovation within institutional or domain-specific boundaries rather than a single global pool.
Section 3: Application Runtime Capabilities
| Platform | Web Apps | GUI / VNC | Parallel (MPI) | Distributed | Serial |
|---|---|---|---|---|---|
| OneSciencePlace | ✅ ★ | ✅ ★ | ✅ ★ | ✅ | ✅ |
| Open OnDemand | ✅ | ✅ | ⚠️ | ⚠️ | ✅ |
| JupyterHub | ✅ | ❌ | ❌ | ❌ | ✅ |
| Tapis (used by OSP) | ❌ | ❌ | ✅ ★ | ✅ ★ | ✅ |
| CyVerse | ✅ | ⚠️ | ⚠️ | ❌ | ✅ |
| CIPRES | ❌ | ❌ | ✅ | ❌ | ✅ |
| Hubzero | ⚠️ | ⚠️ | ⚠️ | ⚠️ | ✅ |
| Airavata | ❌ | ❌ | ✅ | ✅ | ✅ |
| 2i2c | ✅ | ⚠️ | ⚠️ | ❌ | ✅ |
Notes:
- OSP leads on GUI app delivery flexibility — it is agnostic to the display technology inside the container, proxying any GUI application to the browser as long as the container exposes an appropriate display endpoint. This means any Linux GUI application can be delivered without platform-specific integration work.
- Open OnDemand has the widest single-site deployment base for GUI apps but is more prescriptive about supported display technologies and requires more custom configuration for non-standard GUI applications.
- Tapis leads on MPI and distributed computing — OSP inherits this capability through its Tapis integration.
- OSP leads on breadth of web app delivery combined with container flexibility across runtime types.
Section 4: System Integration
| Platform | Local HPC | Remote / Multi-site HPC | Cloud (AWS / GCP / Azure) | Multi-system Federation |
|---|---|---|---|---|
| OneSciencePlace | ✅ | ✅ ★ | ✅ | ✅ ★ |
| Open OnDemand | ✅ ★ | ❌ single site | ⚠️ | ❌ |
| JupyterHub | ✅ | ⚠️ | ✅ | ⚠️ |
| Tapis (used by OSP) | ✅ | ✅ ★ | ✅ | ✅ ★ |
| CyVerse | ❌ hosted only | ❌ | ⚠️ | ❌ |
| CIPRES | ❌ hosted only | ❌ | ❌ | ❌ |
| Hubzero | ⚠️ | ⚠️ | ❌ | ❌ |
| Airavata | ✅ | ✅ | ✅ | ✅ |
| 2i2c | ❌ | ❌ | ✅ ★ | ⚠️ |
Notes:
- Open OnDemand leads on local HPC portal maturity — it is the most widely deployed solution for single-site campus clusters and has the largest institutional adoption base.
- OSP's most significant system integration differentiator is multi-system federation — a single OSP instance can connect local clusters, national HPC resources (such as ACCESS/NAIRR systems), cloud instances, and standalone servers simultaneously, all accessible through one interface and one login. Open OnDemand does not support this.
- 2i2c and JupyterHub lead on cloud-native deployments — they are purpose-built for cloud environments.
- OSP and Tapis lead on multi-site federation — connecting multiple national or institutional HPC resources under a single access point is OSP's strongest system integration differentiator.
Section 5: Identity, Access, and Security
| Platform | Federated Identity | LDAP | RBAC | MFA | Per-System Identity Mapping |
|---|---|---|---|---|---|
| OneSciencePlace | ✅ ★ | ✅ | ✅ | ✅ | ✅ ★ |
| Open OnDemand | ✅ | ✅ | ⚠️ | ⚠️ | ⚠️ |
| JupyterHub | ✅ | ✅ | ⚠️ | ⚠️ | ❌ |
| Tapis (used by OSP) | ✅ | ⚠️ | ✅ | ⚠️ | ✅ |
| CyVerse | ✅ | ❌ | ⚠️ | ⚠️ | ❌ |
| CIPRES | ❌ | ❌ | ❌ | ❌ | ❌ |
| Hubzero | ⚠️ | ✅ | ⚠️ | ❌ | ❌ |
| Airavata | ✅ | ⚠️ | ✅ | ⚠️ | ✅ |
| 2i2c | ✅ | ⚠️ | ⚠️ | ⚠️ | ❌ |
Notes:
- OSP leads on federated identity breadth — supporting CILogon, Globus Auth, InCommon, SAML, LDAP, and per-system identity mapping without requiring a shared IdP across systems.
- Per-system identity mapping is a significant operational advantage for multi-institutional deployments where users authenticate differently across connected systems.
Want to discuss how OSP compares for your specific use case? Talk to the OSP team →