FOSS first
Audience
PLANA staff making technology choices, partners proposing integrations.
PLANA Pulse is built on free and open-source software. This is not a marketing position; it is an operational rule that shapes how we pick tools, accept dependencies, and respond to vendor proposals.
The rule
Before adopting any third-party software, the answer to "is there a reasonable FOSS alternative we can self-host?" must be yes — or there must be a written exception.
Why
- Cost predictability. No per-seat or per-tenant pricing surprises as we grow. Operational cost goes up with usage; license cost stays flat at zero.
- Data control. Self-hosted FOSS means our customers' data sits in our Sofia cluster, not in a third-party SaaS. This is a hard requirement for our compliance posture.
- No vendor lock-in. Migration off a FOSS tool is bounded (port data + change config); migration off a closed SaaS often involves negotiating data export contracts.
- Bug fix latency. When we hit a bug in a FOSS dependency, we can patch it. When we hit one in a proprietary tool, we wait for the vendor.
- Community-aligned values. Our software extends Odoo Community and OCA — both communities expect contributions back. A FOSS-first stack makes contributing the default rather than a special activity.
What this means in practice
Tools we use
Every long-running component is FOSS and self-hosted:
| Category | Choice |
|---|---|
| Git host | Forgejo |
| CI runner | Forgejo Actions |
| Container registry | Forgejo |
| Image builds | Kaniko |
| Identity | Authentik Community |
| Secrets vault | Vaultwarden + SOPS |
| Documentation portal | VitePress |
| Design | Penpot |
| Chat | Matrix Synapse + Element |
| Mailu | |
| Office / file sync | Nextcloud + Collabora + Talk |
| Analytics | Matomo |
| Database | PostgreSQL, Valkey (Redis fork) |
| Ingress | Envoy Gateway |
| Provisioning | Crossplane |
| GitOps | Flux v2 |
| Observability | Prometheus, Grafana, Loki |
| WAF | Coraza |
| IDS | CrowdSec |
| ERP | Odoo Community + OCA modules |
The cluster itself runs on Exoscale SKS, which is closed-source on the management plane but Kubernetes-API-compatible on the data plane. We accept this — Kubernetes is the abstraction layer; the management plane is replaceable.
Vendor exceptions
A small set of exceptions, each justified:
| Tool | Why proprietary |
|---|---|
| Anthropic Claude API | No open-source model at Claude's reasoning level today; cost of running comparable local inference is multiples of the API price |
| Stripe | Payment processing requires acquirer relationships that are not self-hostable |
| Exoscale managed services (SKS, SOS, DNS) | The "managed" parts; we run open-source workloads on top |
| The 10 Bulgarian banks (PSD2) | Banks are not FOSS; the Berlin Group standard is open |
| Mobile push providers (APNs, FCM) | Apple and Google control the channels; no FOSS alternative reaches iOS / Android devices |
Each exception is justified on cost or impossibility, not on convenience.
The Bitnami rule
We do not use vendor-rebranded images of upstream software (Bitnami, Aiven, ScaleGrid container images). The rule:
Use the official upstream image of the project, or build our own. Bitnami and similar vendor builds are rejected.
Reasons:
- Vendor builds add their own patches, change defaults, and introduce a reliance on the vendor's release cadence
- The vendor can change the licence at any time (Bitnami did in 2023)
- Upstream maintainers should be the authority on how their software is packaged
The exception process: if a project has no official image, we either:
- Build from source in our own Dockerfile, or
- Use a small, trusted, community-maintained image (e.g. nginxinc, bitnami-shellscripts — never bitnami-images)
This is enforced by review on every new Deployment manifest. The documentation lives at this page and as a CLAUDE-readable feedback memory.
The OCA rule
For Odoo:
Before writing a custom Odoo module, check whether OCA already has one. PLANA modules are a thin layer above OCA, not a parallel implementation.
This applies even when an OCA module is awkward or under-documented. We contribute upstream rather than fork. The exceptions — modules where we maintain a OCA-fork/<repo> with branches 17.0-planapulse, 18.0-planapulse, 19.0-planapulse — are limited and each has a specific reason.
Asking the FOSS question
When evaluating new software, the FOSS question is:
- Does a FOSS alternative exist?
- If yes, can we self-host it on our cluster within ~1 week of engineering?
- If self-hosting is impractical, is there a SaaS option that:
- Hosts in the EU
- Provides a DPA
- Offers an open data export path
If all three are no, we write a vendor exception with the justification and the planned exit ramp.
When to break the rule
The rule is rigid but not absolute. Cases where breaking it is OK:
- Existential threat to time-to-market. A specific customer commits to ARR of >€100k contingent on a specific proprietary integration — ship the integration, plan a FOSS-equivalent replacement on a 12-month horizon.
- Regulatory requirement. A regulator requires a specific certified product (e.g. an HSM for some key signing use case) — buy the certified product.
- Domain expertise we cannot reproduce. Some areas (banking fraud detection, specific tax-engine implementations for non-Bulgarian countries) are so specialised that buying the product is correct.
When in doubt, the rule applies. Errors of inclusion (adding a FOSS tool we don't quite need) are much cheaper than errors of exclusion (locking into a vendor we later have to migrate from).
Where to read more
- Data residency — the policy that comes from FOSS-first when applied to data
- Architecture → Tech stack — the list of what we use
- Architecture → Shared infrastructure — the FOSS tools we self-host
- The
feedback_no_outside_vendors.mdandfeedback_oca_first.mdmemories codify this as a per-conversation operating rule