Open-Core Distribution Plan

Decision: keep core and runner as private commercial deliverables, and open the plugin SDK, plugin contract, examples, and marketplace-facing metadata.

Goals

Protect commercial differentiation in workflow orchestration, policy, tenant management, and runner control.
Let third parties build plugins in any language that can satisfy the HTTP/JSON contract.
Distribute deployable artifacts through OCI images instead of shipping the private source tree.
Build a plugin ecosystem without exposing the full control-plane implementation.

Distribution model

Private commercial layer

core image
- registry: ghcr.io/<org>/aisopsflow-core
- visibility: private
runner image
- registry: ghcr.io/<org>/aisopsflow-runner
- visibility: private
private deployment bundles
- production compose / helm / swarm templates
- enterprise operational defaults
private docs
- customer install guide
- support runbook
- commercial feature matrix

Public extension layer

plugin-sdk
- language-neutral spec
- signing/auth helpers
- request/response schema
example plugins
- channel-slack
- channel-email
- channel-telegram
- kakao-provider-mock
- kakao-webhook-simulator
plugin test kit
- conformance tests
- local mock harness
plugin catalog metadata
- manifests
- compatibility matrix
- verified badge metadata

Recommended repository split

Repo 1: private product repo

name example: aisopsflow-enterprise
visibility: private
contains:
- core/
- runner/
- production deployment packaging
- internal-only docs
- enterprise roadmap / integration scripts

Repo 2: public SDK and examples repo

name example: aisopsflow-plugin-sdk
visibility: public
contains:
- protocol docs
- JSON schemas
- signing/auth reference implementations
- example plugins
- plugin manifest spec
- conformance suite

Repo 3: public plugin catalog repo

name example: aisopsflow-plugin-catalog
visibility: public
contains:
- reviewed plugin index
- compatibility records
- plugin metadata
- docs for publishing and verification

Registry split

Private GHCR packages

ghcr.io/<org>/aisopsflow-core
ghcr.io/<org>/aisopsflow-runner
tags
- semantic version: v1.2.0
- channel tags: stable, rc, dev
access
- customer robot account or short-lived registry credential
- per-customer entitlements if needed

Public GHCR packages

ghcr.io/<org>/aisopsflow-plugin-sdk-base if a base image is useful
verified first-party plugins
optional language helper images

Third-party plugin packages

preferred: publisher-owned registry namespace
- example: ghcr.io/acme/aisopsflow-plugin-jira
alternative: marketplace-managed mirror after verification

License split

Private code

commercial EULA / proprietary license
applies to:
- core
- runner
- non-public operational packaging

Public SDK and examples

recommended:
- SDK/spec/testkit: Apache-2.0
- examples/templates: MIT
why:
- permissive licenses reduce friction for plugin builders
- Apache-2.0 is safer if protocol helpers may be reused in vendor products

Plugin publisher choice

third-party publishers choose their own source license
marketplace requirement should focus on:
- manifest compliance
- security scan
- compatibility declaration
- OCI signing

Required public contract

This model only works if the extension contract is stable and explicit.

Must be public:

plugin HTTP endpoint definitions
request/response examples
authentication and signature spec
timeout and retry expectations
version compatibility rules
manifest schema
conformance test requirements

Must remain private:

internal scheduling/orchestration implementation
policy engine internals
tenant/rbac internals beyond published API semantics
core-runner operational control logic

Versioning model

Use three independent version tracks.

Product version

version of core and runner

Plugin contract version

version of Runner↔︎Plugin HTTP/JSON contract
example: plugin_api_version: v1

Plugin package version

version of a specific plugin image

A plugin manifest should declare:

api_version: v1
plugin_name: jira-ticket
plugin_version: 1.4.2
compatibility:
  core:
    min: 1.2.0
    max: 1.x
  runner:
    min: 1.2.0
    max: 1.x
capabilities:
  - outbound_http
  - notify

Operational model

Install flow

customer pulls private core and runner images from GHCR
customer deploys public or third-party plugin images
customer registers plugin image references in AisOpsFlow
platform validates:

signature
manifest
compatibility
required capabilities

Recommended trust model

Do not accept arbitrary source uploads to the platform.

Prefer:

publisher builds OCI image
publisher signs image
customer references image digest
platform validates and runs it under policy

Security requirements for marketplace-ready plugins

signed OCI images
immutable digest pinning
SBOM attachment
vulnerability scan
minimal container base image
non-root runtime
explicit outbound network capabilities
strict internal auth verification

Migration path from current repo

carve out public plugin SDK/spec from current repo
freeze a v1 plugin contract
move first-party plugins to public examples repo
keep core and runner in private repo
publish first-party plugin images and manifest examples
add conformance tests and verification badge flow

Recommendation

Use an open-core model, but do not open the marketplace before the contract is stable.

The practical order should be:

freeze plugin contract
publish SDK/spec/examples
publish first-party plugin manifests and signed images
launch private beta for third-party plugins
open public catalog only after verification tooling exists