The Linux Foundation launched the OpenSharing Project on June 10, 2026, giving enterprises building agentic AI a single open protocol to share AI models, agent skills, and unstructured data across any platform — without copying files, writing custom integrations, or staying locked inside a single vendor's marketplace. For any organization running agentic AI workflows that span multiple clouds, tools, or business partners, the arrival of an openly governed standard means the cost and friction of cross-organizational AI collaboration just dropped significantly.
OpenSharing is the evolution of Delta Sharing, the open data-sharing protocol Databricks launched in 2021. Where Delta Sharing focused on structured tabular data, OpenSharing extends the same REST-based, zero-copy architecture to the full range of assets organizations are now trading in the agentic era: agent skills, machine learning models, and unstructured data volumes, alongside the structured tables Delta Sharing already handled. Databricks donated the protocol to the Linux Foundation, making it community-governed under an Apache 2.0 license — the same structural move that turned Delta Sharing from a Databricks tool into a cross-industry standard adopted by thousands of enterprises and used in tools including Apache Spark, Oracle, Power BI, Tableau, and Snowflake.
Zero-Copy REST Architecture Keeps Data Where It Lives
The technical mechanism at the heart of both Delta Sharing and OpenSharing is a design choice with direct implications for security and compliance: data never moves through a broker or a central server. The OpenSharing protocol specification defines a REST API in which what a recipient receives is not the data itself but a short-lived, signed access credential.
When a provider shares an asset, that credential — a bearer token or an OpenID Connect (OIDC) federation token — grants time-limited, read-only access directly to the provider's cloud object storage. The recipient's tool (Apache Spark, a pandas client, Power BI, or any OpenSharing-compatible system) then fetches the data directly from the provider's storage bucket, whether that bucket lives on AWS S3, Azure Data Lake Storage, Google Cloud Storage, or an on-premises system via partners including MinIO, Everpure, and Qumulo. The shared asset never leaves the provider's control; the provider's storage policy and access controls remain authoritative throughout.
This architecture has a measurable overhead cost. Published research on the original Delta Sharing protocol found query times ran 13 to 30 percent above direct storage access, with the overhead decreasing as table sizes grew. That is a concrete, quantified tradeoff: recipients pay a modest latency premium in exchange for not having to stand up their own copy of the data, and providers gain the ability to revoke access at any time by simply invalidating the token rather than coordinating a data deletion across their partner network.
For regulated industries where data residency and access auditability matter — healthcare, financial services, insurance — this architecture is not an incidental design choice. It is the structural reason OpenSharing is viable for organizations that cannot allow sensitive data to leave their perimeter. Kythera Labs CEO Jeff McDonald framed it directly: healthcare data has always been fragmented, and OpenSharing removes friction by delivering analysis-ready data directly into the environments where customers already work.
OpenSharing's Superset Architecture: What Changed From Delta Sharing
OpenSharing is explicitly designed as a superset of Delta Sharing, meaning every existing Delta Sharing client remains compatible with OpenSharing servers. The protocol expands the original in three concrete directions.
First, it adds new asset types. Delta Sharing covered tables and, in later versions, notebooks and volumes within the Databricks ecosystem. OpenSharing formalizes support for machine learning model artifacts, agent skills, and unstructured data volumes as first-class protocol objects — each with standard APIs for discovery, credential vending, and access control. Akram Chetibi, Databricks' product lead for ecosystem and partner integrations and a former founding product manager at AWS Data Exchange, described the problem this solves: "There is no easy way today to share an agent skill. If I ask you today to share with me an agent skill, how would you do it? You would email me a file, but then if I want an update, how do I get the update? You email me another file."
Second, it expands the recipient universe. Delta Sharing's existing connectors reach Databricks, Apache Spark, Oracle, Power BI, Tableau, and Snowflake, among others. OpenSharing adds support for Apache Iceberg IRC clients — the Iceberg REST Catalog interface used natively by platforms including Snowflake's managed Iceberg, AWS Glue, Google BigQuery Omni, and Dremio. Organizations already invested in Iceberg-based lakehouses can now receive OpenSharing-published assets without migrating their infrastructure to Delta Lake.
Third, it enables on-premises sources. Under Delta Sharing, providers needed cloud object storage to share data. OpenSharing extends the protocol to support on-premises and private-cloud storage through named storage partners, meaning organizations with data that cannot move to a public cloud can now participate in OpenSharing ecosystems.
A practical caveat: the OpenSharing GitHub repository notes that while table sharing is fully functional across all connectors, support for volumes, ML models, and agent skills is currently in progress. The protocol specification covers these asset types; full connector implementations are still rolling out. Enterprises planning to use OpenSharing for model or skill exchange specifically should verify connector availability before committing to a timeline.
Linux Foundation Governance Is the Point, Not the Wrapper
What distinguishes OpenSharing from Databricks simply publishing an open-source spec is the governance transfer to the Linux Foundation. Open standards research and the history of successful open protocols converge on the same principle: a standard that a single vendor can unilaterally modify, fork, or restrict — even one licensed permissively — is structurally different from a standard governed by a neutral multi-stakeholder body. The Linux Foundation has demonstrated this pattern repeatedly, with Linux itself, Kubernetes, the Model Context Protocol, OpenSSF, and OpenStack all following the same trajectory: a company or small group contributes a foundational technology, the foundation provides the governance structure that makes broad industry participation trustworthy, and the standard achieves adoption levels no single vendor could have generated alone.
For OpenSharing specifically, the Linux Foundation governance model means that Snowflake, SAP, Oracle, or any other platform vendor can contribute to the protocol specification without contributing to Databricks' competitive position. That is a different proposition than contributing to a Databricks-controlled repository, and it matters for whether competitors will adopt the protocol rather than building a rival one.
Jim Zemlin, CEO of the Linux Foundation, emphasized the governance dimension: "By bringing this technology to the Linux Foundation, we can foster open collaboration, broad industry participation, and the shared governance needed to accelerate AI innovation at scale."
Databricks co-founder and CTO Matei Zaharia framed the donation in terms of the precedent Delta Sharing set: the industry's demonstrated preference for open over locked-in, extended to the full AI stack rather than just structured data.
Industry Backing at Launch
The announcement named early supporters across finance, healthcare, property intelligence, payments, and on-premises storage — a deliberate spread across the industries most constrained by data residency and cross-organizational sharing requirements.
LSEG's Divisional CEO of Data and Analytics, Ron Lefferts, confirmed the platform's adoption: "We chose OpenSharing because it's consistent with our LSEG Everywhere strategy. It allows any customer to use our data in any tool or any cloud with any model." Stripe's Head of Data and AI, Emily Sands, said native OpenSharing support in Stripe Data Pipeline will let customers access advanced analytics and AI capabilities on billing and transaction data. SAP adopted OpenSharing for SAP Business Data Cloud. MinIO co-founder AB Periasamy highlighted the on-premises access case: organizations with sensitive data that cannot migrate to public cloud platforms can connect their on-premises assets to cloud-based AI tools through OpenSharing's storage partner support.
What OpenSharing Still Needs to Prove
The real measure of any open standard is adoption by platform vendors whose proprietary formats it is designed to displace. Delta Sharing achieved genuine cross-platform reach — Snowflake, Oracle, and Tableau all implemented connectors despite Databricks being a direct competitor of each. The question for OpenSharing is whether vendors will extend that cooperation to AI model and agent skill exchange, where the competitive stakes are higher than structured data sharing.
Two things work in OpenSharing's favor. First, the Linux Foundation governance structure reduces the risk that any contributor is inadvertently strengthening a rival. Second, the protocol's superset design preserves backward compatibility with the existing Delta Sharing ecosystem — vendors that have already invested in Delta Sharing connectors face a lower barrier to extending support to OpenSharing's new asset types than they would face adopting a completely new protocol.
The formal technical steering committee has not been announced; the Linux Foundation has not yet published a detailed governance roadmap for OpenSharing. That is typical for early-stage foundation projects — Kubernetes, OpenSSF, and OpenStack all matured their governance structures after the initial contribution — but enterprises evaluating OpenSharing as a long-term infrastructure dependency should track the governance timeline alongside the connector rollout.
More details on contributing or integrating the protocol are available at the OpenSharing GitHub organization and at opensharing.io.
Frequently Asked Questions
What is OpenSharing?
OpenSharing is an open, vendor-neutral protocol for sharing AI assets and data across organizations and platforms, hosted by the Linux Foundation. It is the next evolution of Delta Sharing — the most widely adopted open data-sharing protocol — and extends that protocol to cover agent skills, machine learning models, and unstructured data volumes in addition to structured tabular data. It is licensed under Apache 2.0 and governed as a community project, meaning any compliant client or server implementation is valid with no required SDK or platform dependency.
How is OpenSharing different from Delta Sharing?
Delta Sharing, launched by Databricks in 2021, covered structured data in Delta Lake and Parquet formats and used a REST-based, zero-copy architecture to share tabular data without moving it. OpenSharing is a superset of Delta Sharing: all existing Delta Sharing clients remain compatible, and the protocol adds support for agent skills, AI model artifacts, and unstructured volumes as shareable asset types, alongside new Apache Iceberg IRC client support that expands the universe of systems that can receive shared assets. Support for on-premises and private-cloud storage sources is also new.
Does OpenSharing require Databricks or Unity Catalog to use?
No. OpenSharing is an open-source project under the Linux Foundation, licensed Apache 2.0, and any organization can implement a compliant server or client without using Databricks or its Unity Catalog platform. Databricks offers a built-in OpenSharing server as part of its platform with additional governance and audit features, but the open standard operates independently of any vendor's tooling.
What data formats does OpenSharing support?
For structured tabular data, OpenSharing supports Delta Lake, Apache Iceberg, and Apache Parquet formats. For volumes and model artifacts, the protocol places no constraints on file format or content — providers share them as blobs accessible via the same REST credential-vending model. Support for model and agent skill sharing is currently in progress across connectors, with table sharing fully implemented.
ⓒ 2026 TECHTIMES.com All rights reserved. Do not reproduce without permission.
