Taskwarrior: twenty years of command line task management

Twenty years of development and an ecosystem to match

Taskwarrior describes itself as a command line task list management utility with a multitude of features, developed as a portable open source project with an active and quite vast ecosystem of tools, hooks and extensions. The project says it has been in development since 2006 and that it is the result of work by mostly a small group of volunteers.

That length of history shows in the repository. There is an AUTHORS file, a ChangeLog, an INSTALL file, a RELEASING.md and a CONTRIBUTING.md at the root, alongside SECURITY.md and a .git-blame-ignore-revs file, which is a mechanism for hiding mechanical commits from blame after a reformat. A git-blame-ignore-revs file in a project of this age implies a large enough reformatting history to be worth handling.

The scale figures are substantial: 6082 stars, 420 forks, and 436 open issues. The issue count is high in absolute terms but normal for a project of this age and popularity, where the backlog includes both bugs and feature requests accumulated over years.

The last push was 2026-09-22 and the language is C++, MIT licensed, with topics covering gtd, task-manager, taskwarrior and to-do-list. The website is taskwarrior.org, and the documentation lives there rather than in the repository.

Community is spread across GitHub Discussions as the recommended place to ask questions, a Discord server, a subreddit, and a support page on the website. Code contributions go through pull requests.

Installing it through the distribution package manager

The install section is short because the answer is short. Taskwarrior is packaged on a wide range of Linux and Unix systems, Mac OS and Windows, and the README links package pages for Arch, Debian, Fedora, Homebrew and Ubuntu. It also points at Repology for the full list of versions across distributions.

For most people that is the entire installation story. The alternative given is building from source, with a link into doc/devel/contrib for the build documentation.

What makes the distribution story worth noting is the age of the software relative to the packages. A 2006 project still shipping in current Fedora and Ubuntu releases means the packaging has stayed healthy, and the maintainers have kept the CMake build compatible with a decade of toolchain changes.

The build system itself is CMake, with CMakeLists.txt at the root and a cmake/ directory. Two generated headers, cmake.h.in and commit.h.in, suggest version and build metadata are stamped at compile time rather than hardcoded. The tree also has a .clang-format file, which is what you would expect from a C++ project that accepts outside patches.

The build story is deliberately unremarkable. There is a Dockerfile-based matrix instead, described below, and that is what the contributors actually use.

Testing across distributions with docker compose

docker-compose.yml at the repository root defines one service per distribution, and the names make the intent obvious. Each service builds from a Dockerfile under test/docker and shares the host network:

version: '3'
services:
  test-fedora40:
    build:
        context: .
        dockerfile: test/docker/fedora40
    network_mode: "host"

The full set covers Fedora 40 and 41, Ubuntu 20.04 and 22.04, Debian testing, openSUSE and Arch. Each service sets network_mode to host, sets the container_runtime_t security label and enables a TTY, which are the three settings a terminal test suite needs.

That is seven distribution targets defined declaratively, which means a new target is a Dockerfile plus five lines of YAML. For a project whose hardest compatibility problem is building and running the same binary on a spread of Linux releases plus Windows, this is the right shape.

The performance directory at the root is a separate signal. Having a dedicated directory for performance work, alongside the two performance entries in the v3.5.0 release, suggests the maintainers treat speed as something to measure rather than assume. A task list that runs a query over thousands of tasks will feel slow in a way that matters when it is your primary interface.

A Rust crate in an otherwise C++ codebase

Cargo.toml at the repository root is four lines of substance:

[workspace]

members = [
    "src/taskchampion-cpp",
]

resolver = "2"

That is a single-member Rust workspace, and the member path tells you what it is. src/taskchampion-cpp is C++ bindings to TaskChampion, the Rust task database library, which is the successor to Taskwarrior's own storage engine.

This is the most consequential architectural fact in the repository. Taskwarrior started with its own C++ implementation of the task storage format, and it has been incrementally handing that job to TaskChampion, a separate project written in Rust. The C++ bindings crate in the tree is the seam between the two.

