Zammad vs OFORK: Two Paths to an Open Ticketing System

The decision to adopt an open source ticketing system often balances technological renewal with process continuity. While Zammad is an independent new development relying on a modern web stack and vendor-driven development, OFORK positions itself as the continuation of the OTRS tradition in the AGPL ecosystem. This comparison examines differences in project maturity, technical architecture, and operational consequences to provide IT decision-makers with a solid foundation for their choice.

Project Maturity and Governance Models

A key difference lies in the history and governance of the projects. Initiated in 2016, Zammad is primarily driven by Zammad GmbH. With 5,800 stars and 1,000 forks on GitHub (as of July 2026), the project enjoys broad public resonance. Its governance is clearly vendor-centric, reflected in regular release cycles and a centrally coordinated security policy https://github.com/zammad/zammad/security/policy.

OFORK, on the other hand, is a newer entrant in the public space. Although the project traces its history back to 2018, its public repository dates to October 2025. As a fork of the OTRS Community Edition, OFORK aims to preserve the classic OTRS lineage under the AGPL-3.0 license. Community metrics currently stand at 4 stars and one fork, indicating a smaller active developer base compared to Zammad https://github.com/Franziska-Steps-OFORK-Kim-KI/ofork.

Technical Stack and Infrastructure Requirements

The technological foundations of both systems require different administrative competencies:

• Zammad is built on Ruby on Rails and uses Vue.js for the frontend. PostgreSQL serves as the data store. Elasticsearch (optional but strongly recommended) is used for full-text search, while Redis handles real-time communication. Deployment typically occurs via Docker Compose or Linux packages.
• OFORK stays true to its Perl architecture and uses the classic Apache web server with mod_perl. Regarding database support, OFORK is more flexible, supporting Oracle (>= 10g) alongside MariaDB and PostgreSQL. However, MySQL is only listed as supported in versions prior to 8.0 https://github.com/Franziska-Steps-OFORK-Kim-KI/ofork/releases/tag/v12.0.3.

While Zammad focuses on interoperability and user experience through REST and GraphQL APIs as well as a modern web UI, OFORK offers the familiar structure of the OTRS world, including management via .opm packages. Native container support or a Kubernetes operator is not explicitly documented in OFORK's provided data package.

Feature Set and Extensibility

Zammad integrates modern communication channels and features directly into its core. These include a knowledge base, time tracking, SAML SSO, and, since version 7.0, AI-powered ticket summaries while keeping data control entirely with the operator https://zammad.com/en/product/releases/7-0. Extensions are handled via its proprietary .szpm format.

OFORK focuses on core ticketing features along with agent and customer interfaces. Its strength lies in compatibility with the OTRS family. Extensions are installed using the established .opm package format. Specific modern features like an integrated chat function or native mobile views, which Zammad provides starting from version 6.0, are not listed for OFORK in the current specification.

Migration and Ecosystem

For organizations looking to migrate from legacy systems, Zammad offers documented migration paths for OTRS, Zendesk, and Freshdesk. Since OFORK originates directly from the OTRS lineage, switching from OTRS-based systems is structurally straightforward, though its documentation primarily points to general OTRS kinship.

Zammad's ecosystem is characterized by an active community forum and numerous available packages (54 in the hub directory). OFORK is at the beginning of building its public ecosystem; no specific packages are currently listed in the hub directory.

Which System Fits Whom?

The choice between these two systems depends heavily on existing expertise and strategic goals:

Zammad tends to be the right choice if:

• A modern technology stack (Ruby, Vue.js) is preferred.
• High value is placed on a contemporary user interface and integrated channels such as chat or social media.
• Vendor-backed development with clear security processes and regular updates is required.
• Elasticsearch for high-performance searches across large datasets is already part of the infrastructure strategy.

OFORK tends to be the right choice if:

• There is deep rooting in OTRS logic, and existing workflows should continue without a radical UI redesign.
• The IT department has comprehensive expertise in administering Perl and Apache environments.
• An Oracle database is mandatory as a backend.
• A lean system is desired that closely follows the classic OTRS standard without building dependencies on services like Elasticsearch or Redis.

Data Status and Validity

This comparison is based on available data as of July 30, 2026. The version numbers (Zammad 7.1.1, OFORK 12.0.3) and community statistics are snapshots in time. Because young projects like OFORK can develop dynamically, current repository activity should be reviewed before making a final decision.

Conclusion

Zammad and OFORK address different needs in the ITSM market. While Zammad pursues technological modernization and strong vendor governance, OFORK offers a niche for users seeking stability within the classic OTRS architecture. For a detailed side-by-side comparison of technical parameters, please use the interactive comparison table to filter the systems based on your specific requirements.