GO — Healthy across the board

• Last commit 3d ago
• 32+ active contributors
• Distributed ownership (top contributor 31% of recent commits)
• Other licensed
• CI configured
• Tests present
• ⚠ Non-standard license (Other) — review terms
• ⚠ Scorecard: default branch unprotected (0/10)

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests + OpenSSF Scorecard}

Focalboard is an open-source, self-hosted project management and kanban board application built with TypeScript (2.2M lines) on the frontend and Go (1.7M lines) on the backend. It provides a Trello/Notion/Asana alternative with real-time board collaboration, supporting Personal Desktop (macOS/Windows/Linux) and Personal Server editions for team use. Monorepo structure: TypeScript/React frontend under webapp/ (likely); Go backend under server/; Docker configurations in docker/ and docker-testing/ for multiple databases (MySQL, PostgreSQL, MariaDB); CI/CD workflows in .github/workflows/ (ci.yml, codeql-analysis.yml, prod-release.yml); documentation in docs/ including dev-guide, contribution guidelines.

Development teams and individuals who need self-hosted project management without vendor lock-in; DevOps engineers deploying via Docker; contributors to open-source project management tools; organizations requiring data sovereignty over kanban/database tools.

⚠️ UNMAINTAINED: The repository explicitly states 'This repository is currently not maintained' (see WARNING in README). While it has CI/CD pipelines (workflows in .github/workflows/), Docker support, and was previously mature, active development has stopped and maintainer involvement is needed. High risk for production use.

