Skip to content

PATTERN Cited by 1 source

Inner-sourced module extension

Pattern

Let teams outside the platform's owning team contribute new content types to a CMS-backed delivery platform as self-contained modules — where a "module" is an independently shippable bundle of:

  1. A new CMS entry-type (schema + authoring form + validation).
  2. A new proxy / aggregation mapping from that entry-type to the internal API contract.
  3. New delivery-side UI components (one per platform) rendering the new content type.

None of the existing modules, the platform's runtime, or other teams' work needs to change. The platform team reviews the contribution; the contributing team owns the new module's evolution.

Why it matters

Platforms succeed when they are extended by teams that do not own them. A content-management platform in particular cannot anticipate every content type a growing product roadmap needs. Making extension cost-efficient and review-gated — rather than either impossible (locked-down platform) or chaotic (fork-and-diverge) — is the inner-sourcing discipline the pattern operationalises.

Canonical wiki instance — Sustainability Certificate module

(Source: sources/2022-09-28-zalando-more-editorial-content-please)

The Sustainability team — not the original Zalando Marketing Services (ZMS) Landing Pages team — contributed the Sustainability Certificate module to Zalando's Landing Pages stack. The contribution touched exactly three layers:

No existing module, the Contentful instance itself, FSA, or the Rendering Engine platform had to change. The post frames the result explicitly:

"the implementation of the additional modules by the Sustainability team was a successful example of inner sourcing."

Properties the platform must have for this to work

  • Modular composition primitive — a page is composed of modules, and adding a module does not require changing other modules (concepts/cms-entry-type-modular-composition).
  • Cleanly separated layers — CMS schema, proxy mapping, and UI components are three independent extension points with known contracts between them.
  • Reuse of existing types where possible — the Sustainability Certificate module maps to the existing Collection GraphQL type rather than inventing a new one, reducing the consuming surface's cost to absorb the new module.
  • Review discipline — the platform team reviews the contribution; the contributing team owns the module post-merge.
Last updated · 550 distilled / 1,221 read