Status: Proposed
Date: 2025-08-22
Authors: Symphony Architecture Team
We need to decide whether to distribute Symphony's external extension APIs (Instruments, Operators, Motifs) as three separate Rust crates or as one unified crate with optional features. This decision will impact developer experience, build performance, ecosystem growth, and maintenance overhead for Symphony's extension marketplace. The choice will affect how thousands of extension developers interact with Symphony's platform and directly influences our business model success.
Symphony's external extension system consists of three distinct types of extensions, each serving different purposes and developer communities:
Our target extension developers fall into distinct categories: 60% are AI/ML engineers focused solely on model integration, 25% are data engineers building processing utilities, and 15% are full-stack developers creating comprehensive workflows. Early feedback from prototype testing indicates strong developer preference for focused, specialized APIs rather than comprehensive toolkits.
The extension marketplace is critical to Symphony's business model, targeting 15%+ revenue contribution by Year 2 through marketplace commissions and premium extensions. Developer experience directly impacts ecosystem growth, with build times and dependency management being primary friction points identified in user research.
Current technical constraints include Rust's additive feature system limitations, where features cannot truly eliminate dependencies from the compilation graph. Performance requirements demand sub-5% overhead for extension loading and <100ms initialization times to maintain Symphony's orchestration speed advantages.
We will distribute external extension APIs as three separate Rust crates: symphony_instruments, symphony_operators, and symphony_motifs.
Each crate will depend on a shared private symphony_core crate containing common traits and Orchestra Kit integration utilities: