Open-source task managers compared

Huly puts a project tracker, team messaging, documents, a calendar and time management inside one workspace, so a task, the conversation about it and the document behind it live in the same application. It is aimed at teams who would otherwise run four tools, and it is the broadest single product in this directory.

The tracker is Linear-shaped: issues with sub-issues, components and milestones, moved by keyboard as much as by mouse. Around it sit a shared team calendar, documents, messaging and a virtual office. The calendar is native and central to how the product is meant to be used, but nothing speaks CalDAV or iCalendar to it, so it cannot become the calendar on a phone.

The price of that breadth is the deployment. A Compose file brings up several services with MongoDB or CockroachDB behind them, object storage for files and a search index beside it: more services than anything else in this directory asks you to run, and an ongoing commitment rather than a one-evening install. The code is TypeScript and Svelte, and the repository covers the whole platform rather than the tracker alone.

EPL-2.0 covers that platform, and the July 2026 closure of the hosted service did not touch it. What the closure removes is the vendor’s own instance as a fallback, which is worth weighing against a product this wide. Data leaves through workspace backup and restore tooling plus a plugin and API surface rather than named export formats, and because the workspace holds messages and documents as well as issues, replacing it means replacing several tools at once.

OpenProject is classic project management with the agile parts in the same place: work packages, Gantt, boards, budgets and timesheets under one project structure, with roles and permissions underneath. It is the entry a PMO would recognise on sight, and it carries the highest enterprise-features score in this table.

Everything is a work package - task, milestone, bug, feature, risk - separated by type, and each type carries its own form, workflow and status transitions. Projects nest, modules switch on per project, and portfolio views read across all of them. Time and cost tracking are native rather than a plugin, which is rare at this size.

It is a Rails and Angular application over PostgreSQL, shipped three ways: one packaged container with everything inside it, native packages for the usual distributions, or an official Helm chart. The database is the only external service, and upgrades are documented per release. Calendars leave as iCalendar subscription URLs, one per work-package view and one way only; there is no CalDAV to write back to.

The Community Edition and Enterprise add-ons are GPLv3-licensed, while SSO, two-factor authentication and several administration and reporting features belong to the Enterprise editions. The edition table rather than the feature tour is the document that says what you are getting, and the gap between the two is the most common surprise on this project. Exports are CSV, XLSX and PDF, with an OAuth2 REST API for whatever the exports miss.

Plane is a product-development workspace: work items in cycles and modules, grouped under projects and initiatives, with board, list, spreadsheet and Gantt views over them. It reads like Linear or Jira to anyone arriving from either, and it takes the highest mean score in this directory.

The object model is most of the reason for that score. Work items carry custom properties and states, cycles do the work of sprints, modules group feature-sized slices that cut across cycles, and initiatives sit above projects for portfolio work. Views are saved per project or per person, and the spreadsheet view edits in place, so planning does not mean leaving the tracker.

Self-hosting is Docker Compose over PostgreSQL, Redis and MinIO, or a Kubernetes chart for anything larger. That is several services rather than one container, and the operational cost is real, though both paths are documented. There is no calendar interface of any kind, neither CalDAV nor an iCalendar feed, which is the sharpest gap in an otherwise wide product.

Plane is open core and the boundary has moved between releases, which makes the Community Edition’s own feature list the document to read and the pricing page the one to ignore. On the way out there are CSV and JSON exports, a REST API, webhooks, OAuth apps and an MCP server, which is the widest advertised integration surface recorded here.

Redmine is a configurable issue tracker that has been running projects since 2006: trackers, statuses, workflows and custom fields defined per project and per role, with a plugin ecosystem that has had two decades to fill the gaps. The interface shows its age; almost nothing else about it does.

The configuration model is the product. A tracker is a work type, a workflow is a matrix of role-by-status transitions, and custom fields attach to issues, projects, users or time entries. Subprojects, issue relations and per-project module switches cover most of what newer tools present as headline features. Agile boards are not in core and arrive as a plugin, which is the trade this project has always made.

It runs on Ruby on Rails over PostgreSQL, MySQL or SQLite, from an official Docker image or distribution packages. The stack is ordinary and the upgrade path is documented; plugins are what make upgrades interesting, since each one has to match the Redmine version underneath it. Three supported versions shipped in August 2026, which answers anyone assuming the project is dormant.

There is no first-party hosted service - Planio, Easy Redmine and others sell that. Data leaves as CSV, PDF, XML and JSON, with iCalendar and Atom feeds over any issue query and a full REST API in both XML and JSON. Between standard databases, a documented API and twenty years of format continuity, it has the strongest archival story of the large tools here.

