This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Strategy

This is the documentation for the Naftiko revenue strategy, publishing the plans for how we intend to commercialize our open-source framework and engine using an intentional and well thought out fabric that is commercialized around many different open-source building blocks.

1 - Plans

These are all of the plans we are current developing as part of the commercial open-source offerings of Naftiko, being intentional and transparent with community how Naftiko intends on generating revenue as part of the fabric, working to define what the future of commercial open-source software (COSS) is.

1.1 - Integration

This is the integration plan for Naftiko Signals, targeting other integration providers to share and contribute to open-source artifacts like OpenAPI, AsyncAPI, JSON Schema, and others, establishing a community source of high quality integration patterns and workflows.

Type

  • Signals - This is Naftiko Signals plan.

Features

  • Workshops - Monthly workshops for domain, service, and workflow planning.
  • OpenAPIs - Partner on governed OpenAPI and Arazzo artifacts for any APIs.
  • Sandboxes - Partner on 3rd-party or internal API sandboxes for development.
  • Catalogs - Partner 3rd-party or internal API catalogs for development.

Pricing

  • Revenue Share - Establish a revenue share, or at least incentive model.

Notes

This plan is currently in the planning phase. This does not represent what is currently being offered from Naftiko, just documenting the plans in preparation for launch of Naftiko Signals. The goal here is to document the plans as the develop over time, being intentional and transparent about what goes into each plan, the features and the pricing.

If you have any questions about this plan, would like to provide feedback, ask questions, or get involved in early development as a design partner, please email contact@naftiko.io. We would like to hear from you early on about how your enterprise sees commercial open-source software pricing.

1.2 - Community

This is the community plan for Naftiko, providing an entry-level, but also perpetually open-source plan for engaging with the platform and acting as a formal member of the community, with access to the Naftiko Engine and Framework, but also the fabric of features and support for the community.

Type

  • Product - This is Naftiko product plan.

Features

  • OSS Framework - Access to the Naftiko open-source framework.
  • OSS Engine - Access to the Naftiko open-source engine.
  • Community Fabric - Access to resources in the community fabric.
  • Community Features - Access to all community features.
  • Community Support - Access to support via GitHub issue.

Pricing

  • Free - Always free access to the foundation of Naftiko.

Notes

This plan is currently in the planning phase. This does not represent what is currently being offered from Naftiko, just documenting the plans in preparation for launch of the Naftiko Framework and Engine. The goal here is to document the plans as the develop over time, being intentional and transparent about what goes into each plan, the features and the pricing.

If you have any questions about this plan, would like to provide feedback, ask questions, or get involved in early development as a design partner, please email contact@naftiko.io. We would like to hear from you early on about how your enterprise sees commercial open-source software pricing.

1.3 - Design

This is the design plan for Naftiko Signals, targeting enterprises who we have profiled as part of the research, or would like to be profiled as part of the research, helping define the domains, services, and ultimately capabilities that exist or need to exist within the enterprise.

Type

  • Signals - This is Naftiko Signals plan.

Features

  • Workshops - Monthly workshops for domain, service, and capability planning.
  • OpenAPIs - Provide governed OpenAPI and Arazzo artifacts for any APIs.
  • Sandboxes - Proving 3rd-party or internal API sandboxes for development.
  • Catalogs - Provide 3rd-party or internal API catalogs for development.
  • Domains - Establish common domain vocabulary for organizing integrations.
  • Capabilities - Development of capabilities to better define integrations.

Pricing

  • Contact - Pricing has not been established and we are open to conversations.

Notes

This plan is currently in the planning phase. This does not represent what is currently being offered from Naftiko, just documenting the plans in preparation for launch of Naftiko Signals. The goal here is to document the plans as the develop over time, being intentional and transparent about what goes into each plan, the features and the pricing.

If you have any questions about this plan, would like to provide feedback, ask questions, or get involved in early development as a design partner, please email contact@naftiko.io. We would like to hear from you early on about how your enterprise sees commercial open-source software pricing.

1.4 - Enterprise

This is the enterprise plan for Naftiko, providing the top level of access for Naftiko community members, beginning to get access to enterprise features and support, with pricing based upon a foundational platform fee combined with usage-based pricing for access to different resources.

Type

  • Product - This is Naftiko product plan.

