Genealogy Laravel Package

Technical Evaluation

Architecture fit. Despite being distributed as a Composer package, this is a Laravel 10 application codebase — a runnable family-tree/genealogy site — not a composable library. There is no documented service provider, facade, or published config to composer require into an existing product. That reframes "integration" as a fork-or-extract decision rather than a dependency adoption. It fits if we are building a genealogy product and want a head start on the domain layer (persons, families, events, sources, media, GEDCOM import/export). It does not fit if we simply need genealogy primitives inside an unrelated Laravel app.

Integration feasibility. MIT licensing removes legal friction and permits commercial forks and closed-source derivatives. The practical blockers are lifecycle, not legality: the repository is archived and the last release is July 2023. Laravel 10 left security support in early 2025, and PHP 8.2's security window closes in December 2026, so a fork starts already behind on patch cadence. A 194-star project also implies a very small contributor base, meaning any bug we hit is ours to fix.

Technical risk.

• Abandonment — highest-severity risk. No upstream security patches, no framework upgrades, no GEDCOM spec updates (GEDCOM 7 support is unlikely to arrive).
• Dependency drift — a frozen composer.lock will accumulate transitive CVEs; Symfony and Laravel components age quickly.
• Domain correctness — GEDCOM round-tripping (INDI/FAMC/FAMS links, SOUR/NOTE citations, date ranges, name variants) is genuinely hard and largely unverified by star count.
• Data sensitivity — genealogy data is inherently personal data about living individuals; GDPR/CCPA handling (redaction of living persons, deletion, export) is a first-class requirement the codebase probably does not address.
• Graph performance — ancestor/descendant traversal is recursive and degrades on deep or wide trees; unproven at scale.

Key questions to resolve before committing.

1. Is there a meaningful automated test suite, and does it cover GEDCOM import/export round-trips?
2. What does the data model actually cover — which GEDCOM version, and are relationships normalized or JSON-blobbed?
3. Does an API layer exist, or is it server-rendered Blade only?
4. What are the hard version constraints in composer.json, and what blocks a Laravel 11/12 upgrade?
5. Is authorization multi-tenant / per-tree, or single-tenant?
6. Are recursive queries done in SQL or in PHP, and what is the observed behavior on a 50k-person tree?
7. What is the media storage strategy (local disk vs. S3-compatible)?
8. How much of the code is domain logic versus scaffolding we would discard?

Integration Approach

Stack fit. Strong on paper: Laravel 10 + PHP 8.2 + MySQL is a mainstream, well-staffed stack. If our platform is Laravel-based, the idioms, Eloquent models, and Blade views are immediately legible to our engineers. If we are on Symfony, Node, or a Django stack, the value collapses to "reference implementation" only.

Migration path. Three options, in descending order of preference:

Compatibility. Pin to the archived commit for evaluation, then immediately branch for a Laravel 11/12 upgrade spike. Test the upgrade before committing to a fork — if third-party packages in the lockfile block the move, the extraction path becomes the only viable one. Verify MySQL vs. PostgreSQL portability early if our standard is Postgres.

Sequencing.

1. Week 1 — Clone, install, seed with a public GEDCOM (e.g., a 10k-individual sample). Run the test suite. Produce a codebase map and a coverage report.
2. Week 2 — GEDCOM round-trip fidelity test: import → export → diff. This single test tells us whether the domain layer is worth keeping.
3. Week 3 — Laravel 11/12 upgrade spike on a branch. Timebox it; a failed spike is a valid, cheap answer.
4. Week 4 — Decision gate: reference, extract, or fork. Publish the ADR.
5. Post-decision — Harden: dependency audit, CI, auth review, PII/redaction policy, then integrate.

Operational Impact

Maintenance. We become the maintainer. Budget ongoing effort for framework majors (roughly annual), PHP minors, dependency CVE patching, and GEDCOM edge-case bugs. Treat this as ~10–20% of one engineer's capacity in steady state for a fork, near zero for the reference path.

Support. No vendor, no SLA, no active maintainer. Support is internal only. Retain the original authors' MIT attribution and consider whether a public fork creates an expectation of responsiveness we are unwilling to meet.

Scaling. Genealogy workloads are read-heavy with deep recursive traversals and bursty bulk imports. Expect to need: queue-backed import jobs, materialized ancestor/descendant paths or closure tables, pagination on large trees, and object storage for media. Media libraries grow monotonically — plan lifecycle and dedup policy. Profile on a realistic tree size before sizing infrastructure; do not extrapolate from the demo dataset.

Failure modes to instrument.

• Partial GEDCOM import leaving a half-linked tree (needs transactional or staged import with rollback).
• Recursive query timeouts or memory exhaustion on large/deep trees.
• Duplicate-person merges producing orphaned relationships and dangling media references.
• Unpatched transitive dependency CVE discovered by a scanner mid-quarter.
• PII exposure — living individuals rendered on public pages; needs a redaction rule enforced at the query layer, not the view.
• Silent data loss on export (encoding, non-ASCII names, custom GEDCOM tags).

Ramp-up. A mid-level Laravel engineer is productive on the codebase in roughly one sprint; the framework is the easy part. The real ramp is GEDCOM semantics — INDI/FAMC/FAMS linkage, source citations, date/place normalization — which typically requires a domain expert (genealogist or archivist) on call for the first month. Plan for one engineer at 50% for four weeks plus intermittent SME time. Do not staff this as a pure backend task; the correctness risk is in the domain, not the PHP.