Would agree with @brunopostle and @Moult that the project should be small, however, I think, even a small renovation project, where we try and model all the disciplines (A/M/E/P/S/FP), would still be too much to chew and take on. It would get really complicated, really quickly--there's too many subtleties we'd have to address in the exchanges.
I think we should go even smaller, with a hyper reduced scope.
I would suggest doing something like @yorik and I have been doing with OpeningDetail.com--that is, helping A/E firms draft/model/develop their small scale details.
Repos of past projects: https://github.com/OpeningDETAIL
Visual examples: http://openingdetail.com/gallery/
As I mentioned, in the meeting yesterday, small scale details are about a 1/3 of a typical construction set--so there's relatively large scope of potential work there.
To model these details requires are very small subset of the IFC schema. That is, to compose these details we only need to deal with a few entities such as IfcExtrudedAreaSolid and IfcMaterial, among a few others.
The smaller the subset of the schema we have to deal with, the more we can concentrate on the fidelity of the roundtripping. And in turn, build on this small subset over time.
The other aspect I don't think we should ignore, and was mentioned by @duncan, is that adoption of Blender and Freecad and the other open source tools mentioned here, will not, more than likely, happen wholesale, but instead will happen quicker if these tools can add or augment the predominant tools the industry (Revit/Architect/etc.)
That is, if we can find small little ways (wedges) that someone can use Blender/Freecad, but still add to the Revit/ArchiCAD output stack, the quicker the adoption could be.
Realistically, most A/E firms that would only hire a detailing service like OpeningDETAIL, if the end product could be reused in their BIM tools. That is, they would not just settle for a PDF of the details.
Another reason to use a very small subset of the schema is that it would make it easier to build additional technical services/products around that content. For example, by just using simple extrusion and materials, it would easier to develop very robust diffing and distributed merge control systems (like git) --as you no longer have to deal with be baroque hierarchy of the full fledged IFC schema.
These are avenues where the 'wedge of value' can be widened over time.
With these details, although the scope is reduced, I still think we can pull in the participation of multiple disciplines. That is for example, a structural detail could be pushed back and forth between a structural engineer and architect resulting in (1) coordinated detail, verses (2) versions of the same detail--one in the ARCH's set and one in the STRUCT's set--which are rarely fully coordinated.
This same (1) detail coordination could apply to other disciplines a well.
The objective, for me is to realize workflows that produce content that is not reliant on the tool that created it--similar to how code is not reliant on the IDE, or a website is not reliant on specific browser.
For me, I see this OSArch group as a way to realize that objective.
