Operations·December 2024·9 min read

Celebrating Innovation: Noteworthy Open Source Community Projects of 2025

Five open-source projects are doing real, verifiable work inside commerce stacks right now: Medusa, Saleor, and Vendure as commerce engines, OpenTelemetry as the observability layer wrapped around them, and Playwright for testing storefront and checkout flows. All five are active repositories with commits landing today, not press-release names that can't be found on GitHub.

A correction, first

An earlier version of this post named four "2025 open-source initiatives": an OpenAI decentralized AI framework, an environmental platform called GreenStack, a healthcare platform called HealthLink OS, and an education platform called EduHub. None of these correspond to a findable, active open-source repository or organization. They read like plausible-sounding descriptions rather than real projects, and repeating them here would fail the basic bar for a post about open source: that the software actually exists and can be inspected.

What follows instead is five projects verified live against GitHub's API at the time of writing, each one commerce-relevant, each one with a public commit history anyone can check. All five had commits pushed within the same 24-hour window this piece was drafted, which is a reasonable working definition of "actively maintained" for a dependency a commerce team plans to run in production.

The five, verified live

Project	What it is	License
Medusa	Headless commerce platform, TypeScript, built around a modular architecture for building custom commerce backends and, increasingly, commerce for AI agents	MIT
Saleor	High-performance, composable headless commerce API, Python and GraphQL	BSD-3-Clause
Vendure	Headless commerce platform built with TypeScript, NestJS, and GraphQL	GPLv3 (Community Edition), with a commercial license for proprietary use
OpenTelemetry Collector	Vendor-neutral pipeline for collecting, processing, and exporting telemetry, traces, metrics, and logs	Apache-2.0
Playwright	Cross-browser testing and automation framework covering Chromium, Firefox, and WebKit through one API	Apache-2.0

Why headless commerce engines, not monolithic platforms

Medusa, Saleor, and Vendure share a structural choice: commerce logic, catalog, cart, checkout, orders, lives behind an API rather than bundled with a fixed storefront template. Saleor exposes that through GraphQL as a composable headless commerce API by its own description (GitHub — saleor/saleor). Vendure follows the same pattern with a NestJS backend and GraphQL API (GitHub — vendure-ecommerce/vendure), and Medusa describes itself as commerce infrastructure aimed at both developers and, more recently, AI agents (GitHub — medusajs/medusa).

A headless commerce engine's real value isn't the storefront it ships with. It's that the catalog, cart, and order logic live behind an API a team can put any frontend, or any AI agent, in front of without rewriting the backend.

Medusa: commerce infrastructure built for the agentic layer too

Medusa is MIT-licensed and describes itself on GitHub as "the world's most flexible commerce platform for agents and developers," a framing that lines up with the agentic checkout protocols reshaping the broader e-commerce stack in 2026 (GitHub — medusajs/medusa, Medusa Documentation). It's a Node.js and TypeScript codebase, structured as a set of composable modules rather than a single monolith, which is the same architectural bet Saleor and Vendure make from different language ecosystems.

Saleor and Vendure: two takes on GraphQL-first commerce

Saleor is a Django and GraphQL commerce API, BSD-3-Clause licensed, and its own repository description calls it a high-performance, composable, headless commerce API (GitHub — saleor/saleor, Saleor). Vendure takes the same GraphQL-first approach on a Node.js and NestJS foundation, dual-licensed as GPLv3 for the Community Edition with a commercial license available for organizations that need to keep modifications proprietary (Vendure).

The license difference matters operationally. MIT and BSD-3-Clause, Medusa's and Saleor's licenses, impose essentially no restriction on how a modified version is distributed. GPLv3 requires that distributed modifications stay open under the same terms unless a commercial license is purchased, which is a real constraint to check before building proprietary extensions on top of Vendure's community edition.

Plugin and module systems as the actual extension point

All three engines extend through a plugin or module system rather than forking core code. Vendure's plugin architecture wraps NestJS's own module system, so a plugin can register new GraphQL resolvers, database entities, and background jobs without touching the core codebase directly. Medusa's module system follows the same principle in a different framework, isolating commerce domains, pricing, inventory, fulfillment, so a team can swap or extend one module without destabilizing the rest.

The practical implication: a fork of any of these three projects is almost always the wrong first move. A plugin or module built against the documented extension points survives an upstream version upgrade; a fork has to be manually rebased against every release indefinitely.

OpenTelemetry: the observability layer commerce stacks actually standardized on

OpenTelemetry reached CNCF graduated status, the foundation's highest maturity tier, and its Collector component is the piece most commerce teams deploy directly: a standalone service that receives telemetry from application code and routes it to whichever backend a team uses for storage and analysis (GitHub — open-telemetry/opentelemetry-collector, OpenTelemetry — Specification).

For a commerce backend built on Medusa, Saleor, or Vendure, the Collector sits outside the commerce engine itself, instrumenting checkout latency, payment gateway call duration, and inventory-service response times without vendor lock-in to a single monitoring provider. That vendor neutrality is the actual reason it displaced a generation of proprietary agent-based APM tools.

