Genealogy Laravel Package

Product Decisions This Supports

• Build vs. buy (or "build vs. borrow") for a genealogy vertical. This is a full Laravel application backend rather than a drop-in library, so its real value is as a reference implementation for the domain: how to model persons, names, parent/child and spouse relationships, events (birth, marriage, death), places, sources, and citations in a relational schema. That model is the expensive part of a genealogy product to get right; the CRUD around it is not.
• Domain modeling and schema design for a family-tree feature. If you are adding "household / family / relationship" concepts to an existing product (member directories, alumni networks, clinical family history intake, heritage/travel), this repo is a concrete, MIT-licensed starting point for entity relationships and lifecycle rules you would otherwise spend a design sprint inventing.
• GEDCOM interchange strategy. Genealogy products live or die on importing and exporting GEDCOM files. A working PHP implementation gives you a concrete basis for scoping that workstream, estimating effort, and deciding whether to hand-roll, buy a converter, or fund a maintained library.
• Feasibility spikes and demos. With MIT licensing and no per-seat cost, you can stand up a credible internal demo in days to validate demand with stakeholders, run user research on tree-navigation and data-entry flows, or answer "is this a product or a feature?" before committing headcount.
• Roadmap deprioritization evidence. The package being archived with a last release in mid-2023 is itself a useful data point: the open-source PHP genealogy ecosystem is thin and largely unmaintained. That argues for treating genealogy as a differentiated investment with ongoing ownership, not a commodity capability you can pull off a shelf.
• Procurement and licensing posture. MIT means no copyleft contamination, no attribution burden beyond the notice, and safe use in commercial and closed-source contexts — a low-friction decision for legal and for a first exploratory PR.

When to Consider This Package

Consider it when:

• You are evaluating or prototyping a genealogy, ancestry, heritage, or family-records product and need to compress discovery from weeks to days.
• Your team is already on Laravel/PHP and can read the code as an architectural reference without adopting it as a dependency.
• You need a domain schema and relationship model to react to, not production code to run.
• Your scope is historical/archival records or member-facing family trees where read-heavy browsing and structured data entry dominate, not real-time collaboration at consumer scale.
• You can accept a fork-and-own posture: this is archived, so whoever adopts it buys the maintenance.
• You are looking for GEDCOM handling prior art in PHP specifically.

Look elsewhere when:

• You need a maintained dependency with security patches, an SLA, or vendor support. Archived status plus a 2023 release date means no fixes for the Laravel 10 lifecycle, PHP 8.2 end-of-security-support, or disclosed vulnerabilities. Any adoption is a fork you own.
• You need production readiness out of the box — authentication hardening, GDPR/CCPA handling for living individuals, audit trails, or horizontal scalability are almost certainly not solved here and are the hard parts of a real genealogy product.
• Your stack is not PHP/Laravel, or your organization is standardizing on a different runtime. The domain lessons transfer; the code does not.
• You need GEDCOM 7 conformance, DNA/ancestry integrations, or advanced relationship-graph queries and visualizations at scale — verify current coverage rather than assuming it; archived projects lag standards by definition.
• Privacy and consent for living persons is a regulatory requirement for you. Genealogy data is unusually sensitive (it implicitly exposes information about relatives who never consented). Assume this needs to be designed, not inherited.
• You want a library to require in composer.json. This is an application, not a package; there is no stable public API contract to depend on.

How to Pitch It (Stakeholders)

To executives (one paragraph): We can use this MIT-licensed codebase as a low-cost way to de-risk a build decision, not as a foundation to launch on. It gives us a working model of the hardest part of a genealogy product — how families, relationships, events, and sources fit together — plus prior art on GEDCOM import/export, at zero licensing cost. It is archived and unmaintained, so I am not recommending we run it in production. I am recommending a timeboxed two-to-three week evaluation (roughly one engineer, part-time) to answer three questions: does the domain model hold up, how much of GEDCOM do we get for free, and what would ongoing ownership cost. That spend is small against the cost of designing the schema and interchange layer from scratch, and it produces a credible internal demo we can put in front of prospective users.

To engineering: Treat this as read-only reference code and a possible fork source, never as a composer dependency. Expect to inherit a Laravel 10 / PHP 8.2 upgrade (both approaching or past upstream support), an unaudited dependency tree, no security response process, and test coverage of unknown depth. The evaluation should produce a written assessment of the schema, the GEDCOM handling, and the upgrade surface — and an explicit decision on whether we fork with a named owner or simply mine it for design. If we fork, it enters our repos with our CI, dependency scanning, and an upgrade budget, and we accept that we are now the maintainers of a public MIT project.

Framing to avoid: do not present this as "we found a genealogy backend we can use." 194 stars and archived status will be read correctly by anyone technical as abandoned, and overstating readiness will cost credibility. The honest pitch is "cheap, credible prior art that shortens a decision," and that pitch is strong on its own.