When an IT service desk team outgrows the default ticket form, the next question is rarely “Which ITIL process should we redesign?” It is most likely “Does anyone already ship a plugin for this?” On commercial IT service management (ITSM) platforms, that search is dull but predictable: you open the vendor marketplace. On open-source ticket systems, the same search still feels like archaeology.
I spend much of my week doing that archaeology. For the last year, I have been cataloging plugins, skins, and integrations for Zammad, Znuny, OTOBO, and related forks – not as a researcher looking at marketing pages, but as someone trying to answer a practical question from operators: What exists, does it still install, and on which version?
The short version: the add-on catalog for open-source ITSM isn’t missing. It is scattered, inconsistently labeled, and easy to misread. That wastes days, and it quietly kills otherwise good migrations.
Where open-source ITSM add-ons actually live today
If you ask five Znuny or Zammad admins where they found their last useful extension, you will usually get five different answers. This is not because people are careless. It is because there is no single “app store” that the community treats as authoritative.
In practice, packages hide in at least six places:
Vendor or project shops and package feeds
Znuny publishes add-ons through addons.znuny.com. OTOBO still ships a public package tree (historically via ftp.otobo.org). Zammad documents community and custom packages separately from the core product. Each feed is useful. None of them is complete for the wider ecosystem.
GitHub and GitLab
A surprising number of useful packages never leave a personal repository. The README is the documentation. The last commit is the support policy. Search only works if you already know the package name or the author’s handle.
OPAR and other community archives
The old OTRS Package Archive (OPAR) is still a magnet for legacy .opm files. Some of those packages remain valuable. Many are pinned to framework versions that no longer match a current Znuny or OTOBO install.
Forums and mailing lists
“Has anyone got a working X for 7.x?” is still a normal discovery method. The answer is often a drive link, a gist, or “We forked it two years ago, I’ll email you.”
Internal forks that never get published
Consultancies and in-house teams rewrite a Dynamic Field, a Generic Interface mapping, or a skin, then keep it in a private repo. From the outside, the capability looks missing. Inside one organization, it is already a solved problem.
Comparison sites and blogs
Practitioner write-ups help with system choice. They rarely list package-level compatibility, which is the question you face after you have already picked a fork.
This scatter is not unique to open-source ITSM. What makes it expensive here is that the add-on often determines whether you think, “We can live with this ITSM tool,” or “We will buy something else.” A missing time-accounting package or a broken customer-portal theme is not a nice-to-have. It is a go/no-go.
Why the catalog still feels broken
The OTRS family makes the problem sharper. Znuny, OTOBO, and KIX share a common ancestor and, on paper, a common package format: .opm files with a SOPM manifest. Operators reasonably assume that a file ending in .opm will install “on the next fork.” It often will not.
The first filter is the declared framework version. A package that only lists 6.0.x will be refused or warned on a current OTOBO 11 or a recent Znuny 7 line. The second filter is the API the author actually called. Even when the package manager accepts the file, a renamed Perl module, a changed cache layer, or a new frontend can make the add-on fail at runtime. Skins are worse: a theme built for the classic agent interface rarely maps cleanly onto a redesigned UI. KIX 18, in particular, is far enough from the original architecture that classic .opm add-ons are the wrong mental model.
Zammad has a different version of the same problem. There is no .opm illusion. Instead you get a mix of official features, documented package hooks, community repositories, and one-off scripts. Discovery is easier if you live on the Zammad forum. It is harder if you are evaluating the platform for the first time and only see the marketing site.
On top of compatibility sit the boring metadata failures that still cost time: no license file, no last-tested version, no statement about whether the package is abandoned, and no list of required companion packages. I have opened repositories that looked active because GitHub showed a recent commit – and the commit was a README typo. I have also found “dead” packages that still install cleanly and do one job well. Recency is a clue, not a verdict.
A practical open-source evaluation ITSM add-on checklist
When a team asks me whether they should install an open-source ITSM add-on, I walk the same list every time. It is unglamorous. It is also faster than debugging a production package manager on a Friday.
1. Name the job, not the product
Write the outcome first: “Agents must see an SLA breach banner on the customer record,” not “We need package X.” Then search for that job across official feeds, GitHub, and the relevant forum. You will often find three partial solutions instead of one official one.
2. Match the framework, not the brand
Read the SOPM/package metadata if it exists. “Works on OTRS” is not a version. “Tested on Znuny 7.1” is. If the author names only a product family, treat compatibility as unknown until you have a staging install.
3. Separate installable from operable
A green package-manager message means the archive unpacked. It does not mean the SysConfig keys still exist, the templates still render, or the Generic Interface operation still maps. Plan a test ticket path: create, update, notify, close. If the add-on touches the customer interface, test that path too.
4. Follow the dependency chain
Many .opm packages assume another package, a CPAN module, or a specific Elasticsearch/Redis setup. Missing dependencies fail loudly. Version-skewed dependencies fail quietly. Write down what else you installed. Future you will need that list.
5. Check who will patch it
Look for an issue tracker with recent replies, a named maintainer, and a license you can live with. A useful abandoned package is still useful – but only if you accept that you are now the maintainer. That is a staffing decision, not a technical surprise.
6. Prefer boring open-source packages for production
Add-ons that stay close to business logic – Dynamic Fields, ACLs, web service mappings – travel between forks more often than anything that rewrites the UI. If you need a skin, budget for a fork-specific variant. Do not assume portability because the file extension matches.
What a healthier open-source ITSM catalog would look like
The open-source ITSM community does not need another closed marketplace. It needs shared, boring metadata: which system, which versions, last verified date, license, repository URL, and whether the package is a skin, an integration, or a workflow extension. Official project feeds should remain the source of truth for first-party add-ons. Community catalogs should point at those feeds instead of copying files into yet another silo.
A few efforts already move in that direction. Project documentation from Znuny, OTOBO, and Zammad is the right first stop. OPAR remains a historical index you should treat with version skepticism. Vendor-neutral directories – including the one I help maintain at Open ITSM Hub – are useful when they record compatibility instead of just collecting names. They are harmful when they imply a package is interchangeable across forks. The test is simple: Can an admin decide in five minutes whether a package is even worth staging?
There is also a cultural piece. Authors who publish a package do the community a favor when they state what they do not support. “Znuny 7 only, no OTOBO port” is more helpful than a logo farm on the README. Operators do the community a favor when they report the version they actually tested, not just “Works for us.”
The point of this open-source ITSM article
Open-source ITSM is not short of add-ons. It lacks a trustworthy map. Teams lose time because the same capability is listed under three names, on three sites, for three framework versions, with no shared language for “This will not install on yours.”
If you run Znuny, OTOBO, Zammad, or KIX, treat discovery as part of service design, not as a Friday afternoon Google session. Write the job to be done. Check official feeds first. Then use open-source ITSM community archives and directories as indexes, not as installers. Stage before you trust. And when you find something that works, write down the version numbers – for the next person who will otherwise spend two days rediscovering the same package in a forum thread from 2019.
Open-Source ITSM FAQs
There’s no single authoritative app store. Packages turn up across vendor feeds, GitHub and GitLab repos, the old OPAR archive, forums and mailing lists, unpublished internal forks, and comparison blogs, and none of these sources cover the whole ecosystem on its own.
Not reliably. Znuny, OTOBO, and KIX share a package format, but framework version differences and changes like a renamed Perl module or a new frontend can make an add-on fail at runtime even when the package manager accepts the file. KIX 18 in particular has moved far enough from the original architecture that classic .opm add-ons aren’t a safe assumption.
A green package-manager message only confirms the archive unpacked. It doesn’t confirm the SysConfig keys still exist, the templates still render, or the Generic Interface operation still maps correctly, so a full test ticket path (create, update, notify, close) is the real check.
Six things: name the job the add-on needs to do rather than the product name, match the framework version rather than the product family, separate “installable” from “operable” with a real test path, follow the full dependency chain, check whether anyone will patch it, and favor packages that stick to business logic over ones that rewrite the UI.
No. Recency is a clue, not a verdict. Some repositories look active because of a recent commit that turns out to be a README typo, while some seemingly abandoned packages still install cleanly and do their job well.
Shared, unglamorous metadata: which system, which versions, the last verified date, the license, the repository URL, and whether the package is a skin, an integration, or a workflow extension, with official project feeds staying the source of truth and community catalogs pointing at them rather than duplicating files.
Tobias Bück
Tobias Bück is based in Mannheim, Germany. He works on open-source ticketing as founder of Open Ticket AI and helps maintain Open ITSM Hub, a free catalog of plugins for Zammad, Znuny, OTOBO, and related systems. His day-to-day work is cataloging packages, checking fork compatibility, and helping operators install and migrate IT helpdesks.
Social/web
LinkedIn: https://www.linkedin.com/in/
GitHub: https://github.com/buecktobias
Open ITSM Hub: https://openitsmhub.com
Open Ticket AI: https://openticketai.com
