Concepts

The Open Subsurface Data Universe (OSDU) project presents a fundamental architectural challenge for cloud providers who need to maintain both open-source compatibility and proprietary cloud-specific implementations. This challenge centers on the effective separation and management of Service Provider Interface (SPI) code.

OSDU defines a structured architecture where community standards must remain separate from cloud-specific implementations. The diagram below illustrates how Microsoft maintains this separation through forking:

graph TB
    subgraph Community["OSDU Community Repository - Upstream"]
        A1[API] --- B1[Core Code] --- C1[SPI Interface] --- D1[Community Implementation]
    end

    Community -->|Synced Fork| Fork

    subgraph Fork["Azure SPI Repository"]
        A2[API] --- B2[Core Code] --- C2[SPI Interface] --- D2[Azure Implementation]
    end

    style Community fill:#e8f5e9,stroke:#1b5e20,stroke-width:2px
    style Fork fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
    style C1 fill:#fff3e0,stroke:#e65100,stroke-width:2px
    style C2 fill:#fff3e0,stroke:#e65100,stroke-width:2px
    style D1 fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    style D2 fill:#e3f2fd,stroke:#1565c0,stroke-width:2px

The SPI Interface (highlighted in orange) serves as the critical boundary where community-defined standards meet cloud-specific implementations. Everything to the left must stay synchronized with upstream, while only the implementation layer (rightmost) contains Azure-specific code.

Open Source Components include OSDU core interfaces, community-validated business logic, standard data models, and reference implementations for testing.

Azure-Specific Components encompass Azure SPI layer implementations, Azure-native service integrations, proprietary optimizations, and Microsoft-specific configuration and deployment patterns.

The Fork Management Problem

Maintaining long-lived forks of upstream OSDU repositories creates several critical challenges that compound in enterprise environments:

Traditional vs. Automated Approach

The Automation Solution

The fork management system implements controlled isolation through a three-branch strategy that separates concerns while maintaining automation throughout the integration process.

graph TD
    A[OSDU Community Repository - Upstream]
    A -->|Fork| B

    subgraph Azure["Azure SPI Repository"]
        B[fork_upstream<br/>Mirror]
        B --> C[fork_integration<br/>Conflict Resolution]
        C --> D[main<br/>Azure SPI Ready]
    end

    style A fill:#e8f5e9,stroke:#1b5e20,stroke-width:2px
    style Azure fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
    style B fill:#fff3e0,stroke:#e65100,stroke-width:2px
    style C fill:#fce4ec,stroke:#c2185b,stroke-width:2px
    style D fill:#e3f2fd,stroke:#1565c0,stroke-width:2px

Automated Workflow Capabilities:

AI-Enhanced Development Support leverages multiple AI providers for intelligent analysis, automated impact assessment, step-by-step conflict resolution guidance, and generated commit messages and PR descriptions through Model Context Protocol (MCP) integration.

Why This Matters

This automated fork management approach delivers significant operational and strategic value across development teams, operations, and enterprise architecture.