Is it possible to get IFC standards development to be quicker and more agile?

Is it possible to get IFC standards development to be quicker and more agile?

Projects such as [FreeCAD](https://www.freecadweb.org/) and [BlenderBIM](https://blenderbim.org/) rely heavily on the IFC format, mainly through [IfcOpenShell](https://github.com/IfcOpenShell/IfcOpenShell). In fact, BlenderBIM's native file 'is' the IFC file.

Although there's many advantages to this, there's also a lot of disadvantages. The main disadvantage is that certain types of functionality, very common to many BIM platforms, do not have an equivalent counterpart in the schema.

Functionality such as...

- [mirroring](https://github.com/buildingSMART/NextGen-IFC/issues/86)
- [arraying](https://github.com/buildingSMART/NextGen-IFC/issues/84)
- [one-to-many groups](https://github.com/buildingSMART/NextGen-IFC/issues/61)
- [annotation](https://github.com/IfcOpenShell/IfcOpenShell/issues/1142)
- [material GUIDs](https://forums.buildingsmart.org/t/proposal-for-ifcmaterial-to-become-rooted/2721)
- [typed IfcOpeningElement](https://github.com/buildingSMART/IFC4.3.x-development/issues/1062)
- [IfcRelVoidsElement to have a one-to-many relationship](https://github.com/buildingSMART/NextGen-IFC/issues/87)
- [simple parametrics](http://geometrygym.blogspot.com/2013/10/parametric-ifc.html)
- [support "xrefing"](https://github.com/IfcOpenShell/IfcOpenShell/issues/668)

...to name a few.

Since there's no current schema that accommodates these types of functions, coders create this functionality in the native program. Since it's unique to the particular authoring program, the opportunity for true interoperability is lost.

Once this functionally is 'baked' into the native program there's very little incentive to find ways to translate it to a future IFC schema that will eventually accommodate it. Which, often times, by that time it's available, more bells and whistles have been added to this core functionality, so the lack of incentive continues and the gap continues.

If we could find a way to make standards development as agile as open source development is, I think it would make IFC adoption more robust and commonplace.

Granted such an approach to standards development would be messy and seemly chaotic, as is open source development, a lot of times, is. But it's exactly this ability of users not having to ask permission, and just creating what they think is a good idea, that allows such a rich functionality.

In the end, if it's not a good idea, it will not be adopted by others, and will wither on the vine. Taking an evolutionary analogy, it will not be selected for. But it's exactly this ability to act on these seeds of thought, like genetic mutations, that provides such a rich foundation of innovation.

So what would such an open approach to standards development look like? Thoughts?

The issue provides no file, test, or implementation entry point to inspect; begin by reading the linked IFC and project issues to understand the proposed gaps. A contribution would first need a defined agile standards process and agreed success criteria, which the issue does not specify.

Written by the indexing model from the issue text.