Independent Open-Source Support: What It Covers and What It Does Not

Many teams run open-source data platforms in production without a vendor behind them. Some want help when something breaks at night. The question we hear most often is simple: if Bassirah does not own the project, what exactly are we buying? This post answers it the way our Open-Source Support Model does.

We commit to what our engineers control

We are an independent provider. We do not own, maintain or sell any of the open-source projects we support, and we never present ourselves as if we did. That shapes every commitment. Our agreements commit to response and update times, because those depend on us. Restoring service is pursued with commercially reasonable effort, because it can depend on things outside our reach. Code fixes and release dates belong to each project’s community.

Workaround first, permanent fix second

When a production system has a problem, the first job is to restore service. That usually means configuration changes, a rollback, a failover or more capacity. Finding and fixing the root cause comes second, and it can take longer.

When the root cause is in the project’s code

If the cause is a defect in the open-source code itself, our part is clear and finite:

1. Confirm the defect and build a minimal reproducible case.
2. Provide a workaround or mitigation where one exists.
3. File the issue in the project’s public tracker, or link an existing one, and share the link.
4. Track it and report its status monthly.
5. Apply the fix through your change process once the community releases it.

Private patches and backports of security fixes are not part of any support package. Where they are needed, they can be scoped as a separate professional service.

Severity follows business impact

We agree the severity of a case with you when it opens, based on the impact on your business rather than on how interesting the problem is. A production outage with no workaround is the most severe. Non-production systems are handled at a lower severity, and feature requests or upstream defects that already have a working workaround sit at the lowest. Once a workaround restores service, we lower the severity together and continue on the permanent fix. A case also moves up two escalation tracks at the same time: engineering depth for the problem, and management attention for you, so a difficult case is never only one engineer’s concern.

Which versions are covered

A version is in scope only while its upstream project still maintains it, and each agreement lists the exact versions. When a version reaches end of life upstream, it moves to best effort, and we pass on the notice with a recommended upgrade path. Commercial editions of the same technologies follow the vendor’s own support terms through the partner route, not ours.

What we need from you

Support works when both sides can act. For the most severe cases, that means a contact who is available throughout the incident and access to the affected system. Infrastructure we do not operate, code modified outside the agreement and missing backups are outside our response commitments, although we may still help on a best-effort or billable basis.

Why we draw the line this way

Support for open-source software is only useful if its promises can be kept. Promising a fix date for code we do not control would sound better and mean less. Stating the boundary up front lets you plan: what Bassirah will do, what the community will do, and what stays with your own team. A monthly report keeps that boundary visible, with cases, response performance, open upstream issues and relevant security advisories.

How Bassirah can help

If you run open-source data platforms in production, we can review your current setup, agree the versions and severity rules that fit your workloads, and propose a support package or a managed platform agreement.