Why has openBIM adoption been so slow? Are we facing a new push for open standards?

Opinion · 12 min · 2026-08-06

An analysis of the slow adoption of openBIM and the IFC format: the prejudice that IFC is an "inferior" format, why it is treated as a mandatory formality, and the signals of a new push —better tools, more trained professionals and real strategic benefits— that could change course.

More than two decades ago, buildingSMART promised something that sounded like a revolution: a common language so that every piece of construction software could talk to each other. That language is IFC (Industry Foundation Classes), the foundation of openBIM: an open, neutral model that does not depend on any single vendor.

The promise was huge. Reality, however, has been slower and full of frustration. In much of the world many teams still export to IFC only because they are required to, and keep coordinating and working in their software's native formats. For many, openBIM is still a formality rather than a way of working. Why did this happen? And more importantly: is it changing?

The underlying prejudice: "IFC is an inferior format"

There is a deeply rooted perception, rarely said out loud, that IFC is a second-class format compared to what commercial software like Revit or ArchiCAD produces. It is seen as a "watered-down" version of the real model: something that loses information, looks worse and lacks the intelligence of the native file.

The best analogy is this: it is like asking someone who works all day in Word to hand in their document as .txt. From that viewpoint, exporting to IFC feels like giving up the good stuff: losing formatting, losing richness, doing extra work to deliver something worse. And if the result arrives broken —parameters that did not travel, elements misclassified— the prejudice confirms itself.

The problem is that the analogy is wrong, or at least incomplete. A badly exported IFC does look like a poor .txt. But a well-produced IFC is not a degraded version of the model: it is a structured, portable and independent model with its own logic. The difference is not in the format, but in how it is produced.

Why openBIM got stuck as a "mandatory formality"

If openBIM is perceived as a formality only done when a client demands it, it is because of a combination of very concrete causes —none of them about villains, but about how the industry matured:

  • A steep learning curve. Truly understanding IFC —classes, Property Sets, levels of information— takes time and training. For years that knowledge was concentrated in few hands and little documentation.
  • Scarce or expensive tools. Until recently, validating the quality of an IFC or working with it seriously required costly tools or slow manual processes. Without accessible tools, the standard stays on paper.
  • IFC as a "checkbox". Several software packages implemented IFC export as a requirement to tick, not as a core function. The result: default exports that come out poor, reinforcing the idea that "IFC is useless".
  • Clients that ask for IFC but never check its quality. If you are required to deliver in IFC but nobody reviews whether that IFC is well made, the incentive is to deliver the bare minimum. The standard is met in form, not in substance.
  • Industry inertia. Established workflows are comfortable. Changing how you deliver, coordinate and validate is costly, and construction is not exactly quick to adopt change.

Put together, these causes explain the vicious circle: because IFC is exported badly, it is perceived as inferior; because it is perceived as inferior, nobody invests in doing it well; and because nobody invests, it keeps being exported badly.

What has actually driven adoption

Not everything has been inertia. Institutional efforts kept the openBIM flag flying even when real adoption was slow:

  • National BIM strategies and mandates that began requiring and standardizing the use of models in public projects.
  • The sustained work of buildingSMART and its local chapters, promoting IFC and certifying software and implementations.
  • The consolidation of ISO 19650 as a common information- management framework, giving openBIM international regulatory backing.

These efforts planted the seed. But public policy can require IFC; what it cannot do alone is make the industry want to use it. For that, other things had to come together.

The signals of a new push

And here is the hopeful part: several of those things are happening right now.

  • There are more and better tools. Free IFC viewers, open- source libraries to read and write IFC, plugins, and online platforms that audit a model's quality in minutes. The barrier to entry has dropped dramatically compared to five years ago.
  • There are more trained professionals. A new generation of BIM Managers, architects and engineers learned openBIM at university or in specialized courses. It is no longer the knowledge of a few.
  • IFC has improved over time. The schema evolved (from IFC 2x3 to IFC4 and beyond) and software implementations are increasingly complete. Today's IFC is not the IFC of a decade ago.
  • Clients are starting to verify, not just ask. The most important shift: when the party receiving the model checks its quality, the incentive flips. "Delivering something in IFC" is no longer enough; it has to be delivered well. And that forces everyone to raise the bar.

The key turn: stop seeing it as a loss and start seeing it as strategy

The real change of mindset is not technical, it is strategic. When done well, openBIM stops being a loss and becomes a competitive advantage:

  • You do not depend on licenses. Your information is not held hostage in a vendor's format. If you change software tomorrow, or a partner uses another one, the IFC model is still readable. That is freedom.
  • It does not become obsolete. An open, documented format can be opened 20 years from now. Native files tied to program versions have no such guarantee. For an asset's full life cycle —which can last decades— this is decisive.
  • It is lightweight and versatile. A well-exported IFC is surprisingly efficient and portable. You do not need to open an entire heavy suite just to review the model.
  • It lets you build workflows with several tools, not one suite. Instead of paying for a single vendor's full suite for the whole project cycle, you can combine the best tool for each stage. The openBIM approach frees you from that dependency.
  • It is programmable. Perhaps the biggest potential: because it is an open, structured format, you can build on top of IFC. Custom software, automatic validators, compliance checks, data extraction, integrations. You can build specific solutions without waiting for a vendor to add them to their product.

That last point is the most underrated. A closed native format gives you what the vendor decided to give you. An open format gives you a base to build on whatever your project, office or country needs.

So, is this the definitive push?

Honestly: nobody can guarantee it. Industry inertia is real and cultural change takes years. But for the first time the three missing ingredients are aligned: accessible tools, trained professionals and clients who verify quality. When those three come together, the standard stops being a formality and starts being a way of working.

openBIM does not need everyone to love IFC. It needs us to stop seeing it as a poor .txt and start treating it as what it is: a strategic, open and durable asset. The technology is ready. The question —as almost always— is whether the industry is ready to take advantage of it. And this time, there are good reasons to think it is.

From talk to practice

Talking about openBIM quality is easy; verifying it is the hard part. That is exactly why we built BIMaudit: a platform that audits IFC models 100% deterministically against a public standard aligned with ISO 19650, so any team can check —in minutes and objectively— whether their model is well made before delivering it. You can try it for free with a model at bimaudit.io.

Audit your IFC model for free with BIMaudit