Znuny: a maintained fork of OTRS for service desks

A ticketing system for service desks, not a generic helpdesk

The description calls Znuny a free, open source and versatile web based ticketing system for customer service, help desk, IT service management and more, and it is explicit about the values behind it, that it is built for transparency and long term sustainability and is highly tailorable to an organisation's needs. The topic list gives the functional range, with customer care, customer support, helpdesk, itsm, service management, support and ticketing all present, and the language badges show that Perl is the core with JavaScript on the front end. What distinguishes a ticketing system from a helpdesk script is the ticket model. A ticket is a persistent record with a lifecycle, a queue, a history of every action, and assignments, and a service desk lives or dies on whether that record is reliable over years and across thousands of cases. The tailorability claim is the other thing to notice. In this lineage, an installation is a configuration and a set of custom modules rather than a purchase of seats, which suits the organisations that have already made that choice and is the reason the project describes itself as transparent and sustainable rather than cheap. The audience is a support or IT service team, or the company that builds software for one.

A continuation of OTRS, and the two goals behind it

The lineage is stated in the opening paragraph and it explains both the opportunity and the constraint. Znuny is a continuation of the OTRS Community Edition, version 6.0.30, which was declared end of life at the end of December 2020. Two goals follow. The primary goal is to provide a maintained and stable version of the well known ticket system and improve it with new features. The second is to reestablish a connection to the community. Both are worth reading carefully, because they tell you what this project is competing on. It is not competing on being the newest ticketing product. It is competing on continuity, and the continuity is real: the interface, the admin surface, the ticket model and the extensive configuration model all come from a codebase that many organisations already run, and the 7.x line continues from 6.0.30 rather than starting over. The flip side is that the same inheritance brings the old constraints, the Perl and mod_perl stack, the classic web tier, and a database schema that has grown by accretion for many years. A greenfield product will do some of those things better. What it will not do is let your agents keep the procedures they already wrote.

The requirements list tells you what you are signing up for

The software requirements section is short and specific, and it is the most useful paragraph in the readme for a first evaluation. The operating system requirement is Linux, with Debian or Red Hat preferred. The runtime is Perl 5.16.0 or higher. The web server section recommends Apache 2 with mod_perl2 or higher, and allows a web server with CGI support while saying plainly that CGI is not recommended. The database list is the widest part, with MySQL 8.0 or higher, MariaDB 10.3 or higher, PostgreSQL 12.0 or higher and Oracle 19c or higher all supported, which is unusual for a Perl era application and tells you the project keeps its database layer current. The browser section lists what is explicitly not supported, Internet Explorer before version 11, Firefox before version 31 and Safari before version 6, so the floor is old but the ceiling is not.

None of these are unusual requirements, and that is the point. There is no container to run, no cluster to size, and no service to subscribe to. The operational surface of Znuny is a Perl application behind a web server against a database you probably already run, and the documentation points to doc.znuny.org for the details, with the repository holding an INSTALL.md, an UPDATING.md and a SECURITY.md for the parts that matter in production. The honest caveat is that the default web stack, mod_perl2, is a configuration that fewer people now know how to operate, and CGI, the fallback, is worse. A team that has standardised on a reverse proxy with a modern application server will have to reintroduce a piece of that stack.

Mail intake is the reason for the fetchmail and procmail files

The repository listing contains several files that explain the architecture better than any diagram could. There is a .bash_completion file, which is a convenience for operators. There is a .fetchmailrc.dist, a .procmailrc.dist and a .mailfilter.dist, and those three are the reason this system exists in its current shape. A ticketing system for customer service usually has to ingest mail, because that is where the requests arrive, and the lineage here ships the whole chain: fetchmail to retrieve messages, procmail to route them, and mailfilter to classify them, with the .dist suffix marking them as templates to be copied and edited. It is an old and reliable way to do it, and it means an installation can be configured to turn incoming email into tickets without an agent touching a web page.

The i18n directory is the other structural hint. A service desk software product is only useful in a team that speaks the language of the people writing, so a translation directory is a baseline expectation, and the readme carries a translation status widget pointing at the project's translation platform, which is where the community contributions for languages live. The remaining directories complete the picture of a classic self hosted web application, with bin, development, doc, scripts and var, a Kernel directory, a Custom directory, and a licence file set that includes COPYING and a separate COPYING-Third-Party for the bundled components, which is the file to read before you redistribute a build.

