Genealogy Laravel Package

Product Decisions This Supports

• Feature scoping for a genealogy vertical. The repo gives a working reference for the domain primitives you'd otherwise spend weeks defining: person records, family/union groupings, parent–child and spouse relationships, life events (birth, death, marriage, residence), places, sources/citations, notes, and media. Use it to pressure-test your own data model before committing to schema migrations.
• Build vs. buy vs. fork. This is a full Laravel application, not a composer library. The real decision is "do we fork this as a starting point?" rather than "do we composer require it?" That reframing should drive the evaluation.
• GEDCOM interop strategy. Genealogy users arrive with existing trees. Determining whether you import/export the de facto GEDCOM format, and how much lossy conversion you tolerate, is a roadmap-defining question. Review what this codebase does here and treat it as a baseline spec, not a finished implementation.
• Privacy and living-person rules. Genealogy products carry unusual obligations — living individuals' data is typically suppressed or restricted by default. This codebase is a useful prompt for deciding whether privacy gating is a launch blocker or a fast-follow.
• Visualization and search scope. Tree rendering (pedigree, descendant, fan charts) and relationship-path search are the two features users judge the product on. Seeing one implementation helps you decide build vs. embed vs. licensed charting library.
• Roadmap sequencing. Use it to separate "table stakes to be credible" (records, relationships, import) from "differentiators" (DNA matching, record hints, collaboration, merge/duplicate detection) — the latter are largely not covered and remain your opportunity.
• Use cases this validates: hobbyist and society genealogy SaaS, heritage/archival projects, membership organizations digitizing records, and educational family-history tools.

When to Consider This Package

Consider it when:

• You're starting a greenfield Laravel product in this vertical and want a domain reference before writing your first migration.
• Your team is comfortable owning a fork permanently — reading, pruning, and upgrading it yourselves.
• You need a demo or prototype fast to validate demand before investing in a real build.
• The scope is internal, single-tenant, or short-lived, where a Laravel 10 / PHP 8.2 runtime is acceptable.
• You want to benchmark your own estimates: how long does GEDCOM import take us versus what's already here?

Look elsewhere when:

• You need a maintained dependency. The repository is archived and the last release is July 2023. Laravel 10 is past end of life and PHP 8.2 is aging out. There is no upstream to receive security patches from — every fix becomes yours. This alone should rule it out for anything customer-facing and long-lived without an explicit internal ownership commitment.
• You need a package, not an application. If you expected a composer-installable domain library, this is the wrong shape; expect to extract and refactor.
• You're not on Laravel/PHP — the domain knowledge transfers, the code does not.
• You need scale, multi-tenancy, API-first/mobile clients, SSO, or audit trails — assume these are absent or thin until verified.
• You operate under compliance obligations (GDPR special-category data, HIPAA-adjacent, government archives) where provenance, retention, and deletion controls must be demonstrable, not inferred.
• Advanced genealogy is the product. GEDCOM 7, evidence-based genealogical proof standards, DNA kit ingestion, and record-hint matching are specialist problems this codebase will not solve for you.

Verdict: treat it as a design input and prototype scaffold, not a supply-chain decision. Score it on time-to-first-prototype saved, not on longevity — it has none.

How to Pitch It (Stakeholders)

To executives: This is a reference implementation of a family-tree product, not a piece of infrastructure we can depend on — it stopped receiving updates in mid-2023. Its value is de-risking: reading it compresses the hardest part of this domain (modeling messy real-world families — second marriages, adoptions, name changes) from roughly six to eight weeks of discovery into a week or two of review. That's cheap insight. What it does not buy us is a running product: we'd still own security, hosting, the Laravel version upgrade, and every feature beyond basic records and relationships. Recommendation: spend one to two weeks on a technical spike against it, then decide whether to fork it as a head start or simply harvest its data model. Either way, budget explicit engineering ownership — there is no vendor, no support contract, and no community to escalate to.

To engineering: Treat this as an archived application you would adopt, not a library you would install. The evaluation we need back is concrete: (1) quality of the relational schema for people, relationships, and events — is it worth copying? (2) GEDCOM import/export coverage and fidelity; (3) test coverage and migration hygiene; (4) what an upgrade to Laravel 11/12 and PHP 8.3+ actually costs in hours; (5) any auth, authorization, or input-handling patterns we would not want to inherit. Assume we fork to a private repo, pin the dependency tree, and never merge upstream. If the upgrade estimate exceeds roughly three weeks, we default to using it as a specification only and building fresh — the domain insight is the asset, and it survives the throwaway.