AFFiNE puts documents, an infinite whiteboard and databases in one workspace, with tasks as database views rather than a tracker of their own. The interface is among the most finished in this directory, and the licence underneath it splits in a way no other entry here does.

A page has two modes: a document, and an edgeless canvas where the same blocks sit on a whiteboard alongside shapes, frames and connectors. Databases carry table, board and gallery views, though no calendar, and blocks written in a document can be pulled onto the canvas without leaving the page. The whiteboard has no real peer among the tools here.

The licensing line runs between client and backend. The client is MPL-2.0; the self-hosted backend ships under an AFFiNE Enterprise Edition licence, and multi-admin roles and team management sit in a paid self-hosted tier. That is why sovereignty scores 2.8, the lowest in this table, for a product whose source you can read.

Running it is Docker Compose with PostgreSQL and Redis, which is more machinery than a notes application suggests. Exports are Markdown, HTML, JSON and PDF or PNG over a GraphQL API with WebSocket sync - fine for documents, thinner for structured work. The audience is large for the editor and much smaller for the backend, so self-hosting questions find fewer public answers than the star count implies.

AppFlowy is a Notion-shaped workspace: nested documents with inline databases, where table, board and calendar are three views of the same records. It has one of the largest followings in this directory, and a much smaller share of that following runs the backend itself.

Documents are the container and databases are embedded in them, with typed fields underneath; a view is a saved arrangement of one database rather than an object of its own. Kanban, grid and calendar are all first-class, workspace roles and guest links cover sharing, and the desktop and mobile builds lead the web one.

Self-hosting means running AppFlowy Cloud, the sync server, from Compose: several services over PostgreSQL, documented but not a single container. The clients are Flutter and Rust, and sync is WebSocket-based over a cloud API. There is no CalDAV or iCalendar interface, so the calendar view stays internal.

The core is AGPL and the margin is elsewhere: AI features and a vault tier are paid, and SSO and audit belong to the commercial side. Which build a capability lives in is the question to settle first, because the answer has moved with the releases. Exports are JSON, Markdown and CSV, which is adequate for documents and thinner for structured work.

Habitica wraps habits, dailies and to-dos in a role-playing game: tasks award experience and gold, missed dailies cost health, and parties and guilds carry the accountability a manager otherwise would. It is a motivation system, and it takes the lowest mean score here because it is being measured against project tools.

There are four lists and no views: habits, dailies, to-dos and rewards. A daily repeats on a schedule the interface never draws for you, there is no board, timeline, calendar or timer, and completion rather than duration is the unit. That is the whole interface, and the narrowness is the design rather than a gap in it.

The social layer is where the work happens. Parties run quests that convert task completion into shared progress, guilds carry topic communities, and challenges let one person set tasks for many. It is a social structure rather than an organisational one, with no roles or permissions behind it.

The code is GPLv3 and self-hostable with Compose over Node.js, MongoDB and Redis, and the subscriptions are cosmetic and live on habitica.com, where nearly all of its users are. That leaves the self-hosted path thinly travelled: the bugs you hit there have fewer people ahead of you in the queue. Exports are JSON and CSV over a full REST API with user-configurable webhooks, which is more than this category usually offers.

Leantime is project management written for teams that have no project manager in them: tasks and Kanban at the front, with timelines, retrospectives, goal boards and native timesheets behind. The audience is explicit, down to onboarding that assumes you have never run a sprint.

A project carries a blueprint rather than an empty board: ideas and a strategy board, milestones on a timeline, tasks with estimates, and retrospectives at the end. Time logging sits in the core, so a timesheet comes out of the same records the board moves. The vocabulary stays plain throughout - no work items, no initiatives, no portfolio.

It is PHP over MySQL with a server-rendered interface, run from a Compose file with a web server beside it. There is no queue, cache or object store to operate, which puts it among the lighter deployments here despite the feature count. Calendars leave as iCalendar feed URLs for tasks and milestones, one way out; there is no CalDAV.

The AGPL core is the product and the commercial layer is a plugin marketplace rather than a held-back edition, which makes the boundary easier to read than most open-core arrangements. It does move, though: anything you build on a paid plugin has to be replaced before you leave. CSV, JSON and timesheet exports, a REST API and webhooks cover the exit for the core itself.

