Extractor Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for data ingestion. This package is the "build on a framework" option for authoring Keboola extractor components (jobs that pull third-party SaaS data — CRMs, ad platforms, billing systems — into Keboola storage). The decision it informs: standardize on Keboola's extractor conventions, roll our own connector scaffolding, or buy a managed ELT vendor. It is not a library for consuming Keboola data from a Laravel product; that job points at the Storage/Job Queue REST APIs instead.
• Connector roadmap scoping and effort estimation. The bundle exists because authentication, configuration schemas, pagination, incremental sync state, error/exit-code semantics, and output manifests are the recurring costs of every connector. Its presence lets a PM reason about a reusable pattern rather than re-estimating each source from zero — and it tells you roughly how many sources are realistically shippable per quarter once the scaffolding is in place.
• Platform/framework alignment fork. Despite the "Laravel/PHP" framing, this is a Symfony bundle with Keboola-specific runtime conventions, not a Laravel package. Adopting it implies committing to Symfony idioms, a Keboola component runtime contract (/data/config.json, run action, state files, CSV + manifest output), and Docker packaging — or building a non-trivial adapter. That is a real architectural fork for a PHP data product, and it is the decision worth escalating above the package itself.
• Vendor-risk and ecosystem posture. With zero stars, a zero score, zero dependents, Bitbucket-only hosting, and no surfaced license, this is not a community-vetted dependency. The decision it best supports is negative: treat Keboola as a platform partner (adopt their conventions, possibly their tooling) vs. a black-box SaaS integrated over APIs only.
• Realistic use cases: internal Keboola connector development; teams already operating a Keboola stack; and — most defensibly for a PM without a Keboola mandate — as a reference implementation to study extractor patterns rather than a production dependency.

When to Consider This Package

Consider it only when all of the following hold:

• You are already standardized on Keboola as your data platform and/or Symfony as your PHP framework — the bundle lives inside those conventions.
• The job to be done is authoring extractors (not pulling Keboola data into a Laravel app), and you expect to build several, so shared scaffolding for config, auth, and sync semantics actually amortizes.
• You will treat it as an isolated deployable (its own repo/image invoked by a queue job or internal HTTP call), never inside the Laravel dependency graph.
• You have engineering capacity to vendor, pin to a commit, fork to internal VCS, and audit it — there is no observable community to catch regressions.
• You can access the Bitbucket repo and confirm the license (a blocker if unclear) and that the bundle is still the recommended path rather than superseded by keboola/php-component.

Look elsewhere when:

• You are on Laravel. No bundle registry, no package discovery, service-container mismatches; a Laravel-native ingestion approach or a managed ELT vendor will be cheaper. If the real need is consuming Keboola, use their APIs, not this.
• You need a supported, SLA-backed dependency. Zero stars and zero dependents mean no ecosystem safety net; treat it as unsupported code you own.
• You only need one or two connectors. Buy or use a hosted connector service; the framework investment doesn't pay back.
• Your stack is Python/Node/Go. The value is PHP/Symfony-specific — use Singer/Meltano-style tap frameworks instead.
• Composer resolution fails against your PHP/Symfony constraints (or a current Laravel's). This is the first gate and the most likely early blocker; a 1–2 day spike decides the architecture.

How to Pitch It (Stakeholders)

To executives: "This is a narrow, low-visibility development bundle Keboola publishes for building data extractors on their platform. It is not a mainstream open-source dependency — no stars, no downstream users, unclear licensing, and Bitbucket-only hosting — so it carries real vendor and support risk. My recommendation is not to adopt it as a production dependency today. Instead, treat it as a signal: if ingesting third-party data is on our roadmap, we should decide between (a) committing to the Keboola platform and its conventions, (b) buying a managed ELT service, or (c) building minimal in-house connectors. I'll bring a cost/risk comparison for those three options, and I'll flag that this package doesn't solve our Laravel side either way — it's a Symfony/Keboola tool, not a Laravel integration."

To engineering: "It's a Symfony bundle, not Laravel; its value is as a pattern reference for extractor scaffolding — config schema, auth, pagination, incremental state, error/exit-code handling, output manifests. If we adopt it, it lives as an isolated, Dockerized Keboola component invoked from Laravel over a queue job or internal HTTP — never inside the app's dependency graph. Before we take it as a dependency we need: license confirmation, a pinned commit forked into our VCS, a Composer-resolution spike against our runtime, a security review, and a named owner for upgrades. Expect ~1–2 weeks ramp for a mid-level PHP dev unfamiliar with Keboola, and plan per-extractor resource limits and exit-code mapping so failed jobs aren't misclassified and retried wrongly."

Bottom line for the roadmap: deprioritize the package as a dependency; elevate the underlying decision — how we do data ingestion — as the decision worth funding, and make the Keboola-vs-buy-vs-build call explicitly before any code is written.