Skip to content

Kanban OSS Trade-Off Analysis

This document evaluates the open-source Kanban options for the Pebble Business Orchestrator, with a focus on licensing implications for SaaS strategy.

Executive Summary

Criteria Plane.so Focalboard Wekan
License AGPL-3.0 AGPL-3.0 (Focalboard) / MIT (standalone) MIT
UI Quality Linear-grade Notion-grade Trello-grade
API Access Full REST API Limited Limited
SaaS Risk HIGH MEDIUM LOW

[!WARNING] AGPL-3.0 License Implication: If Pebble Orchestrator is offered as a SaaS to external customers, the entire connected codebase (including our custom API bridge) may be subject to source code disclosure requirements.

AGPL-3.0 License: SaaS Implications

What AGPL Requires

The GNU Affero General Public License v3.0 closes the "SaaS loophole" in standard GPL:

Trigger Requirement
Network Interaction If users interact with Plane.so over a network (including via Pebble's UI), they have the right to request the source code.
Modifications Any modifications to Plane's codebase MUST be released under AGPL.
Derivative Works If your code is tightly coupled with AGPL code (e.g., shared database, direct API calls from same process), it MAY be considered a derivative work.

Impact on Pebble SaaS Strategy

Scenario Impact
Internal Use Only NO IMPACT. AGPL only triggers on network access by external users.
Self-Hosted for Client LOW RISK. Client hosts Plane; we provide integration code separately.
Pebble-Hosted SaaS HIGH RISK. Users interacting with Plane via Pebble's UI may trigger source disclosure for our entire stack.

Mitigation Strategies

  1. Strict API Isolation: Keep Pebble backend as a separate service communicating with Plane only via REST API. This maintains "separate programs" status.
  2. No Plane Code Modification: Use Plane as-is. All customization via API + webhooks. Avoids derivative work classification.
  3. Commercial License: Contact Plane.so for a commercial license that removes AGPL obligations (if available).
  4. Alternative OSS Selection: Switch to MIT-licensed Wekan (lower risk, lower quality).

Plane.so API Accessibility

Confirmed: Full REST API in Community Edition

API Feature OSS Availability
POST /issues (Create card) YES
PATCH /issues/{id} (Update) YES
Webhooks (issue.updated) YES
Custom Labels YES
Custom Fields YES (Enterprise feature)
API Key Auth YES

Source: Plane API Docs - API is available for both Cloud and Self-Hosted.

API Limitations

Feature OSS Availability Workaround
Custom Fields ❌ Enterprise Only Use Labels + Description JSON
Rate Limits Not documented Likely none for self-hosted
Endpoint Deprecation /issues/ → /work-items/ by March 2026 Plan migration

[!WARNING] Custom Fields Not Available in OSS: The Community Edition does not support custom fields on issues. To store AI classification metadata (stream, intent, entity_id), use: 1. Labels: Create labels like Stream:CRM, Intent:Enquiry, Priority:High 2. Description JSON: Embed a JSON block at the end of the issue description for structured metadata

Alternative: MIT-Licensed Options

Option A: Wekan (MIT)

Pros Cons
MIT license = No SaaS source disclosure UI is dated (Trello 2015)
Fully self-hosted Limited API documentation
Mature and stable No native webhooks (needs extension)

Option B: Custom React Board

Pros Cons
Full control, no license risk 4-6 weeks additional dev time
Tailored to Pebble UX Maintenance burden

Option C: Plane.so with Commercial License

Pros Cons
Best-in-class UI Commercial license cost (TBD)
Full API access Vendor dependency
No source disclosure Negotiation required

Recommendation

For POC (Internal Use Only)

Proceed with Plane.so. AGPL does not apply to internal tools.

For Production SaaS

Evaluate two paths:

  1. Path A (Low Risk): Use Wekan (MIT) or build custom React Kanban (4-6 weeks).
  2. Path B (Commercial): Contact Plane.so for commercial licensing terms before going live.

[!IMPORTANT] Action Required: Before any external SaaS rollout, get legal review of AGPL compliance strategy.

References