Webtrees Laravel Package

Product Decisions This Supports

This is a reference implementation and a fork candidate — not a dependency. The single most important framing: fisharebest/webtrees is a complete standalone PHP application that consumes Laravel components (Eloquent, Blade), not a Composer library you require into an existing Laravel service. That reframes the decision from "adopt a package" to "buy vs. build vs. fork-and-operate," and the PM should force that framing early.

Decisions it can inform:

• Build vs. buy for a genealogy/lineage vertical. If the roadmap includes family-tree, ancestry, or pedigree features, webtrees is a working, battle-tested spec for what "done" looks like. It converts an open-ended scoping exercise into a concrete feature checklist: GEDCOM import/export, merge/conflict resolution, moderation queues, per-person privacy, interactive charts, media management.
• Standards strategy: GEDCOM 5.5.1 support as a requirement. If we decide to support GEDCOM at all, webtrees demonstrates the real cost of full import/export fidelity and round-trip integrity. It also raises the strategic question of whether standards compliance is a moat or table stakes — note that GEDCOM I/O is inherently an anti-lock-in feature: users can leave with their data. Good for trust and acquisition, weak for retention.
• Privacy model design (highest-transfer-value asset). Per-tree, per-person, per-user granular privacy combined with role-based access is genuinely expensive to build correctly — the "living people" problem in genealogy is a legal/ethical requirement, not a nice-to-have. webtrees is a strong prior-art reference for our own data-access layer even if we build a different domain.
• Localization roadmap. 100+ language translations is a very large sunk cost we should not rebuild. It informs whether i18n is a launch requirement, a post-PMF investment, or something we defer entirely.
• Extension architecture. The module system that extends charts, reports, and data sources is a preview of a partner/plugin ecosystem decision — useful as a case study in how much API surface a plugin model costs to maintain.
• Roadmap de-risking via spike, not commitment. The right decision this package unlocks is a time-boxed "read and extract" spike (2–3 weeks) whose deliverable is a build estimate and a reuse shortlist, not a production deployment.

Data hygiene caveat the PM must flag: the metadata lists a last release of 2016-12-05 while the description claims "leading," "modern Laravel components," and active collaboration features. That contradiction is almost certainly a stale pipeline field, but the PM's job is to state plainly that release cadence, security patch history, and supported PHP/Laravel versions are unverified and must be confirmed before this enters any estimate as a maintained dependency.

Also load-bearing: GPL-3.0. Server-side SaaS use where no binary is distributed generally does not trigger source obligations, but any redistribution — on-prem appliance, Docker image shipped to a customer, a fork embedded in a distributed product — pulls the whole derivative under GPL-3.0, including patent and anti-tivoization terms. Treat licensing as a gating question, not a footnote. (Not legal advice; route to counsel.)

When to Consider This Package

Consider it when all of these hold:

• The product is self-hosted or internal — a non-profit, society, archive, university, or hobby-community deployment where "runs anywhere PHP and MySQL run" is a feature, not an ops liability.
• GEDCOM 5.5.1 round-trip fidelity is a hard requirement. Reimplementing this is months of edge cases; webtrees has already paid that cost.
• Granular privacy is a compliance requirement, not a preference — you need per-person suppression of living individuals and auditable role-based access out of the box.
• The team is PHP/Laravel-fluent, so reading Eloquent models and Blade views is low-friction and forking is a real option rather than a fantasy.
• GPL-3.0 is acceptable to the business, or the usage is non-distributed, or the engagement is explicitly "read for design, write our own."
• You need multi-language day one and cannot fund a translation program.
• You're comfortable owning a fork — pinning a commit and absorbing security patches yourself.

Look elsewhere (or narrow to a reading-only exercise) when:

• You need to redistribute commercially or embed in a closed-source product. GPL-3.0 is disqualifying; the copyleft exposure dwarfs the development savings.
• You need a composable library. If the ask is "a GEDCOM parser I can call from a Laravel service," take a focused parser package. Pulling in an entire application to get one capability is a bad trade on every axis — surface area, upgrade risk, blast radius.
• You need vendor-backed SLAs, CVE response commitments, or an LTS policy. Verify the release cadence first; a ten-year-old last-release field, even if wrong, means the data isn't trustworthy enough to bet a roadmap on.
• You need SaaS-scale, cloud-native, or horizontal-scaling guarantees. Monolithic PHP/MySQL app architecture won't map cleanly to a multi-tenant, autoscaling target.
• Your entity graph isn't genealogy-shaped. The value is concentrated in GEDCOM semantics and pedigree-specific privacy rules; a generic "people and relationships" CRUD need gets no leverage.
• The market signal says don't. The low opportunity score (26.25) and middling overall score (34.9) are consistent with a mature, narrow, well-served niche. If the business case is "genealogy is a growth market," webtrees is evidence the incumbent is free — which caps willingness to pay.
• Nobody on the team can commit to maintaining it. An unmaintained fork of a GPL application is a liability that quietly accrues.

How to Pitch It (Stakeholders)

Executive summary. webtrees is a mature open-source genealogy application — GEDCOM-standard family trees, collaborative editing with moderation and change history, person-level privacy controls, interactive charts and reports, extensible modules, and 100+ languages. It is built on PHP with Laravel's Eloquent and Blade, so our team can read and maintain it without a new skill investment. It is not a library we can drop into an existing product; it's a full application we would self-host, fork, or study.

The ask is small and the downside is capped: fund a short, time-boxed spike to extract a build estimate and a reuse shortlist. We are not committing to adoption.

Why it's worth the spike. Three things in webtrees are expensive to build and cheap to learn from: GEDCOM 5.5.1 import/export fidelity, a granular privacy and role model that handles living-individual suppression correctly, and a 100+ language localization base. Reading these instead of discovering them by trial-and-error is a meaningful schedule and cost avoidance on any lineage-adjacent roadmap.

Three gates before any production decision:

1. License. GPL-3.0. Fine for internal or non-distributed server-side use; a hard blocker if we intend to ship or embed it in a distributed commercial product. Legal review required before engineering time is spent.
2. Health. Our metadata shows a stale release date that contradicts the project description. Before we treat this as maintained, we need verified release cadence, supported PHP/Laravel versions, and a security-patch history.
3. Commitment. Adopting or forking means we own upgrades and CVEs. If no one owns that, we don't adopt — we read.

Recommendation to engineering. Treat webtrees as prior art. Do not introduce it as a dependency. If genealogy is a confirmed roadmap item and the license clears, evaluate it as a self-hosted base or a fork with a named owner and a pinned version.

What would change the recommendation: a commercial redistribution requirement (walk away), verified active maintenance plus GPL clearance for a self-hosted internal deployment (proceed to a pilot), or a decision to drop lineage features entirely (archive the spike output as institutional knowledge and move on).