openDesk cost of ownership and editions

ZenDiS recommends openDesk Enterprise Edition for production, and that recommendation should drive the first line of your cost model. Both editions use the same open-source core licenses, so the difference is not in the code you can read. Enterprise adds closed-source modules, an Enterprise-only registry and license file that your deployment must use, and SLA-backed second and third level support and patches. Enterprise is sold either as SaaS or for installation on premises, and that choice changes who operates the platform and where the subscription sits in your budget. Before you compare totals, confirm with ZenDiS which deployment model fits your data residency and operating constraints.

The Enterprise-only features are where the cost model starts to diverge from a community build. They include Collabora branding and automatic load scaling for the web office, Element AdminBot, GroupSync and the Admin Console, Nextcloud Enterprise security patches and the Guard app, OX S3 storage and advanced full-text search, OpenProject Enterprise add-ons, and XWiki Pro apps. Each one either replaces work your team would otherwise build or maintain, or removes a capability you would have to find elsewhere. Make a list of the features your user groups and administrators need in the first year, then check each one against the Enterprise feature set and the Community build, and record which items you would need to build, buy or drop.

Community Edition is supported only by the community on openCode, with no SLA. For a public-sector or regulated operator, that means no contractual response time, no vendor-backed patch commitment for the Enterprise-only security items, and no escalation path when a Kubernetes or component issue blocks users. The cost moves into staffing and risk. Your platform team must hold the knowledge to triage issues across every bundled component, track security advisories for each license and project, and own the patch cycle, including the monthly minor releases that only the latest minor version receives. Put that effort in the budget as recurring operations time, and name an accountable owner for security response before you choose Community Edition for any production environment.

When you request a quote, ask ZenDiS for written Enterprise terms that state the subscription scope, what support levels are included, how patches are delivered for each bundled component, and what the SaaS and on-premises options each cover. Ask which features are included in each deployment model, and whether any Enterprise-only module changes your Kubernetes or external service requirements. Then set your internal estimate against both options: the subscription and any integration work on one side, and the staffing, on-call coverage and risk exposure of Community Edition on the other. Confirm the numbers with ZenDiS and your own finance and security teams rather than relying on a general comparison.

Most teams keep the parts of an openDesk deployment that define their own environment and their own accountability. The Kubernetes platform itself is the first of these. openDesk requires a CNCF-certified cluster at v1.33 or later, an ingress controller, cert-manager and an RWO volume provisioner, and the team that already runs the organization's clusters is usually the one that operates them. That work needs Kubernetes operations skills: node lifecycle, storage classes, ingress certificates, and capacity planning. The cloud or data center account stays in-house for the same reason, since budgets, network segmentation and procurement rules belong to the client. Expect these costs to recur every month whether or not a partner is involved.

Two more areas usually stay with the client. The first is the directory and identity source. openDesk can federate over OIDC with an existing identity provider, and it recommends the one-way Nubus Directory Importer for LDAP or Active Directory. Someone inside the organization must own the authoritative user store, decide which attribute matches users (for example username or mailPrimaryAddress), and administer identities after go-live. The second is the business decision on user groups and data: which departments receive which applications, who may administer groups, where files are retained and who signs off on data classification. A partner can document options, but these decisions carry the organization's legal and policy risk and should be recorded by the client.

Other parts are commonly outsourced because they are front-loaded and benefit from outside experience. Sizing and cost modelling is one. The team should compare the evaluation minimum (12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk, per the openDesk requirements) with the production expectations for external PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Edition comparison is another, since the Community Edition has no SLA while ZenDiS recommends the Enterprise Edition for production. Ask a partner for a written comparison of Community and Enterprise features against your use cases, and ask for the Enterprise subscription terms in writing.

The quote and an initial build of the deployment against your requirements are the last outsourced items. The build usually involves Helm and Helmfile work to deploy the chosen components, PostgreSQL and MariaDB administration to provision the external databases, and identity administration to connect the IdP. Each skill should be named explicitly in the quote so you can see who performs which task. Ask the vendor to state which tasks are one-time (the initial build, the first federation setup) and which recur (monthly minor upgrades, database maintenance, identity administration), and to confirm which of these your own team must be able to perform without the partner.

Before you request quotes, confirm internally that you have owners for the cluster, the cloud account, the identity source and the data and group decisions. Then confirm with openDesk and with any partner which skills they cover and which you must supply. Many cost surprises come from assuming a partner covers operations that were never in the written scope, so record the split between in-house and outsourced work in the statement of work.

A cost quote for openDesk is only as reliable as the inputs behind it. The supplier cannot see your users, data volumes, platform or identity setup from the outside, so every figure that is missing becomes a guess. Before a quote is requested, the organization should gather the inputs below and record each one in the written scope as either a confirmed value or a named assumption, with an owner and a date for confirmation. Start with sizing. Provide user counts by group, such as staff, external partners, administrators and any shared or service accounts, because each group uses different components and licenses. State the expected concurrency at peak for chat through Element, video through Jitsi and co-authoring in Collabora. Provide a data volume estimate for files in Nextcloud and for mailboxes in OX App Suite, including current size, annual growth and any retention rules that keep data longer. Ask for the expected growth over the contract period, not only the first deployment.

Next, describe the platform that will run openDesk. Name the target Kubernetes platform and its version. openDesk requires a CNCF-certified cluster at v1.33 or later, an ingress controller, cert-manager, an RWO volume provisioner, Helm 3.17.3 or later below v4, and Helmfile 1.0.0 or later. The deployment is tested on kubespray clusters and not on OpenShift, so an OpenShift estate changes the scope. Confirm whether the cluster already exists, who operates it and whether it is in your own cloud account, a data center or an air-gapped network. Then list the external services that production requires: PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. For each one, state whether your organization already runs it as a managed service, which storage and backup standards apply, and whether a new instance must be built. Existing standards often decide whether a service is reused, extended or added, and each choice moves the quote.

Identity and compliance inputs affect both build effort and recurring work. Identify the directory or identity source: Active Directory, LDAP, Microsoft Entra ID or an existing OIDC identity provider. Entra ID does not expose LDAP, so a deployment that syncs from it needs Azure AD Domain Services, which is a separate cost and a separate operating area. Confirm the attribute used to match users, such as username or mailPrimaryAddress, and whether the directory owner will grant the access the import needs. List the compliance requirements that apply, including the frameworks, controls and evidence your assessors expect. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors and certification bodies issue the reports. Ask the assessor now which evidence they will request, because log retention, access reviews and backup testing add effort that a quote should show as a line item.

Finally, decide the deployment model and name the people who own the decisions. Choose between the Community Edition, which has community support on openCode and no SLA, and the Enterprise Edition, which ZenDiS recommends for production and which carries SLA-backed second and third level support and patches. The Enterprise Edition can be sold as SaaS or installed on premises, and each option changes the subscription line and the responsibilities for operations. Record the choice in the scope. Name a budget owner who approves the edition, subscriptions, change requests and any revised figures. Name a technical owner who answers architecture questions, approves access, and signs off assumptions. Agree how changes to the inputs will be handled, with a written change request that states the cost and schedule effect. A quote built on named owners and recorded assumptions can be compared fairly with an internal estimate and revised without reopening the whole scope.