CRITICAL: Repository is officially unmaintained with no active maintainer. No recent commit data provided, but the maintenance notice and call for new maintainers (issue #5038) signals abandonment risk. Large TypeScript/Go codebases need ongoing dependency updates. The standalone Focalboard and plugin versions (mattermost-plugin-boards) have diverged, creating confusion. No test file metrics visible in top 60 structure suggests testing coverage may be incomplete.

No active development; repository awaiting new maintainers. Last signals: release workflows exist (dev-release.yml, prod-release.yml), CodeQL security analysis enabled, Dependabot configured for dependency updates (.github/dependabot.yml), but no evidence of recent commits or merged PRs from provided data.

git clone https://github.com/mattermost-community/focalboard.git
cd focalboard
make build  # See Makefile for targets
# For development setup, consult docs/focalboard-dev-guide.md

Daily commands: For Personal Server development: Follow docs/focalboard-dev-guide.md. For web extension: npm run watchdev then npm run servedev (from experiments/webext/package.json). Full server: make build (see Makefile for platform-specific targets). Docker: docker-compose up using files in docker/ or docker-testing/.

• README.md — Primary entry point explaining Focalboard's purpose, editions, and current maintenance status—essential context for all contributors.
• Makefile — Orchestrates the full build pipeline for server, web, and desktop targets—every developer must understand the build workflow.
• .github/workflows/ci.yml — Defines CI/CD pipeline validation rules and testing gates that all PRs must pass before merge.
• CONTRIBUTING.md — Establishes contribution guidelines, code review standards, and developer responsibilities.
• docs/focalboard-dev-guide.md — Comprehensive developer guide covering architecture, local setup, and development workflows across all components.
• docker/docker-compose.yml — Primary local development environment stack definition—required for spinning up a working instance.
• app-config.json — Central configuration schema for server and application settings—essential for understanding runtime configuration.

• Server (Go) (Go, database drivers, REST framework) — Receives API requests, enforces permissions, persists data to database, handles migrations and multi-user board operations.
  • Failure mode: API unavailable; users cannot read/write boards; database locks block concurrent requests.
• Web Frontend (React/TypeScript) (React 17, TypeScript, bundled by Parcel) — Renders board UI, manages local state, dispatches API calls, handles user interactions and form validation.
  • Failure mode: UI freezes or fails to load; user input lost if not persisted; broken API integration prevents data sync.
• Database (PostgreSQL/MySQL/MariaDB) (PostgreSQL, MySQL, MariaDB) — Stores boards, cards, comments, attachments, user accounts; enforces schema consistency and transactional integrity.
  • Failure mode: Data corruption on unclean shutdown; concurrent writes conflict; locked tables halt server operations.
• Import Tools (Asana, Jira, Nextcloud Deck) (TypeScript, XML/JSON parsing, HTTP clients) — Extract data from third-party systems, transform to Focalboard schema, create boards/cards via API or direct DB inserts.
  • Failure mode: Partial import if source API times out; data loss if transformation logic fails; unmapped fields silently dropped.
• Browser Extension (Experimental) — Captures webpage

Add a new import source (e.g., Monday.com)

1. Create new directory under import/ with importer module structure (import/asana)
2. Implement data transformer class following pattern in import/asana/importAsana.ts (import/asana/importAsana.ts)
3. Add utility functions for API authentication and data extraction in utils.ts (import/asana/utils.ts)
4. Register new importer in main Makefile import build target and CI (Makefile)

Add a new Browser extension feature

1. Create new React component in experiments/webext/src/views/ (experiments/webext/src/views/OptionsApp.tsx)
2. Update manifest.json with new permissions or content scripts if needed (experiments/webext/manifest.json)
3. Implement API calls using networking layer pattern in src/utils/ (experiments/webext/src/utils/networking.ts)
4. Build with 'npm run watchdev' and test with 'npm run servedev' in experiments/webext/ (experiments/webext/package.json)

Modify Docker deployment configuration

1. Edit primary docker-compose file for local or production service setup (docker/docker-compose.yml)
2. Update server config file if new environment variables or database settings needed (docker/server_config.json)
3. If base image or build steps change, modify Dockerfile (docker/Dockerfile)
4. Test with 'make docker-compose-up' or similar Makefile target (Makefile)

• React + TypeScript (Web & Web Extension) — Type-safe component-driven UI development; Parcel bundler handles web extension packaging natively.
• Docker Compose (Local Development) — Eliminates host-machine setup variance; multi-service orchestration (server, database, optional reverse proxy) in single file.
• Makefile (Build Orchestration) — Platform-agnostic task runner; coordinates server, web, desktop, and import tool builds from single entry point.
• PostgreSQL/MySQL/MariaDB Support — Pluggable database backend allows deployment flexibility; docker-testing includes all variants for CI validation.

• Modular import tools (Asana, Jira, Nextcloud Deck) vs. unified importer framework

  • Why: Each source has unique data schemas and authentication flows; separate packages reduce tight coupling.
  • Consequence: Higher maintenance burden per importer; must ensure consistent transformation logic across multiple implementations.

• Browser extension in experiments/ (not core)

  • Why: Web clipper is experimental; kept separate to avoid production bloat and allow parallel development.
  • Consequence: Extension must independently manage auth, API versioning, and error handling; potential feature drift from core API.

• JSON config files (app-config.json, config.json, server_config.json) vs. environment-only config

  • Why: Supports both file-based and env-var overrides; simplifies Docker Compose and single-binary deployment.
  • Consequence: Multiple config sources can create precedence confusion; docs must clearly specify override order.

• Repository currently unmaintained (per README warning)

  • Why: Mattermost shifted focus to mattermost-plugin-boards; standalone version frozen.
  • Consequence: Community contributors must manage own upgrades and bug fixes; no official security patches expected.

• Real-time multi-user collaboration (WebSocket sync not in scope)
• Mobile native app (web-only or web extension focus)
• Enterprise authentication (SAML, OAuth2 delegated auth beyond basic server setup)
• Financial/billing features (open-source project management only)

1. Repository Status: Must recognize this is unmaintained; PRs unlikely to merge. 2. Plugin vs Standalone: mattermost-plugin-boards (separate repo) is actively maintained; standalone Focalboard is not—users often confused. 3. Database Initialization: Docker-testing configs suggest database migrations required; check server startup for DB setup requirements. 4. Multi-DB Support: Code supports MySQL, PostgreSQL, MariaDB; SQL dialect differences may hide in server code. 5. Environment Variables: docker/server_config.json vs config.json distinction unclear without deeper inspection—verify which env vars override which config file. 6. Desktop App Distribution: Separate build pipelines for Windows (.exe), macOS (.app), Linux (.tar.gz); release workflow in prod-release.yml may require manual steps.

• CRDT (Conflict-free Replicated Data Type) — Real-time collaborative board features likely use CRDTs to sync card/board state across clients without central coordination; critical for multi-user kanban boards
• Server-Sent Events (SSE) — Likely used for real-time board updates from server to clients; alternative to WebSocket for push notifications
• REST API Versioning & Swagger/OpenAPI — Focalboard exposes Swagger docs (server/swagger/docs/html/index.html); understanding API contract versioning is essential for backend changes
• Docker Multi-Stage Builds & Database Agnosticism — Multiple Dockerfile targets and docker-compose variants (MySQL/PostgreSQL/MariaDB) require understanding abstraction layers in ORM/query builders
• Electron / Desktop App Packaging — Personal Desktop edition requires understanding cross-platform packaging (macOS .app, Windows .exe, Linux .tar.gz); separate build pipelines in CI/CD
• React Component State Management (likely Redux or Context API) — Frontend uses TypeScript + React; board state, undo/redo, real-time sync likely managed via Redux or Context; critical for UI modifications
• Go Goroutines & Channels for Concurrency — Backend handles concurrent requests from multiple clients; Go's goroutine model powers real-time features and is fundamental to scaling

• mattermost/mattermost-plugin-boards — Active successor to standalone Focalboard; provides kanban/board features as Mattermost plugin instead of standalone server
• openproject/openproject — Alternative open-source project management tool with Gantt charts, time tracking; solves same PM problem with different UX
• wekan/wekan — Actively maintained open-source Trello alternative with real-time collaboration; closest competitor in same ecosystem
• mattermost/mattermost-server — Parent organization; Focalboard was designed to integrate with Mattermost as a companion collaboration tool
• jira-opensource/openmtbmap — Not directly related but represents the OSS project management tool ecosystem (example of alternatives)

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for web extension build pipeline

The experiments/webext directory contains a Parcel-based web extension project with build scripts (watchdev, servedev, build) but no corresponding CI workflow or integration tests. The main CI pipeline (.github/workflows/ci.yml) likely doesn't validate that the web extension builds successfully or that its dependencies remain compatible. This is critical since the extension has external dependencies (parcel, web-ext, react) that could break silently.

• [ ] Create .github/workflows/webext-build.yml to run npm install && npm run build in experiments/webext/
• [ ] Add linting step for TypeScript files in experiments/webext/src/ (add eslint config if missing)
• [ ] Add test for manifest.json validation using web-ext lint command
• [ ] Document the web extension build process in docs/focalboard-dev-guide.md with setup instructions

Add unit tests for experiments/webext/src/utils/ modules

The web extension contains three utility modules (Board.ts, networking.ts, settings.ts) with no apparent test coverage. These utilities handle critical functionality (board data manipulation, API communication, extension settings) and lack test files. New contributors can add Jest/Vitest configuration and tests without requiring deep system knowledge.

• [ ] Add jest or vitest configuration to experiments/webext/package.json with typescript support
• [ ] Create experiments/webext/src/utils/tests/Board.test.ts covering Board utility functions
• [ ] Create experiments/webext/src/utils/tests/networking.test.ts with mocked fetch calls
• [ ] Create experiments/webext/src/utils/tests/settings.test.ts for localStorage/settings operations
• [ ] Add test script to package.json and integrate into CI workflow

Add development setup documentation for web extension

The README.md snippet shows the repo is currently unmaintained and contributors may not understand how to develop the web extension locally. The experiments/webext/README.md exists but the root docs/ folder has no specific guide for extension development. This blocks new contributors and increases friction.

• [ ] Create docs/webext-dev-guide.md covering: installation of web-ext globally, running watchdev vs servedev, browser testing with Firefox/Chrome, debugging in browser DevTools
• [ ] Document the manifest.json targets and build output structure (dist/dev vs dist/prod)
• [ ] Add troubleshooting section for common Parcel/web-ext issues (e.g., unsigned extension warnings)
• [ ] Link this new guide from docs/focalboard-dev-guide.md and update experiments/webext/README.md with reference to root docs

• Add missing unit tests for TypeScript utilities in webapp/src/ (if test coverage <80%). Start by identifying untested utility files and adding Jest/Mocha tests following existing patterns.: Large TS codebase (2.2M lines) likely has coverage gaps; testing non-UI utilities is low-risk and high-value.
• Document database migration process and schema in docs/. Create a new file docs/database-migrations.md explaining how to run migrations, supported databases, and schema versioning.: Docker-testing has 3+ DB variants; no visible migration docs; critical for self-hosted deployments.
• Add missing CodeQL queries or GitHub security advisories for Go dependencies in server/. Verify all indirect dependencies are scanned in .github/codeql/codeql-config.yml.: 1.7M lines of Go; unmaintained repos need extra security scrutiny; low-barrier way to improve security posture.

The Focalboard codebase has moderate security concerns. The most critical issue is that the repository is unmaintained, creating a significant risk for security vulnerabilities not being patched. Additionally, the web extension components use outdated dependencies with potential security vulnerabilities. The presence of multiple hardcoded configuration files and lack of visible security header implementation further weaken the security posture. Positive aspects include the presence of CodeQL analysis and Dependabot configuration in CI/CD. Immediate actions should focus on: (1) resolving maintenance status, (2) updating dependencies and running security audits, (3) implementing environment-based configuration management, and (4

• High · Repository Maintenance Status — README.md. The repository is explicitly marked as 'currently not maintained' in the README. This means security patches and vulnerability fixes may not be applied in a timely manner, leaving the codebase potentially exposed to known security issues. Fix: Either resume active maintenance of the repository or migrate to the actively maintained Mattermost plugin version (mattermost-plugin-boards). Establish a clear maintenance schedule if continuing with this repository.
• High · Outdated Dependencies in Web Extension — experiments/webext/package.json. The web extension package.json contains outdated dependencies with potential security vulnerabilities: React 17.0.2, TypeScript 4.4.4, and Parcel 2.0.0 are significantly outdated. These versions may contain known CVEs and lack security patches. Fix: Update all dependencies to their latest stable versions. Specifically: React to ^18.x, TypeScript to ^5.x, Parcel to latest 2.x or 3.x, and other dev dependencies. Run security audit with 'npm audit' and address identified vulnerabilities.
• Medium · Missing npm Audit Configuration — experiments/webext/. No evidence of npm audit setup or dependency vulnerability scanning in the build pipeline for the web extension component. The package-lock.json files may contain vulnerable transitive dependencies that are not being monitored. Fix: Add npm audit to CI/CD pipeline in GitHub workflows. Configure automated dependency updates using Dependabot (already present in .github/dependabot.yml but verify it covers all package.json files). Set up regular security scanning.
• Medium · Potential XSS Risk in Web Extension — experiments/webext/manifest.json. Web extensions handle user input and DOM manipulation. The presence of React without explicit Content Security Policy configuration in manifest.json could increase XSS attack surface. Fix: Implement strict Content Security Policy (CSP) headers in the manifest.json. Audit React components in PopupApp.tsx and OptionsApp.tsx for unsafe innerHTML usage. Use React's built-in XSS protection by avoiding dangerouslySetInnerHTML.
• Medium · Hardcoded Configuration Files — app-config.json, config.json, docker/config.json, docker/server_config.json. Multiple hardcoded configuration files present (app-config.json, config.json, docker/config.json, docker/server_config.json). These may contain sensitive configuration or be committed with default/insecure values. Fix: Move sensitive configuration to environment variables or secure vaults. Use .example files for templates. Implement config validation to ensure required security settings are present. Add config files to .gitignore if they contain secrets.
• Low · Missing Security Headers Documentation — docker/Dockerfile, docker/docker-compose.yml. No explicit documentation or configuration visible for implementing security headers (Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, etc.) in the application. Fix: Document and implement recommended security headers. Configure reverse proxy (nginx shown in docker-compose) with proper security headers. Add HSTS, CSP, and other recommended headers to the deployment configuration.
• Low · Unverified Third-party Import Tools — import/asana/asana.ts, import/asana/importAsana.ts. Import utilities for Asana and other services are present (import/asana/) but their security review status is unclear. These handle external data and authentication. Fix: Conduct security review of import modules, especially around authentication handling. Implement input validation for imported data. Document any external API dependencies and their security posture. Ensure no credentials are hardcoded.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/mattermost-community/focalboard shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live mattermost-community/focalboard repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/mattermost-community/focalboard.

What it runs against: a local clone of mattermost-community/focalboard — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in mattermost-community/focalboard | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 33 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of mattermost-community/focalboard. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/mattermost-community/focalboard.git
#   cd focalboard
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of mattermost-community/focalboard and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "mattermost-community/focalboard(\\.git)?\\b" \\
  && ok "origin remote is mattermost-community/focalboard" \\
  || miss "origin remote is not mattermost-community/focalboard (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "Makefile" \\
  && ok "Makefile" \\
  || miss "missing critical file: Makefile"
test -f ".github/workflows/ci.yml" \\
  && ok ".github/workflows/ci.yml" \\
  || miss "missing critical file: .github/workflows/ci.yml"
test -f "CONTRIBUTING.md" \\
  && ok "CONTRIBUTING.md" \\
  || miss "missing critical file: CONTRIBUTING.md"
test -f "docs/focalboard-dev-guide.md" \\
  && ok "docs/focalboard-dev-guide.md" \\
  || miss "missing critical file: docs/focalboard-dev-guide.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 33 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~3d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/mattermost-community/focalboard"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.