Features

  • OSS Framework - Access to the Naftiko open-source framework.
  • OSS Engine - Access to the Naftiko open-source engine.
  • Community Fabric - Access to resources in the community fabric.
  • Enterprise Features - Access to all community features.
  • Enterprise Support - Access to support via GitHub issue.

Pricing

  • Capacity Pricing - Usage based pricing for resources.
  • Platform Fee - Base monthly fee for access to platform.

Notes

This plan is currently in the planning phase. This does not represent what is currently being offered from Naftiko, just documenting the plans in preparation for launch of the Naftiko Framework and Engine. The goal here is to document the plans as the develop over time, being intentional and transparent about what goes into each plan, the features and the pricing.

If you have any questions about this plan, would like to provide feedback, ask questions, or get involved in early development as a design partner, please email contact@naftiko.io. We would like to hear from you early on about how your enterprise sees commercial open-source software pricing.

1.5 - Market

This is the market plan for Naftiko Signals, targeting companies of all shapes and sizes who are more interested in the data being produced as part of Naftiko Signals, and would like to see research expanded into industries, or specific companies of interest in any domain.

Type

  • Signals - This is Naftiko Signals plan.

Features

  • Workshops - Monthly workshops for domain, service, and capability planning.
  • Industries - Expand Signals research into specific industries of interest.
  • OpenAPIs - Provide governed OpenAPI and Arazzo artifacts for available APIs.
  • Catalogs - Provide 3rd-party or internal API catalogs for development.
  • Domains - Establish common domain vocabulary for organizing integrations.
  • Data - Provide more access to Signals data to help satisfy market needs.

Pricing

  • Contact - Pricing has not been established and we are open to conversations.

Notes

This plan is currently in the planning phase. This does not represent what is currently being offered from Naftiko, just documenting the plans in preparation for launch of Naftiko Signals. The goal here is to document the plans as the develop over time, being intentional and transparent about what goes into each plan, the features and the pricing.

If you have any questions about this plan, would like to provide feedback, ask questions, or get involved in early development as a design partner, please email contact@naftiko.io. We would like to hear from you early on about how your enterprise sees commercial open-source software pricing.

1.6 - Service

This is the service plan for Naftiko Signals, targeting companies who have public or partner APIs they would like to make more easily accessible, reducing friction when onboarding by developers, and help make more appealing to a business audience by aligning with domain capabilities.

Type

  • Signals - This is Naftiko Signals plan.

Features

  • Workshops - Monthly workshops for domain, service, and capability planning.
  • OpenAPIs - Provide governed OpenAPI and Arazzo artifacts for available APIs.
  • Sandboxes - Proving 3rd-party or internal API sandboxes for development.
  • Catalogs - Provide 3rd-party or internal API catalogs for development.
  • Domains - Establish common domain vocabulary for organizing integrations.
  • Capabilities - Development of capabilities to better define integrations.

Pricing

  • Contact - Pricing has not been established and we are open to conversations.

Notes

This plan is currently in the planning phase. This does not represent what is currently being offered from Naftiko, just documenting the plans in preparation for launch of Naftiko Signals. The goal here is to document the plans as the develop over time, being intentional and transparent about what goes into each plan, the features and the pricing.

If you have any questions about this plan, would like to provide feedback, ask questions, or get involved in early development as a design partner, please email contact@naftiko.io. We would like to hear from you early on about how your enterprise sees commercial open-source software pricing.

1.7 - Standard

This is the standard plan for Naftiko, providing the next level of access for Naftiko community members, beginning to get access to premium features and support, with pricing based upon a foundational platform fee combined with usage-based pricing for access to different resources.

Type

  • Product - This is Naftiko product plan.

Features

  • OSS Framework - Access to the Naftiko open-source framework.
  • OSS Engine - Access to the Naftiko open-source engine.
  • Community Fabric - Access to resources in the community fabric.
  • Premium Features - Access to all community features.
  • Premium Support - Access to support via GitHub issue.

Pricing

  • Capacity Pricing - Usage based pricing for resources.
  • Platform Fee - Base monthly fee for access to platform.

Notes

This plan is currently in the planning phase. This does not represent what is currently being offered from Naftiko, just documenting the plans in preparation for launch of the Naftiko Framework and Engine. The goal here is to document the plans as the develop over time, being intentional and transparent about what goes into each plan, the features and the pricing.

