OPEN SOURCE · SUPPORT MODEL
Open-Source Support With Clear, Honest Commitments.
Bassirah is an independent support provider. We do not own the projects we support, so we commit to what our engineers control: responding, diagnosing, restoring service and working the issue upstream. Code fixes and release dates stay with each project’s community, and we say so up front.
Independent engineering support · Response commitments · Transparent upstream boundaries
WHAT WE COMMIT TO
We Commit to What Our Engineers Control
Our service agreements guarantee response and effort, not outcomes that depend on someone else. That keeps every commitment one we can actually keep.
| Bassirah commits to | Bassirah does not commit to |
|---|---|
| Initial response targets by severity, published below | Resolution or restoration times |
| Regular updates while a case is open | Upstream fix, merge or release dates |
| Diagnosis, root-cause analysis and workarounds | Patches for versions the community no longer maintains |
| Filing and following upstream issues on your behalf | Acceptance of a fix or feature by the community |
| Configuration, tuning and runbook fixes in environments we can access | Outcomes on infrastructure, clouds or third-party tools we do not operate |
Bassirah’s open-source support is independent engineering. It does not imply endorsement by project maintainers, foundations or vendors, and it does not include vendor support rights, vendor security fixes or licensed enterprise features.
PRINCIPLES
Six Principles Behind Every Agreement
Independent provider
We are not the owner, maintainer or vendor of any project we support, and we never present ourselves as one.
Response, not outcome
Agreements guarantee response and update times. Restoration is pursued with commercially reasonable effort.
Workaround first
For a production problem we restore service first, by configuration, rollback, failover or capacity. The permanent fix comes second.
Upstream is best effort
Code defects go to the project with a reproducible case. We track them and apply the fix once the community releases it.
Community-maintained versions
Coverage follows each project’s own release and end-of-life policy, and your agreement names the versions in scope.
Transparent reporting
A monthly report shows cases, response performance, open upstream issues and relevant security advisories.
HOW A CASE FLOWS
From Your First Call to the Upstream Fix
Every case follows the same path. The steps in solid blue are ours to commit to; the community’s fix and release run on the project’s own timeline.
WHO DOES WHAT
A Clear Split of Responsibilities
We own diagnosis and restoration in environments we can reach. The community owns the code. You own your infrastructure, data and change approvals.
| Activity | Bassirah | Upstream community | Customer |
|---|---|---|---|
| Logging a case with severity and evidence | Consulted | — | Responsible |
| Triage, diagnosis and root-cause analysis | Responsible | — | Consulted |
| Workaround or configuration fix | Responsible | — | Approves the change |
| Code fix in the project | Reports and follows up | Responsible, at its discretion | Informed |
| Release and security patch publication | Informed | Responsible | Informed |
| Applying a released patch or upgrade | Responsible when in contract scope | — | Approves the window and rollback decision |
| Backups, restore tests and data integrity | Advises, and verifies if contracted | — | Responsible |
| Infrastructure, cloud, network and operating system | Advises | — | Responsible, or its provider |
| Third-party plugins and connectors | Best effort | Their own maintainers | Responsible for the choice |
| Feature requests | Files and advocates upstream | Decides | Informed |
Under a managed platform agreement, Bassirah also takes responsibility for applying patches and routine operations. Upstream code still belongs to the community.
SUPPORT PACKAGES AND COVERAGE
Four Packages, One Boundary With Upstream
Packages scale coverage and hands-on scope. The line between what Bassirah controls and what the community controls stays the same in every package.
| Package | Purpose | Coverage | Hands-on scope |
|---|---|---|---|
| Architecture Advisory | Architecture and best-practice guidance | Business hours | Advice only, no production changes |
| Platform Care | Break-fix support for a self-managed platform | Business hours | Remote diagnosis and workarounds with access you grant |
| Enterprise Operations | Production support plus proactive care | Extended hours for Severity 1–2; business hours otherwise | Adds health checks, patch planning and a named engineer |
| Mission-Critical Managed Platform | Bassirah operates the platform | 24×7 for Severity 1; extended hours for Severity 2; business hours otherwise | Adds monitoring, patching, upgrades and runbook execution |
- Business hours: 09:00–17:00 in your contracted support region’s time zone (Cairo, Dubai, Riyadh or London), on that region’s working days, excluding public holidays.
- Extended hours: 08:00–22:00, seven days a week, in the same time zone.
- Official channels: cases are opened through the support portal or support email named in your agreement, and critical cases are also phoned in. Messages to individual staff do not start the clock.
- What counts as a response: a named Bassirah engineer acknowledges the case through an official channel and starts work. Automated receipts do not count.
- The clock pauses while we wait for information, access or approval from you, or for an upstream release.
Initial response targets
| Severity | Architecture Advisory | Platform Care | Enterprise Operations | Mission-Critical Managed Platform |
|---|---|---|---|---|
| Severity 1 — Critical | Not covered | 2 business hours | 1 hour, extended hours | 30 minutes, 24×7 |
| Severity 2 — High | Not covered | 4 business hours | 2 hours, extended hours | 1 hour, extended hours |
| Severity 3 — Medium | 2 business days | 1 business day | 8 business hours | 4 business hours |
| Severity 4 — Low | 3 business days | 2 business days | 2 business days | 1 business day |
Response is the only guaranteed time.
Targets are measured within each package’s coverage hours, from the moment a complete case reaches an official channel. Your service agreement confirms the package, coverage and any service credits. Restoration is always a best-effort objective, never a guaranteed time, and upstream fixes have no committed date.
SEVERITY LEVELS
Severity Is Set by Business Impact
We agree the severity with you when a case opens, and lower it once a workaround restores service.
| Severity | Definition | Examples |
|---|---|---|
| Severity 1 — Critical | Production is down or data is at immediate risk, with no workaround | A PostgreSQL primary will not start; a Cassandra cluster loses quorum; the Trino coordinator is unavailable to all users |
| Severity 2 — High | Production is badly degraded or a critical function is lost; a workaround may exist | ClickHouse queries run several times slower after an upgrade; a MongoDB replica set runs without a secondary |
| Severity 3 — Medium | Partial, non-critical loss of function, or any non-production outage | A dbt Core job fails in staging; DataHub ingestion fails for one source |
| Severity 4 — Low | Question, guidance, documentation or feature request | Sizing advice; configuring a connector; a request for a new upstream feature |
- Severity 1 needs a customer contact available throughout the incident and access to the affected system.
- Non-production systems are handled at Severity 3 or lower.
- Feature requests, and upstream defects with a working workaround, are Severity 4.
UPSTREAM DEFECTS AND SECURITY
When the Root Cause Is in the Project's Code
Our commitment ends at a reproducible report, a workaround where one exists, and applying the fix once the community ships it.
Code defects
- Confirm and reproduceWe confirm the defect and build a minimal reproducible case.
- MitigateWe provide a workaround or mitigation where one exists.
- Report upstreamWe file the issue in the project’s public tracker, or link an existing one, and share the link with you.
- TrackWe follow the issue and report its status monthly until it is released or closed upstream.
- ApplyOnce released, we apply or schedule the fix through your change process.
Security vulnerabilities
- We monitor public advisories for the projects in scope and tell you about relevant ones, with an impact view and mitigations.
- We do not commit to a patch date. Patches come from the project, on the project’s schedule.
- Vulnerabilities we discover are disclosed privately to the project under its own security policy.
- Under a managed platform agreement, applying a released security patch is scheduled as a priority change, subject to your approval of the window.
Private patches and backports are not part of any package. Where needed, they can be scoped as a separate professional service.
SCOPE AND VERSIONS
Projects and Versions in Scope
A version is in scope only while its upstream project still maintains it. Your agreement lists the exact versions covered.
| Project | Upstream steward | Licence |
|---|---|---|
| Trino | Trino Software Foundation and community | Apache 2.0 |
| ClickHouse (open source) | ClickHouse, Inc. and community | Apache 2.0 |
| dbt Core | dbt Labs and community | Apache 2.0 |
| DataHub | DataHub project community | Apache 2.0 |
| PostgreSQL | PostgreSQL Global Development Group | PostgreSQL Licence |
| MongoDB Community Server | MongoDB, Inc. | SSPL (source-available) |
| Apache Cassandra | Apache Software Foundation | Apache 2.0 |
| Apache Superset | Apache Software Foundation | Apache 2.0 |
| YugabyteDB | YugabyteDB, Inc. and community | Apache 2.0 (core database) |
- End-of-life versions move to best effort, with no response targets, when upstream support ends. We pass on the notice as soon as upstream announces it, with a recommended upgrade path.
- Commercial editions such as Starburst, ClickHouse Cloud, MongoDB Atlas or Enterprise Advanced, and dbt Cloud follow the partner route and the vendor’s own support terms.
- Forks and custom builds are in scope only when Bassirah built or approved them in writing.
BOUNDARIES
Exclusions and What We Need From You
Outside response commitments
- Versions past upstream end of life, or not listed in your agreement
- Code modified by you or a third party, and unofficial builds
- Third-party plugins, connectors and drivers not named in your agreement
- Features found only in commercial editions
- Outages of infrastructure, cloud, network or operating systems we do not operate
- Data loss from missing backups or untested restores
- Delays while access, approval or a contact is unavailable
- Upstream code fixes, release schedules and patch dates
- Development, migration, upgrade projects and training, which are separate services
We may still help with these on a best-effort or billable basis.
Prerequisites
- An onboarding health check of each covered environment before support starts
- Each covered cluster or instance listed with its version and topology
- Agreed remote access, tested at onboarding
- Named contacts who can open cases, and a contact available during critical incidents
- Logs, metrics and configuration shared on request
- Working backups and regularly tested restores, unless your managed agreement transfers this to Bassirah
- A non-production environment for testing upgrades
- Staying on an in-scope version and applying recommended patches
ESCALATION AND REPORTING
Two Escalation Tracks, One Monthly Report
A case moves up two tracks at once: engineering depth for the problem and management attention for you. The final step is upstream, which we can request but not direct.
| Level | Engineering track | Management track |
|---|---|---|
| 1 | Support engineer | Support lead |
| 2 | Senior or specialist engineer for the project | Service delivery manager |
| 3 | Principal engineer or architect | Chief Technology Officer |
| Upstream | Project issue tracker, mailing list or security contact | Account owner keeps you informed |
- Monthly report: cases by severity, response performance, time to restore for information, open upstream issues with links, relevant advisories and effort used.
- Quarterly review for Enterprise Operations and Mission-Critical agreements: trends, recurring causes and the upgrade and end-of-life roadmap.
- Written summary after every critical incident.
Frequently Asked Questions
Do you guarantee how fast an issue will be fixed?
No. We guarantee how fast we respond and keep you updated, and we work to restore service with a workaround as quickly as we can. A permanent code fix may depend on the project’s community, so we never promise its date.
What happens if the problem is a bug in the open-source project?
We confirm it, give you a workaround where one exists, report it upstream with a reproducible case, track it, and apply the fix once the community releases it.
Do you publish standard response times?
Yes, for initial response. The targets table shows them by package and severity. We do not publish restoration or resolution times, because a permanent fix can depend on the project’s community.
What are your business hours?
09:00–17:00 in your contracted support region’s time zone (Cairo, Dubai, Riyadh or London), on that region’s working days. Enterprise Operations adds extended hours (08:00–22:00, seven days) for Severity 1–2, and Mission-Critical Managed Platform adds 24×7 cover for Severity 1.
Do you support versions that have reached end of life?
On a best-effort basis only, without response targets. We tell you as soon as upstream announces an end-of-life date and recommend an upgrade path.
Is MongoDB Community Server open source?
MongoDB Community Server is source-available under the Server Side Public License (SSPL). We support it independently. For MongoDB Atlas or Enterprise Advanced, see our partner-led MongoDB route.
Talk to Us About Supporting Your Open-Source Platforms
Start with a health check of your current deployment. We will recommend a package and agree the service levels that fit it.