Why Windshift is open source
The AGPL codebase keeps the core product available, while plugins give teams a maintainable place for local extensions.
A work management system becomes part of a company's operations. Replacing one means more than moving records: teams must rebuild reports and integrations, verify permissions, retrain users, and revise established processes.
Jira Server customers faced that cost when Atlassian discontinued its on-premise product line. Some moved to Cloud, some paid for Data Center, and others rebuilt their setup around a decision they did not make.
Windshift is open source so customers retain another option. If our direction, pricing, or release schedule no longer works for a team, the core product remains available to run and maintain.
The AGPL keeps the core available
Windshift's core is licensed under AGPL v3. Our contributor agreement keeps contributed code available under the same license, so future community work cannot quietly turn the shared codebase into a private asset.
This gives customers practical rights:
A public API is not always enough
Most work management concepts are common: items, boards, workflows, permissions, milestones, and comments. The rules around them quickly become specific to a company.
One team needs a release check tied to a contract. Another needs an internal CRM attached to customer requests. A third has a branch naming policy or approved language for weekly status notes. Vendors cannot build every local rule into the core product.
Plugins keep local changes out of the core
Some core changes justify a fork, but most extensions should remain separate. Windshift plugins provide that boundary while allowing the main installation to stay close to upstream releases.
Plugins run as WebAssembly modules through Extism. A package contains a `manifest.json`, a `plugin.wasm` entry point, and optional static UI files. Windshift loads it at startup and applies default limits of five seconds and 64 MB of memory.
Coding agents work better from source
Source and plugin documentation also give coding agents better context. An agent can trace a host function, adapt an example, or draft a small plugin using the product's actual structures. A developer can then review a focused change through the normal pull request process.
Closed products confine agents to public APIs, SDKs, and assumptions. That may be enough for a simple integration, but it is weaker when a change depends on internal product behavior.