Logseq is an outliner over plain Markdown and Org-mode files on your own disk, where a task list is a query across notes you already wrote. It takes 5.0 for both sovereignty and portability, which is what a database made of files on your own disk is worth.

Work is captured as blocks. A block marked TODO or DOING is a task, a clock log accumulates on it while it is DOING, and queries pull them back together by page, tag, deadline or scheduled date. The daily journal is the default entry point, so tasks tend to be written where the thinking happened rather than filed somewhere separate.

Deployment is optional: a container for the self-hosted web app, a desktop build with no server at all, or the hosted browser demo reading a local folder. Opening a local graph in the browser needs the File System Access API, which Chromium implements and Firefox and Safari do not. There is no CalDAV or iCalendar interface anywhere in it.

The marketplace listed 486 plugins in August 2026, and the shape of that number matters more than its size: it extends the editor rather than reaching out to other systems. A kanban board and calendar views are in there, and neither is in core. The open question is the database rewrite, in beta for a long time with plugin compatibility against it still unsettled. The exit, meanwhile, is that there is nothing to exit: Markdown and Org-mode files, readable if Logseq never runs again.

Deck is a Kanban board that runs as an app inside Nextcloud, beside Files, Calendar and Talk. If Nextcloud is already deployed it is the cheapest board in this directory to add; if it is not, it is the most expensive.

Cards carry due dates, labels, assignees, checklists and attachments drawn from Nextcloud Files, and boards share through the same groups that share everything else on the platform. A Gantt view was announced in June 2026, which is why older comparisons still list its absence. What is missing is the layer above the board: no portfolio, no cross-project reporting, no cost model.

The strongest reason to choose it is calendar sync. Deck cards surface through Nextcloud Tasks over CalDAV, read and write, against the same items the board shows. With Vikunja it is one of only two entries here offering a two-way standard interface, which is what makes an unmodified phone a first-class client. Time tracking is not native; a third-party app covers it.

Deployment is Nextcloud’s own, and Deck is the short step at the end of it: stand up the platform over PostgreSQL or MariaDB, then add Deck and Tasks from the app store. Identity, sharing, quotas and administration are inherited rather than implemented, which is most of why the enterprise score sits where it does. Data leaves as iCalendar and CalDAV, JSON, and CSV through companion apps, over OCS and REST APIs - but it leaves with Nextcloud rather than on its own.

NocoDB puts grid, kanban, gallery, form and calendar views over a SQL database, including one you already run, so a task board becomes a view rather than a new system of record. It is the largest project here by star count and among the furthest from being a task manager out of the box.

Point it at an existing PostgreSQL or MySQL schema and it reads the tables as they stand; start from scratch and it keeps its own SQLite. Either way you get formulas, lookups, rollups, links between tables, per-view filters and sorts, and forms that write rows. Five view types over any table is a lot of interface for something that models nothing about tasks in particular.

Because the database can be yours, the data need never enter NocoDB’s storage in the first place, which is the strongest portability position in this directory. Exports are CSV, JSON and Excel, the REST API is generated from the schema with Swagger, webhooks fire per table, and Zapier, n8n and Make connectors are packaged.

The AGPL core self-hosts in full from one container, with owner, creator, editor, commenter and viewer roles per base; SSO, audit logs and row-level policy sit in the paid tiers. What it does not supply is a method. Sprints, dependencies and timelines exist only once you have modelled them, and the modelling is yours to get right.

PLANKA is the closest self-hosted thing to Trello: lists of cards on a board, dragged between columns, with swimlanes, labels, due dates and attachments. The Community edition is a working board for a team; the timeline and calendar views sit in the paid tiers.

Board mechanics are where the effort has gone. Cards carry checklists, comments, membership and stopwatch-style time entries, notifications reach a wide set of targets, and boards move in and out as JSON. There is no portfolio layer and no dependency model, because the board is the product rather than a view onto something larger.

Deployment is two containers, the application and PostgreSQL, and nothing else: no object store, no queue, no cache. It comes up quickly and the Node.js and React stack is ordinary to operate. There is no calendar interface at all, so due dates stay inside PLANKA.

The licence is the part to read before committing. PLANKA is recorded here as source-available rather than FOSS: the editions are governed by fair-code terms rather than OSI-approved licensing, and several organisational features belong to Pro and Enterprise. The data is yours and leaves as JSON or CSV over a REST API. The software comes with conditions attached, which is precisely what the licensing column is recording.

Taiga is agile-first and says so by omission: backlogs, sprint boards, burndowns, WIP limits, swimlanes and epics, with no Gantt, no calendar and no time tracking anywhere in it. A team that already runs sprints needs no introduction to it; anyone who needs a timeline has finished the evaluation.

