Kanban OSS Trade-Off Analysis
This document evaluates the open-source Kanban options for the Pebble Orchestrator (Pebble IQ), 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 (Pebble IQ) 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
- Strict API Isolation: Keep Pebble backend as a separate service communicating with Plane only via REST API. This maintains "separate programs" status.
- No Plane Code Modification: Use Plane as-is. All customization via API + webhooks. Avoids derivative work classification.
- Commercial License: Contact Plane.so for a commercial license that removes AGPL obligations (if available).
- Alternative OSS Selection: Switch to MIT-licensed Wekan (lower risk, lower quality).
Plane.so API Accessibility
| 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 |
Final Strategy: Enhanced Plane.so (Hybrid)
- For the POC, we will implement the Enhanced Plane.so model.
- Why this path:
- Speed: Leverages a robust, battle-tested Kanban interface immediately.
- Industrial Depth: Accomplished via AI-driven Labels on Plane cards and Direct Deep Links to specialized Pebble CRM Sidecar screens.
- License Mitigation: AGPL-3.0 is mitigated by maintaining Strict API Isolation. The Pebble backend is a separate service; it communicates with Plane only via standard REST/JSON transactions.
[!IMPORTANT]
Implementation Rule: Do NOT fork or modify the Plane.so codebase. All customizations must be via API, Webhooks, and Metadata (Labels/Descriptions) to ensure easy upgrades and zero "derivative work" license triggers.
Service Interaction & API Flow
To maintain strict license isolation and industrial performance, the interaction is brokered by the Pebble Backend.
Transaction Sequence:
- Trigger: User drags a card from
New to Qualified on the Visual Kanban (Plane UI).
- Event: Plane.so emits a
Webhook (issue.updated) to the Pebble Backend.
- Logic Engine: Pebble Backend intercepts the webhook and triggers the CRM State Machine:
- Validates presence of mandatory fields (CIN/PAN).
- Calls government verification APIs (GST/MCA).
- If valid, promotes record from
Prelead to Prospect.
- Feedback Loop: Pebble Backend calls Plane REST API to update the card labels (e.g., adds
[Verified] label) or post an internal system comment.
- Deep Link: If further industrial data is needed (e.g., Costing), the user clicks a Deep Link on the Plane card which opens the Pebble CRM Sidecar (a native React screen).
API Call Map:
| Flow |
Source |
Destination |
Protocol |
Purpose |
| User Action |
Pebble UI / Plane UI |
Pebble Backend |
REST |
Trigger Business Logic |
| State Sync |
Plane.so |
Pebble Backend |
Webhook |
Event Notification |
| Logic Update |
Pebble Backend |
Plane.so |
REST |
Update Card Data/Labels |
| Sidecar Load |
Pebble UI |
Pebble Backend |
REST |
Fetch CRM/Master Data |
[!TIP]
No Direct Client-Side Sync: The CRM Client (UI) does NOT directly invoke the Kanban API. All interactions are proxied through the Pebble Backend to enforce RBAC and maintain a clean audit log.
References