Product Decisions This Supports

Feature prioritization for the editor experience. The package is a working precedent for the "editors lose work when a session drops" pain point. It supports a decision to treat autosave / draft recovery as a table-stakes capability in any content authoring surface you own, rather than a nice-to-have.
Build vs. buy — leaning build. The artifact itself is not a viable buy: archived repository, last release February 2019, zero dependents, 22 stars, and a NOASSERTION license that creates legal ambiguity. The useful signal is the pattern (periodic draft persistence, restore-on-return, conflict handling), not the code.
Legacy platform roadmap. If you still run eZ Publish legacy (4.x/5.x), this informs a fork-and-own vs. accelerate-migration decision. The package is evidence that the legacy editing stack is frozen in time and that investment should go toward migration rather than patching.
Incident and support-cost input. Autosave reduces a recurring class of support tickets (lost drafts, rework after timeouts). Use it to justify engineering hours for native implementation in your target platform.
Use cases to scope against: long-form article editing, unreliable network conditions, multi-tab editing, session timeout recovery, and editorial workflows where re-authoring cost is high.

When to Consider This Package

Only if you operate eZ Publish legacy and cannot migrate in the near term — and even then, treat it as a starting point to fork, audit, and own, not a dependency to install.
Consider it as a reference implementation when writing requirements for autosave in a modern editor: what triggers a save, debounce intervals, where drafts live, how conflicts and restores are surfaced.
Look elsewhere when:
- You are on Ibexa DXP or any actively maintained CMS (Drupal, WordPress, Contentful, Strapi) — autosave is native or has maintained extensions.
- You need PHP 8 compatibility, security patching, or a clear license for procurement and legal review.
- You expect community support — zero dependents and a 2019 release mean no upstream signal.
- You are starting greenfield work; the ecosystem this targets is end-of-life.

To executives: This is not a purchase or a new dependency. It is a signal that autosave is an expected editorial capability and that our legacy platform no longer receives this kind of investment. Frame it as an argument for migration budget and for setting a minimum bar in the editor we ship next.
To engineering: Read the source as a design reference for draft persistence and recovery UX. Do not add it to composer.json — the repository is archived and the license is unclear. Extract the requirement ("editors must not lose work"), then implement the pattern natively in the target platform.
Recommendation: Capture the requirement, close the legacy gap by migration or a small owned implementation, and formally retire this package from consideration. Its value is historical evidence, not reusable code.