Scrum and Kanban are separate project types rather than two layouts of one. User stories carry points per role, sprints close with a burndown, and epics group stories across projects. Custom fields, custom statuses and per-project workflow configuration go deep; what is absent sits above the sprint, in portfolio, cost and governance.

Self-hosting is a multi-container Compose stack - Django and React over PostgreSQL, with RabbitMQ and Redis behind the events system - installed through an official script. It is documented, and it is not one container. The Python stack is conventional; the number of services is the cost.

It is open source throughout with nothing reserved for a paid edition, and the first-party cloud is convenience rather than leverage. A project dumps completely as JSON, with CSV beside it and a REST API and webhooks for the rest. The integration story is source control: GitHub, GitLab, Gitea and Gogs are the documented ones.

Focalboard is a Trello-shaped board with Notion-shaped properties: table, gallery and calendar views over the same cards, custom fields, filters and grouping. It came out of the Mattermost project, and it is now maintained by whoever turns up.

A board is a table of cards with typed properties - select, date, person, number, text - and the four views are four ways of drawing that table. Grouping by any select property makes a different board without moving any data. Above the board there is nothing: roles are admin, editor, commenter and viewer, per board, with no organisational model over them.

The personal server is a single Docker image, or the board runs as a plugin inside an existing Mattermost, where identity and sharing come from the platform instead. MIT covers the personal server and an AGPL enterprise build sits beside it. Hosting exists only inside Mattermost Cloud, which is to say there is nowhere to buy the board on its own.

Governance is the caveat and it is a hard one. Mattermost stopped bundling the plugin in September 2023 and contributes neither features nor fixes; community commits continue into 2026 against an open call for maintainers. Plan around a roadmap that is not there, and read the exit routes as the operative feature: JSON board archives, CSV exports and a REST API are enough to leave with, which for a project in this state is what matters.

Grist is a relational spreadsheet with Python formulas, cell-level access rules, and a document that is a SQLite file. A task tracker is one of the things you can build in it. It is not one of the things it ships.

A document holds tables, and the pages over them are assembled from widgets: a grid, a card list, a chart, a kanban widget over a status column, a calendar over a date column. Widgets link by selection, so picking a project row filters the task table beside it. Formulas are real Python evaluated in a sandbox, which puts conditional logic and rollups within reach of anyone who can write a list comprehension.

Access rules have no equal in this table. Read, update and create rights can be granted by table, by column, by row and by the value of a cell, evaluated per user, and the rule engine is in the Apache-2.0 core rather than the paid build. SSO and SCIM are Enterprise. The rest self-hosts as one container over SQLite, with no external database, queue or object store to run beside it.

The exit is unusually clean: a Grist document is a SQLite file you can download and open with anything that speaks SQLite, with CSV and Excel exports and a REST API with an interactive console beside it. Packaged Zapier, n8n and Make connectors and outgoing webhooks cover automation. The project has visible adoption in public-sector and civic-tech deployments, where that exit is the reason it was chosen.

Kanboard is a minimal Kanban board with an unusually small operational footprint: one PHP application over SQLite, no build step, no JavaScript framework, MIT licensed with nothing held back. It suits teams who want the board to be dependable more than they want it to be handsome.

Behind the sparse interface is more machinery than it advertises. Swimlanes, WIP limits per column, automatic actions that fire on card events, subtasks with their own timers, a Gantt chart and a calendar are all in core. Plugins add the rest, and a plugin is PHP dropped into a directory rather than a build step.

It runs on SQLite by default, with PostgreSQL and MySQL optional, in a single container or on any PHP host. There is almost nothing to operate - no queue, no cache, no object store - and a backup is a file copy. That is why it takes 4.9 for deployment, behind only the entry with no server at all.

Calendars leave as read-only iCalendar feeds, one per project and one per user; a JSON-RPC API and webhooks cover automation. The licence is MIT, the codebase is small enough to read, and and the project has been maintained since 2014 by a contributor list in the hundreds. Very little of it would be hard to leave behind, which is the point of it.

Kimai is a timesheet application with tasks attached rather than the reverse: activities under projects under customers, with rates, budgets, approvals and invoices on top. For teams whose work exists mainly to be billed, it is the shortest path from a recorded hour to a sent invoice.

