Visit the ZenTao website
The official site of the open-source ZenTao repository, published by EasySoft. Opens in a new tab — hold Ctrl (⌘ on a Mac) or middle-click to keep it in the background.
github.com/easysoft/zentaopmsZenTao separates three things most tools blur together: the product (what is being built and why), the project (the work and the people doing it), and quality (what was tested and what was found). Requirements, tasks, defects, test cases and releases are distinct objects with links between them, and the links are what make the platform worth deploying.
The reason to choose it over a lighter tracker is evidence. ZenTao can show, for a given requirement, which tasks implemented it, which test cases verified it, which defects were raised against it and which release it shipped in — and hold that as a record you can produce years later. For organisations that must demonstrate that to internal audit or a regulator, that chain is the entire point.
Who it’s for
Organisations that must evidence how a requirement became a released change.
- Banks and financial institutions with change-traceability obligations to internal audit or a regulator
- Teams working under a formal quality system where requirement-to-test coverage must be demonstrable
- Development organisations running Scrum, waterfall or a mix of both in the same portfolio
- Departments consolidating requirements, tasks, defects and test evidence off separate systems
What we deliver
A configured platform with your traceability model built in, not bolted on afterwards.
Installation and hardening
Deployment on your servers or VMs — application and database tiers separated and secured to your standards. PHP and MySQL, the stack your team most likely already runs.
Directory integration
LDAP or Active Directory authentication with project and role mapping.
Product and project modelling
Your products, programmes and projects structured so the hierarchy matches how your organisation actually governs work.
Workflow configuration
Requirements, tasks, defects and change requests modelled with your fields, states and transition rules rather than the defaults.
Traceability links
Requirement-to-task, task-to-case and case-to-release links configured so coverage reporting is generated rather than assembled by hand.
Test management
Test cases, suites, runs and results held against the requirements they verify, in the same system as the defects they raise.
Agile and waterfall side by side
Backlogs, sprints and burndown for the teams that work that way, alongside stage-gated structure for the ones that do not.
Release management
Builds and releases recorded against the stories and defects they contain, so the contents of a past release can be stated rather than reconstructed.
Migration
Import of existing projects, requirements and backlogs from your current tooling.
Training and handover
Separate tracks for project managers, developers, QA and administrators.
On-premises versus cloud
Every criterion below is one your auditors will ask about. This is why we deploy inside your network by default.
| Criterion | On-premises, on your infrastructure | Public cloud / SaaS |
|---|---|---|
| Security | You control the firewall, the encryption keys, the access policy and the audit trail. | Shared infrastructure and a provider-defined security boundary. |
| Privacy | Data never leaves your network perimeter. | Data is stored and processed on third-party systems under their terms. |
| Autonomy | Full customisation, your upgrade schedule, no vendor lock-in. | Provider-driven roadmap and forced upgrade windows. |
| Integrity | You define backup, retention and recovery, and you test them. | You inherit the provider’s backup policy and their definition of acceptable loss. |
| Continuity | Service survives loss of internet connectivity; it runs on your intranet. | An outage or a commercial dispute at the provider becomes your outage. |
| Cost | Capital cost plus support; no per-seat escalation as headcount grows. | Per-user subscription that grows with your organisation. |
Requirements and test evidence are among the most commercially sensitive artefacts an organisation holds. Where they are stored is a question worth answering deliberately.
How it connects to the rest of your stack
Nothing we deploy is meant to stand alone. These are the joins we build as part of the same engagement.
- Governance — Where we tailor PRINCE2 Agile for you, stage boundaries, tolerances and management products are configured inside the platform and its reporting views rather than left in a separate document.
- Defect tracking — Where a lighter defect tracker is already in use, defects can be linked into the traceability chain rather than duplicated.
- Service desk — Changes raised through the service desk can be promoted into governed work with the original request preserved.
- Monitoring — Infrastructure incidents needing engineering work enter the same backlog as planned work rather than being handled invisibly.
Engagement summary
Questions we’re usually asked
Is ZenTao too heavy for a small team?
Often, yes — and we will say so. It earns its complexity when traceability is a requirement. If your teams need planning and task tracking without a formal audit chain, Leantime is usually the better fit and we will recommend it instead.
What is the licence, exactly?
ZenTao is offered under either AGPL-3.0 or the publisher’s own ZPL. We deploy it unmodified, so neither licence’s copyleft obligations are triggered by ordinary internal use — but your legal team should see the terms, and we provide them at scoping rather than after signature.
What if the publisher changes direction?
It happens, across the industry, and it is why our first commitment is on-premises rather than open source. What matters then is exit cost. ZenTao’s source is AGPL-3.0, published on GitHub and mirrored elsewhere, so a licence already granted cannot be withdrawn and the code cannot be taken off the internet by one company’s decision. We also keep our own archive of the exact release we deployed for you, and hand you a copy.
Under PRINCE2 governance
Where the accountability is requirement-to-test evidence, ZenTao is where we start. Product, project and quality are separate objects, and the links between them are what an auditor follows.
| PRINCE2 | ZenTao |
|---|---|
| Project Product Description, Business Case | Product and project documentation |
| Project and Stage Plans | Roadmap, iteration and release planning |
| Work Packages | Epics, features and work items |
| Quality Register | Test cases, suites and runs |
| Risk and Issue Registers | Risk and issue trackers |
| Progress control | Dashboards and reports |
The chain runs Business Case to Accepted Product with every link queryable, which is what turns ‘we follow a process’ into evidence. The full thirteen-row mapping is in Where each PRINCE2 management product lives.
How this compares with the other platforms we deploy, and which one fits which obligation, is on Choosing Between Our Platforms.