# OpenSharing on Linux Foundation: Share AI Models and Agent Skills > Source: > Published: 2026-06-16 10:09:16+00:00 On June 10, the Linux Foundation took custody of **OpenSharing** — the successor to Delta Sharing and the first open protocol to treat AI models and agent skills as shareable objects with the same governance you’d apply to a production database table. If your organization is building multi-agent workflows and currently shares trained models by emailing zip files to partners, this announcement is directly relevant to you. ## Delta Sharing Hit a Wall Delta Sharing launched in 2021, reached general availability in 2022, and became genuinely widespread: Stripe, SAP, Atlassian, LSEG, Amadeus, and thousands of other enterprises use it. It grows 300% year-over-year, and 40% of its active shares are consumed by recipients outside the Databricks ecosystem — a signal that the open-protocol bet paid off. But Delta Sharing was designed for structured tables. It handles Delta Lake, Parquet, and some Iceberg. What it cannot handle is the asset types that AI workloads actually need to share: trained model artifacts, custom agent skills, and unstructured document volumes. You can’t Delta-Share a LangGraph tool definition or a fine-tuned fraud-detection model. That’s the wall it hit. ## What OpenSharing Adds OpenSharing is a strict superset of Delta Sharing. Your existing Delta Sharing clients work without modification — backward compatibility was a hard design requirement. What it adds is six asset types under one unified three-level hierarchy: `Share → Schema → Asset` . - Delta Lake tables - Apache Iceberg tables (new — Delta Sharing was Delta-centric) - Parquet datasets - Unstructured data volumes — documents, logs, media - ML model artifacts - Agent skills One auth model. One discovery API. One access control layer across all of it. That’s the architectural win: instead of a separate integration for each asset type, a single protocol handles a Parquet table and an agent skill identically at the transport layer. ## How It Actually Works The core mechanism is **credential vending**, not data movement. When a recipient requests access to an asset, the OpenSharing server does not serve the data — it issues a short-lived, signed credential (AWS STS tokens, Azure SAS, GCP OAuth, or Cloudflare R2, depending on where the asset lives). The recipient then accesses the asset directly from the provider’s storage. This is zero-copy sharing. Data never duplicates, egress costs don’t multiply, and data sovereignty stays with the provider. The sharing server is out of the data path entirely. The REST API is simple enough to call without a dedicated SDK: ``` GET /shares GET /shares/{share}/schemas GET /shares/{share}/schemas/{schema}/models GET /shares/{share}/schemas/{schema}/agent-skills ``` Bearer token authentication. Apache 2.0 license. Any compliant server or client works — no required SDK, no platform dependency. ## The Honest Status Report Table sharing works in production today. The parts that make OpenSharing genuinely novel — model artifacts, agent skills, and unstructured volumes — are still in development. The spec exists and the API is defined, but connector implementations are not complete across the ecosystem. That’s not a knock against the project; it’s infrastructure work, not a product launch. If you need to share trained models across organizations this week, OpenSharing is not yet the answer in practice. What it gives you now is a production-quality data sharing protocol with a defined path to AI asset sharing as connectors ship. ## On-Premises Storage, Finally Delta Sharing assumed you were on public cloud. OpenSharing does not. It supports on-premises and private-cloud storage through named storage partners — Everpure (formerly Pure Storage), MinIO, and Qumulo. For organizations in regulated industries with data that cannot touch a public cloud bucket, this unlocks participation in OpenSharing ecosystems without forcing a cloud migration. ## Why This Approach Is Right Open protocols beat proprietary marketplaces for foundational infrastructure. That’s the lesson from HTTP, SMTP, and RSS. Databricks contributing OpenSharing to the [Linux Foundation](https://www.linuxfoundation.org/press/linux-foundation-announces-opensharing-project-to-standardize-ai-asset-and-data-exchange) rather than keeping it as a Unity Catalog feature is the right call — the value of a sharing protocol scales with how many independent organizations implement it. Proprietary AI asset marketplaces already exist. Salesforce has one. AWS has SageMaker Model Registry. HuggingFace Hub serves the open-source community well but is still a centralized platform. None of them offer the combination of vendor neutrality, zero-copy access, and unified governance across data and AI assets that OpenSharing targets. [The New Stack](https://thenewstack.io/databricks-opensharing-ai-agents/) summarized it well: Databricks wants to kill the “email me a file” problem for AI agent skills. That is exactly the problem, and an open protocol governed by the Linux Foundation is the right kind of solution. ## What Developers Should Do Now If you already use Delta Sharing, your clients work with OpenSharing without modification — test against the spec when your provider upgrades. If you’re evaluating data sharing options for a new project, start with OpenSharing rather than Delta Sharing; you get the same table-sharing capabilities today and a clear path to AI asset sharing without a migration later. The spec and reference implementations live on [GitHub](https://github.com/OpenSharing-IO/OpenSharing). The protocol documentation is at [opensharing.io](https://opensharing.io/). [Databricks’ announcement](https://www.databricks.com/company/newsroom/press-releases/databricks-announces-opensharing) covers the full list of founding storage partners and the asset type roadmap. Apache 2.0 — read the spec, build something, and contribute connectors for the asset types that matter to your stack.