OpenProject vs Redmine

If your directory is LDAP or Active Directory and you do not need browser-based single sign-on, both products can authenticate users against the directory. Redmine includes LDAP authentication in its core, so there is no paid edition to evaluate for this case. OpenProject lists LDAP group sync as an Enterprise plan feature, which matters only if you want directory groups to drive project roles automatically.

• Core LDAP login: Redmine's free core covers LDAP authentication. Confirm the bind account, TLS settings and attribute mapping with your directory team in a test environment.
• Group sync: OpenProject lists LDAP group sync on its pricing page as an Enterprise feature. Without it, you assign roles to users or groups inside the application and maintain that mapping yourself.
• Offboarding: Ask how disabled directory accounts are reflected in each product, including whether existing sessions and API tokens are revoked.
• Audit trail: Confirm which login and permission changes are logged, and whether those logs can be exported to your central log platform.
• Quote question: If you need LDAP group sync from OpenProject, ask DeployOpen to include that Enterprise feature in the written scope and licensing line.

Before deciding, document which directory groups must map to which project roles and who approves changes to that mapping.

If your identity provider issues SAML or OpenID Connect assertions for browser sign-on, the decision depends heavily on edition. OpenProject lists SAML and OpenID Connect single sign-on as Enterprise plan features on its pricing page, beyond the free Community edition. For Redmine, single sign-on is not part of the core described in its project materials, so SSO options depend on plugins or on the surrounding identity layer, such as a reverse proxy or access gateway. Treat those plugins as a separate security review, not as a checkbox.

• OpenProject path: SAML or OIDC sign-on is licensed through the Enterprise plan. Ask for the exact edition and the renewal terms in writing.
• Redmine path: Identify whether a maintained plugin supports your protocol, who maintains it, and how it handles session expiry and attribute mapping.
• Gateway path: An identity-aware proxy in front of Redmine can enforce sign-on, but confirm how it passes user identity and how API access is handled.
• Group model: Decide whether IdP groups or claims map to application roles, and who owns that mapping when it changes.
• Test plan: Verify sign-in, forced logout, deprovisioning and role changes against your actual IdP before go-live.

Confirm the protocol versions and the claims your identity provider sends with your identity team, then test them against the specific product version you plan to run.

Kerberos and CAS environments are the least common and the most sensitive to configuration. OpenProject lists Kerberos and CAS among its Enterprise plan single sign-on options, so these integrations are not part of the free Community edition. Redmine's project materials do not list Kerberos or CAS as core features, so you should assume they require a plugin or a front-end component. Confirm whether either approach is available and supported for your exact version before committing.

• Ticket-based sign-on: Kerberos depends on a correctly configured service principal, keytab handling and time synchronization. Confirm who manages those secrets.
• CAS gateway: Determine whether your CAS server is the only trusted sign-on path, and how service accounts and API clients authenticate.
• Fallback access: Plan a break-glass administrator account that does not depend on the single sign-on path.
• Audit requirements: Confirm that authentication failures and privileged role changes appear in logs your security team reviews.
• Vendor confirmation: Ask OpenProject for the current supported configuration and ask the Redmine plugin maintainer for compatibility with your Redmine version.

Run a pilot with your own identity provider and a non-production copy of the application before you choose the edition or the plugin.

OpenProject is GPL-3.0 licensed, so the team can download, run, modify and redistribute the Community edition inside its own cloud accounts, data centers or air-gapped networks without paying a license fee for the software itself. The free Community edition is the baseline. The Enterprise plan adds features that the vendor lists on its pricing page, and those features are the reason many teams look at a paid tier.

• Single sign-on: SAML, OpenID Connect, CAS or Kerberos sign-in is listed as an Enterprise feature, so confirm which protocol your identity provider needs before assuming the Community edition covers it.
• LDAP group sync: group membership synchronization is listed as Enterprise, which matters if access follows directory groups.
• Baseline comparison and portfolio views: full baseline comparison and portfolio and resource management are Enterprise features.
• Custom branding: branding changes are listed as Enterprise.
• Vendor support: the paid plan is the route to vendor-backed support, so ask what response channels and scope come with it.

Before committing, ask the vendor which features are included in the subscription term, how upgrades between minor releases are handled, and whether the license covers the exact deployment model you intend to run.

Redmine is GPL-2.0-or-later licensed, written in Ruby on Rails, and maintained by community volunteers with no paid edition. The core product carries no license fee, and the team can run it in its own infrastructure, modify it and redistribute it under the terms of that license. The feature set covers multiple projects with role-based access, Gantt charts, per-project wikis and forums, time tracking, custom fields and LDAP authentication, so many capabilities that teams associate with paid tiers are part of the core.

• Plugin model: much of the extended behavior comes from plugins, each with its own license, maintenance status and compatibility with the Redmine version you run.
• No vendor support tier: there is no paid Redmine edition, so support comes from your own staff, a consultant you contract, or community channels.
• Feature gaps are filled by plugins: capabilities such as portfolio-style reporting or SSO connectors may depend on plugins, so verify each one against your target release.
• Release lines: Redmine publishes several release lines in parallel, so pick the line your plugins support.
• Operational ownership: upgrades, backups and security patching sit with your team or your implementation partner.

Before committing, ask which plugins your workflow depends on, who maintains each one, and what their license terms are.

The two platforms use different GPL versions, and that difference shapes what a team may combine. GPL-3.0 and GPL-2.0-or-later are not interchangeable, and a plugin or extension written under one version may not combine cleanly with code under the other. Teams that modify either product, embed it in another system, or distribute it to customers should not assume the same obligations apply to both.

• Version terms: GPL-3.0 and GPL-2.0-or-later carry different conditions on distribution and patents, so read the text rather than the label.
• Modifications: check what you must publish when you change the core or a plugin, especially for internal-only use versus distribution.
• Plugin licenses: each Redmine plugin and each OpenProject extension may carry its own license, which can differ from the core.
• Contributor agreements: ask whether the project requires contribution terms that affect code you write for the team.
• Subscription terms: the Enterprise agreement is a separate contract and may add restrictions beyond the GPL.

Your team's legal counsel should review both licenses and every plugin license before rollout.