Varieties Bundle Laravel Package

Product Decisions This Supports

• Taxonomy schema design for any agri/botanical feature. If the roadmap touches seeds, cultivars, nursery inventory, crop research, or a botanical catalog, the core question is how to represent the ranked hierarchy Family → Genus → Species → Subspecies → Variety. This package is a validated reference implementation of exactly that model — the decision it informs is "what shape should our schema take," not "what should we install."
• Build vs. buy vs. borrow. The cheapest path is almost always "copy the schema, not the package." Use it to answer the build decision with confidence: the five-level adjacency model is a few days of Eloquent work, with full control over naming, synonyms, and audit fields.
• Roadmap sequencing. Taxonomy is routinely scoped as "just a lookup table" and then blows up. Seeing a ranked hierarchy with subspecies and variety levels clarifies that cultivar naming, synonym handling, and authority cross-references are separate, later workstreams. That lets you sequence a catalog MVP (family/genus/species) ahead of a compliance-grade variety registry.
• Framework-fit gate. Despite being filed under Laravel/PHP, this is a Symfony bundle — no service provider, no facade, no auto-discovery. That is a real architectural decision point: it can be consumed conceptually but not dropped into a Laravel codebase without a rewrite or adapter.
• Legal/IP review trigger. The license resolves to NOASSERTION — no recognized SPDX identifier. That forces a legal review before any code reuse, regardless of model quality. It becomes a gating item on any roadmap item that assumed this as a dependency.
• Deprecation triage. Explicitly DEPRECATED, 0 stars, 0 dependents, composite score 0.03. That is a decision against adoption and for treating it as documentation. Any plan that assumed it needs re-planning now, not at integration time.

When to Consider This Package

Consider it (narrowly) when:

• You need a domain reference model for botanical taxonomy and want a validated shape for the hierarchy before designing your own schema. Read the entity design; don't install the code.
• You are already on Symfony and need a low-stakes internal tool — a research catalog, a demo, a back-office admin — where an unmaintained dependency is tolerable.
• You are running a spike or proof of concept on cultivar/variety management and want to short-circuit schema design for a week.
• You have in-house capacity to fork and maintain the code, and legal has cleared the ambiguous license.
• Your taxonomy needs are purely taxonomic — no cultivar marketing names, breeder rights, or regulatory registration data.

Look elsewhere when:

• You are on Laravel. A Symfony bundle is not a drop-in; integration cost likely exceeds the cost of writing the models directly.
• You need maintained, supported code. No security response, no PHP-version guarantee, no issue triage.
• Scope is production or revenue-critical. Anything customer-facing or contractually bound to uptime should not sit on an abandoned package.
• You need authoritative taxonomy data, not just a schema. This provides structure, not content. Real products need integration with POWO, IPNI, GRIN/GRIN-Global, or EPPO — not solved here.
• License clarity is mandatory. NOASSERTION means legal must opine; if procurement blocks unlicensed code, this is disqualified today.
• You need richer agronomic modeling — growth cycles, hardiness zones, seed-lot lineage, certifications — all out of scope.

How to Pitch It (Stakeholders)

For executives: This is a reference design, not a purchase. It is a small, deprecated, unmaintained open-source component that models the plant taxonomy hierarchy — family, genus, species, subspecies, variety. Its value is a head start on the data model for any agri, nursery, seed, or botanical catalog work on our roadmap. Two hard blockers rule out direct adoption: it is built for Symfony rather than our Laravel stack, and its license is not machine-identifiable, requiring legal review before any code reuse. Recommendation: use it as a design input in a one-week spike, budget zero for licensing, and do not add it as a dependency.

For engineering leadership: Treat this as a schema reference and a cautionary data point. The five-level hierarchy is a sound skeleton we can reimplement in Eloquent in a few days, with full control over cultivar naming, synonym handling, and external authority integration — none of which this package covers. Adopting it would mean inheriting a Symfony bundle, an unmaintained codebase, and an unresolved license. The right cost comparison is not "package vs. nothing" but "package vs. two to three days of our own modeling," and our own modeling wins on every axis except day-one speed.

For the product team: If taxonomy appears in a feature spec, escalate it as a modeling problem with content dependencies, not a library-selection problem. The real work is deciding which authority we trust, how we handle renamed species, and whether varieties are a catalog attribute or a compliance record. This package answers none of those — but it does give us a shared vocabulary to start the conversation.