The Kernel and Custom split, and what tailoring actually means

Two directory names in the listing do most of the explaining here. There is a Kernel directory and a Custom directory, and that separation is the heart of how this lineage is customised. The framework code lives in the kernel and is shared, while the things that make the installation yours, the organisation's own configuration, the additional ticket fields, the custom templates and any locally written modules, live in the custom layer that is meant to survive an upgrade. The practical consequence is a support contract between you and the project. When a new release arrives, you update the kernel and your custom layer is supposed to still work, which is a promise that is only as good as the discipline in the custom directory.

The same shape shows up in the documentation set. CONTRIBUTING.md, AUTHORS.md and CHANGES.md sit next to the code, so the changelog for each release is in the repository rather than in a tracker, and the development directory suggests the project keeps the scaffolding for a development environment alongside the application. A RELEASE file records the current version state. This is the layout of software that has been upgraded many times, and it is the layout that makes the transparency claim credible, because every part of the product, including the code you run, is in a public repository. The trade is that a system this configurable accumulates a lot of local knowledge, and a team that has customised heavily inherits a migration burden of its own making, which is the point where a support contract from the vendor becomes worth paying for.

A company funds the project, and it sells the support

The vendor section is one paragraph and it is important for anyone assessing the project. It is mainly funded by Znuny GmbH, Berlin, and the readme points to professional support and consulting through the company site, alongside the project website, the community forum and a Discord server. So the community project and the commercial company are the same organisation, which is a healthier arrangement than a community project abandoned by its former owner, and it is why the primary goal can be a maintained and stable version rather than a firehose of new features. The readme's second goal, reestablishing a connection to the community, is a statement of intent that this arrangement is meant to deliver.

The practical read for an evaluator is that you are choosing between a product with a company attached and a product without one, and this is the version with a company attached, which is the better of the two situations in most organisations. The company can be accountable for a fix, for a security patch and for a migration, and the source stays open so you are not locked out of what you run. The number to check is the one on the badge in the readme, since the latest release is tracked as a 7.3 tarball, and the readme also links the current release download directly.

https://download.znuny.org/releases/znuny-latest-7.3.tar.gz

That file is the starting point, and the project keeps no GitHub releases, so the download site and the changelog in the repository are the two places that tell you what you are installing.

Development on a dev branch, with CI and translation automation

The development model is visible in the badges and the repository layout. The default branch is dev rather than master, so the stable line is somewhere else, and the release badge tracks the rel-7_3 series. Continuous integration is driven by a workflow file named ci.yaml, and the repository also carries a .gitlab-ci.yml, so the project runs on both hosted CI systems rather than depending on one. The readme links a translation status widget that points at the project's own translation platform, which is a separate service from the repository, and the presence of a .weblate directory in the listing points to the same tool. The two are the parts of the project that need a community, and they are also the parts where a contributor has the most direct route in, since a corrected string or a configuration change is a concrete contribution rather than a code patch.

The other point to weigh is what the project does not say. The readme does not describe a supported version matrix per release, a deprecation policy for the old branches, or a change cadence, and it points to UPDATING.md and the changelog instead. For a system that runs a help desk, that absence matters, because a support contract is mostly about the boring parts, the upgrade path from the version you run to the version you want, and who is responsible when the database schema changes underneath you. So the sensible first step is not to install anything, it is to read UPDATING.md for the version you are on, and to check the change log for the releases between there and where you want to be.

Editorial conclusion

Adopt Znuny if you run a service desk today, want the OTRS interface your team already knows, and need a codebase that is still receiving fixes, because the alternative is maintaining a 6.0.30 era installation yourself. It does not fit a team that needs a modern product roadmap with a vendor accountable for it, since the community work is carried by a small company and the releases are published without GitHub release notes. Before you deploy it, read INSTALL.md and UPDATING.md in the repository, check the database and Perl versions in the requirements list against your platform, and decide deliberately whether the email intake path through fetchmail and procmail fits your mail flow or whether you will drive ticket creation through the web interface instead.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Project website
4. README
5. znuny/Znuny on GitHub