Nowadays, IFD International Framework for Dictionaries ISO 12006-3 and mainly IFC Industry Foundation Classes ISO 16739 play a vital role in the OpenBIM environment all around the world, and accordingly, IfcDoc tool from buildingSMART International has become a critical tool for digital built environment industry. But this critical tool has had a lot of issues which we just focus on some of the vitally important ones:

• First of all, it is not a cross-platform tool and just works on Windows.
• Secondly, the logic behind the IfcDoc tool makes the IFC schema and the IFC schema development more dependent on its data modeling tool which today has issues and buildingSMART International has started to develop it again based on UML, but in reality, UML will not solve the dependency barrier, likewise.
• Thirdly, many think about parametric IFC which existing IFC development does not support.

And some other issues and obstacles ahead which led us to think and start the IfcXtreme project as an alternative to IfcDoc, which is a cross-platform visual IFD / IFC programming that revolutionizes the OpenBIM environment due to its freedoms and easy usage which gives a gift to the end users as BIM as well as OpenBIM experts

Our project on bSI forum: https://forums.buildingsmart.org/t/ifcx-and-ifclite-projects/1440

The base idea which introduced on LinkedIn: https://www.linkedin.com/pulse/ifcxtreme-ehsan-azari/

Our GitHub page: https://github.com/IfcXtreme/IfcXtreme

For this reason, we decided to build a transparent and easy to use software which will help OpenBIM, especially in Automation and Control aspects.

Our project will accelerate IFD and IFC development and will speed up national integrated digital projects all around the world.

There is a gitter chat room for realtime, ephemeral interaction if preferred.

We encourage you to contribute to IfcXtreme! If you would like to contribute to IfcXtreme, you should subscribe to the developers mailing list (IfcXtreme-dev), where the developers of IfcXtreme discuss the development.

You can send pull requests via GitHub. Patches should:

1. Follow the style of the existing code.
2. One commit should do exactly one thing.
3. Commit messages should start with a summary line below 80 characters followed by a blank line, and then the reasoning/analysis for why the change was made (if appropriate).
4. Commits that fix a bug in a previous commit (which has already been merged) should start with fixup! and then the summary line of the commit it fixes.
5. Rebase your branch against the upstream’s master. We don’t want to pull redundant merge commits.
6. Be clear about what license applies to your patch: The files within this repository are under the MIT and GPL3 (or later) but, as the original creators, we are still allowed to create non-free derivatives. However, if patches are given to us under GPL then those cannot make it into any non-free derivatives we may later wish to create. So to make it easier for us (and avoid any legal issues) we prefer if patches are released as public domain.

The files within this repository are under the MIT and GPL3 (or later) but, as the original creators, we are still allowed to create non-free derivatives. However, if patches are given to us under GPL then those cannot make it into any non-free derivatives we may later wish to create. So to make it easier for us (and avoid any legal issues) we prefer if patches are released as public domain.