If you have any questions about this plan, would like to provide feedback, ask questions, or get involved in early development as a design partner, please email contact@naftiko.io. We would like to hear from you early on about how your enterprise sees commercial open-source software pricing.

2 - Tooling

The open-source tooling we are building Naftiko on possess a variety of implications when it comes to how they fund work on tooling, and directly or indirectly commercialize on top of open-source. Our goal is to document the revenue implications of the tooling we are building upon, beginning with licensing, but also plans, pricing, and commercialization surrounding open-source, and using to shape the Naftiko revenue strategy.

2.1 - Docker

We are working to understand the open-source and commercial dimensions of the Docker ecosystem, understanding how Docker, and DockerHub as a distribution mechanism can also fit into the revenue strategy for Naftiko, shaping the deliver of commercial open-source software within the enterprise.

Individual unit of compute for delivering applications and integrations.

Docker provides a platform for developing, shipping, and running applications by packaging them into standardized units called containers. Containers are lightweight, standalone, executable packages that include everything needed to run an application—code, runtime, system tools, libraries, and settings. Docker enables developers to separate applications from infrastructure, allowing them to deliver software quickly and consistently. The platform uses a client-server architecture where the Docker client communicates with the Docker daemon, which handles the heavy lifting of building, running, and distributing containers. Containers are isolated from each other and the host system, yet they share the operating system kernel, making them much more efficient than traditional virtual machines. This means multiple containers can run simultaneously on a server, with containerized software running the same way regardless of the infrastructure—whether it’s on a local development machine, in a data center, or in the cloud.

Docker streamlines the entire development lifecycle by providing tools and workflows for continuous integration and continuous delivery (CI/CD). Developers can write code locally using containers that provide standardized environments, share their work with colleagues, push applications to test environments, and deploy to production with confidence that the application will work the same everywhere. Docker automates repetitive tasks like environment setup, dependency management, and image building, allowing developers to focus on writing code rather than troubleshooting configuration issues. The platform includes Docker Hub, a public registry containing thousands of pre-built container images that developers can use as starting points for their applications, and Docker Compose for defining and running multi-container applications. By improving resource utilization and enabling teams to ship code faster—Docker users ship software seven times more frequently than non-Docker users—Docker helps organizations reduce costs, accelerate development cycles, and build modern applications using microservices architectures.

License: Apache 2.0

Tags: Containers, Compute

Properties: Kubernetes-native control plane (CRDs, controllers), multi-cloud and SaaS provisioning via Providers, Managed Resources, Composite Resource Definitions (XRDs), Compositions, Claims (XRCs), Composition Functions, declarative GitOps workflows, fine-grained RBAC and namespace isolation, drift detection and continuous reconciliation, secret propagation to workloads, health/status via Conditions, policy and validation via OpenAPI schemas, package manager (OCI) for providers and compositions, versioning and upgrades with rollback, observability (events, metrics, logs), pluggable provider ecosystem (including Terrajet), cross-resource references and dependency ordering, cross-namespace publishing and claim binding, works with Helm/Kustomize/Argo CD/Flux

Website: https://www.docker.com/

2.2 - Backstage

We are interested in understanding the open-source and commercial dimensions of the Backstage ecosystem. It has showed up a lot in our market research, and provides a compelling way to reach the community in both open and commercial ways, and our goal is to understand and use to align with our revenue strategy.

Delivering internal developer portals.

Backstage is an open-source platform (created at Spotify and now a CNCF project) for building internal developer portals that centralize a company’s software ecosystem—services, data pipelines, websites, libraries, infrastructure, and more—into a single, searchable catalog. It provides opinionated building blocks like the Software Catalog, Software Templates (scaffolder) for “golden paths,” TechDocs for docs-as-code, and a rich plugin system so teams can surface CI/CD status, deployments, cost, ownership, and runbooks in one place. The goal is to tame sprawl, standardize workflows, and give developers a self-service hub that speeds delivery while improving reliability and governance.

License: Apache 2.0

Tags: Portals, Catalogs

Properties: Domains, Systems, Components, APIs, Resources, Groups, Locations, Templates

Website: https://backstage.io/

2.3 - Bruno

Bruno is an open-source, offline-first API client that stores collections as plain text files directly on your filesystem and uses Git for version control, providing a lightweight alternative to Postman for testing, debugging, and managing APIs while keeping your data local and private.

