User Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for user/identity management — still firmly "build," or buy a maintained IdP. kimai/user-bundle remains a vendor split of Kimai's internals rather than a product: 1 star, 0 dependents, and now a single patch release (3.0.1) after a multi-year gap. The 3.0.1 fix is a one-line PHP 8.1 deprecation cleanup in PasswordUpdater — it is a maintenance blip, not a maintenance commitment. The supported decision is not to adopt it, which is itself a decision worth recording so it isn't re-litigated next quarter.
• Fork-vs-embed decision for Kimai itself. If you are evaluating Kimai (the time-tracking app) as a base, this bundle tells you how Kimai decomposes its user domain. That is useful for scoping a Kimai-based product: user management is a first-class, separable concern in their architecture, and you would more realistically extend Kimai in-place than consume its bundles à la carte.
• Requirements baseline for a user-management feature set. Reading the bundle's surface (user entity, roles/permissions, user preferences, profile handling) gives a PM a concrete checklist of what "user management" means in a time-tracking domain — useful input to a PRD even if you never install the code.
• Architecture/roadmap guardrail against premature package extraction. This remains a case study in what happens when an application extracts an internal module into a standalone package with no downstream consumers: it decays. The 3.0.1 release does not change that arc — it confirms the bundle only gets touched when someone upstream trips over it, not because anyone owns it. That supports a policy decision: don't fund "let's publish our internal bundle" initiatives unless there is an identified external consumer and a named maintenance owner.
• Security and compliance posture decisions. An identity-adjacent package with a single patch release after a three-year gap has no dependable CVE response path — a deprecation fix is not an advisory process. That directly informs your dependency policy (allow-list policy for identity code) and your SOC2/ISO evidence narrative around third-party component maintenance.

When to Consider This Package

Adopt only under narrowly defensible conditions:

• You are already inside the Kimai codebase at a version contemporaneous with the bundle (roughly late-2022 Symfony/PHP versions) and are reading or patching it in-tree — not installing it from Packagist. Note that 3.0.1's PHP 8.1 deprecation fix is the only signal the bundle will receive compatibility attention at all.
• You need a reference implementation of a Symfony-based user model for a time-tracking domain and want to compare designs. Read-only use, pinned to a commit.
• You are maintaining a hard fork of Kimai and need to understand how its user layer was decomposed upstream.

Look elsewhere if any of the following is true — which is nearly always:

• You need a maintained identity layer. Use Symfony's own Security/PasswordHasher components with Doctrine, or delegate to a dedicated IdP (Keycloak, Auth0, Entra ID, Cognito). These have release cadence, security advisories, and support.
• You need current Symfony or PHP compatibility. A single 8.1 deprecation fix does not indicate Symfony 6.x/7.x deprecation tracking; assume the bundle is pinned to its 2022-era framework assumptions.
• You need multi-tenancy, SSO/SAML/OIDC, SCIM provisioning, MFA, or audit logging — none of which a 1-star, near-dormant bundle is going to give you.
• You need a support contract or SLA. There is no vendor, no maintainer commitment, and 0 dependents means no community to fall back on. A lone patch release does not create an escalation path.
• You are evaluating FOSUserBundle as an alternative — note it is also effectively end-of-life; the correct modern answer is Symfony's native user provider plus MakerBundle, not another legacy bundle.
• You were relying on the "no release since 2022" signal as your rejection rationale — that specific argument is now stale. Reject for lack of ownership and consumer base, not for literal dormancy, and re-verify the repository's archived status before citing it.

How to Pitch It (Stakeholders)

The short version: kimai/user-bundle is a Symfony bundle extracted from the Kimai time-tracking application that packages its user entity and user-management logic. It is MIT-licensed and technically readable. As of release 3.0.1 it is no longer strictly dormant — but that release is a single PHP 8.1 strlen() deprecation fix in PasswordUpdater, against a backdrop of one GitHub star and zero dependent packages. It should be treated as reference material, not as a dependency.

To executives: The cost of adoption is near zero and the cost of ownership is unbounded — identity-adjacent code with no release cadence and no one to call when it breaks. The recent 3.0.1 patch is a deprecation cleanup, not a sign of a supported product; do not read it as renewed investment. Recommendation: do not allocate engineering time to integration. We are capturing its domain model as an input to our own user-management requirements and moving on. Expected spend avoided: an unknown-but-nonzero migration off an unsupported auth component, which is one of the more expensive kinds of technical debt to unwind.

To engineering: Read it, don't vendor it. If you need a working example of Symfony user/role modeling for a time-tracking domain, skim the source at a pinned commit and then implement against Symfony's current Security component. The 3.0.1 release only fixed a null-to-strlen() deprecation in PasswordUpdater — useful if you are copying that class, meaningless as a compatibility guarantee. Flag any existing internal proposal to consume Kimai bundles directly as high-risk; the upstream extraction still has no consumer base and no maintainer signal.

To security/compliance: Keep archived and near-dormant identity-adjacent packages on the dependency deny-list by default. This one qualifies on ownership and advisory-response grounds: no vendor, no dependents, and a single deprecation patch after a three-year gap is not an advisory process. Note for the record that the "no release since November 2022" evidence point is superseded by 3.0.1; if the repo has been unarchived, update the deny-list rationale to "no maintenance owner" rather than "archived."