Get Involved

Founded in 2019 under the umbrella of the Linux Foundation, the Cloud Information Model (CIM) is both a member alliance and a community. Together, collaborating in Working Groups, members define and use a common open data model, influence existing and future standards, and build open solutions to solve common problems.

CIM exists because enterprise data is fragmented across dozens of applications, each with its own proprietary schema, naming conventions, and semantics. A customer in Salesforce, a customer in SAP, and a customer in a homegrown billing system are all “customers” — but they rarely agree on what a customer is, which attributes are authoritative, or how relationships between customers, orders, and products should be expressed. CIM’s answer is a shared, application-agnostic model that any system can map to, so integration work becomes a mapping exercise rather than a bespoke translation project.

Key Takeaways

• CIM is a Linux Foundation project (founded 2019) that publishes an open, standards-based data model translated into multiple formats so heterogeneous systems can adopt it.
• Participation is tiered: Steering Members, Contributor Members, and the broader CIM Community, with progressively broader rights as you move up.
• The single current Working Group defines new Subject Areas, mappings, and API requirements — this is where the substantive technical work happens.
• Contribution is not just code: proposing Subject Areas, participating in consensus polls, and joining Working Groups are all first-class ways to shape the standard.
• The model is deliberately format-neutral, which is what lets relational, graph, and API-oriented consumers share one canonical definition.

Why a Shared Data Model Matters

Most integration pain is semantic, not technical. ETL pipelines, iPaaS platforms, and API gateways are mature; what breaks is the meaning layer. When two systems disagree about whether “account” means a billing entity or a corporate hierarchy, every downstream report, join, and reconciliation inherits that ambiguity.

A canonical model like CIM addresses this by providing a neutral reference point. Instead of mapping N systems to each other (an N×N problem), each system maps once to the canonical model (an N×1 problem). This is the same architectural principle behind standards such as the Common Information Model used in the energy sector (IEC 61970/61968) and the HL7 FHIR resources used in healthcare — domain-specific canonical models that let independently built systems interoperate.

CIM’s scope is broader and more horizontal: it targets the common business entities — customers, products, orders, suppliers, and the relationships among them — that appear across CRM, ERP, commerce, and supply-chain systems. The goal is not to replace any of those systems’ native models, but to sit above them as a shared vocabulary.

Working Group Scope

We have developed the Cloud Information Model (CIM) with a standards-based approach and translated it into multiple formats. This approach enables businesses with varying technologies to adopt CIM. It also empowers contributors and fosters growth for a larger CIM ecosystem.

Concretely, “multiple formats” means the same underlying model can be consumed by different toolchains — for example, as a schema definition for relational or document stores, as a graph of entities and relationships, and as the basis for API contracts. A team using a relational warehouse, a team using a graph database, and a team building REST or GraphQL services can all work from one source of truth rather than three divergent definitions.

This format-neutrality is a deliberate design choice with real trade-offs:

• Pro: No single vendor’s tooling is privileged, so adoption isn’t gated on buying a particular platform.
• Pro: The model can evolve independently of any serialization format.
• Con: Contributors must think carefully about which constructs are truly canonical versus artifacts of a particular format.
• Con: Tooling to translate between formats must be maintained, and round-tripping is not always lossless.

For architects evaluating whether to adopt CIM, the practical question is whether your integration surface is dominated by shared business entities. If most of your mappings are one-off and domain-specific, a canonical model adds overhead. If you repeatedly map the same handful of entities across many systems, the N×1 reduction pays for itself.

Cloud Information Model Working Group

Currently, CIM has a single Working Group which works in the definition of new Subject Areas, mappings and APIs requirements.

A Subject Area is a coherent slice of the model — for example, a grouping of entities and relationships around a business domain. Proposing a Subject Area is one of the most impactful contributions a member can make, because it determines what the standard covers next. Mappings connect Subject Areas to real-world systems and formats; API requirements capture what consumers need from services built on the model.

If you are considering joining the Working Group, a useful way to decide where to contribute is to ask:

1. Which entities cause the most integration rework in your organization? Those are candidates for Subject Area proposals.
2. Where do your systems already agree, and where do they silently diverge? Divergence is where mappings add the most value.
3. What do your downstream consumers actually need from an API? That shapes API requirements.

Because there is currently one Working Group, the practical path for a new contributor is usually to join it and propose a Subject Area, rather than to spin up a new group. Proposing a new Working Group is a right reserved for higher tiers and is best reserved for genuinely distinct areas of work that would otherwise overload the existing group.

Membership Tiers and Benefits

CIM participation is structured in tiers, each with progressively broader rights. The table below summarizes the benefits as published by CIM.

Benefit	Steering Member	Contributor	CIM Community
Use CIM Model Releases	✓	✓	✓
Stay up-to-date on CIM progress & innovations	✓	✓	✓
Contribute ideas to the CIM Consortium	✓	✓	✓
May propose a Subject Area	✓	✓	✓
Access to restricted and private resources	✓	✓
Eligible to join a Working Group	✓	✓
Contribute to Working Groups	✓	✓
Propose new Working Groups	✓	✓
Counted towards minimum support quorum of a Subject Area	✓	✓
Participate in consensus polls	✓	✓
Contributes to the CIM Roadmap	✓	✓
Drives the overall strategic direction for CIM	✓
Eligible to join the Steering Committee	✓
Eligible for a Working Group Chair position	✓
Eligible to vote to adopt content as part of the CIM Standard	✓
May appeal on technical issues	✓
May appeal on procedural issues	✓

