Product Decisions This Supports
- Build vs. buy for internal delivery tooling. GitScrum is a self-hosted, MIT-licensed Scrum/kanban application (backlog, sprints, boards, tasks, time tracking, git integration) rather than a composable library. It gives you a credible "buy at zero license cost" baseline to price against Jira, Linear, Trello, or a custom build. The zero dependent count still holds: this is not something you
composer require into an existing app — the decision is fork-and-operate, not integrate.
- MVP acceleration for a roadmap item. If a roadmap item is "internal project tracker for the dev team," forking this app shortens time-to-first-demo on the entity model (projects → sprints → tasks → time entries) and the board UX. Budget the real work as upgrade, hardening, and customization, not greenfield feature development.
- Use-case fit. Best suited to small-to-mid dev teams (5–30) or agencies that want self-hosted, data-sovereign project tracking with no per-seat cost; internal/demo/educational environments; teams already standardized on Laravel that want a familiar codebase to extend.
- Reference architecture input. Even if you don't ship it, it's a useful read for how to model sprints, backlogs, and git linkage in Laravel — cheap input to a design doc for a homegrown tool.
- Risk/roadmap signal — revised by 1.1.0. The project sat dormant since 2017-10-01; release 1.1.0 is the first sign of life since, containing incremental work rather than modernization: label filtering by user story, AJAX issue creation, a
IssueController@index refactor, sync-without-detach, a fix for private-mode sprints, dead-code cleanup, a Laravel Page Speed integration, and — most relevant to a fork — test and seeder configuration. Read this as a modest maintenance pulse, not a return to supported-product status. A roadmap that depends on this code must still carry an explicit ownership line item (upgrade path, security patching, PHP/Laravel version support), and one small release does not establish cadence.
When to Consider This Package
Consider it when:
- You need a self-hosted, MIT-licensed Scrum/kanban tool and per-seat SaaS cost or data residency is a blocker.
- You have in-house Laravel/PHP capacity and are willing to own a fork — including dependency upgrades, security review, containerization, and CI.
- The deployment is internal and low-blast-radius (dev team tooling, not customer-facing, not regulated data).
- You want a timeboxed spike or demo to validate workflow before committing to a buy or a full build.
- You're comfortable running or upgrading a Laravel 5.x-era codebase, or you've scoped the modernization effort and accepted it. The new test/seeders configuration in 1.1.0 slightly lowers the cost of getting a fork under CI, but does not remove the framework-upgrade work.
Look elsewhere when:
- You need maintained security updates, a support SLA, or a vendor to hold accountable — the 1.1.0 release is a welcome signal but there is still no evidence of a sustained maintenance commitment, security process, or release cadence.
- You require modern platform support (current Laravel/PHP 8+, SSO/SAML, SCIM, audit logs, mobile, robust API/webhooks) — plan on substantial rework, not configuration. The 1.1.0 additions (label filtering, AJAX issue creation, private-sprint fix) are usability increments, not platform modernization.
- Your organization is regulated, customer-facing, or has strict vulnerability-remediation timelines.
- You have no Laravel maintenance capacity: total cost of ownership here is dominated by upkeep, not acquisition.
- You actually want a library to embed in an existing product — this is an application, and the zero dependent count confirms it isn't distributed as a reusable component.
- You need long-horizon planning (3+ years) on the tool; a lightly maintained fork becomes a migration project later.
How to Pitch It (Stakeholders)
To executives: GitScrum is an MIT-licensed, self-hosted Scrum tool with real feature coverage (boards, sprints, backlog, time tracking) and strong historical traction (~2.9k GitHub stars). The license cost is zero, but the project went dormant after its October 2017 release; a new 1.1.0 release landed with incremental features and a bug fix for private sprints, which is encouraging but not a support commitment. The true cost is ownership: we'd be adopting a fork that we maintain. Recommendation: treat it as a timeboxed evaluation against buying a SaaS tool — worth 1–2 weeks of engineering to fork, containerize, and run a pilot, aided by the newly added test/seeders configuration — with a clear kill criterion if modernization (Laravel/PHP upgrades, security hardening) exceeds the buy option's annual cost. Do not position this as a long-term supported platform on the strength of one release.
To engineering: This is a Laravel application, not a package — we'd fork and operate it, not depend on it. Release 1.1.0 gives us a small but useful delta: label filtering by user story, AJAX issue creation, an IssueController@index refactor, sync-without-detach, a private-mode sprint fix, removal of unused variables, a Laravel Page Speed addition, and test/seeders configuration that should shorten the path to a working CI pipeline. None of that changes the core cost: dependency and framework upgrades, security review of an aging dependency tree, and containerization. Upside remains the domain model (projects, sprints, tasks, time entries, git linkage) and board UX, so we're editing rather than inventing. Ask for a scoped spike with an explicit estimate of upgrade hours before any commitment, and confirm whether 1.1.0 marks the start of a cadence or a one-off.