Nothing in it is a card on a board. An hour is booked against an activity, inside a project, inside a customer, started on a timer or typed in afterwards, and the rest is the machinery around it: hourly and internal rates per user, customer and activity, budgets with alerts, approval workflows, and invoice templates that render to PDF from the same records.

It is a Symfony PHP application over MySQL, one Compose file, maintained since 2006, with an installation guide that has had twenty years of questions put to it. Roles run customer, user, team lead and administrator with strict visibility gates, and SSO and an audit trail are in the core rather than sold on top. A one-way iCalendar feed of the timesheet is the only calendar interface.

The commercial layer is an official plugin store, and a good part of the ecosystem lives there, including accounting and chat connectors such as Bexio, Lexoffice and Microsoft Teams. The AGPL core still tracks, budgets and invoices without reaching for the store. Exports are CSV, XLSX, PDF and JSON over a JSON REST API, with mobile and desktop clients and a CLI beside them, because getting time into an accounting system is the design goal.

Super Productivity is a personal task list with a pomodoro timer and a day schedule, which pulls its work items out of the trackers a team already runs. It is single-user by design, it has no server, and it takes 5.0 for deployment because there is nothing to deploy.

The loop is the product: pick a task, start the timer, and the time log writes itself; at the end of the day the schedule shows where the hours went. Tasks arrive from a dozen named issue providers - Jira, GitHub, GitLab, OpenProject, Linear and Azure DevOps among them - and each one is called straight from your own device, with no middleware holding a copy in the middle.

There is no multi-user model at all: no roles, no shared instance, nothing to administer. That is the lowest enterprise score in the table and a description rather than a complaint. Data lives in the browser’s IndexedDB, with optional sync to WebDAV, Dropbox or a local file, so the sovereignty question resolves before it is asked.

It reads a CalDAV server as one more issue source but is not itself a CalDAV server, and the schedule timeboxes today rather than charting dependencies. Exports are JSON and CSV, plus whatever the sync target already holds as plain files. MIT, no hosted tier, 22.1k stars, and frequent releases from one maintainer with a steady contributor stream behind them.

Taskwarrior is a command-line task manager with a tuneable urgency model, twenty years of continuity, and no first-party web interface. It is in this directory because third-party clients built on its sync protocol reach it from a browser.

Tasks carry projects, tags, priorities, due and scheduled dates and arbitrary user-defined attributes, and urgency is a weighted sum of them with coefficients you can edit. Contexts and filters do the work a board would do elsewhere. Reports are defined in configuration and rendered in the terminal, including a calendar report that is a printout rather than a view you can schedule against.

Storage is a local database, with TaskChampion, the Rust sync implementation, as an optional server for keeping several machines in agreement. There are no roles, no organisation and no shared project, and the enterprise score of 1.2 describes a tool that was never trying to have any.

The browser route is the caveat. It comes from third parties on the documented sync protocol, including WingTask and taskwarrior_web, and the MIT licence at the head of this record covers the task engine rather than the client you would log into. Data is JSON and the native task format, with a CLI and a hook system, on a format with two decades of compatibility behind it.

Trilium Notes is a scriptable hierarchical note tree with attributes, templates and scripting that runs inside the notes themselves. The first-party task list is still being built; until it lands, a to-do is a note wearing a label and a community script is what renders those notes as a list.

Notes nest, and the same note can appear in several places in the tree at once. Attributes - labels and relations - are the modelling primitive, templates apply structure to new notes, and scripts stored in notes run against the rest. Almost anything can be built from that, given the patience to invent the convention first.

It runs as one container with an embedded SQLite database, with desktop clients syncing to it. There is no concept of a second user: the instance is single-tenant and password-protected. That rules it out for team work and leaves it strong as a personal knowledge base with tasks inside it.

The lineage matters here, because the name outlived the repository it started in: development moved, releases resumed on a regular cadence, and 37.9k stars came across with it. Anything written about Trilium before that move describes a codebase nobody is maintaining. Data leaves as HTML, Markdown or a complete database ZIP, with a token-authenticated REST interface called ETAPI; leaving is a download.

Vikunja is task management that stays a task list: list, Kanban, table and Gantt views over tasks, labels and reminders, with CalDAV underneath and importers from the tools people are usually leaving. It is the lightest server in this directory and one of only two entries with two-way calendar sync.

The model is plain on purpose. Projects hold tasks; tasks hold subtasks, relations, labels, assignees, reminders and attachments; saved filters do the work a query language does elsewhere. There are no work items, initiatives or portfolios to learn, and little enterprise workflow configuration behind the views.