The consequences reach users. A schema migration from the old storage format is not a small operation, which is part of why the version numbers move in minor steps and why the 436 open issues include a long tail of upgrade reports. The consequences also reach developers: the storage layer is no longer something you read in this repository alone.

Everything else in the tree is C++ and CMake. src/ holds the main sources, test/ holds the test suite, doc/ holds documentation including the devel/ contributor guides the README links, misc/ and scripts/ hold supporting material, and performance/ holds the benchmarking work. There is also a .devcontainer/ directory, a .pre-commit-config.yaml, a Cargo.lock, and a .gitmodules file for submodule dependencies.

A .gitmodules in a project this age, alongside CMake, pre-commit hooks and a Docker matrix, is a repository that has absorbed several build systems over two decades and kept each one in place.

What recent releases actually changed

The release notes give a clear picture of where the project's effort goes. v3.5.0, published 2026-08-16, lists six changes. Two are performance: a dependency performance improvement and a burndown performance improvement, both from the same contributor. Two are features: Git sync and allowing hyphens in tags. One is an organisational change, moving the default theme into a dedicated file. One is a fix, for handling `scheduled` in recurring tasks.

The split is informative. A 2006 project still spending two of six release slots on query performance tells you the storage layer transition is not finished. The burndown feature is one of Taskwarrior's analytics views, and making it faster is a different kind of work from adding a filter operator.

Git sync is the notable feature. It means the task database can be synchronised through Git rather than through a bespoke sync service, which is a deliberate choice: it pushes the conflict resolution problem onto the user and removes a server dependency. Given the ecosystem link the README highlights, there are external tools built around exactly this.

The earlier releases are smaller. v3.4.1, from 2025-03-14, carries a single fix, for a reminder to check task news not actually being removed once read after a last-minute regression in 3.4.0. v3.4.2, from 2025-10-21, adds random sorting through a `report.<report-name>.sort = random` configuration, fixes tag handling in a tags column after `task edit`, and fixes `tags.none:`.

Those three lines in v3.4.2 are a good illustration of how configuration-driven Taskwarrior works. Reports are named, each report has its own filter and columns, and sort order is per-report configuration. Adding random sort is a configuration key rather than a new command, which is the framework's whole design idea.

Where the README points and what it leaves out

Almost everything operational lives off the repository. The README links online documentation for features, a tools page for the ecosystem of hooks and extensions, a download page, a support page and Repology. The documentation is the actual manual; the README is an index with download badges.

The download badges themselves are a small piece of social proof. The README shows an OS X downloads badge from the Homebrew analytics endpoint, a GitHub downloads badge for total releases, and a Linux downloads badge that is deliberately marked unknown and grey. That last detail is honest rather than lazy: there is no single Linux download counter that means anything because distribution packages are built by the distributions.

For contributors, the README points at a milestone progress badge for the current milestone, a good first issue label, the contributors graph, and doc/devel for further development documentation. The presence of a milestone number in the badge URL rather than a static label tells you the current development target is tracked on GitHub rather than in a roadmap file in the tree.

So the evaluation path is straightforward. Install from your distribution, read the online documentation to understand reports and filters, and use the tools page to see what other people have built on top. If you want to read the code instead, src/ plus the Cargo workspace tells you the storage layer now lives partly in another project, and doc/devel is where the build and contribution process is documented.

Editorial conclusion

Taskwarrior is at its best for people who already think in text filters and want their task list to be scriptable, greppable and version-controllable, and it is a poor fit if you want a graphical view or a shared team board. The project has been in development since 2006 and v3.5.0, published 2026-08-16, still contains performance work on dependency resolution and burndown alongside features like Git sync and hyphenated tags. Its packaging is the quiet advantage: Arch, Debian, Fedora, Homebrew and Ubuntu all ship it, so installation is a package manager operation rather than a build. If you want to understand the code, start with src/, then read ChangeLog for behaviour over time and doc/devel for the contributor documentation the README keeps pointing at.

Frequently asked questions

Official sources

1. GothenburgBitFactory/taskwarrior on GitHub
2. License: MIT
3. Project website
4. README
5. Releases