Why Windshift is open source
Windshift is open source because customers should not lose their work platform when a vendor changes direction. The AGPL codebase stays available, and the plugin system gives teams a practical way to adapt it.
A work management system is a long-term bet. Teams put plans, customer requests, delivery history, test results, time entries, and internal process into it. Over time, the tool becomes part of how a company operates. Replacing it means more than moving records between databases. It means retraining people, rebuilding reports, testing integrations, checking permissions, and explaining the change to everyone who depended on the old system.
Many Jira Server customers went through that when Atlassian discontinued its on-prem product line. The decision made business sense for Atlassian, but customers had to carry the cost. Some moved to Cloud. Some paid for Data Center. Some spent months reviewing apps, rebuilding workflows, and changing deployment plans because a vendor policy changed above them.
Windshift is open source because we do not want our customers exposed to that kind of dependency. If we change direction, customers still have the code. If a commercial plan no longer fits, customers still have the code. If a team needs to maintain an older version while it plans an upgrade, customers still have the code.
Self-hosting needs source access
Self-hosting gives teams control over data, infrastructure, network boundaries, backups, and upgrade timing. Those are valuable, but they are incomplete if the vendor can later remove the product path that made self-hosting possible.
A downloadable binary helps a team get started. Public source gives the team a way to keep going. The AGPL gives everyone the right to inspect, modify, and share the code under the same license. Our contributor agreement keeps that right attached to future contributions, so the shared codebase does not drift into a private asset over time.
Open source also changes customization
Every work management product starts with common concepts: items, boards, backlogs, milestones, workflows, permissions, reports, and comments. The details become local very quickly. One company has a release review rule tied to a customer contract. Another has a branch naming policy. Another has an internal CRM that must stay attached to customer requests. Another needs a weekly status note written in language that legal already approved.
A vendor can build the common pieces. It cannot predict every internal process. That gap is where teams usually end up with spreadsheets, side scripts, browser extensions, and private reporting jobs.
Coding agents make that context more useful
Agentic coding changes the amount of custom software a small team can attempt. A customer can ask an agent to draft a connector, adapt a sample plugin, trace a host function, or create a small admin screen. The output still needs a human review, but the first version arrives faster.
Source access improves the quality of that first version. The agent can read the Windshift code and docs, then follow the product's real naming, data structures, and UI patterns. It can compare a proposed plugin against the host functions. It can help debug a local instance. It can produce a patch that a developer reviews in a normal pull request.
Plugins are where most customer code should live
Private forks are useful for some core changes, but most customer extensions should stay outside the core product. Windshift's plugin system gives teams a controlled place to add local code while keeping the main installation close to the upstream release.
Windshift plugins are built on [Extism](https://extism.org/) and WebAssembly. A plugin includes a `manifest.json`, a `plugin.wasm` entry point, and optional static files for UI. Windshift loads plugins at startup and runs them in an isolated sandbox with default limits of 5 seconds and 64 MB of memory.
Ordinary extensions matter
The most valuable internal extensions are often boring in a useful way. They connect a private system, enforce a rule, move data into the right place, or remove a weekly manual step.
A support team might add an admin tab that shows escalations from a private CRM. A delivery team might generate status comments from milestone data. A regulated team might add a release readiness check before work moves into a final state. A development team might create branches using its own naming policy and link them back to Windshift items.
The commitment we are making
Windshift is open source because work management software should remain available to the teams that run their work through it. Atlassian's Server customers already saw what happens when a vendor changes the path. We are making a different commitment with Windshift: the core code is AGPL, contributed code stays AGPL, and customers can keep the product alive even if our priorities change.
The commercial parts of Windshift should fund development, support, and advanced features. They should not remove the customer's ability to run the core platform. That boundary is important to us, and it should be visible to customers before they bet on the product.