Open-source, GitOps, Local API Client

Bruno is an open-source, Git-friendly API client designed for developing, testing, and organizing API requests in a local, file-based environment. Unlike traditional tools like Postman or Insomnia that rely on cloud storage or proprietary formats, Bruno stores collections as plain-text files in a human-readable “.bru” format, making them easy to version, share, and collaborate on using Git. It supports REST, GraphQL, and other request types, along with features such as scripting, environment variables, and testing through lightweight JavaScript assertions. Built to be fast, offline-first, and privacy-respecting, Bruno provides a streamlined and developer-centric experience for managing APIs directly within existing source control workflows.

License: Apache 2.0

Tags: Client, Testing

Properties: Collections, Requests, Responses, Scripts, Tests, Automation

Website: https://www.usebruno.com/

2.4 - Microcks

Microcks is an open-source, cloud-native tool that turns API specifications (OpenAPI, AsyncAPI, gRPC, GraphQL, and others) into live mocks in seconds and performs contract conformance testing to verify that API implementations meet their contracts.

Mocking and contract testing for APIs using common API artifacts.

Microcks is an open-source, cloud-/Kubernetes-native tool for API mocking and contract testing that turns your existing artifacts—OpenAPI, AsyncAPI, gRPC/Protobuf, GraphQL schemas, Postman collections, SoapUI projects—into live mocks and reusable tests, with CI/CD integrations (Jenkins, GitHub Actions, Tekton). It supports both synchronous and event-driven APIs, connecting to brokers like Kafka, MQTT, AMQP/RabbitMQ, NATS, and WebSocket to validate payloads against your specs. Microcks is a Cloud Native Computing Foundation Sandbox project (accepted June 22, 2023).

License: Apache 2.0

Tags: Testing, Mocking

Properties: API mocking for REST/gRPC/GraphQL/SOAP, event-driven mocking & contract testing for Kafka/MQTT/AMQP-RabbitMQ/NATS/WebSocket (and other brokers), import from OpenAPI/AsyncAPI/Protobuf/GraphQL/Postman/SoapUI, schema-conformance testing with drift detection, smart dynamic mocks with on-the-fly transformations, GitHub Actions & CI/CD integration, Microcks REST API for automation, Kubernetes-native deployment via Helm and Operator, Avro + Schema Registry support on Kafka, organized repository & web UI for managing mocks and tests.

Website: https://microcks.io/

2.5 - Crossplane

Crossplane is an open-source framework for building cloud-native control planes that extends Kubernetes to orchestrate and manage applications and infrastructure across any cloud provider or environment without needing to write code, allowing platform engineers to create custom APIs that enable self-service infrastructure provisioning with built-in policies and guardrails.

Establish a control plane for infrastructure and APIs.

Crossplane is a CNCF project that turns Kubernetes into a universal control plane for infrastructure and platform APIs: cloud resources (databases, buckets, networks), SaaS, and even other clusters are modeled as Kubernetes custom resources and reconciled by providers for AWS, Azure, GCP, and more. Platform teams define higher-level, opinionated abstractions using XRDs and Compositions, publish them as installable packages, and expose safe “claims” so app teams can self-serve PostgreSQLs, queues, or whole app platforms via the same Kubernetes API they already use. This enables GitOps-friendly, declarative, multi-cloud provisioning with fine-grained RBAC, drift detection, and the ability to build bespoke internal platforms without writing bespoke controllers.

License: Apache 2.0

Tags: Control Plane, Infrastructure, Platform, APIs

Properties: Kubernetes-native control plane (CRDs, controllers), multi-cloud and SaaS provisioning via Providers, Managed Resources, Composite Resource Definitions (XRDs), Compositions, Claims (XRCs), Composition Functions, declarative GitOps workflows, fine-grained RBAC and namespace isolation, drift detection and continuous reconciliation, secret propagation to workloads, health/status via Conditions, policy and validation via OpenAPI schemas, package manager (OCI) for providers and compositions, versioning and upgrades with rollback, observability (events, metrics, logs), pluggable provider ecosystem (including Terrajet), cross-resource references and dependency ordering, cross-namespace publishing and claim binding, works with Helm/Kustomize/Argo CD/Flux

Website: https://www.crossplane.io/