Semantic conventions matter more than the Collector binary

OpenTelemetry's semantic conventions define a standard vocabulary for what a span or metric is named and what attributes it carries, so an HTTP request span looks the same whether it's emitted from a Node.js checkout service or a Python inventory service (OpenTelemetry — Semantic Conventions). Without that shared vocabulary, every team ends up naming the same concept, order total, checkout duration, differently, and dashboards built across services stop lining up.

A trace, the unit OpenTelemetry uses to represent one request's full journey through a system, is what actually lets a team follow a single checkout call from the storefront through the commerce engine, the payment gateway, and back (OpenTelemetry — Traces). Instrumenting a Medusa, Saleor, or Vendure deployment with OpenTelemetry from day one, rather than retrofitting it after a production incident, is the difference between a five-minute root-cause investigation and a multi-hour one across service boundaries.

A commerce stack built on open source: a commerce engine at the center (Medusa, Saleor, or Vendure), wrapped by an OpenTelemetry-instrumented observability layer, with Playwright running end-to-end checks against the storefront and checkout flows the engine powers.

Playwright: the testing layer commerce teams standardized on for checkout

Playwright automates Chromium, Firefox, and WebKit through a single API, which matters specifically for checkout flows that need verification across every rendering engine a real customer might use (GitHub — microsoft/playwright, Playwright). It's Apache-2.0 licensed and maintained by Microsoft, with commits landing continuously.

A checkout flow that only gets tested in one browser engine is a checkout flow with an unverified failure mode waiting in whichever engine wasn't tested. Cross-browser coverage isn't optional for a payment flow; it's the actual point of running an automated suite instead of manual spot checks.

Trace-first debugging changes how a failing test gets fixed

Playwright's trace viewer records a full timeline of a test run, DOM snapshots, network requests, and console output, that can be replayed after the fact instead of re-running a flaky test locally to catch the failure a second time. For a checkout suite running in CI, that's the difference between a five-minute trace review and an afternoon spent trying to reproduce an intermittent failure that only shows up on the CI runner.

Wiring Playwright's checkout suite into the same CI pipeline that deploys Medusa, Saleor, or Vendure, and feeding the commerce engine's OpenTelemetry traces into the same observability backend that stores test results, closes the loop: a failing checkout test and a checkout latency regression become visible in the same place, on the same commit.

How to vet an open-source dependency before betting a commerce stack on it

Star count is the least useful signal available, and it's also the one most often quoted. These are the checks that actually predict whether a project stays maintained:

Star count measures past attention, not present maintenance. Commit recency, issue triage speed, and a documented upgrade path are what predict whether a dependency is still alive in eighteen months.

Check commit recency directly on the repository, not a cached badge, before assuming a project is active.
Read the license text, not just its name. GPL, LGPL, and Apache-2.0 carry materially different obligations for a business building on top.
Check open issue count against issue close rate, a large and growing backlog with no triage is a maintenance warning sign.
Confirm governance: is there a company behind it with a commercial incentive to keep maintaining it, a foundation, or a single unpaid maintainer.
Read the actual documentation site, not just the README, to gauge whether the project treats external users as a real audience.
Check whether the project has a documented upgrade path between major versions, since a commerce backend that can't be upgraded safely accumulates security debt fast.

Commerce engine choice: match the license and language ecosystem to the team's actual stack, not the project with the most GitHub stars.
Observability: standardize on OpenTelemetry's vocabulary even if the backend storage changes later, since the instrumentation code doesn't have to be rewritten.
Testing: run checkout and payment flow tests across all three engines Playwright supports, not just the team's default development browser.

FAQ

Are Medusa, Saleor, and Vendure interchangeable?

No. They differ in language ecosystem (Node/TypeScript for Medusa and Vendure, Python/Django for Saleor), API style, and license terms. The right choice depends on the team's existing stack and whether GPLv3's copyleft terms are acceptable for the intended use.

Is Vendure's GPLv3 license a problem for a commercial storefront?

Only if the business needs to keep its modifications to Vendure's core proprietary. Running an unmodified or lightly-configured instance to power a storefront doesn't trigger the same obligations as distributing a modified, closed version of the software itself. Vendure also offers a commercial license for cases where that matters.

Why OpenTelemetry instead of a proprietary APM tool?

Vendor neutrality. Instrumentation written against OpenTelemetry's API doesn't need to be rewritten if the team switches observability backends later, which isn't true of code instrumented directly against a single vendor's proprietary agent.

Does Playwright replace manual QA for checkout flows?

It replaces the repetitive cross-browser regression checks that don't need human judgment. Manual QA still matters for new checkout features and edge cases a test suite hasn't been written for yet.

What happened to the projects named in the original version of this post?

They couldn't be verified as real, active open-source repositories. This rewrite replaces them with five projects confirmed live against GitHub's API, each with a public commit history and a real maintaining organization behind it.

References

From the Destm engineering archive. For current work on this topic, start at Solutions or the blog.