Self-Hosted Project Management Platforms: The Domain Explained#

Purpose: Bridge general software awareness to understanding the self-hosted project management landscape Audience: Newcomers to project management tooling and self-hosting Context: Why owning the platform that tracks all your work — instead of renting it — is a real and increasingly common choice

The Hardware Store Analogy#

If software libraries were tools in a hardware store, self-hosted project management platforms would live in the workshop-organization aisle — the one with pegboards, labeled bins, wall planners, and the big magnetic job-tracking board that hangs by the shop door. These aren’t the tools that do the work (the drills, the saws, the code). They’re the system that decides what gets worked on, by whom, in what order, and whether it’s done yet. Every other tool in the shop passes through this board.

There are two ways to get that board. You can rent a fully managed one — someone else owns it, maintains it, and hands you a login (this is SaaS: Jira, Asana, Monday, Linear, Trello). Or you can buy the board, bolt it to your own wall, and run it yourself (this is self-hosting: Plane, OpenProject, Redmine, Vikunja, and the rest of this survey). The rented board is effortless until the rent goes up, the landlord changes the rules, or you realize every note you ever pinned to it lives in someone else’s building. The board you own is yours forever — but you also own the wall, the upkeep, and the day the screws come loose.

This survey is a tour of the buy-it-yourself aisle. The goal here isn’t to talk you into self-hosting; it’s to explain what’s on the shelves, why the aisle exists at all, and how to read the labels.

What Problem Does This Domain Solve?#

At its simplest, a project management platform answers a question every team faces: “Who is doing what, and where does it stand?” Sticky notes, spreadsheets, and chat threads work for a while, then collapse under their own weight. Work gets lost, priorities get argued, and nobody can see the whole picture at once.

Project management platforms solve this by giving work a shared, structured home: a task has an owner, a status, a due date, a priority, and a place in a larger plan. Everyone looks at the same source of truth instead of ten private versions.

The dominant way to get this today is SaaS — you sign up, pay per user per month, and the vendor runs everything. That model is genuinely excellent and is the right choice for most teams. So why would anyone choose to run their own instead?

Why Choose Self-Hosting Over SaaS?#

Data sovereignty and compliance. When you self-host, your project data — which can include customer names, contract details, security findings, and internal strategy — sits on infrastructure you control, in a jurisdiction you choose. For organizations under GDPR, HIPAA, government data-residency rules, or defense contracts, “the data never leaves our building” isn’t a preference; it’s a legal requirement. A SaaS vendor storing your data in another country can be a non-starter.

Cost and subscription fatigue. SaaS PM tools charge per user per month, and that bill grows linearly (sometimes brutally) as you add people. A 200-person org paying $10–20 per user per month is spending $24,000–$48,000 a year — forever. Self-hosting flips this: you pay for a server (often $10–200/month regardless of headcount) plus some maintenance time. The math favors SaaS for tiny teams and flips toward self-hosting somewhere in the range of a few dozen users. Recent price increases across the SaaS PM market (Atlassian’s changes being the most cited) have pushed many teams to run the numbers.

Vendor lock-in. When your entire project history lives inside a proprietary SaaS platform, leaving is painful by design. Exports are incomplete, formats are proprietary, and integrations rebuild from scratch. With an open-source self-hosted tool, you own the database. You can back it up, inspect it, migrate it, and — because the source code is open — you’re never held hostage by a single vendor’s roadmap or survival.

Customization. SaaS gives you the features the vendor decided to build. Open-source self-hosted platforms let you change the code, add plugins, wire in bespoke workflows, and integrate with internal systems that no vendor would ever support. If your process is unusual, this can matter enormously.

Air-gapped and regulated environments. Some networks have no internet access at all — classified environments, industrial control systems, certain financial and medical settings. SaaS simply cannot run there. A self-hosted platform on the local network is the only option.

The honest counterweight: SaaS wins on convenience, reliability, and zero-maintenance. Self-hosting trades money and control for effort and responsibility. This survey exists because for a growing set of teams, that trade is worth making.

Core Concepts#

Once you’re inside the aisle, the tools all speak a shared vocabulary. Learn these six ideas and every platform becomes legible.

1. Work Items and Hierarchy#

The atom of every platform is the work item — variously called a task, issue, card, or work package. It has a title, a description, an assignee, a status, and usually a priority and due date.

Work items nest into a hierarchy so big goals break down into doable pieces:

• Epic — a large body of work (“Launch the mobile app”)
• Story / Task — a concrete deliverable within it (“Build the login screen”)
• Subtask — a checklist step inside a task (“Add password validation”)

Some lightweight tools (Vikunja, WeKan) keep this shallow; enterprise tools (OpenProject, Redmine) support deep multi-level hierarchies and cross-project relationships.

2. Views#

The same underlying tasks can be displayed in different shapes, and each view answers a different question:

• Kanban board — cards in columns (To Do / Doing / Done). Answers “what’s the flow?”
• Gantt chart — horizontal timeline bars with dependencies. Answers “when, and what blocks what?”
• Table / List — spreadsheet-style rows. Answers “show me everything, sortable.”
• Calendar — tasks on dates. Answers “what’s due this week?”

A key modern expectation is that one tool offers several views over the same data. Older or simpler tools may offer only one (WeKan is Kanban-only; Vikunja offers List, Table, Kanban, and Gantt).

3. Workflows and Automation#

A workflow is the set of states a work item moves through and the rules governing those moves (e.g., a task can’t go to “Done” until it’s been “In Review”). Automation layers on top: “when a task is assigned, notify the owner,” “when all subtasks are done, close the parent,” “every Monday, create the weekly-report task.” Automation is where a platform stops being a passive record and starts actively moving work along.

4. Roles and Permissions#

Not everyone should see or change everything. Role-based access control (RBAC) defines who can view, edit, assign, or administer. A contractor might see one project; a manager sees all of them; an admin configures the system. In regulated settings, granular permissions and audit logs (who changed what, when) are essential, and this is an area where mature platforms like Redmine and OpenProject are notably strong.

5. Integrations#

A PM platform is rarely an island. The important connections are:

• Git (GitHub, GitLab) — link commits and pull requests to the tasks they resolve
• Chat (Slack, Mattermost, Teams) — push notifications where people already talk
• CI/CD — tie deployments and test runs back to work items
• File storage (Nextcloud, S3, OneDrive) — attach and manage documents

For self-hosted tools, integration usually happens through a REST API and webhooks, so you can wire the platform into whatever else you run.

6. Where AI Is Entering#

The newest frontier. AI features are beginning to appear: drafting task descriptions, breaking an epic into subtasks, summarizing project status, and suggesting priorities. Among the platforms here, Plane has leaned into AI-assisted planning, and Leantime ships built-in AI features. Most others expose an API that third-party AI tools can drive rather than embedding AI directly. This space is early and moving fast — treat any specific AI claim as something to re-verify.

The Landscape: A Map, Not a Ranking#

The self-hosted PM aisle isn’t a single shelf sorted best-to-worst. It’s a map with several neighborhoods, each solving the same core problem with a different philosophy. Where you belong depends on your team, not on which tool has the most stars.

Modern-UI Newcomers#

Tools built from 2020 onward that compete directly with commercial polish (Linear, Notion, Monday). Contemporary interfaces, multiple views, Docker-first deployment, and increasingly AI features.

• Plane — the current star of the category (by a wide margin on GitHub), positioned as a modern Jira/Linear alternative with issues, cycles, epics, and AI-assisted planning.
• Huly — an ambitious all-in-one that bundles project management with messaging, documents, and more, aiming to replace a whole stack of tools at once.

These are exciting and modern, with the trade-off that “newer” also means “less battle- tested” than the veterans.

Mature Workhorses#

The veterans — a decade or two of production use, deep feature sets, enterprise-grade permissions and reporting. Less fashionable, more proven.

• OpenProject — comprehensive, supports classic/agile/hybrid methodologies, excellent Gantt charts, a generous free Community edition, and a paid Enterprise tier.
• Redmine — the elder statesman (born 2006), famous for a vast plugin ecosystem and rock-solid multi-project tracking. Long knocked for a dated interface, though a 2026 release brought a navigation redesign.

If you need something that has survived every hype cycle since the 2000s, it lives here.

Lightweight and Self-Host-Friendly#

Simple, low-resource tools that a small team — or one person — can stand up quickly and run on modest hardware. They deliberately do less, and do it cleanly.

• Vikunja — a lightweight task manager (Go + Vue) that runs happily on a Raspberry Pi, offers multiple views, and reached its 1.0 milestone in 2026 after years of development.
• WeKan — a straightforward open-source Trello replacement focused purely on Kanban, with a permissive MIT license and the ability to run fully offline on a local network.
• Leantime — aimed at small teams and non-technical users, notable for built-in AI and a focus on making project management approachable for people who find Jira overwhelming.

The trade-off is a ceiling: they’re not built for deep enterprise reporting or complex multi-team hierarchies.

Agile-Focused#

Built around Scrum and Kanban ceremonies specifically — sprints, backlogs, burndown charts, swim lanes.

• Taiga — a design-forward platform with excellent Scrum and Kanban support and the flexibility to switch methodologies. A strong fit for software teams who live in agile.

A Word on Dormant Options#

Open source is not immortal, and a newcomer should know which shelves are dusty. The most important example: standalone Focalboard (Mattermost’s Notion/Trello-style board tool) was set adrift in August 2024 — the standalone project is unmaintained and seeking maintainers. Its capabilities live on only as an in-suite plugin (Mattermost Boards) for teams already running Mattermost. A newcomer who finds an old blog post praising Focalboard should not start a fresh standalone deployment there today. The general lesson: before adopting any self-hosted tool, check that the project is currently active — recent releases, responsive maintainers, a living community. A gorgeous tool that’s stopped shipping security fixes is a liability, not a bargain.

The Trade-Offs of Self-Hosting#

Choosing to own the board means owning the wall it hangs on. Be clear-eyed about what that entails — this is the part SaaS quietly handles for you:

• Backups are your job. If you don’t have a tested backup-and-restore routine, you are one disk failure away from losing all your project history. SaaS vendors do this invisibly; you now do it deliberately.
• Upgrades are your job. New versions bring features and — crucially — security patches. Somebody has to schedule, test, and apply upgrades, and occasionally untangle a migration that goes sideways.
• Security is your job. Exposing a web application to the internet means you own authentication, TLS certificates, patching, and hardening. A misconfigured self-hosted instance is a genuine risk.
• Availability is your job. If you need the tool to stay up 24/7, high availability (redundant servers, failover, monitoring) is on you. A single cheap VPS is fine for a small team; a mission-critical deployment is a real infrastructure project.

The upside of all this responsibility is the flip side of every downside above: total control, flat costs, no vendor lock-in, and data that never leaves your walls. The right answer depends entirely on whether your team has (or wants to build) the operational muscle to carry it. Docker-first deployment has lowered the entry barrier dramatically — many of these tools install in under 30 minutes — but installing and operating for years are different commitments.

How to Read This Aisle#

A newcomer walking this aisle should ask, in order:

1. Should I even self-host? For a small team without ops capacity, managed SaaS is often the wiser choice. Self-hosting earns its keep on sovereignty, scale-driven cost, customization, or air-gapped requirements.
2. What shape is my work? Simple task lists point to the lightweight neighborhood; heavy agile points to the agile-focused tools; deep enterprise reporting points to the mature workhorses; a desire for modern polish points to the newcomers.
3. What can I operate? Be honest about the ops burden you can carry. A Raspberry-Pi- friendly tool and an enterprise Rails application demand very different skills.
4. Is it alive? Confirm the project ships regular releases and has an active community before you commit years of your team’s data to it.

This explainer stops at the map. The rest of the survey walks each neighborhood in detail — architecture, real feature comparisons, use-case personas, and long-term viability — so you can move from “I understand the aisle” to “I know which shelf is mine.”

Key insight: Self-hosted project management is not “cheaper Jira.” It’s a deliberate trade — you accept the responsibility of backups, upgrades, security, and uptime in exchange for data sovereignty, flat costs, freedom from lock-in, and the ability to run anywhere, even offline. The tools range from Raspberry-Pi-light to enterprise-heavy, and the right one is a function of your team’s needs and your appetite for ownership — never a single “winner.”

Date compiled: July 2, 2026

1.131: Self-Hosted Project Management Platforms - S1 Rapid Discovery#

Research Date: November 7, 2025 Category: 1.130-139 Business Application Platforms (Self-Hosted) Methodology: MPSE S1 (Rapid Discovery)

Executive Summary#

The self-hosted project management landscape in 2025 offers mature alternatives to SaaS platforms like JIRA, Asana, Monday, and Trello. Key drivers for self-hosting include data sovereignty, compliance requirements, vendor lock-in avoidance, and cost control at scale. The ecosystem divides into three tiers: lightweight task boards (WeKan, Vikunja, Focalboard), full-featured agile platforms (Plane, Taiga, Worklenz), and enterprise-grade systems (OpenProject, Redmine).

Market positioning: Self-hosted PM tools are experiencing renewed interest in 2024-2025 due to increasing data privacy regulations, remote work normalization, and enterprises seeking alternatives to escalating SaaS subscription costs.

Platform Landscape Overview#

Tier 1: Modern Full-Featured Platforms (2020+)#

1. Plane#

