Tds Provider Bundle Laravel Package

Product Decisions This Supports

• Feature scope: enterprise/legacy data connectivity. This package is a Laravel service-provider bundle for TDS-based data sources (Tabular Data Stream — the protocol behind Microsoft SQL Server / Sybase). It lets you add that connectivity as a registered provider rather than hand-wiring drivers, config, and container bindings into each service.
• Roadmap: on-prem and enterprise customer segments. If your roadmap includes customers whose data sits in SQL Server (common in finance, healthcare, manufacturing, and any company with a Microsoft estate), this is the kind of plumbing that unblocks those deals without a custom integration project per account.
• Build vs. buy vs. fork. The functional surface here is small — provider registration, connection config, driver selection. That makes "build it in-house in ~1–2 days" a credible alternative to adopting an unmaintained dependency. Treat this package as a reference implementation first and a dependency second.
• Use cases it plausibly enables: reporting/BI modules reading from an MSSQL warehouse, nightly sync jobs into the Laravel primary database, migration tooling off legacy Sybase, and internal admin panels over an existing ERP.
• Decision it should not drive: anything customer-facing that requires a support commitment. Zero stars, zero dependents, and a low opportunity score mean you are the maintainer the moment you install it.

When to Consider This Package

Consider it when:

• The use is internal only (internal tools, back-office jobs, one-off migrations). GPL-3.0's obligations trigger on distribution and on providing a network service in some interpretations — internal, non-distributed use is the defensible zone.
• You have a named owner on the team who will read the source, pin the version, and vendor/fork it into your monorepo.
• The scope genuinely matches: you need standardized provider wiring for TDS connections and nothing more.
• You're comfortable that the license, not the code, is the binding constraint on where this can ship.

Look elsewhere when:

• You distribute the product — shipped binaries, on-prem installers, white-label deployments, or an OSS/commercial dual model. GPL-3.0 is a material legal risk here and will fail most legal reviews. This is the single biggest gate.
• You need security patch SLAs, CVE response, or vendor support. Single-maintainer, zero-adopter packages offer none.
• A first-party or widely adopted alternative covers the need: Laravel's native database layer with the sqlsrv/dblib PDO drivers, doctrine/dbal for schema introspection, or the FreeTDS extension directly. These have orders of magnitude more eyes on them.
• The requirement is actually "read from SQL Server occasionally" — a scheduled job with a raw PDO connection may be simpler than a bundle and its lifecycle.
• Verify the scope before committing. With no stars, no dependents, and no public usage evidence, confirm by reading the source that "TDS" means what you assume and that the package does what the README claims. Do not take the name at face value.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost enabler for the enterprise/on-prem segment — it shortcuts the plumbing needed to connect our product to customers running Microsoft SQL Server. It is not a strategic dependency. The two things to weigh are (1) the GPL-3.0 license, which likely restricts us from shipping it inside a distributed product, and (2) its maturity — no community, no adopters, one maintainer. Recommendation: approve as an internal-only enabler, budget a day of engineering to vendor it in-house, and treat the package as a design reference rather than a long-term dependency.

To engineering: The package is a Laravel service provider bundle for TDS connectivity. Functionally thin, so the real question is ownership: if we adopt it, we own it. Please (a) read the source end-to-end before adopting, (b) confirm the license position with legal for the specific deployment model, and (c) give a build-it-ourselves estimate — for a surface this small, in-house is likely cheaper than absorbing an unmaintained GPL dependency. If we do adopt, pin the version, vendor the source, and add it to the dependency review list.

Bottom line: Justified only as an internal, non-distributed, owner-backed component — or as a reference implementation. Not justified as a customer-shipping dependency.