*Steering Member Application — Contributor Members may apply for a Steering Membership.

How to read the tiers

The tiers map onto a familiar open-source governance pattern used across Linux Foundation projects: a broad community that can use the output and contribute ideas, a contributor tier that does the hands-on work, and a steering tier that owns strategy and formal adoption. The distinction that matters most in practice:

• CIM Community is the entry point. You can adopt released models and contribute ideas without a formal working role. This is appropriate if you are evaluating CIM for a project or want to influence direction informally.
• Contributor is where technical influence lives. Joining a Working Group, contributing to it, proposing Subject Areas, and participating in consensus polls all sit here. If your goal is to shape the standard rather than just consume it, this is the tier to target.
• Steering Member carries governance rights: strategic direction, Steering Committee eligibility, Working Group Chair eligibility, and the formal vote to adopt content as part of the CIM Standard. Contributor Members may apply for a Steering Membership.

A subtle but important detail: being “counted towards minimum support quorum of a Subject Area” is a Contributor-and-above right. Quorum rules exist so that a Subject Area isn’t adopted on the strength of a single participant — a governance safeguard common to consensus-based standards bodies. If your organization cares about a particular Subject Area reaching adoption, having Contributor-level participation is what lets you count toward that threshold.

How to Get Involved: A Practical Path

If you are new to CIM, a sensible sequence is:

1. Start as CIM Community. Review the released models and the FAQ, and identify where your systems’ entities overlap with CIM’s Subject Areas.
2. Contribute ideas. Even at the community tier you can propose ideas to the CIM Consortium — a low-commitment way to test whether your use case resonates.
3. Move to Contributor if you want to do the work. This unlocks Working Group participation, Subject Area proposals, and consensus polls.
4. Apply for Steering Membership if your organization wants to help set direction and hold formal adoption votes.

For open-source contributors specifically, the model’s format-neutrality means there is room to contribute tooling — format translators, validators, mapping generators — alongside the model content itself. For platform and application vendors, mapping your product’s schema to CIM is a way to reduce the integration cost your customers pay, which is often a competitive differentiator.

Governance, Standards, and Appeals

CIM follows a standards-based approach, which implies a defined process for proposing, reviewing, and adopting content. The presence of formal “appeal” rights — technical and procedural — at the Steering tier is a hallmark of mature standards governance. It means disputes have a defined resolution path rather than being settled informally.

This mirrors how established standards organizations operate. The Linux Foundation hosts many such projects and provides the legal and governance scaffolding — trademark, IP, and antitrust policies — that lets competitors collaborate on shared infrastructure. If you are evaluating CIM for enterprise adoption, the Linux Foundation affiliation is a meaningful signal: it means the model is governed by a neutral foundation rather than owned by a single vendor, which reduces the risk of a future licensing or direction change.

Related Information

• Frequently Asked Questions
• Membership Fees
• List of Current SteerCo Members
• Contributor Web Form
• CIM Model Resources
• CIM Presentation
• CIM Formats
• CIM in the News
• GitHub Repositories
• News Blog
• Contact

Frequently Asked Questions

What is the Cloud Information Model?

The Cloud Information Model (CIM) is an open data model and member community founded in 2019 under the Linux Foundation. It defines a common, application-agnostic model of business entities so that cloud and on-premises systems can interoperate through shared semantics rather than bespoke point-to-point mappings.

Who can join CIM, and what does it cost?

CIM has three participation levels: Steering Member, Contributor, and CIM Community. The community tier is the broadest entry point, while Contributor Members may apply for a Steering Membership. Membership fees are published separately by CIM, so consult the Membership Fees page for current figures rather than assuming a cost.

What is a Subject Area in CIM?

A Subject Area is a coherent slice of the model covering a set of related entities and relationships. Proposing a Subject Area is a Contributor-level right and one of the most direct ways to influence what the standard covers. Subject Areas are also subject to a minimum support quorum, which prevents adoption on the basis of a single participant.

Do I need to be a Steering Member to contribute?

No. Contributor Members can join Working Groups, contribute to them, propose Subject Areas, and participate in consensus polls. Steering Membership adds governance rights such as strategic direction, Steering Committee eligibility, and the formal vote to adopt content as part of the CIM Standard.

How does CIM relate to other data standards?

CIM is a horizontal, cross-industry model focused on common business entities, in contrast to domain-specific canonical models such as the energy sector’s Common Information Model (IEC 61970/61968) or healthcare’s HL7 FHIR. Its format-neutral design lets it complement, rather than replace, the native models of the systems you already run.

Why does format-neutrality matter for adoption?

Because it lets teams with different technology stacks — relational warehouses, graph databases, and API services — consume one canonical definition instead of maintaining divergent schemas. The trade-off is that translation tooling must be maintained and round-tripping between formats is not always lossless, so teams should validate mappings against their actual integration needs.

Further reading

• Working group — Wikipedia
• Linux Foundation — Wikipedia