Status: Active Development (v1.3.1, May 2026; ~53k GitHub stars — #1 open-source PM) | License: Open Source (AGPL-3.0) | First Release: 2022

Key Characteristics:

• Positioning: Modern alternative to JIRA, Linear, Monday, Asana
• Tech Stack: React + Django
• Deployment: Docker/K8s, 2GB RAM minimum, 4GB recommended
• Core Features:
  • Issues, epics, cycles tracking
  • Work items, sprint management, roadmaps
  • Built-in analytics and AI-assisted planning
  • Multiple PM frameworks (Agile, Waterfall, hybrid)
  • Modern interface with excellent UX

Target Audience: Teams wanting modern PM without vendor lock-in

Strengths:

• Contemporary UI/UX rivaling commercial products
• AI integration for idea brainstorming and work planning
• Fast Docker deployment
• Active GitHub community (~53k stars, #1 open-source PM by stars)

Weaknesses:

• Younger platform (less proven than alternatives)
• Smaller plugin ecosystem than Redmine/OpenProject
• Limited enterprise features compared to OpenProject

Best For: Startups and scale-ups migrating from Linear/JIRA Cloud

2. Taiga#

Status: Mature | License: Open Source (AGPL-3.0) | First Release: 2014

Key Characteristics:

• Positioning: Agile-focused (Scrum, Kanban, Scrumban)
• Tech Stack: Python (Django) + Angular
• Deployment: Docker-based, self-hosted or cloud ($10/month)
• Core Features:
  • Native Scrum & Kanban boards with swim lanes
  • Epic & sub-task hierarchy
  • Sprint planning with burndown charts
  • WIP limits, custom workflows
  • Wiki, issue tracking
  • Pre-configured integrations: Slack, GitHub, GitLab, Mattermost

Target Audience: Agile software development teams

Strengths:

• Beautiful, designer-focused UI
• Excellent Scrum/Kanban implementation
• Flexible methodology switching (can use both simultaneously)
• Extensive API and webhook support
• Free self-hosted, affordable cloud option

Weaknesses:

• Less suitable for waterfall/traditional PM
• Smaller feature set than OpenProject for enterprise needs
• Python/Angular stack may require specific expertise

Best For: Agile development teams prioritizing design and methodology flexibility

3. Worklenz#

Status: Active Development | License: Open Source (GPL-3.0) | First Release: 2023

Key Characteristics:

• Positioning: All-in-one PM tool for efficient teams
• Tech Stack: React + TypeScript + Express.js + PostgreSQL + MinIO
• Deployment: Self-hosted with S3-compatible storage
• Core Features:
  • Project & task management
  • Time tracking & reporting
  • Team collaboration with file sharing
  • Task automation & recurring tasks
  • Due dates, priorities, comments

Target Audience: SMBs and teams needing comprehensive PM with modern tech

Strengths:

• Modern tech stack (React, TypeScript, PostgreSQL)
• Open-source community development
• Uses MinIO for S3-compatible object storage
• Good balance of features vs complexity

Weaknesses:

• Free edition limited: 5 members, 3 projects, 1GB storage
• Very young platform (2023), less battle-tested
• Smaller community than established alternatives

Best For: Small teams wanting modern tech stack with growth path to paid hosting

Tier 2: Enterprise-Grade Platforms#

4. OpenProject#

Status: Mature (v17.5, June 2026) | License: GPL-3.0 (Community), Commercial (Enterprise) | First Release: 2011

Key Characteristics:

• Positioning: Enterprise PM supporting classic, agile, hybrid methodologies
• Editions:
  • Community (Free, self-hosted, unlimited users/projects)
  • Enterprise On-Premises (Paid: $405/year for 5 users)
  • Enterprise Cloud (Paid: $7.25-$19.50/user/month)
• Core Features:
  • Task management, Gantt charts, boards
  • Team collaboration, time & cost reporting
  • Integration with GitHub, GitLab, Nextcloud, OneDrive/SharePoint
  • Enterprise features: advanced admin, SSO, custom branding

Target Audience: Enterprises and organizations needing full PM capabilities

Strengths:

• Most comprehensive free Community edition
• Supports multiple methodologies (waterfall, agile, hybrid)
• Excellent Gantt chart implementation
• Strong integration ecosystem
• Compliant with enterprise security standards
• 14-day free trial for Enterprise features

Weaknesses:

• Self-hosted Enterprise ($405/5 users) more expensive than cloud ($275/5 users)
• UI less modern than Plane/Taiga
• Steeper learning curve due to feature richness

Best For: Enterprises needing comprehensive PM with mixed methodologies

5. Redmine#

Status: Mature (v7.0, June 2026 — Rails 8, header/nav redesign, event webhooks) | License: GPL-2.0 | First Release: 2006

Key Characteristics:

• Positioning: Traditional, Ruby on Rails-based PM framework
• Tech Stack: Ruby on Rails
• Deployment: Self-hosted (requires Rails/DevOps expertise)
• Core Features:
  • Multi-project tracking with subprojects
  • Flexible role-based access control
  • Issue tracking, Gantt charts, calendar
  • Per-project wikis & forums, time tracking
  • VCS integration (Git, SVN, Mercurial)
  • Custom fields for issues/projects/users
  • REST API, 49 language translations
  • Multiple database support, LDAP authentication

Plugin Ecosystem:

• 60+ new plugins in 2024
• Major vendors: RedmineUP, Redmineflux, Easy Redmine
• Plugins for Agile boards, helpdesk, CRM, resource management

Target Audience: Enterprises with Rails expertise and existing Redmine installations

Strengths:

• Extremely mature (20 years)
• Vast plugin ecosystem (1000+ plugins)
• Highly customizable via plugins
• Proven at enterprise scale
• Strong multi-project hierarchy
• Excellent VCS integration

Weaknesses:

• Dated UI/UX (2006-era design)
• Requires Ruby on Rails + DevOps expertise
• Complex installation and maintenance
• Plugin quality varies significantly
• Performance issues at very large scale without tuning

Best For: Organizations with Rails expertise or legacy Redmine deployments

Tier 3: Lightweight Kanban & Task Boards#

6. WeKan#

Status: Active (v9.35+, 2026; Meteor 3.5 / Node 24) | License: MIT | First Release: 2015

Key Characteristics:

• Positioning: Open-source Trello alternative
• Tech Stack: Meteor.js
• Deployment: Self-hosted, local network capable
• Core Features:
  • Kanban boards with drag & drop
  • Cards, lists, swimlanes, labels
  • Attachments, checklists, due dates
  • WIP limits, color coding, templates
  • GDPR-compliant when self-hosted
  • 60 language translations
  • Trello import capability

Target Audience: Teams needing simple Kanban without SaaS dependency

Strengths:

• True Trello alternative with import capability
• MIT license (permissive)
• Lightweight, can run on local network disconnected from Internet
• Complete data sovereignty
• Swimlanes feature (Trello lacks this)
• Multi-language support

Weaknesses:

• Limited to Kanban methodology
• No native mobile apps (browser only)
• Smaller feature set than full PM platforms
• Meteor.js may be unfamiliar to some teams

Best For: Teams wanting self-hosted Trello replacement, government agencies, high-security environments

7. Vikunja#

Status: Active (v2.x; reached 1.0 in Jan 2026 after 8 yrs; repo now go-vikunja/vikunja) | License: AGPL-3.0 | First Release: 2018

Key Characteristics:

• Positioning: Lightweight task manager, alternative to Todoist/ClickUp
• Tech Stack: Go + Vue.js
• Deployment: Docker-Compose, Raspberry Pi capable
• Core Features:
  • Projects with hierarchical subprojects
  • Multiple views: List, Gantt, Table, Kanban
  • Task assignment & team collaboration
  • Due dates, priorities, labels
  • Project sharing with users/teams
  • Lightweight resource footprint

Target Audience: Individuals and small teams needing task management

Strengths:

• Extremely lightweight (runs on Raspberry Pi)
• Modern tech stack (Go + Vue.js)
• Multiple view options in one tool
• Simple Docker deployment
• Good for personal productivity scaling to teams

Weaknesses:

• Less suitable for complex enterprise PM
• Smaller community than major platforms
• Limited advanced PM features (no resource management, advanced reporting)

Best For: Individuals, freelancers, small teams prioritizing simplicity

8. Focalboard#

Status: Standalone UNMAINTAINED (seeking maintainers since Aug 2024; Mattermost Boards continues only as an in-suite plugin) | License: MIT (Community Edition) | First Release: 2021

Key Characteristics:

• Positioning: Mattermost’s alternative to Trello, Notion, Asana
• Tech Stack: React + Go
• Deployment: Self-hosted, integrates with Mattermost
• Core Features:
  • Kanban, table, gallery, calendar views
  • Cards with descriptions, attachments, custom properties
  • Mattermost integration for communication
  • Project and task organization

Target Audience: Teams using Mattermost for collaboration

Strengths:

• Tight Mattermost integration (unified collaboration)
• Modern tech stack (React + Go)
• Multiple view types like Notion
• MIT license for Community Edition
• Backed by Mattermost (enterprise chat platform)

Weaknesses:

• Relatively new (2021)
• Best value when paired with Mattermost (added complexity)
• Smaller standalone community vs dedicated PM tools
• Less feature-rich than dedicated PM platforms

Best For: Organizations already using Mattermost; teams wanting Notion-like flexibility

Platform Comparison Matrix (Quick Reference)#

Key Decision Dimensions#

1. Methodology Support#

• Agile-Native: Plane, Taiga, Worklenz
• Waterfall/Traditional: OpenProject, Redmine
• Hybrid/Flexible: OpenProject, Plane
• Kanban-Only: WeKan, Focalboard
• Task-Focused: Vikunja

2. Technical Stack Complexity#

• Modern & Easy: Plane (Docker), Taiga (Docker), WeKan (Docker), Vikunja (Docker)
• Moderate: Worklenz (PostgreSQL + MinIO), Focalboard (Go + React)
• Complex: Redmine (Rails + DevOps), OpenProject (Ruby)

3. Deployment Effort#

• Quick (< 30 min): Plane, Taiga, WeKan, Vikunja, Focalboard (all Docker)
• Moderate (1-2 hours): Worklenz, OpenProject
• Complex (4+ hours): Redmine (Rails environment setup)

4. Resource Requirements#

• Lightweight: Vikunja (Raspberry Pi capable), WeKan
• Medium: Plane (2-4GB), Taiga, Focalboard, Worklenz
• Heavy: OpenProject, Redmine (especially with plugins)

5. Enterprise Readiness#

• Enterprise-Grade: OpenProject (commercial support), Redmine (mature)
• Growing: Plane, Taiga
• SMB-Focused: Worklenz, WeKan, Vikunja, Focalboard

6. Licensing Philosophy#

• Copyleft (AGPL/GPL): Plane, Taiga, Vikunja, OpenProject, Redmine, Worklenz
• Permissive (MIT): WeKan, Focalboard
• Dual (Open + Commercial): OpenProject (Community vs Enterprise)

Market Trends (2024-2025)#

1. Renewed Self-Hosting Interest#

Driven by:

• Data privacy regulations (GDPR, CCPA, data sovereignty)
• Remote/hybrid work normalization (stable infrastructure needs)
• SaaS cost escalation (subscription fatigue)
• Vendor lock-in concerns (especially post-Atlassian pricing changes)

2. Modern UX Expectations#

Platforms launched post-2020 (Plane, Worklenz) compete on UX:

• Contemporary interfaces matching Linear, Notion
• AI integration (Plane leads here)
• Multiple view types (Kanban, Gantt, Table, Calendar)

3. Docker-First Deployment#

All modern platforms prioritize Docker/K8s deployment:

• Simplifies self-hosting complexity
• Enables quick trials (< 30 min to production)
• Supports hybrid cloud strategies

4. Integration Ecosystem Maturity#

Pre-configured integrations now table stakes:

• Git platforms (GitHub, GitLab)
• Chat (Slack, Mattermost, Teams)
• File storage (Nextcloud, S3, OneDrive)
• CI/CD pipelines

5. Methodology Flexibility#

Modern platforms support multiple methodologies:

• Teams often mix Scrum, Kanban, Waterfall across projects
• Rigid methodology enforcement (old Taiga) losing favor
• Hybrid approaches common in 2025

Selection Framework Snapshot#

Choose Plane if:#

• You want modern JIRA/Linear alternative
• AI-assisted planning appeals
• Team values contemporary UX
• Docker deployment preferred
• Okay with newer platform (2022)

Choose Taiga if:#

• Pure agile team (Scrum/Kanban)
• Design/UX important to team adoption
• Need established platform (2014)
• Want affordable cloud option ($10/month)
• Integrations with Slack/GitHub critical

Choose OpenProject if:#

• Enterprise with mixed methodologies
• Need comprehensive free Community edition
• Gantt charts critical requirement
• Compliance/security standards important
• Budget exists for Enterprise support ($405/year for 5)

Choose Redmine if:#

• Already have Redmine deployment
• Ruby on Rails expertise in-house
• Need vast plugin ecosystem (1000+)
• Multi-project hierarchy critical
• Legacy integrations important

Choose WeKan if:#

• Need Trello replacement
• Simplicity over features
• GDPR compliance critical
• Local network (air-gapped) deployment
• Swimlanes important

Choose Vikunja if:#

• Personal productivity or very small team
• Lightweight infrastructure (Raspberry Pi)
• Task management > project management
• Simple Docker deployment
• Multiple view types in minimal package

Choose Worklenz if:#

• Want modern tech stack (React, TypeScript, PostgreSQL)
• Small team (< 5 people)
• Growth path to paid hosting acceptable
• Open-source community development important

Choose Focalboard if:#

• Already using Mattermost
• Want Notion-like flexibility
• Communication + PM in one platform
• MIT license important
• Kanban primary need

Research Gaps for S2 (Comprehensive Discovery)#

1. Performance Benchmarks

   • Load testing (100 users, 1000 users, 10k users)
   • Database performance at scale
   • Resource consumption under load

2. Feature Matrix

   • Detailed feature comparison (50+ dimensions)
   • Gantt chart capabilities
   • Resource management
   • Time tracking accuracy
   • Reporting depth
   • Custom fields & workflows
   • API completeness
   • Mobile app capabilities

3. Total Cost of Ownership

   • Infrastructure costs (cloud vs on-prem)
   • Maintenance effort (hours/month)
   • Migration costs from existing tools
   • Training requirements
   • Support costs (community vs commercial)

4. Security & Compliance

   • Authentication methods (LDAP, SAML, OAuth)
   • Role-based access control depth
   • Audit logging capabilities
   • Compliance certifications (SOC 2, ISO 27001)
   • Data encryption (at rest, in transit)

5. Integration Architecture

   • API quality & completeness
   • Webhook capabilities
   • SSO implementations
   • Third-party plugin ecosystems
   • Import/export formats

6. Operational Complexity

   • Backup/restore procedures
   • Upgrade paths & frequency
   • Database migration tools
   • High availability setups
   • Disaster recovery

Immediate Next Steps#

For S2 Comprehensive Discovery:#

1. Install all 8 platforms in isolated environments
2. Create standardized test projects with:
   • 50 tasks across 5 projects
   • 10 users with different roles
   • File attachments, time tracking
   • Custom fields and workflows
3. Benchmark performance, API quality, feature completeness
4. Document migration paths between platforms
5. Assess plugin/extension ecosystems

For S3 Need-Driven Discovery:#

1. Map to generic use case patterns:
   • Software development teams
   • Marketing agencies
   • Construction/engineering projects
   • Professional services (consulting, legal)
   • Government/compliance-heavy environments
   • Non-profit organizations
2. Create architecture decision trees
3. Build TCO models for different scales

For S4 Strategic Discovery:#

1. Analyze vendor/project viability (5-year horizon)
2. Community health metrics (GitHub activity, contributors)
3. Commercial backing assessment
4. Technology evolution trajectories
5. Lock-in mitigation strategies
6. Build vs buy decision frameworks

References#

1. Plane Documentation: https://plane.so/
2. Taiga Documentation: https://taiga.io/
3. OpenProject Documentation: https://www.openproject.org/
4. Redmine Project: https://www.redmine.org/
5. Worklenz GitHub: https://github.com/Worklenz/worklenz
6. WeKan Project: https://wekan.github.io/
7. Vikunja Documentation: https://vikunja.io/
8. Focalboard GitHub: https://github.com/mattermost-community/focalboard

S1 Status: ✅ Complete S2 Status: 🔲 Pending S3 Status: 🔲 Pending S4 Status: 🔲 Pending Last Updated: July 2, 2026 (freshness pass — versions/status refreshed; S2, S4, and DOMAIN_EXPLAINER still missing)

1.131: Self-Hosted Project Management Platforms - Comprehensive Discovery (S2)#

Research Date: July 2, 2026 Category: 1.130-139 Business Application Platforms (Self-Hosted) Methodology: MPSE S2 (Comprehensive Analysis)

Research Objective#

Deep technical analysis of self-hosted project management (PM) platforms across a 50+-dimension feature matrix, per-platform architecture, scale behavior (small team → 1,000 → 10,000 users), total cost of ownership (infra + maintenance + migration), security & compliance (auth/RBAC/audit), integration architecture (API/webhooks/SSO), and operational complexity (backup/upgrade/HA).

This is a category-first comparison: each platform is judged on its merits for any reader. No single deployment scenario is privileged here (scenario-specific guidance lives in S3 patterns). Where public load-test numbers do not exist, scale behavior is framed as architecture-implied rather than benchmarked — self-hosted PM vendors rarely publish standardized benchmarks, so honesty about that gap matters more than invented figures.

Tool set (8 primary): Plane, Taiga, Worklenz, OpenProject, Redmine, WeKan, Vikunja, Focalboard. Emerging entrants (lighter treatment): Huly, Leantime.

License verification (2026-07-02) — corrections from S1:

• Worklenz: verified AGPL-3.0 (S1 recorded GPL-3.0). Corrected.
• Taiga: the actively self-hosted classic stack (taiga-back / taiga-front) is AGPL-3.0-or-later; the next-generation rewrite (kaleidos-ventures/taiga, “Taiga Next”, Penpot-linked) is MPL-2.0. Self-hosters today deploy the AGPL-3.0 classic stack; the MPL-2.0 monorepo is where future development is heading.
• Focalboard: standalone UNMAINTAINED since Aug 2024 (seeking maintainers). Treated here as legacy/dormant; lives on only as the Mattermost Boards in-suite plugin.
• Huly: EPL-2.0. Leantime: AGPL-3.0 core.

1. Comprehensive Feature Matrix#

Legend: ✅ built-in / native · ⚠️ partial or limited · ❌ absent · 🔌 via plugin/add-on · 💰 paid/enterprise edition only.

1.1 Views & Work Organization#

1.2 Work Item Model#

1.3 Execution Features#

1.4 Integration & Extensibility#

1.5 Security, Access & Reach#

Reading the matrix. Three clusters emerge on capability breadth:

• Full-suite / enterprise — OpenProject and Redmine cover the widest feature surface (Gantt + cost + resource + audit), but much of Redmine’s breadth is 🔌 plugin-gated and much of OpenProject’s compliance surface is 💰 enterprise-gated.
• Modern agile — Plane, Taiga, and Worklenz emphasize sprint/cycle flow and modern UX. Plane leads on native AI and mobile; Taiga is the purest Scrum/Kanban tool but notably lacks Gantt and calendar; Worklenz leads this tier on time tracking and resourcing.
• Lightweight — WeKan (Kanban-first), Vikunja (multi-view task manager), and Focalboard (Notion-style boards, now dormant). Vikunja punches above its weight with Gantt + calendar + CalDAV in a tiny footprint.

2. Per-Platform Architecture#

2.1 Plane#

• Stack: React/Next.js frontend, Django (Python) API, plus worker services.
• Data store: PostgreSQL (primary), Redis (cache/queues), RabbitMQ (async), MinIO or S3-compatible object storage for attachments.
• Deployment: Docker Compose (community) and Kubernetes (Helm). ~4–6 containers.
• Version: v1.3.1 (May 2026), ~53k GitHub stars (#1 OSS PM by stars).
• HA story: Stateless web/API tiers scale horizontally behind a load balancer; durability rests on external Postgres HA (replication) and object storage. Redis/RabbitMQ become the pieces to cluster for true HA. Multi-service composition means HA is achievable but not turnkey.

2.2 Taiga#

• Stack (classic, self-hosted): Django (Python) backend (taiga-back), Angular/legacy frontend (taiga-front), plus a Node events service (taiga-events).
• Data store: PostgreSQL, RabbitMQ + Redis for the real-time events channel.
• Deployment: Docker Compose (taiga-docker). ~6 containers (back, front, events, async, gateway, DB).
• License: AGPL-3.0-or-later (classic); MPL-2.0 for the “Taiga Next” rewrite.
• HA story: Django app tier is horizontally scalable; the events/RabbitMQ layer adds a stateful component that complicates HA. No first-party HA reference architecture.

2.3 Worklenz#

• Stack: React + TypeScript frontend, Node.js/Express backend.
• Data store: PostgreSQL, with MinIO / S3-compatible object storage for files.
• Deployment: Docker Compose; self-host requires wiring S3-compatible storage.
• License: AGPL-3.0 (verified — corrects S1’s GPL-3.0).
• HA story: Conventional stateless-Node + Postgres pattern; horizontally scalable in principle, but the project is young (2023) with little published guidance on scale-out. Free self-host tier historically caps members/projects/storage.

2.4 OpenProject#

• Stack: Ruby on Rails backend, Angular frontend.
• Data store: PostgreSQL, memcached for caching.
• Deployment: Docker (all-in-one image or Compose), DEB/RPM packages, Kubernetes/Helm.
• Version: v17.5 (June 2026); Community = GPL-3.0, Enterprise = commercial add-on on top of the same core.
• HA story: The most explicitly enterprise-oriented of the set. Supports external Postgres, separate web/worker (background job) processes, and horizontal web scaling; documented for load-balanced multi-node deployment. The strongest turnkey HA story here.

2.5 Redmine#

• Stack: Ruby on Rails (Rails 8 as of v7.0).
• Data store: MySQL/MariaDB, PostgreSQL, SQLite, or SQL Server (widest DB portability in the set).
• Deployment: Native Rails (Passenger/Puma + nginx/Apache) or community Docker images.
• Version: v7.0 (June 30, 2026) — Rails 8, header/nav redesign, event webhooks now in core (previously plugin-only); 20 years old.
• HA story: Stateless Rails app scales horizontally behind a load balancer with a shared DB and shared attachment volume/object store; mature and battle-tested at scale, but HA is hand-assembled (no vendor reference stack) and DevOps-heavy.

2.6 WeKan#

• Stack: Meteor.js (Node 24 / Meteor 3.5 as of v9.35).
• Data store: MongoDB.
• Deployment: Docker, Snap, Kubernetes; can run fully air-gapped on a local network.
• License: MIT (most permissive in the set).
• HA story: Meteor’s real-time model historically pins scale to MongoDB oplog tailing; multiple WeKan instances can share one MongoDB replica set, but websocket/real-time fan-out is the practical ceiling. HA = MongoDB replica set + multiple app instances.

2.7 Vikunja#

• Stack: Go backend (single static binary) + Vue.js frontend (served as static assets).
• Data store: SQLite (default), MySQL/MariaDB, or PostgreSQL; local disk or S3 for files.
• Deployment: Single binary or one Docker container — the simplest deployment in the set; runs on a Raspberry Pi.
• Version: reached 1.0 (Jan 2026) after ~8 years; now 2.x (repo go-vikunja/vikunja). No native AI — only via third-party MCP integrations.
• HA story: The Go binary is stateless when backed by Postgres/MySQL + S3, so multiple replicas behind a load balancer is straightforward; the single-binary design makes it the easiest to scale horizontally in principle, though it targets small/medium teams.

2.8 Focalboard (legacy / dormant)#

• Stack: Go backend + React frontend.
• Data store: SQLite (personal), or PostgreSQL/MySQL (server).
• Deployment: Single binary/Docker (standalone) — standalone unmaintained since Aug 2024. Active form is the Mattermost Boards in-suite plugin.
• License: MIT (Community Edition).
• HA story: As a Mattermost plugin it inherits Mattermost’s clustering/HA; the standalone server has no active HA path and should be considered end-of-life for new greenfield self-hosting.

3. Performance & Scale (Architecture-Implied)#

No vendor in this set publishes standardized, comparable load-test results, so the following is reasoned from architecture, data-store choice, and deployment model — not measured benchmarks. Treat tiers as directional.

Small team (≤ ~50 users, 1 node) — All eight run comfortably on a single 1–4 GB VPS. Vikunja and WeKan are the lightest (512 MB–2 GB); Plane/Taiga/Worklenz sit at 2–4 GB; OpenProject and Redmine-with-plugins want 4–8 GB. Focalboard standalone is light but dormant.

Mid-scale (~1,000 users) — The determining factor is whether the app tier is stateless and the datastore can be scaled/replicated:

• Comfortable: OpenProject and Redmine (mature Rails-on-relational-DB, horizontally scalable app tier, decades of large-deployment precedent). Plane and Vikunja scale cleanly given external Postgres + object storage.
• Requires care: Taiga (RabbitMQ/events layer) and WeKan (MongoDB oplog / real-time fan-out) introduce a stateful real-time component that becomes the bottleneck first.
• Unproven: Worklenz at four figures — young project, little public evidence.

Large-scale (~10,000 users) — This is where the field thins:

• Credible: OpenProject (explicit multi-node/HA documentation, commercial support) and Redmine (proven at large enterprises, though tuning- and DevOps-intensive). These are the two with real-world precedent at this size.
• Plausible but self-engineered: Plane and Vikunja can be scaled out (stateless app + Postgres HA + object storage + Redis), but the operator owns all the tuning.
• Poor fit: WeKan (real-time model), Taiga (events layer), Worklenz (immaturity), and Focalboard (dormant) are not the tools to reach for at 10k seats.

General principle: for self-hosted PM, scale is gated less by the framework than by (1) whether the app tier is stateless, (2) whether the primary datastore supports HA replication, and (3) whether real-time/websocket fan-out is a core dependency. Tools whose “live board” experience depends on a stateful broker (Taiga, WeKan) hit ceilings earlier than tools that treat the DB as the single scaling axis (Redmine, OpenProject, Plane, Vikunja).

4. Total Cost of Ownership (TCO)#

TCO for self-hosted PM has three components: infrastructure footprint, maintenance/upgrade burden, and migration/lock-in cost. License cost is $0 for community editions; the real spend is compute + human time.

4.1 Infrastructure Footprint#

Infra cost scales roughly with component count and RAM: Vikunja/WeKan at a $5–15/mo VPS; Plane/Taiga/Worklenz at $20–40/mo; OpenProject/Redmine at $40–80/mo; Huly’s multi-service stack is the outlier (a small cluster or a large single node).

4.2 Maintenance & Upgrade Burden#

• Lowest: Vikunja (single binary — replace and restart), WeKan (Docker image bump), Focalboard-standalone (but no upgrades are coming — a liability, not a saving).
• Moderate: Plane, Taiga, Worklenz — multi-container Compose upgrades; watch for breaking DB migrations across minor versions (younger projects change schemas faster).
• Highest: Redmine (native Rails upgrades, plugin-compatibility matrix across Rails 8 in v7.0, gem dependency management) and OpenProject (larger surface, though the packaged installer and all-in-one image soften this considerably).

Upgrade cadence also matters: Plane ships extremely fast (89 releases in 2025), which means more frequent optional upgrades; Redmine/OpenProject move on slower, more predictable release trains, which is easier to schedule around.

4.3 Migration & Lock-in#

• Import maturity (getting in): WeKan (native Trello import) and Plane/OpenProject (Jira/CSV importers) are the smoothest on-ramps. Vikunja imports CSV/Todoist.
• Export / getting out: All are self-hosted with full DB access, so data is never hostage — the lock-in is schema effort, not data ownership. Redmine’s 20-year-stable schema and vast tooling make it the safest long-term data home; younger platforms (Plane, Worklenz) carry more schema-churn risk.
• License-driven lock-in: AGPL (Plane, Taiga classic, Worklenz, Vikunja, Leantime) and GPL (OpenProject Community, Redmine) obligate you to publish modifications if you offer the modified software over a network — relevant only if you fork and redistribute, not for internal self-hosting. MIT (WeKan, Focalboard) and EPL-2.0 (Huly) are more permissive for those who intend to embed or re-distribute.

5. Security & Compliance#

5.1 Authentication#

The compliance-relevant gap: SAML SSO is often the paywall line. Community editions of Plane and OpenProject support OIDC/OAuth but reserve SAML for paid tiers; WeKan is the notable exception offering SAML in the MIT core. Vikunja standardizes on OIDC (no direct SAML). Redmine reaches SAML/OIDC only via plugins.

5.2 Authorization / RBAC#

• Fine-grained: OpenProject and Redmine offer role × project permission matrices with custom roles — the granularity regulated environments expect.
• Solid: Plane (workspace/project roles).
• Basic: Taiga, Worklenz, WeKan, Vikunja, Focalboard offer role tiers (admin/member/ viewer-ish) but limited custom-permission composition.

5.3 Audit Logging#

This is the sharpest compliance differentiator:

• Enterprise-gated: OpenProject (comprehensive audit trail is an Enterprise feature).
• Plugin: Redmine (audit via plugins).
• Partial/implicit: Plane, Taiga, WeKan, Vikunja keep activity/history streams on work items but not a tamper-evident, admin-level audit log suitable for SOC 2 / ISO 27001 evidence out of the box.
• Absent: Worklenz, Focalboard.

Net: for audit-logging, SAML, and fine-grained RBAC together, only OpenProject (Enterprise) and Redmine (+ plugins) clear the bar without custom engineering. Data sovereignty (self-hosting = data stays in your jurisdiction) is universal across all eight. No community self-hosted PM tool ships with vendor compliance certifications — those attach to the SaaS offering, not the code you run.

6. Operational Complexity#

6.1 Backup / Restore#

All eight reduce to two artifacts: the database and the file/object store.

• Single-datastore tools (Vikunja on SQLite, WeKan on MongoDB, Redmine on one RDBMS) are the simplest to back up — a DB dump plus an attachments directory.
• Multi-service tools (Plane, Taiga, Worklenz) require coordinated backup of Postgres and MinIO/S3 buckets; a DB-only backup silently loses attachments.
• Redis/RabbitMQ state (Plane, Taiga) is transient and generally need not be backed up.

6.2 Upgrade Path#

• Cleanest: Vikunja (swap binary), WeKan (pull image). Redmine and OpenProject have well-documented, if heavier, upgrade procedures (Redmine’s is the most manual; OpenProject’s packaged installer is the most guided).
• Watch-outs: fast-moving young projects (Plane, Worklenz) can introduce breaking schema migrations between minor releases — pin versions and read release notes before jumping.

6.3 High Availability / Clustering#

• First-class HA guidance: OpenProject (documented multi-node, external Postgres, separate workers).
• Achievable, self-assembled: Redmine, Plane, Vikunja (stateless app + HA Postgres + shared object store + load balancer).
• Constrained by design: Taiga (RabbitMQ/events) and WeKan (MongoDB replica set + real-time fan-out) — HA possible but the real-time layer is the hard part.
• Not applicable: Focalboard standalone (dormant); use the Mattermost plugin form to inherit Mattermost HA.

Overall operational effort ranking (low → high): Vikunja < WeKan < Focalboard < Worklenz ≈ Plane ≈ Taiga < OpenProject < Redmine. (OpenProject and Redmine cost the most operationally precisely because they do the most.)

7. Emerging Entrants (Lighter Treatment)#

These two were coverage gaps in S1 and are increasingly cited in 2026 self-hosted PM comparisons. Treated here at survey depth, not full per-tool architecture parity.

7.1 Huly#

• Positioning: All-in-one workspace (PM + docs + team chat + GitHub sync) — pitched against Linear, Jira, Slack, Notion, and Motion. ~26k GitHub stars.
• License: EPL-2.0 (Eclipse Public License — more permissive than AGPL/GPL).
• Stack: Heavyweight and distinctive — CockroachDB, Elasticsearch, Redpanda (Kafka- compatible), MinIO, Nginx, all containerized; external LiveKit (video), Redis (real-time), and SMTP/SES (email) for full production.
• Footprint: Minimum 2 vCPU / 8 GB RAM; recommended 4+ vCPU / 16 GB — the heaviest self-host in this survey by a wide margin.
• Deployment: Docker Compose via the huly-selfhost repo.
• 2026 note: The hosted Huly cloud service is being discontinued (~July 20, 2026) for funding reasons; self-hosted deployments are unaffected. This shifts Huly further toward a self-host-only story and is a viability signal to weigh in S4.
• Category fit: The most ambitious feature surface (chat + video + docs + PM in one), at the cost of the heaviest ops burden. Real HA means clustering CockroachDB, Elasticsearch, and Redpanda — enterprise-grade infrastructure skills required.

7.2 Leantime#

• Positioning: Goals-focused PM “for non-project managers,” explicitly designed for neurodivergent users (ADHD/autism/dyslexia) with behavioral-science framing. ~10k stars.
• License: AGPL-3.0 core; enterprise license available for closed modification.
• Stack: PHP + MySQL/MariaDB (classic LAMP) — the most familiar/accessible stack in the survey for the large pool of shared-hosting/LAMP administrators; official Docker image.
• Features: Tasks/sub-tasks, Kanban, calendar, timeline (Gantt), strategy & program management, whiteboards, notes, Pomodoro, custom fields (several via plugin marketplace), plus a built-in AI assistant and built-in screen/video capture.
• Footprint: Light — LAMP on a small VPS; self-host setup commonly under an hour.
• Category fit: Occupies a distinct niche (strategy + accessibility) rather than competing head-on with the agile/enterprise clusters; the LAMP stack lowers the ops bar meaningfully versus the Docker-Compose-heavy modern entrants.

8. Research Confidence Assessment#

High confidence (>90%)

• Tech stacks, data stores, deployment models, and license identities (web-verified 2026-07-02).
• Feature-presence matrix for mainstream capabilities (views, hierarchy, API/webhooks, i18n).
• Relative operational-complexity ordering (implied directly by component count and stack).

Medium confidence (70–90%)

• Exact SAML/audit gating boundaries between community vs paid editions (vendors move these lines between releases — verify against the target version before committing).
• Fine-grained RBAC depth for the lighter tools (documented feature lists, not hands-on).

Architecture-implied, NOT benchmarked

• All scale/performance tiers in §3. No standardized public load tests exist for this category; figures are reasoned from architecture, not measured. Any production decision at 1k+ users should be validated with a load test on the specific version and datastore.

Known open items for later stages

• Hands-on migration effort (Jira/Trello/Asana → each platform) — quantify in an applications-level analysis, not in this category survey.
• S4 will weigh viability signals surfaced here (Focalboard dormant; Huly cloud shutdown; Worklenz youth; Plane’s rapid release velocity).

S2 Status: ✅ Complete Methodology note: Category-first (RAIL 0) — no single deployment scenario privileged; scenario mapping lives in S3, final ranking/recommendations in S4. Last Updated: July 2, 2026

1.131: Self-Hosted Project Management Platforms - S3 Need-Driven Discovery#

Research Date: November 7, 2025 Category: 1.130-139 Business Application Platforms (Self-Hosted) Methodology: MPSE S3 (Need-Driven Discovery - Generic Use Case Patterns)

Document Purpose#

This document provides generic use case PATTERNS for selecting self-hosted project management platforms. These are parameterized patterns that ANY team can map their situation to - not specific recommendations.

Hardware Store Model: This is the catalog of “what tool for what job.” Application-specific analysis belongs in applications/{app}/.

Pattern Index#

1. Simple Kanban Transition from Trello
2. Solo Practitioner Scaling to Small Team
3. Multi-Project Portfolio Management
4. Software Development Team with Git Integration
5. Small Team with Limited DevOps Capability
6. Scaling Beyond Basic Boards
7. Mixed Methodology Requirements
8. Agency Managing Multiple Client Projects
9. Enterprise with Compliance Requirements
10. Technical Team Needing Deep Customization
11. Budget-Constrained Team Avoiding SaaS Costs
12. Modern UX Expectations (Linear/Notion Style)

Pattern 1: Simple Kanban Transition from Trello#

Team Characteristics#

• Size: 1-10 people
• Current Tool: Trello (or similar simple Kanban)
• Skills: Basic tech literacy, minimal DevOps
• Budget: $0-100/month
• Pain Points: Trello costs ($5-17.50/user/month), data ownership concerns, need self-hosting

Project Characteristics#

• Count: 1-5 active projects
• Complexity: Low to moderate
• Methodology: Pure Kanban (boards, lists, cards)
• Features Needed: Drag-drop, labels, due dates, attachments, basic checklists
• Features NOT Needed: Gantt charts, resource management, time tracking, complex workflows

Platform Recommendations#

Primary Option: WeKan#

Why:

• Closest Trello clone (direct import from Trello)
• MIT license (permissive)
• Swimlanes (Trello lacks this)
• Lightweight (1-2GB RAM)
• 60 language support
• GDPR-compliant when self-hosted

Trade-offs:

• ✅ Familiar Trello-like interface
• ✅ Easiest migration path (Trello JSON import)
• ✅ No Docker expertise required (can run on simple VPS)
• ❌ Limited to Kanban (no Gantt, no Scrum sprints)
• ❌ Smaller feature set than full PM platforms
• ❌ Meteor.js stack may be unfamiliar

Deployment:

• Docker: 15-30 minutes
• Infrastructure: $10-20/month VPS (DigitalOcean, Linode)
• Maintenance: 1-2 hours/month

Breakeven vs Trello: 2-4 users (Trello Standard $5/user = $120-240/year for 2-4 users)

Alternative Option: Vikunja#

Why:

• Multiple view types (List, Kanban, Gantt, Table)
• Very lightweight (Raspberry Pi capable)
• Modern Go + Vue.js stack
• Simple Docker deployment

Trade-offs:

• ✅ More view flexibility than WeKan
• ✅ Extremely lightweight
• ✅ Modern tech stack
• ❌ Less Trello-like (steeper learning curve for Trello users)
• ❌ No direct Trello import
• ❌ More task-focused than project-focused

When to choose Vikunja over WeKan:

• Want multiple view types (not just Kanban)
• Need very lightweight deployment
• Prefer modern tech stack (Go/Vue vs Meteor)
• Okay with manual migration from Trello

Alternative Option: Focalboard#

⚠️ 2026 status: standalone Focalboard is UNMAINTAINED (seeking maintainers since Aug 2024). Active development continues only as Mattermost Boards, an in-suite plugin. Prefer WeKan/Vikunja for new self-hosted Kanban unless already committed to the Mattermost suite.

Why:

• Backed by Mattermost (enterprise chat platform)
• MIT license
• Notion-like flexibility (Kanban, table, gallery, calendar views)
• React + Go stack

Trade-offs:

• ✅ Notion-like flexibility
• ✅ Multiple view types
• ✅ Modern stack
• ❌ Best value when paired with Mattermost (added complexity)
• ❌ Less mature than WeKan (launched 2021)
• ❌ No Trello import

When to choose Focalboard over WeKan:

• Already using or planning to use Mattermost
• Want Notion-like flexibility beyond Kanban
• Prefer React + Go stack

Decision Criteria#

Choose WeKan if:

• Pure Kanban is sufficient
• Want easiest migration from Trello
• Familiar interface is priority
• Team is non-technical

Choose Vikunja if:

• Want multiple view types (Kanban + List + Gantt)
• Need very lightweight deployment
• Modern tech stack preferred

Choose Focalboard if:

• Using/planning Mattermost
• Want Notion-like flexibility
• React + Go stack familiar

Migration Path#

From Trello to WeKan:

1. Export Trello board as JSON
2. Deploy WeKan via Docker
3. Import Trello JSON into WeKan
4. Verify cards, labels, attachments
5. Train team on WeKan (1-2 hours, very similar to Trello)

Estimated Migration Time: 4-8 hours

Migration Risks:

• Custom Power-Ups from Trello won’t migrate
• Some formatting may need adjustment
• Automations must be recreated (Butler → WeKan Triggers)

Cost Comparison#

Breakeven: 1-2 years for self-hosted vs Trello Standard

Pattern 2: Solo Practitioner Scaling to Small Team#

Team Characteristics#

• Current Size: 1 person
• Growth Trajectory: 1 → 3-5 people over 12-24 months
• Current Tool: Personal task list, Notion, or nothing formal
• Skills: Technical proficiency (developer, designer, consultant)
• Budget: Minimal ($0-50/month)

Project Characteristics#

• Count: 3-10 active projects (personal + client work)
• Complexity: Low to moderate (solo work, small deliverables)
• Methodology: Flexible (task lists now, may need Kanban/sprints later)
• Features Needed: Task lists, due dates, hierarchical projects
• Future Needs: Collaboration, team assignments, client project separation

Platform Recommendations#

Primary Option: Vikunja#

Why:

• Scales from personal use to small team
• Multiple view types (start with lists, add Kanban/Gantt later)
• Very lightweight (can run on existing server/Raspberry Pi)
• Free and open source
• Simple Docker deployment

Growth Path:

• Month 1-6 (solo): Use as personal task manager
• Month 6-12 (1-2 people): Share projects, assign tasks
• Month 12-24 (3-5 people): Use team collaboration features, project hierarchies

Trade-offs:

• ✅ Grows with you (personal → team)
• ✅ Multiple view types
• ✅ Very low cost ($10-15/month VPS)
• ❌ Less feature-rich than full PM platforms (no resource management, limited reporting)
• ❌ May need to migrate later if team grows beyond 10-15 people

Alternative Option: Plane#

Why:

• Modern interface
• Designed for technical teams
• AI-assisted planning
• Scales from small to medium teams (10-50+)

Trade-offs:

• ✅ Better for larger team growth (10-50+ people)
• ✅ Modern UX
• ✅ AI features
• ❌ Overkill for solo use initially
• ❌ Higher resource requirements (2-4GB RAM)
• ❌ More complexity than needed for solo practitioner

When to choose Plane over Vikunja:

• Expect rapid growth to 10+ person team
• Technical team (developers, designers)
• Value modern UX and AI features
• Can handle higher infrastructure costs

Decision Criteria#

Choose Vikunja if:

• Solo now, slow growth to 3-5 people
• Budget-conscious ($10-15/month)
• Need lightweight deployment
• Task management > project management

Choose Plane if:

• Expect rapid growth to 10+ person technical team
• Value modern UX
• Can handle $20-40/month infrastructure costs
• Project management > task management

Cost Comparison#

Pattern 3: Multi-Project Portfolio Management#

Team Characteristics#

• Size: 3-15 people
• Structure: Managing 5-20 concurrent projects
• Skills: Intermediate technical capability
• Budget: $50-200/month
• Pain Point: Need project hierarchy, cross-project visibility, resource allocation

Project Characteristics#

• Count: 5-20 active projects simultaneously
• Complexity: Moderate to high
• Methodology: Mixed (some Kanban, some waterfall, some ad-hoc)
• Features Needed:
  • Project/subproject hierarchy
  • Cross-project dashboards
  • Resource allocation visibility
  • Portfolio-level reporting
  • Multi-project search

Platform Recommendations#

Primary Option: OpenProject#

Why:

• Designed for multi-project management
• Project hierarchy (projects + subprojects)
• Portfolio dashboards
• Free Community edition (unlimited projects)
• Gantt charts for waterfall projects
• Boards for agile projects

Trade-offs:

• ✅ Best multi-project support in open source
• ✅ Free Community edition very capable
• ✅ Mixed methodology support (Kanban + Gantt + traditional)
• ✅ Cross-project reporting
• ❌ Steeper learning curve
• ❌ Higher resource requirements (4-8GB RAM)
• ❌ More complex deployment

Deployment:

• Docker: 1-2 hours
• Infrastructure: $40-80/month VPS
• Maintenance: 3-5 hours/month

Alternative Option: Redmine#

Why:

• Mature multi-project hierarchy (19 years old)
• Subproject nesting
• Cross-project issues
• Vast plugin ecosystem for custom needs

Trade-offs:

• ✅ Very mature multi-project support
• ✅ Extremely customizable via plugins
• ✅ Cross-project features well-developed
• ❌ Dated UI/UX
• ❌ Requires Ruby on Rails expertise
• ❌ Complex deployment (4+ hours)

When to choose Redmine over OpenProject:

• Have Ruby on Rails expertise
• Need vast plugin ecosystem
• Legacy integrations important
• Okay with dated UI for functionality

Alternative Option: Plane#

Why:

• Modern multi-project support
• Workspaces for project organization
• Cross-project visibility

Trade-offs:

• ✅ Modern UX
• ✅ Simpler deployment than OpenProject
• ❌ Newer platform (less proven for large portfolios)
• ❌ Less robust hierarchy than OpenProject/Redmine
• ❌ Limited portfolio reporting

When to choose Plane over OpenProject:

• UX is priority over feature depth
• Portfolio < 10 projects
• Team is technical (developers)
• Modern stack preferred

Decision Criteria#

Choose OpenProject if:

• 10+ concurrent projects
• Need mixed methodologies (Kanban + Gantt)
• Portfolio reporting critical
• Can handle deployment complexity

Choose Redmine if:

• Very complex project hierarchies (deep nesting)
• Ruby on Rails expertise available
• Need extensive customization via plugins
• UI/UX not priority

Choose Plane if:

• <10 concurrent projects
• Modern UX critical for team adoption
• Technical team (developers)
• Simpler deployment preferred

Architecture Pattern: Project Hierarchy#

OpenProject Structure:

Organization
├── Product Line A
│   ├── Project A1
│   │   ├── Sprint 1
│   │   └── Sprint 2
│   └── Project A2
├── Product Line B
│   ├── Project B1
│   └── Project B2
└── Internal Operations
    ├── HR
    └── Finance

Key Capabilities:

• Cross-project Gantt charts
• Portfolio dashboards
• Resource allocation across projects
• Milestone tracking across portfolio

Pattern 4: Software Development Team with Git Integration#

Team Characteristics#

• Size: 3-20 developers
• Current Tool: GitHub/GitLab Issues, Trello, or JIRA
• Skills: High technical capability (developers)
• Budget: $50-200/month
• Pain Point: Need tight Git integration, issue tracking tied to commits/PRs

Project Characteristics#

• Count: 2-10 active codebases
• Complexity: Moderate to high (software projects)
• Methodology: Agile (Scrum or Kanban)
• Features Needed:
  • Git integration (GitHub, GitLab, Bitbucket)
  • Issue tracking linked to commits/PRs
  • Sprint planning
  • Burndown charts
  • Code review workflow integration

Platform Recommendations#

Primary Option: Plane#

Why:

• Designed for technical teams (modern stack)
• GitHub/GitLab integration
• Issues, epics, cycles (sprints)
• Modern UX developers expect (Linear-like)
• API-first architecture

Trade-offs:

• ✅ Best modern UX for developers
• ✅ GitHub/GitLab integration
• ✅ Developer-friendly (keyboard shortcuts, CLI)
• ✅ React + Django stack familiar to devs
• ❌ Newer platform (less proven than JIRA/Redmine)
• ❌ Smaller plugin ecosystem

Deployment:

• Docker: 15-30 minutes
• Infrastructure: $20-40/month VPS
• Maintenance: 2-3 hours/month

Breakeven vs JIRA: 3-5 users (JIRA $8-16/user/month = $288-960/year for 3-5 users)

Alternative Option: Taiga#

Why:

• Agile-native (Scrum/Kanban)
• GitHub/GitLab integration pre-configured
• Sprint boards with swimlanes
• Burndown charts
• Beautiful UI

Trade-offs:

• ✅ Excellent Scrum/Kanban implementation
• ✅ GitHub/GitLab integration built-in
• ✅ Beautiful UI developers like
• ❌ Less modern than Plane (2014 vs 2022)
• ❌ Python + Angular stack less trendy

When to choose Taiga over Plane:

• Pure agile team (Scrum or Kanban, not hybrid)
• Beautiful UI more important than cutting-edge
• Established platform preferred (2014 vs 2022)

Alternative Option: Redmine#

Why:

• Deep Git integration (Git, SVN, Mercurial)
• Issue linking to commits
• Mature development workflow
• Vast plugin ecosystem

Trade-offs:

• ✅ Most mature Git integration (19 years)
• ✅ Plugin ecosystem for any custom need
• ✅ Deep VCS integration (beyond just Git)
• ❌ Dated UI (2006-era)
• ❌ Rails deployment complex
• ❌ Developers may resist old-looking UI

When to choose Redmine over Plane:

• Legacy codebases (SVN, Mercurial)
• Ruby on Rails expertise
• Need extensive customization
• UI/UX not critical for team adoption

Decision Criteria#

Choose Plane if:

• Modern developer team
• GitHub/GitLab primary VCS
• UX important for adoption
• Want Linear/JIRA alternative

Choose Taiga if:

• Pure agile (Scrum/Kanban)
• Beautiful UI critical
• GitHub/GitLab integration needed
• Established platform preferred

Choose Redmine if:

• Legacy VCS (SVN, Mercurial)
• Rails expertise available
• Deep customization needed
• UI not critical

Integration Architecture#

Plane + GitHub:

GitHub PR #123
  ↓ (references)
Plane Issue #456
  ↓ (tracked in)
Sprint 3 (Cycle)
  ↓ (part of)
Epic: User Authentication

Workflow:

1. Create issue in Plane
2. Create branch: feature/PLANE-456-oauth-login
3. Commit with message: Implement OAuth login (PLANE-456)
4. Open PR referencing PLANE-456
5. Plane automatically links PR to issue
6. Merge PR → Plane marks issue “Done”

Pattern 5: Small Team with Limited DevOps Capability#

Team Characteristics#

• Size: 2-8 people
• Skills: Non-technical to beginner technical (designers, marketers, small business)
• DevOps Capability: Minimal (can follow tutorials, no Rails/K8s expertise)
• Budget: $20-100/month
• Pain Point: Want self-hosting benefits without operational complexity

Project Characteristics#

• Count: 2-8 projects
• Complexity: Low to moderate
• Methodology: Flexible (Kanban or simple task lists)
• Features Needed: Basic PM, easy deployment, minimal maintenance

Platform Recommendations#

Primary Option: Vikunja#

Why:

• Simplest Docker deployment (docker-compose up -d)
• Very lightweight (1GB RAM sufficient)
• Modern UI (easy for non-technical users)
• Multiple view types (List, Kanban, Gantt)

Trade-offs:

• ✅ Easiest deployment (15 minutes)
• ✅ Minimal maintenance (1-2 hours/month)
• ✅ Very low cost ($10-15/month VPS)
• ❌ Limited advanced features
• ❌ May need to migrate if team grows significantly

Deployment Steps:

1. Rent $10/month VPS (DigitalOcean, Linode)
2. Install Docker
3. Run docker-compose up -d with Vikunja config
4. Point domain to VPS
5. Done (15-30 minutes total)

Alternative Option: WeKan#

Why:

• Simple Docker deployment
• Familiar Kanban interface
• Lightweight

Trade-offs:

• ✅ Trello-like (familiar)
• ✅ Easy deployment
• ❌ Kanban-only (less flexible than Vikunja)

When to choose WeKan over Vikunja:

• Kanban is sufficient (no need for Gantt/Table views)
• Trello familiarity important

Option to Avoid: Redmine, OpenProject#

Why NOT:

• Redmine requires Rails expertise
• OpenProject requires 4-8GB RAM, more complex deployment
• Both have steeper learning curves
• Overkill for small teams with limited DevOps

Decision Criteria#

Choose Vikunja if:

• Want easiest deployment
• Multiple view types needed
• Very budget-conscious

Choose WeKan if:

• Kanban-only sufficient
• Trello familiarity important

Avoid if:

• Limited DevOps: Redmine (complex), OpenProject (resource-heavy)

Managed Alternatives (If Self-Hosting Too Complex)#

If even Docker is too complex:

• Vikunja Cloud: Hosted Vikunja (pricing varies)
• WeKan Cloud: Third-party WeKan hosting
• Taiga Cloud: $10/month for small teams
• OpenProject Cloud: $7.25-19.50/user/month

Trade-off: Pay for convenience ($10-100/month) vs self-hosting ($10-20/month infra)

Pattern 6: Scaling Beyond Basic Boards#

Team Characteristics#

• Current Tool: Basic Kanban (Trello, WeKan, Vikunja)
• Size: 5-20 people
• Growth: Team has outgrown simple boards
• Pain Point: Need resource management, Gantt charts, time tracking, advanced reporting

Project Characteristics#

• Complexity: Increasing (simple Kanban insufficient)
• Methodology: Evolving from pure Kanban to mixed (Kanban + Gantt + sprints)
• Features Needed:
  • Gantt charts (waterfall projects)
  • Resource allocation
  • Time tracking
  • Advanced reporting
  • Dependencies between tasks

Platform Recommendations#

Primary Option: OpenProject#

Why:

• Supports Kanban (familiar) + Gantt + traditional PM
• Resource management
• Time tracking built-in
• Advanced reporting
• Free Community edition

Migration Path from Basic Kanban:

1. Deploy OpenProject
2. Create projects with Work Packages (like cards)
3. Set up Boards view (like Kanban)
4. Gradually add Gantt charts for waterfall projects
5. Add time tracking as needed
6. Build reports once data accumulates

Trade-offs:

• ✅ Smooth transition (has Kanban boards)
• ✅ Grows with team (Kanban → full PM)
• ✅ Free Community edition very capable
• ❌ Steeper learning curve
• ❌ Higher infrastructure costs ($40-80/month)

Alternative Option: Plane#

Why:

• Modern alternative
• Cycles (sprints) for more structure
• Roadmaps for planning
• Analytics

Trade-offs:

• ✅ Modern UX (easier adoption)
• ✅ Less complex than OpenProject
• ❌ No Gantt charts (Kanban + Cycles only)
• ❌ Limited resource management

When to choose Plane over OpenProject:

• Don’t need Gantt charts
• Modern UX critical for adoption
• Agile-only (no waterfall)

Decision Criteria#

Stick with Basic Kanban (WeKan/Vikunja) if:

• Team < 5 people
• Projects simple (no dependencies, no resource conflicts)
• Kanban methodology sufficient

Move to OpenProject if:

• Team 10+ people
• Need Gantt charts for waterfall projects
• Resource management needed
• Time tracking required
• Complex dependencies

Move to Plane if:

• Team 5-20 technical people
• Need more structure (cycles/sprints) but not full PM
• Modern UX critical
• Agile-only

Pattern 7: Mixed Methodology Requirements#

Team Characteristics#

• Size: 5-50 people
• Structure: Different teams use different methodologies
• Example: Dev team (Agile) + Marketing (Kanban) + Construction projects (Waterfall)

Project Characteristics#

• Methodology Mix:
  • Some projects: Agile/Scrum (sprints, backlogs)
  • Some projects: Kanban (continuous flow)
  • Some projects: Waterfall (Gantt charts, dependencies)
• Features Needed: Platform supporting ALL methodologies

Platform Recommendations#

Primary Option: OpenProject#

Why:

• Explicitly supports multiple methodologies
• Kanban boards for agile teams
• Gantt charts for waterfall teams
• Scrum-style backlogs available
• Each project can choose methodology

Methodology Support:

• Agile: Work packages → Backlogs → Sprint boards
• Kanban: Work packages → Kanban boards → WIP limits
• Waterfall: Work packages → Gantt charts → Dependencies

Trade-offs:

• ✅ Best multi-methodology support
• ✅ Free Community edition
• ✅ Each team can use their preferred method
• ❌ Complexity (learning curve for each methodology)
• ❌ May feel “jack of all trades, master of none”

Alternative Option: Plane#

Why:

• Flexible views (Kanban, Lists, Cycles)
• Can approximate multiple methodologies

Trade-offs:

• ✅ Modern UX
• ✅ Simpler than OpenProject
• ❌ No true Gantt charts (limited waterfall support)
• ❌ Best for agile variations, not waterfall

When to choose Plane over OpenProject:

• “Mixed” = Kanban + Scrum (both agile)
• Don’t need true waterfall (Gantt)
• Modern UX priority

Decision Criteria#

Choose OpenProject if:

• Need TRUE mixed methodologies (Agile + Kanban + Waterfall)
• Gantt charts required for some projects
• Resource management across methodologies
• Complex dependencies

Choose Plane if:

• “Mixed” = agile variations (Kanban + Scrum)
• No waterfall/Gantt needed
• Modern UX critical

Pattern 8: Agency Managing Multiple Client Projects#

Team Characteristics#

• Size: 5-25 people
• Structure: Agency/consultancy with multiple clients
• Pain Point: Need client project separation, reporting per client, time tracking for billing

Project Characteristics#

• Count: 10-50 client projects (varying sizes)
• Isolation: Clients must NOT see each other’s projects
• Billing: Time tracking needed for hourly billing
• Reporting: Per-client reports for billing/transparency

Platform Recommendations#

Primary Option: OpenProject#

Why:

• Strong multi-project hierarchy
• Time tracking built-in (billable hours)
• Cost tracking
• Per-project permissions (client isolation)
• Client can be given read-only access to their project only

Agency Architecture:

OpenProject Instance
├── Client A
│   ├── Project A1
│   └── Project A2
├── Client B
│   ├── Project B1
│   └── Project B2
└── Internal
    └── Agency Operations

Permissions:

• Agency staff: See all projects
• Client A: See ONLY Client A projects (read-only or limited)
• Client B: See ONLY Client B projects

Trade-offs:

• ✅ Excellent multi-project + permissions
• ✅ Time tracking for billing
• ✅ Cost reports per client
• ❌ No true multi-tenancy (single instance, permission-based separation)
• ❌ Complex permission setup

Alternative Option: Redmine#

Why:

• Mature multi-project hierarchy
• Time tracking plugins
• Billing plugins available
• Can create per-client parent projects

Trade-offs:

• ✅ Very mature multi-project support
• ✅ Extensive plugins for agency needs
• ❌ Dated UI (may not impress clients)
• ❌ Rails expertise needed

When to choose Redmine over OpenProject:

• Rails expertise available
• Need specific agency plugins
• Okay with dated UI

Multi-Tenancy Pattern (Advanced)#

If TRUE multi-tenancy needed (separate databases per client):

• Deploy multiple instances of Plane/Taiga/Vikunja (one per client)
• Use Docker containers with separate databases
• More complex infrastructure but TRUE isolation

When multi-tenancy needed:

• High-security clients (government, healthcare)
• Data MUST be isolated (not just permission-based)
• Clients demand dedicated instances

Cost: Higher (multiple VPS or K8s cluster)

Decision Criteria#

Choose OpenProject if:

• Permission-based separation sufficient
• Time tracking for billing critical
• Need per-client reporting

Choose Redmine if:

• Rails expertise available
• Need extensive plugins for agency workflows

Choose multi-tenancy (multiple instances) if:

• High-security requirements
• True data isolation required (separate DBs)
• Budget allows ($100-500/month for multiple instances)

Pattern 9: Enterprise with Compliance Requirements#

Team Characteristics#

• Size: 20-500+ people
• Industry: Healthcare, finance, government, regulated industries
• Requirements:
  • Audit logging (who changed what, when)
  • Role-based access control (RBAC)
  • GDPR/HIPAA/SOC2 compliance
  • SSO (LDAP, SAML)
  • Data encryption (at rest, in transit)

Project Characteristics#

• Complexity: High (enterprise-grade)
• Compliance: Critical (audit trails, data sovereignty)
• Scale: 100s-1000s of users

Platform Recommendations#

Primary Option: OpenProject Enterprise#

Why:

• Commercial support available
• LDAP/SAML authentication
• Audit logging (Enterprise edition)
• RBAC
• Can be deployed on-premise (data sovereignty)
• SOC2/ISO27001 compliance possible

Compliance Features:

• Audit logs: All changes tracked
• SSO: LDAP, SAML, OAuth
• Encryption: SSL/TLS, database encryption
• RBAC: Fine-grained permissions
• Data sovereignty: Self-hosted = data stays in your jurisdiction

Trade-offs:

• ✅ Enterprise-ready
• ✅ Commercial support available
• ✅ Compliance features built-in (Enterprise edition)
• ❌ Enterprise edition costs ($405/5 users/year, scales up)
• ❌ Community edition lacks some compliance features

Cost:

• Community: Free (but limited audit logging)
• Enterprise: $405/5 users/year to $10K+/year for large deployments

Alternative Option: Redmine#

Why:

• Can be deployed on-premise
• LDAP authentication built-in
• Audit plugins available
• Mature (trusted in enterprises)

Trade-offs:

• ✅ Free and open source
• ✅ LDAP built-in
• ✅ Audit plugins available
• ❌ No commercial support (unless third-party)
• ❌ Audit features require plugins (not built-in)
• ❌ Dated UI

When to choose Redmine over OpenProject:

• Budget-constrained (no money for Enterprise support)
• Rails expertise available
• Plugins acceptable for compliance features

Decision Criteria#

Choose OpenProject Enterprise if:

• Budget exists for commercial support ($5K-50K/year)
• Need compliance certifications (SOC2, ISO27001)
• Audit logging critical
• SSO required (SAML, LDAP)

Choose OpenProject Community if:

• Budget-constrained
• Basic RBAC sufficient
• Can implement some compliance features manually

Choose Redmine if:

• Free and open source requirement
• Rails expertise available
• Plugins acceptable for compliance

Compliance Checklist#

Pattern 10: Technical Team Needing Deep Customization#

Team Characteristics#

• Size: 5-50 technical people
• Skills: Developers, DevOps engineers
• Pain Point: SaaS PM tools don’t fit workflows; need custom fields, workflows, integrations
• Budget: $50-500/month (labor + infrastructure)

Project Characteristics#

• Complexity: High (custom workflows, unique processes)
• Integration Needs: Custom APIs, webhooks, third-party tools
• Customization Depth: Extensive (custom fields, states, automations)

Platform Recommendations#

Primary Option: Plane#

Why:

• Modern tech stack (React + Django)
• API-first architecture (GraphQL + REST)
• Open source (AGPL-3.0, can fork and customize)
• TypeScript/Python codebase familiar to developers

Customization Depth:

• Custom fields: Via API
• Custom workflows: Via API
• Custom integrations: REST/GraphQL API
• Custom UI: Fork and modify (React)

Trade-offs:

• ✅ Modern stack developers love
• ✅ API-first (easy to extend)
• ✅ Can fork and customize
• ✅ GraphQL for flexible queries
• ❌ Newer (less community plugins than Redmine)
• ❌ Requires dev time to customize

Alternative Option: Redmine#

Why:

• 1000+ plugins available
• Mature plugin API
• Can customize extensively via plugins
• Ruby on Rails (full control)

Customization Depth:

• Custom fields: Built-in + plugins
• Custom workflows: Workflow plugins
• Custom integrations: 1000+ plugins
• Custom UI: Rails views, theming

Trade-offs:

• ✅ Vast plugin ecosystem
• ✅ Proven customization platform
• ✅ Don’t need to build everything (plugins exist)
• ❌ Dated tech stack (Rails)
• ❌ Plugin quality varies

When to choose Redmine over Plane:

• Rails expertise available
• Plugin ecosystem more valuable than modern stack
• Don’t want to build custom features (use plugins)

Alternative Option: Taiga#

Why:

• Python + Angular
• REST API + webhooks
• Open source (can customize)

Trade-offs:

• ✅ Python + Angular (modern but not cutting-edge)
• ✅ Good API
• ❌ Smaller plugin ecosystem than Redmine
• ❌ Less customizable than Plane (less API-first)

Decision Criteria#

Choose Plane if:

• Want modern stack (TypeScript, React, Django, GraphQL)
• API-first architecture critical
• Willing to build custom features
• Small team of developers

Choose Redmine if:

• Want to use existing plugins (not build)
• Rails expertise available
• Vast plugin ecosystem valuable

Choose Taiga if:

• Python + Angular stack preferred
• Agile-focused
• Moderate customization needs

Customization Examples#

Plane + Custom Integration:

// Custom webhook handler
app.post('/webhook/plane', async (req, res) => {
  const issue = req.body.issue

  // Custom logic
  if (issue.priority === 'critical') {
    await sendPagerDutyAlert(issue)
  }

  // Update custom system
  await updateCustomDashboard(issue)
})

Redmine + Plugin:

# Install existing plugin
gem install redmine_agile

# Or build custom plugin
class CustomWorkflowHooksListener < Redmine::Hook::ViewListener
  def controller_issues_new_after_save(context={})
    # Custom logic when issue created
  end
end

Pattern 11: Budget-Constrained Team Avoiding SaaS Costs#

Team Characteristics#

• Size: 3-15 people
• Budget: Minimal (<$50/month total)
• Pain Point: SaaS costs $500-2,000/year for team, want <$500/year total
• Skills: Willing to learn Docker, basic DevOps

Project Characteristics#

• Count: 2-10 projects
• Complexity: Low to moderate
• Methodology: Flexible (Kanban or simple PM)

Cost Comparison Reference#

Target: <$500/year (<$42/month)

Platform Recommendations#

Ultra-Budget Option: Vikunja#

Infrastructure Cost:

• VPS: $10-15/month (DigitalOcean, Linode, Hetzner)
• Domain: $10-15/year
• Total: ~$135-195/year

Savings vs SaaS: $400-1,700/year (vs $600-1,920 SaaS alternatives)

Trade-offs:

• ✅ Lowest cost self-hosted option
• ✅ Very lightweight (512MB-1GB RAM)
• ✅ Simple deployment
• ❌ Limited advanced features
• ❌ 2-4 hours setup + 1-2 hours/month maintenance

Breakeven: Immediate (Year 1: $300-400 total vs $600+ SaaS)

Budget Option: WeKan#

Infrastructure Cost:

• VPS: $10-20/month
• Domain: $10-15/year
• Total: ~$135-255/year

Savings vs SaaS: $345-1,665/year

Trade-offs:

• ✅ Low cost
• ✅ Familiar Trello-like interface
• ❌ Kanban-only

Mid-Budget Option: Plane#

Infrastructure Cost:

• VPS: $20-40/month (higher RAM needed)
• Domain: $10-15/year
• Total: ~$255-495/year

Savings vs SaaS: $105-1,425/year

Trade-offs:

• ✅ Modern features
• ✅ Better for larger teams (10-20 people)
• ✅ More robust than Vikunja
• ❌ Higher infrastructure costs
• ❌ Higher maintenance time

Decision Criteria#

Choose Vikunja if:

• Absolute minimal budget (<$200/year)
• Small team (3-8 people)
• Simple needs (task lists + basic Kanban)

Choose WeKan if:

• Budget <$300/year
• Kanban sufficient
• Trello-like interface important

Choose Plane if:

• Budget <$500/year
• Larger team (10-15 people)
• Need modern features
• Can justify higher infra costs for better UX

Hidden Costs to Consider#

Time Investment:

• Initial setup: 2-8 hours ($250-1,000 @ $125/hr if outsourced)
• Monthly maintenance: 1-3 hours ($125-375/month if outsourced)

If outsourcing DevOps:

• Year 1: $1,500-5,000 (setup + maintenance)
• Breakeven shifts to 15-30 users vs SaaS

DIY DevOps recommendation: Learn Docker yourself (20-40 hour learning curve) to keep costs minimal

Budget Optimization Strategies#

1. Use cheapest VPS (Hetzner €4/month, Contabo, DigitalOcean $6/month droplet)
2. Avoid managed services (Managed K8s = 3-5x infrastructure cost)
3. Choose lightweight platform (Vikunja over OpenProject)
4. Learn Docker (avoid outsourcing setup/maintenance)
5. Use free domain (Subdomain from existing domain, or Cloudflare free tier)

Pattern 12: Modern UX Expectations (Linear/Notion Style)#

Team Characteristics#

• Size: 5-30 people
• Culture: Design-conscious, modern tech expectations
• Current Tools: Linear, Notion, or considering them
• Pain Point: Want self-hosting BUT cannot tolerate “ugly” open source tools
• Budget: $50-200/month

Project Characteristics#

• Complexity: Moderate
• Methodology: Agile (modern style, not traditional JIRA)
• Features Needed:
  • Beautiful, modern interface
  • Keyboard shortcuts
  • Fast performance
  • Multiple views (Kanban, List, etc.)
  • Clean, minimal design

Platform Recommendations#

Primary Option: Plane#

Why:

• Explicitly designed as Linear alternative
• Modern React UI
• Keyboard shortcuts (vim-like)
• Fast, responsive
• Multiple views
• AI features

UX Characteristics:

• Clean, minimal design (like Linear)
• Dark mode
• Keyboard-first navigation
• Fast (no page reloads)
• Modern color scheme

Trade-offs:

• ✅ Best modern UX in open source PM
• ✅ Comparable to Linear/Notion
• ✅ Team will actually want to use it
• ❌ Newer platform (2022)
• ❌ Smaller feature set than established tools

Deployment:

• Docker: 15-30 minutes
• Infrastructure: $20-40/month
• Maintenance: 2-3 hours/month

Comparison to Linear:

Alternative Option: Taiga#

Why:

• Beautiful, design-focused UI
• Created by designers
• Modern (but 2014, not 2022)

UX Characteristics:

• Beautiful UI (focus on design)
• Colorful, vibrant
• Good UX (not quite Linear-level)

Trade-offs:

• ✅ Beautiful UI (better than most open source)
• ✅ Agile-focused
• ❌ Not quite as modern as Plane
• ❌ Python + Angular (less trendy than React)

When to choose Taiga over Plane:

• Prefer colorful, vibrant UI over minimal
• Agile-only (Scrum/Kanban)
• Established platform preferred (2014 vs 2022)

Options to Avoid: Redmine, OpenProject#

Why NOT for modern UX expectations:

• Redmine: 2006-era UI (dated, functional but not beautiful)
• OpenProject: Traditional enterprise UI (not modern/minimal)

Team adoption risk: Design-conscious teams may resist ugly tools

Decision Criteria#

Choose Plane if:

• Modern UX non-negotiable
• Want Linear-style interface
• Keyboard shortcuts important
• Fast, minimal design preferred

Choose Taiga if:

• Beautiful UI important (but not necessarily minimal)
• Colorful, vibrant design preferred
• Agile-focused

Avoid if modern UX critical:

• Redmine (dated UI)
• OpenProject (traditional enterprise UI)
• WeKan (functional but basic)

UX Comparison Matrix#

Cross-Pattern Decision Tree#

Start Here: What’s Your Primary Constraint?#

Constraint 1: Budget (<$300/year total)#

→ Vikunja (ultra-budget) or WeKan (budget Kanban)

Constraint 2: DevOps Skills (minimal/none)#

→ Vikunja (simplest) or consider managed alternatives (Taiga Cloud $10/month)

Constraint 3: UX (must be modern/beautiful)#

→ Plane (Linear-like) or Taiga (design-focused)

Constraint 4: Methodology (mixed Agile/Kanban/Waterfall)#

→ OpenProject (multi-methodology support)

Constraint 5: Scale (10+ concurrent projects)#

→ OpenProject (portfolio management) or Redmine (complex hierarchies)

Constraint 6: Compliance (GDPR/HIPAA/SOC2)#

→ OpenProject Enterprise (audit logging, SSO) or Redmine (plugins)

Constraint 7: Customization (API-first, extensible)#

→ Plane (modern API) or Redmine (vast plugins)

Constraint 8: Simplicity (just need Kanban, nothing more)#

→ WeKan (Trello clone) or Vikunja (lightweight)

Migration Cheat Sheet#

From Trello#

Best Target: WeKan (direct import) or Vikunja (manual migration) Migration Time: 2-8 hours Complexity: Low

From JIRA#

Best Target: Plane (modern alternative) or OpenProject (feature parity) Migration Time: 20-80 hours (depends on JIRA complexity) Complexity: High

From Asana#

Best Target: Plane (modern UX) or Taiga (agile-focused) Migration Time: 10-40 hours Complexity: Medium

From Linear#

Best Target: Plane (explicit Linear alternative) Migration Time: 10-30 hours Complexity: Medium

From Notion#

Best Target: Focalboard (Notion-like) or Plane (modern alternative) Migration Time: Varies (Notion is very flexible) Complexity: Medium to High

From Spreadsheets#

Best Target: Vikunja (simplest) or WeKan (familiar Kanban) Migration Time: 4-12 hours Complexity: Low to Medium

Total Cost of Ownership (TCO) Summary by Pattern#

Notes:

• Setup: One-time (hours @ $125/hr, or DIY time)
• Monthly Infra: VPS, domain, backups
• Monthly Maint: Updates, monitoring (hours @ $125/hr, or DIY time)
• Actual costs may be $0 if DIY (just infrastructure)

Platform Selection Matrix (Quick Reference)#

Legend:

• ⭐⭐⭐ = Excellent fit
• ⭐⭐ = Good fit
• ⭐ = Possible but not ideal
• ❌ = Poor fit / avoid

Appendix: Pattern Combinations#

Real-World Scenario: Multi-Pattern Teams#

Many teams match MULTIPLE patterns. Example:

Scenario: 8-person software development agency

• Pattern 3: Multi-project (5 client projects)
• Pattern 4: Dev team (Git integration needed)
• Pattern 8: Agency (client separation)
• Pattern 11: Budget-conscious (<$500/year)

Analysis:

• Patterns 3, 8 → OpenProject (multi-project + agency features)
• Pattern 4 → Plane (modern dev team)
• Pattern 11 → Vikunja (ultra-budget)

Trade-off:

• OpenProject fits Patterns 3, 8 BUT violates Pattern 11 (costs $1,300-2,600/year)
• Vikunja fits Pattern 11 BUT poor for Patterns 3, 8 (limited multi-project)
• Plane middle ground: Fits Pattern 4, moderate for Patterns 3, 8, moderate cost

Decision: Prioritize patterns by importance

• If budget is #1 constraint → Vikunja (compromise on multi-project)
• If multi-project is #1 constraint → OpenProject (compromise on budget)
• If modern dev UX is #1 constraint → Plane (compromise on agency features)

Pattern Priority Framework#

1. Identify ALL matching patterns
2. Rank patterns by business criticality
3. Find platform matching top 2-3 patterns
4. Accept trade-offs on lower-priority patterns

S3 Status and Next Steps#

S3 Status: ✅ Complete - 12 generic use case patterns documented

What S3 Provides:

• Generic decision frameworks (hardware store catalog)
• Parameterized patterns (team size, budget, skills, etc.)
• Platform recommendations BY PATTERN (not by specific user)
• Trade-off analysis for each pattern
• TCO summaries
• Migration guidance

What S3 Does NOT Provide:

• Specific recommendations for YOUR projects (that’s applications/ folder)
• Application-specific ROI calculations
• Implementation roadmaps for specific teams
• Migration guides for specific SaaS → self-hosted transitions

Next Steps:

1. For Application-Specific Analysis → Create applications/project-management/ with:

   • Analysis of ALL your projects (e.g. project-alpha, project-beta, project-gamma, etc.)
   • Map your portfolio to patterns from S3
   • Select ONE platform for entire portfolio
   • Implementation roadmap

2. For S2 Comprehensive Discovery → Performance benchmarks, detailed feature matrix, security analysis

3. For S4 Strategic Discovery → Vendor viability, community health, technology evolution

Document Complete: S3 Need-Driven Discovery (Generic Use Case Patterns) Last Updated: July 2, 2026 (freshness pass — Focalboard maintenance caveat added)

1.131: Self-Hosted Project Management Platforms - Strategic Discovery (S4)#

Research Date: July 2, 2026 Category: 1.130-139 Business Application Platforms (Self-Hosted) Methodology: MPSE S4 (Strategic Selection)

Research Objective#

Strategic synthesis for the self-hosted project management category over a 5-year horizon (2026-2031): project/vendor viability, community-health signals, commercial backing, technology-evolution trajectories, data lock-in and migration, build-vs-buy / self-host-vs-SaaS framing, an architecture decision tree, and TCO models by scale.

This is a category-first analysis (RAIL 0): a neutral comparison for any reader evaluating self-hosted PM, not a decision memo for one team or one triggering scenario. No single “winner” is crowned; instead, tools are sorted into safe-bet vs higher-risk tiers by reader profile.

Scope note: S4 assesses the eight primary tools from S1/S3 — Plane, Taiga, Worklenz, OpenProject, Redmine, WeKan, Vikunja, Focalboard — plus two emerging entrants the S1 scan flagged as coverage gaps: Huly and Leantime. All ten are evaluated purely as public open-source projects.

Metrics caveat: All GitHub star counts, contributor counts, and release cadences below are approximate and dated to mid-2026. Star counts are a popularity proxy, not a quality or viability guarantee; they are used only as one input among several (bus-factor, funding, cadence). Verify against the live repositories before relying on any single figure.

Part 1: Five-Year Viability by Tool#

Viability here combines five factors: commercial backing (is there a company/foundation funding the work?), funding runway (VC, dual-license revenue, donations, or none), bus-factor / maintainer depth (how many people could the project lose before it stalls?), release cadence (shipping regularly?), and momentum (adoption trajectory).

Each tool gets a viability grade on a simple scale:

• A — Safe long-term bet: multiple maintainers or institutional backing, steady releases, healthy momentum.
• B — Solid, watch one risk: viable but with a single identifiable dependency (one company, one maintainer, or an unproven monetization).
• C — Higher risk: thin bus-factor, funding uncertainty, or slowing cadence — usable but plan an exit.
• D — Not recommended for new deployments: maintenance has effectively stopped.

Plane — Grade B (VC-backed momentum leader, monetization unproven)#

• Backing: makeplane, Inc. (Hyderabad, India), founded Nov 2022 by Vamsi and Vihar Kurama. ~94 employees as of mid-2026.
• Funding: $4M Seed from OSS Capital, announced April 2024. Notably still Seed-stage — no Series A on record as of mid-2026. Open-core model (Community AGPL-3.0 + paid cloud/enterprise).
• Bus-factor: Company-employed core team plus a large contributor base — good depth while the company is funded.
• Cadence: Very high — ~89 releases in 2025; v1.3.1 (May 2026). Among the most active repos in the category.
• Momentum: Strongest in the category — ~53k stars, the #1 OSS PM project by stars, fastest-growing.
• The watch item: A single Seed round funding ~94 employees implies burn well ahead of proven revenue. If enterprise monetization or a Series A does not materialize, the pace that makes Plane attractive is also its risk. The AGPL core is a real hedge (the code survives the company), but momentum would slow sharply. Safe for teams comfortable that the open-source core is a floor even if the company stumbles.

Taiga — Grade B (independent steward, quiet but durable)#

• Backing: Kaleidos Ventures (Spain), a self-funded product studio (also behind Penpot). No outside VC pressure.
• Funding: Consulting/hosted revenue + studio funding. Modest but self-sustaining, not burn-driven.
• Bus-factor: Small in-house team; contribution activity is steadier than flashy. The “Taiga Next” unification effort signals continued investment.
• Cadence: Moderate — active across the unified kaleidos-ventures/taiga repo through 2026, but not high-velocity.
• Momentum: Flat-to-slow. Stars are split across historical repos (taiga-back, taiga-front, and the unified repo), so no single ~10k headline figure; aggregate community is mid-sized and mature.
• The watch item: Low velocity relative to Plane/Huly could read as stagnation, but 11 years of continuous stewardship by a stable, profitable studio is exactly the profile that survives hype cycles. A safe bet for agile-only teams who value stability over novelty.

Worklenz — Grade C (young, thin backing)#

• Backing: Worklenz (Ceydigital, Sri Lanka). Small commercial team; cloud offering with a free tier.
• Funding: Bootstrapped/cloud-revenue; no disclosed institutional funding.
• Bus-factor: Thin — small core team, ~2.9k stars, launched 2023. Least-proven of the primary set.
• Cadence: Active releases, but a short track record.
• Momentum: Growing (reports of 20k+ cloud users) but from a small base.
• The watch item: Everything young-project: unproven longevity, small contributor pool, restrictive free tier (5 members / 3 projects / 1GB) that pushes toward the paid cloud. The AGPL-3.0 license (see licensing correction below) means the self-hostable core is protected, which softens the risk. Reasonable for small teams who accept early-stage risk; not for anything mission-critical yet.

OpenProject — Grade A (dual-license company, category anchor)#

• Backing: OpenProject GmbH (Berlin, Germany). Established, revenue-generating company with Community (GPL-3.0) + Enterprise (commercial) editions.
• Funding: Sustainable dual-license/subscription revenue — no VC runway dependency. The most conventionally “safe” commercial model in the category.
• Bus-factor: Company-employed core team plus community; healthy depth.
• Cadence: Very active — monthly-ish releases; v17.5 (June 2026), 17.6 planned. Predictable, disciplined release train.
• Momentum: Steady enterprise adoption; ~9k stars understates its install base (enterprises don’t star repos).
• The watch item: Few. UI modernization lags the Plane/Huly cohort, and some compliance features are Enterprise-gated. Otherwise this is the lowest-viability-risk option for organizations that need a 5-year commitment with a support contract available.

Redmine — Grade A (foundational longevity, community-governed)#

• Backing: Community-governed OSS led by Jean-Philippe Lang; no single company owns it. A commercial ecosystem (RedmineUP, Easy Redmine, Redmineflux) funds plugins/forks around it.
• Funding: No central funding needed — the project is mature and low-burn; commercial value accrues to the plugin vendors.
• Bus-factor: Distributed across a long-standing contributor community plus multiple commercial forks that could sustain it. Very resilient.
• Cadence: Historically slow but just accelerated meaningfully — v7.0 (June 2026) brings Rails 8, a header/nav redesign, and event webhooks. This directly retires the old “dead/legacy” risk narrative.
• Momentum: Not growing in mindshare, but 20 years of production deployments and 1000+ plugins make it the definition of durable.
• The watch item: The risk is aesthetic/velocity, not survival. Rails/DevOps expertise is required to run it well. The safest bet in the category on the “will it still exist in 2031?” question specifically — community-governed projects with this much install base do not disappear.

WeKan — Grade C (single-maintainer bus-factor)#

• Backing: None commercial — community project, effectively driven by one lead maintainer (Lauri Ojansivu / xet7).
• Funding: Donations; no company.
• Bus-factor: The clearest single-maintainer risk in the survey. Development, releases, and support largely flow through one person. This is the dominant viability concern regardless of how active the project currently is.
• Cadence: Very active — v9.35+ (2026), kept current on Meteor 3.5 / Node 24.
• Momentum: Stable niche (~19k stars) as the leading self-hosted Trello clone; not growing fast.
• The watch item: The bus-factor. MIT licensing and a mature, self-contained feature set mean a fork could continue if needed, but a sudden maintainer departure would stall the project. Fine for low-stakes Kanban where you can tolerate a fork-or-migrate contingency; risky as a long-horizon organizational standard.

Vikunja — Grade B (small team, healthy trajectory)#

• Backing: Independent OSS (go-vikunja) with a small core team and a modest paid cloud to fund development. Recently migrated from self-hosted Gitea to GitHub, widening the contributor funnel.
• Funding: Cloud subscriptions + donations. Lean but real.
• Bus-factor: Small but broader than WeKan — ~195 contributors, ~528 forks, and a plugin system (2.3.0) that distributes extension work.
• Cadence: Active — reached 1.0 in Jan 2026 after 8 years, now on 2.x with regular security-fix releases and a new plugin architecture.
• Momentum: Steady, ~4.6k stars. Reaching 1.0 is a maturity signal, not a limitation.
• The watch item: Small team and modest resources cap the pace of big features (no native AI; only third-party MCP integrations). AGPL-3.0 protects the core. A solid long-term bet for the lightweight/task-management tier, with realistic expectations about feature velocity.

Focalboard — Grade D (standalone unmaintained — NOT recommended for new deployments)#

• Backing: Mattermost, Inc. — but the company discontinued standalone Focalboard. The repo split on 2024-08-28 and has sought outside maintainers since.
• Funding: None for the standalone edition. Mattermost’s investment now flows only to Mattermost Boards, an in-suite plugin (mattermost/mattermost-plugin-boards).
• Bus-factor: Effectively zero for standalone use — no active maintainer.
• Cadence: Dormant standalone since Aug 2024.
• Momentum: Negative. High historical star count (~21k) is a trailing indicator, not a live signal.
• The verdict: Do not adopt standalone Focalboard for a new self-hosted deployment. It is a viability red flag: an abandoned standalone project. The only defensible path is Mattermost Boards if you are already committed to running the full Mattermost suite for chat — and even then you are buying into Mattermost’s suite roadmap, not a dedicated PM tool. For new Kanban/Notion-style needs, WeKan, Vikunja, Plane, or Huly all supersede it.

Huly — Grade B (emerging, ambitious, hosted arm de-funded)#

• Backing: Hardcore Engineering (hcengineering / Huly Labs). Positions as an all-in-one alternative to Linear + Jira + Slack + Notion + Motion.
• Funding: Company-backed, but a caution flag surfaced in 2026: the hosted Huly cloud service is being discontinued (shutdown announced for ~July 20) because its hosting was no longer funded. Self-hosted deployments are explicitly unaffected, and the platform remains fully open source (EPL-2.0).
• Bus-factor: Company core team + large contributor base; ~26k stars, ~345 releases, daily commits — high activity.
• Cadence: Very high.
• Momentum: Strong on GitHub (second only to Plane by stars in this set), but the de-funded hosted service is a genuine commercial-health signal to weigh, not dismiss.
• The watch item: Two-sided. The engineering momentum and permissive-ish EPL-2.0 license are attractive; the hosted-service shutdown suggests the commercial side is under strain, which historically precedes either a pivot or a slowdown in company-funded OSS work. Huly is also resource-heavy to self-host (many services). Promising for teams who want a modern all-in-one and will self-host regardless of the company’s cloud fate — but track the company’s health over the next 12 months.

Leantime — Grade B (niche-differentiated, accelerator-backed)#

• Backing: Leantime (Techstars ‘23 cohort). Commercial cloud + open-source core.
• Funding: Accelerator-backed with a paid cloud/tiered pricing model funding development.
• Bus-factor: Small commercial team; ~10k stars. Contributor base smaller than the star count implies.
• Cadence: Active releases.
• Momentum: Growing on a clear differentiator — a neurodiversity-focused UX (built for ADHD/autism/dyslexia), strategy-first canvases/goals, and built-in AI assistance. This is the most distinctive positioning in the category.
• The watch item: Standard early-commercial-OSS risk (small team, monetization still maturing). AGPL-3.0 protects the core. Its differentiation is a moat and a niche — if the neurodiversity/goals angle resonates it is very sticky; if a buyer only needs generic PM, larger-community options are safer. A solid bet for teams who specifically want its goals-first / accessibility angle; otherwise evaluate against the mainstream tier.

Licensing corrections (verified July 2026)#

The S1 license table contained two errors, corrected here:

The AGPL/MPL/EPL distinction matters for lock-in and redistribution (see Part 4). MPL-2.0 (Taiga) and EPL-2.0 (Huly) are file/module-level copyleft — more permissive for embedding and modification than AGPL-3.0’s network-copyleft.

Part 2: Community-Health Comparison#

All figures approximate, mid-2026. Treat stars as a popularity proxy only.

Reading the table:

• Stars ≠ viability. Focalboard has ~21k stars and is the least viable (dormant). Redmine has ~5k stars and is among the most viable (20 years, community-governed, now modernizing). Star count captures hype and recency, not survival probability.
• The A-grades (OpenProject, Redmine) are the “boring” ones — moderate stars, high install base, funding models that don’t depend on VC runway. That is exactly the profile that survives a 5-year horizon.
• The high-star B-grades (Plane, Huly) trade momentum for monetization uncertainty. Both have strong engineering activity and copyleft cores that survive the company; both carry a company-health question.
• The C-grades (WeKan, Worklenz) share a bus-factor problem — one maintainer (WeKan) or a very young small team (Worklenz). Usable, but plan a contingency.

Part 3: Technology-Evolution Trajectories#

Where each tool is heading over the 5-year window, grouped by the category-wide currents.

Category current 1: AI-native positioning (evaluate skeptically)#

Across software in 2025-2026, PM tools are racing to attach “AI.” As with the scheduling category (see 1.096 S4), much of this is positioning layered on existing engines and should not drive selection for teams doing ordinary task/board work.

• Plane — “AI-native project management” is now its headline; AI-assisted planning/triage. Deepest AI investment among the self-hosted set.
• Leantime — built-in AI assistant tied to its behavioral-science/goals model; AI is core to the product thesis, not bolted on.
• Huly — AI transcription in its built-in video/office; AI woven through the all-in-one suite.
• OpenProject — measured, enterprise-cautious AI adoption (assistive, not central).
• Redmine, WeKan, Taiga, Worklenz, Vikunja — little-to-no native AI. Vikunja explicitly relies on third-party MCP integrations rather than shipping AI.

Category-first read: For plain PM, AI is not yet a decision axis. For teams building AI/agent-adjacent workflows or who want AI planning assistance, Plane / Leantime / Huly are the substantive options; the rest are untouched by the trend and remain correct defaults for teams that just need boards, Gantt, and tracking.

Category current 2: Modern UI / UX convergence#

The old “open source = ugly” tradeoff is closing. Trajectory:

• Modern-native: Plane, Huly (Linear/Notion-class UI is their whole pitch).
• Modernizing: Redmine (v7 header/nav redesign — the biggest UI signal in years), OpenProject (steady polish), Worklenz (modern React from birth).
• Stable/design-led: Taiga (designer-built, colorful), Vikunja (clean, multi-view).
• Functional/static: WeKan (Trello-like, unchanging by design).

Category current 3: Architecture direction#

• All-in-one consolidation: Huly (PM + chat + docs + video), Leantime (PM + strategy + docs), Plane (PM + docs + wiki) are absorbing adjacent categories.
• Modern stacks maturing: Plane (React/Django), Worklenz (React/TS/Postgres/MinIO), Vikunja (Go/Vue — the lightest footprint), Huly (service-rich, resource-heavy).
• Platform modernization: Redmine’s Rails 8 jump (v7) is the notable move — it retires the “stuck on old Rails” risk and extends the runway another cycle. Event webhooks bring it toward modern integration expectations.
• Plugin ecosystems as durability: Redmine (1000+ plugins) and Vikunja (new 2.x plugin system) distribute extension work across the community, which improves bus-factor.

5-year consolidation prediction (category-level)#

• High confidence: The all-in-one tier (Huly, Plane, Leantime) keeps absorbing docs/wiki/chat; buyers increasingly choose a suite, not a board.
• High confidence: The lightweight Kanban tier consolidates around WeKan and Vikunja; Focalboard’s standalone exit already removed one option.
• Medium confidence: Enterprise self-hosting stays anchored by OpenProject and Redmine; neither is displaced within 5 years.
• Medium confidence: At least one VC/company-backed entrant (Plane or Huly) faces a monetization inflection — a raise, a pivot, or a slowdown — within the window; the AGPL/EPL cores mean the software survives either way.

Part 4: Lock-In & Migration#

Self-hosting already eliminates the biggest SaaS lock-in vectors — you own the database, the host, and the upgrade schedule. The residual lock-in is data-model and export-format lock-in: how hard is it to leave tool A for tool B.

Data portability by tool#

Lock-in findings:

• No true standard exists. There is no interchange format for PM data equivalent to iCal for calendars. Every migration is a mapping exercise (statuses, custom fields, attachments, comments, time entries rarely survive cleanly).
• The universal escape hatch is the database + REST API. Because all ten are self-hosted open source, worst case you script an ETL against the API or query the DB directly. This is the single biggest advantage over SaaS: your data can never be held hostage behind a paywall or an account suspension.
• Best portability: Vikunja (broad import set incl. WeKan/Trello/Todoist + full export) and WeKan (clean board JSON, Trello-compatible) — the lightweight tier is the easiest to enter and exit. OpenProject and Redmine have mature exporters suited to enterprise migration.
• License and lock-in: AGPL-3.0 (Plane, Vikunja, Worklenz, Leantime, and Taiga’s classic self-hosted stack; Taiga Next is MPL-2.0, Huly is EPL-2.0) guarantees you can always self-modify and self-host the core; no tool in this set can “pull an Atlassian” and strand you on-prem. This is a structural anti-lock-in property of the whole category.

Migration-cost reality#

• Lightweight ↔ lightweight (WeKan ↔ Vikunja, Trello → either): low cost, often importer-supported.
• Into enterprise (anything → OpenProject/Redmine): medium — importers exist but custom fields/workflows need remapping.
• Between all-in-ones (Plane ↔ Huly ↔ Leantime): high — each has a bespoke data model spanning PM + docs + more; expect API-scripted ETL.
• Rule of thumb: budget migration effort proportional to how much of the adjacent surface (docs, wiki, chat, time tracking) you used, not to the task count.

Part 5: Build-vs-Buy and Self-Host-vs-SaaS#

The three real options#

For any PM need there are three strategic paths, not two:

1. Buy SaaS (Jira, Linear, Asana, Monday, ClickUp, Trello) — vendor runs it.
2. Self-host open source (this survey) — you run someone else’s software.
3. Build in-house — you write it.

Build (#3) is almost never correct for PM. PM is a solved, deeply commoditized problem with ten viable free implementations. Building your own means re-implementing boards, Gantt, permissions, notifications, and mobile — years of work to reach parity with tools you can docker compose up today. Build only if PM is your actual product, or you have a workflow so idiosyncratic that even forking an AGPL codebase (the cheaper “build”) can’t reach it. For everyone else the decision collapses to #1 vs #2.

Self-host vs SaaS: the decision axes#

The cost crossover is the decision’s center of gravity: SaaS is linear in seats (~$5-16/user/month), self-hosting is roughly flat in infrastructure ($10-200/month) plus maintenance labor. The breakeven lands around 5-20 users depending on the tool’s weight and whether ops labor is staff time (near-zero marginal) or outsourced (which pushes the crossover to 15-30 users). Below the crossover, SaaS usually wins on total cost and convenience; above it, self-hosting’s flat curve compounds in your favor every year.

Architecture decision tree#

START: Do you need project management for a team you control?
│
├─ Is PM your actual product, or is your workflow un-implementable in any of 10 tools?
│   └─ YES → BUILD (or fork an AGPL tool). Rare. Stop here only after proving no tool fits.
│   └─ NO  → continue
│
├─ Do you have (or will you build) basic Docker/Linux ops capability?
│   └─ NO  → Strongly consider SaaS, OR a managed-hosting provider for one of these tools.
│            (Self-hosting without ops = hidden cost + reliability risk.)
│   └─ YES → continue
│
├─ Hard requirement: data sovereignty / compliance / air-gap / lock-in immunity?
│   └─ YES → SELF-HOST (this survey). Continue to tool selection.
│   └─ NO  → Is your seat count above the ~5-20 user cost crossover?
│             ├─ NO  → SaaS is likely cheaper & simpler. Revisit at scale.
│             └─ YES → SELF-HOST pays off. Continue to tool selection.
│
└─ TOOL SELECTION (self-host path) — pick by dominant constraint:
    │
    ├─ Need Gantt + mixed methodology + compliance + support contract?
    │      → OpenProject (A)   [enterprise anchor]
    │
    ├─ Need deep customization / 1000+ plugins / have Rails skills?
    │      → Redmine (A)       [most durable, now modernized]
    │
    ├─ Want modern Linear/Jira-class UX for a dev team, accept Seed-stage vendor?
    │      → Plane (B)         [momentum leader, AGPL floor]
    │
    ├─ Want an all-in-one suite (PM+docs+chat/video)?
    │      → Huly (B)  or  Leantime (B, if goals/neurodiversity angle fits)
    │
    ├─ Pure agile team, value 11-yr stability over novelty?
    │      → Taiga (B)
    │
    ├─ Lightweight tasks/personal→small team, minimal footprint?
    │      → Vikunja (B)       [best portability, runs on a Pi]
    │
    ├─ Just need self-hosted Trello / simple Kanban?
    │      → WeKan (C)         [accept single-maintainer risk]
    │
    ├─ Young team OK with early-stage risk, want modern stack?
    │      → Worklenz (C)
    │
    └─ Already all-in on the Mattermost suite and only need boards?
           → Mattermost Boards plugin (NOT standalone Focalboard — D)

Part 6: Total Cost of Ownership by Scale#

TCO = infrastructure + maintenance labor + migration/setup. The dominant variable is labor, not hosting. Figures below are annualized, approximate, and assume DIY ops (staff time). If ops is outsourced at ~$125/hr, add setup + maintenance hours accordingly.

Small team (3-10 users)#

At this scale, lightweight self-hosting beats SaaS on cash cost almost immediately (infra < $250/yr vs $600+ SaaS), but only if you value your ops hours near zero. If ops is outsourced, SaaS often wins below ~10 users. Category read: small teams should either run a lightweight tool (Vikunja/WeKan) themselves, or stay on SaaS — the enterprise tier is over-built here.

Department (10-50 users)#

This is the self-hosting sweet spot. The cost crossover is firmly behind you: flat infra

• part-time ops undercuts linear SaaS seat pricing, and the gap widens every year. Huly is the resource outlier (many services → higher infra). OpenProject/Redmine cost more in labor but deliver enterprise features SaaS would also charge premium tiers for.

Organization (50-500+ users)#

At org scale the math overwhelmingly favors self-hosting on cash — a DevOps fraction-to-FTE plus infra is dwarfed by six-figure SaaS seat bills. The real cost is organizational: you’re taking on uptime, security patching, backups, and DR. Only OpenProject and Redmine are credible here; the lightweight and young-vendor tiers are not built for this scale. Category read: at 50+ seats, self-hosting OpenProject or Redmine is the default rational choice if and only if you can staff the ops function; if you can’t, a support contract (OpenProject Enterprise) or SaaS buys that capability.

TCO principle#

The infrastructure line is almost never what matters — labor and organizational risk- appetite dominate. A $10/month VPS running Vikunja and a $1,000/month HA OpenProject cluster both live or die on whether someone competent keeps them patched and backed up. Choose the tool whose operational weight matches your operational capability, then let the flat-vs-linear cost curve reward you at scale.

Part 7: Strategic Recommendations (Category-First)#

No single winner. The category sorts into safe long-term bets and higher-risk / contingency-planned options, organized by reader profile. A tool’s grade (Part 1) is the viability floor; the profile determines fit.

Safest 5-year bets (lowest viability risk)#

• OpenProject (A) and Redmine (A) are the two lowest-risk “will it still exist and be maintained in 2031?” choices. Both survive on models that don’t depend on VC runway (dual-license company; community + plugin-vendor ecosystem). Choose these when the 5-year commitment itself is the priority — enterprise, compliance, multi-project portfolios, or any deployment you don’t want to re-platform. Redmine’s v7/Rails 8 jump removes its old “legacy” caveat; OpenProject adds a buyable support contract.

Strong bets with one tracked risk#

• Plane (B) — the momentum and UX leader; adopt it when modern developer-facing UX matters, treating the AGPL core as your floor if the Seed-stage company stumbles. Track its next raise.
• Vikunja (B) — the safest lightweight bet: 1.0-mature, best-in-class portability, tiny footprint. Adopt for personal→small-team task management with realistic feature- velocity expectations.
• Taiga (B) — the safest agile-only bet: 11 years under a stable self-funded studio. Adopt when you value durability over novelty and don’t need waterfall/Gantt.
• Huly (B) and Leantime (B) — the emerging all-in-one bets. Huly for a modern Linear/Notion-class suite you’ll self-host regardless of its cloud fate (watch company health after the hosted-service shutdown; budget for its heavier footprint). Leantime when its goals-first / neurodiversity / built-in-AI differentiation is specifically what you want.

Higher-risk — usable with a contingency plan#

• WeKan (C) — excellent, active Trello replacement, but a single-maintainer bus-factor. Fine for low-stakes Kanban; keep a fork-or-migrate plan (MIT license + clean exports make this feasible) before making it an org-wide standard.
• Worklenz (C) — modern and promising but young and thinly backed. Suitable for small teams accepting early-stage risk; not for mission-critical use yet.

Not recommended for new deployments#

• Focalboard (D) — standalone is unmaintained since Aug 2024. Do not adopt it fresh. The only defensible path is Mattermost Boards inside a Mattermost suite you’re already running; for standalone needs, WeKan / Vikunja / Plane / Huly all supersede it.

The three durable category-level insights#

1. Self-hosting is structural lock-in immunity. Every tool here is AGPL/GPL/MPL/EPL open source with an owned database and REST API. No vendor in this set can strand you on-prem or paywall your data — the defining advantage over SaaS, and the reason the whole category is a rational hedge post-Atlassian-pricing-shock.

2. Match operational weight to operational capability, not features to wishes. The commonest self-hosting failure is adopting OpenProject/Redmine/Huly without the ops function to run them — or, conversely, forcing a lightweight tool to do enterprise portfolio work. Grade fit on who will keep it patched and backed up, then on features.

3. Momentum and viability are different axes — weight them by horizon. For a 5-year commitment, the “boring” A-grades (OpenProject, Redmine) beat the high-star B-grades (Plane, Huly) on survival probability, even though the latter win on UX and buzz. For a 1-2 year horizon where re-platforming is acceptable, the momentum leaders are fine — their AGPL/EPL cores are a floor either way. Choose by how long you intend to stay.

Time Invested: ~3 hours Analysis Methods: Repository/community metrics review, funding/backing verification (web, July 2026), license verification, cross-reference with S1/S3 and 1.096 S4 methodology Confidence Level: Medium-High — viability grades grounded in verified backing/cadence/bus-factor; star counts and TCO figures are approximate and dated mid-2026 Key Strategic Insight: In self-hosted PM, choosing a tool is choosing an operational-weight and viability profile, not a feature set. Over a 5-year horizon, community-governed and dual-license anchors (Redmine, OpenProject) are the safest survival bets, the copyleft cores of the VC/company-backed momentum leaders (Plane, Huly) make them safe-enough despite monetization uncertainty, and only Focalboard’s dormant standalone is disqualifying — because the category’s shared AGPL/GPL/MPL/EPL foundation makes lock-in, not longevity, the problem self-hosting already solves.

S4 Status: ✅ Complete Last Updated: July 2, 2026