It deploys as a single Go binary on a machine you already have, or as two containers over SQLite or PostgreSQL, with nothing else required beside it. CalDAV is native and two-way against the same tasks the interface shows, which makes a phone’s built-in reminders app a client. Importers cover Todoist, Trello and Microsoft To Do.

Time tracking moved to a separate Pro tier in 2026, out of the free AGPL core, and audit and administration features sit there too. The core stays AGPL, self-hostable and exportable: a full account export as JSON with a ZIP of attachments, plus CalDAV, a REST API and webhooks. The move between Vikunja Cloud and a self-hosted instance is documented in both directions.

Wekan is an open-source Trello that has been shipping since 2016: lists, cards, swimlanes, checklists, subtasks, colour-coded labels and rule-based automation, under MIT with no edition held back. It is one of the plainest licensing positions in this directory.

The board is deeper than the one it imitates. Swimlanes cross the lists, rules fire on card events without a plugin, and a card carries received, start, due and end dates - four date fields, and still no timer or timesheet behind them. Views cover Kanban, lists, swimlanes and a calendar.

The operational story is the caveat. Wekan is a Meteor application over MongoDB, run from Compose or a snap package, and the Meteor upgrades have been the eventful part of its history rather than the board on top of them. The application is dependable; the stack under it is where the attention goes.

Data leaves as JSON, CSV and TSV over a REST API with outgoing webhooks tested against Slack and Rocket.Chat, and a documented Trello import brings boards in. Due dates leave as a one-way iCalendar feed; there is no CalDAV. Ten years of continuous releases and 21.1k stars sit behind it, and the project was marked at the Free Software Conference Ukraine in July 2026.

Restyaboard is a Trello-shaped board with offline caching, card-level messaging and email-to-card, last tagged at 1.7.1 in March 2022. It is recorded here for completeness rather than as a recommendation.

The feature list was ahead of its moment: Kanban, list, Gantt and calendar views, offline sync, chat on cards, and mail dropped straight onto a board. Organisation admins, board managers and restricted guests cover the access model. All of it works, and all of it looks precisely like 2022.

Deployment is Docker with Nginx, PHP and PostgreSQL, and the install notes have not been revisited since the code stopped moving. The stack - PHP with a Backbone.js front end - dates the project as clearly as the interface does. A one-way iCalendar feed of card due dates is the only calendar interface.

The licence is OSL-3.0: OSI-approved, but unusual, with reciprocity terms that complicate reuse more than MIT or GPL would. The company still sells a commercial product; the open board has had no tagged release in four years, and the commits since do not add up to one. Check whether that has changed before going further, and treat CSV, JSON and the REST API as the reason it is safe to try at all.

Titra tracks time against tasks for studios and agencies: assignments, budgets, burn rates and client projects, with a weekly time grid as the main interface. It is a small project with a narrow remit and does not pretend to a wider one.

The unit is a booked hour. Tasks exist as things to book time against rather than cards to move, the calendar view is a time grid by day and week rather than a calendar of work, and there is no board of any kind. Project permissions and client rate masking cover the access model, which is enough for an agency and not for a department.

It is a Meteor and React application over MongoDB, deployed as one container and small enough to run and forget. A first-party hosted service exists and sells hosting rather than features: nothing is reserved out of the AGPL build.

Everything points at the handover. CSV, XLSX and JSON exports and a REST API are there to get time into an accounting system, which is the design goal rather than an afterthought. The counterweight is scale: 497 GitHub stars, the fewest in this directory, and a maintainer group small enough to count - worth weighing against how much of a billing process you would put on it.

Worklenz is built for agencies and services firms: client projects, task boards, billable time, and the reports that turn one into an invoice. It is younger than most of this table and the commercial model around it is still settling.

Work is organised by client and project, with tasks carrying estimates, assignees and time entries, and timesheets rolling up per person and per project. Boards, lists, Gantt and a reporting section cover the views. The workflow extension depth of Redmine or OpenProject is not there, and for this audience it is not what is being bought.

It is Node.js and Angular over PostgreSQL, deployed with Docker Compose plus object storage for attachments, on a self-hosting path that is current and documented. There is no calendar interface of any kind, so deadlines and bookings stay inside the application.

The core is AGPL and the direction is commercial: a self-hosted business licence exists and its edition boundaries have moved, so the terms are worth reading in full before a deployment rather than after one. Data leaves as CSV and Excel exports of tasks, timesheets and reports, with a REST API beside them. The ecosystem is smaller than the leaders here: hundreds of forks, moving issues, continuing releases.