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

SymbolMeaning
Fully supported or strong capability
⚠️Partially supported or limited
Not supported
Category leader for this specific capability
*Customizable or extensible
H / M / LHigh, Medium, Low: effort, skill, or capability level

Section 1: Platform Characteristics

PlatformHostingSaaSTech StackOriginTrendExtensibleDev Overhead
OneSciencePlaceSelf (planned) / ManagedPHP, Drupal2022New, Active*L ★
Open OnDemandSelfRuby, Node2017Active*M
JupyterHubSelf / CloudPython, K8s2015Active*H
Tapis (used by OSP)Self / ManagedJava, Python2013Stable*H
CyVerseManagedJava, iRODS2008StableM
CIPRESSelfJava2005LegacyH
HubzeroSelfPHP, Joomla fork2006Legacy⚠️H
AiravataSelfJava, Python2011Stable⚠️H
2i2cManagedJupyterHub, K8s2019New, 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

PlatformUIWorkflowsFAIR PublishingUser-Contrib AppsLow / 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

PlatformWeb AppsGUI / VNCParallel (MPI)DistributedSerial
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

PlatformLocal HPCRemote / Multi-site HPCCloud (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

PlatformFederated IdentityLDAPRBACMFAPer-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 →