> Has an architect ever forked an open source building? Has an biomedical engineer ever forked a open source prosthetic hip implant? Has a civil engineer forked an open source bridge?
------
TLDR: Yes and no. They driver is 'why'. What were you intending to achieve by forking a building/bridge? It's not always useful for geometry but is for the information that drives that geometry, which we are getting better at doing thank's to some international standards.
------
Walloftext: As someone who consults to Engineers and Architects on their use of technology in collaborative design, as well as previously working in both types of design environments as a CAD Manager I'll attempt to answer, but not really answer your (maybe hypothetical) question.
Firstly, effective collaboration in the Architecture Engineering Construction (AEC) industry is a big problem, widely regarded as the core reason why the industry's productivity rate globally has remained so low and stagnate for years when compared to other industries.
One of the big problems has been effective digital interoperability. Currently there are two global standards in development, ISO15926 (for plant) and IFC ISO16739 (for architecture). Both are domain specific ways of transmitting information about a design at all stages of a projects lifecycle to other people involved. Think of it as an object orientated way of representing buildings, rather than by arbitrary geometry.
What you'll notice about both of these standards is that geometry (whilst important) only forms a portion of the overall dataset. There's information on procurement, construction, cost, scheduling, materials etc. and in my experience that is the information, and the reasons why such information was decided upon, that would benefit most from a version control system. (I've had success with using semantic wiki for collaborating on contracts, scopes of work and specifications for instance). At the moment the design processes behind designing a bridge or building are like a manual CVS. Every part of the design is modularised, you have folders that have sheets of paper showing drawings at particular revisions and associated documents like calculations. This way those who need to sign off documents have the full design history available to them. However this is extremely cumbersome and has limitations. Merely replicating this process digitally (with files and folders) ends up being a duplication of the manual process anyway.
Digitally there are ways to centrally share and 'fork', 'merge', 'pull', 'push' etc, many around the standards I mentioned, however the industry tends to be mostly linear in it's design methods and is only slowly moving towards a central model of digital collaboration (for pages and pages of reasons that I won't mention; cultural, historical, legal...). Short answer however, there a huge number of nuanced variables and complicated dependencies that make things difficult.
Would you fork a building? Yes and no, it's pretty much done all the time (in 2D mostly) by builders and property developers where you see a show home and then slightly modify it to your block. However, Architecture is always uniquely tied to it's environment; Even ignoring the art of designing for place, you have regulations that will dictate setbacks, overshadowing, where windows can be placed in relation to your neighbours, etc. Currently if you have a whole load of dumb 2D and 3D geometry this is a manual process and simply modifying may take you longer than just starting a model again from scratch. IFC is making this easier, much research has been done in Singapore on this particular example (automated code compliance) but is still quite a way off from mainstream adoption.
Would you fork a bridge? Probably not. I've been heavily involved in engineering (mining) for the last 6 years and have been fascinated watching the "copy and paste" design scenario play out again, and again. Standard design has it's place but is mostly a myth or relegated to smaller parts with fixed parameters and requirements (like a truss or a joint), not entire projects. You'll be very lucky if you have say, the ground conditions match up exactly to the size of your previous bridge. Say physically it's the same, maybe the soil conditions or the way water drains off that bank is different, requiring you to redesign the foundations. Things get jigged a bit and have a compound knock on effect somewhere else in the design. The wind-loads are different here and you need to reconsider the bracing and profile. Then suddenly the client has different needs, requiring you to redesign for them. Before you know it, you have a completely different bridge, with different specifications, dimensions and a different contract. But it was quicker to start from the initial one, right? Well, that's debatable. This is a very simple scenario but in my experience, probably not.
I worked for a company recently that had some IP in mineral processing, a very modular system, a lot of repetition, hundreds of kilometres of piping and thousands of tonnes of steel. Despite it being a "standard" design, it is still re-engineered every single time it was used, partly because of the regulatory requirements for documentation, partly because of local conditions (they can't procure unit A so get unit B, they don't have capacity to construct in a particular method, so everything is changed to suit another method of construction).
Copy and paste in large scale engineering in the built environment is a fools paradise. Geometry is just the tip of the iceberg. On one project I produced visual diffs on detail drawings for a while, but the feedback was that they weren't really required, most teams are so intimately linked to their design visually that they don't need them. What they do like, however are diffs on what drives that geometry (notes on calculations, specifications, product data-sheets).
I'm going to stop now before this gets more out of hand and less helpful.
------
TLDR: Yes and no. They driver is 'why'. What were you intending to achieve by forking a building/bridge? It's not always useful for geometry but is for the information that drives that geometry, which we are getting better at doing thank's to some international standards.
------
Walloftext: As someone who consults to Engineers and Architects on their use of technology in collaborative design, as well as previously working in both types of design environments as a CAD Manager I'll attempt to answer, but not really answer your (maybe hypothetical) question.
Firstly, effective collaboration in the Architecture Engineering Construction (AEC) industry is a big problem, widely regarded as the core reason why the industry's productivity rate globally has remained so low and stagnate for years when compared to other industries.
One of the big problems has been effective digital interoperability. Currently there are two global standards in development, ISO15926 (for plant) and IFC ISO16739 (for architecture). Both are domain specific ways of transmitting information about a design at all stages of a projects lifecycle to other people involved. Think of it as an object orientated way of representing buildings, rather than by arbitrary geometry.
What you'll notice about both of these standards is that geometry (whilst important) only forms a portion of the overall dataset. There's information on procurement, construction, cost, scheduling, materials etc. and in my experience that is the information, and the reasons why such information was decided upon, that would benefit most from a version control system. (I've had success with using semantic wiki for collaborating on contracts, scopes of work and specifications for instance). At the moment the design processes behind designing a bridge or building are like a manual CVS. Every part of the design is modularised, you have folders that have sheets of paper showing drawings at particular revisions and associated documents like calculations. This way those who need to sign off documents have the full design history available to them. However this is extremely cumbersome and has limitations. Merely replicating this process digitally (with files and folders) ends up being a duplication of the manual process anyway.
Digitally there are ways to centrally share and 'fork', 'merge', 'pull', 'push' etc, many around the standards I mentioned, however the industry tends to be mostly linear in it's design methods and is only slowly moving towards a central model of digital collaboration (for pages and pages of reasons that I won't mention; cultural, historical, legal...). Short answer however, there a huge number of nuanced variables and complicated dependencies that make things difficult.
Would you fork a building? Yes and no, it's pretty much done all the time (in 2D mostly) by builders and property developers where you see a show home and then slightly modify it to your block. However, Architecture is always uniquely tied to it's environment; Even ignoring the art of designing for place, you have regulations that will dictate setbacks, overshadowing, where windows can be placed in relation to your neighbours, etc. Currently if you have a whole load of dumb 2D and 3D geometry this is a manual process and simply modifying may take you longer than just starting a model again from scratch. IFC is making this easier, much research has been done in Singapore on this particular example (automated code compliance) but is still quite a way off from mainstream adoption.
Would you fork a bridge? Probably not. I've been heavily involved in engineering (mining) for the last 6 years and have been fascinated watching the "copy and paste" design scenario play out again, and again. Standard design has it's place but is mostly a myth or relegated to smaller parts with fixed parameters and requirements (like a truss or a joint), not entire projects. You'll be very lucky if you have say, the ground conditions match up exactly to the size of your previous bridge. Say physically it's the same, maybe the soil conditions or the way water drains off that bank is different, requiring you to redesign the foundations. Things get jigged a bit and have a compound knock on effect somewhere else in the design. The wind-loads are different here and you need to reconsider the bracing and profile. Then suddenly the client has different needs, requiring you to redesign for them. Before you know it, you have a completely different bridge, with different specifications, dimensions and a different contract. But it was quicker to start from the initial one, right? Well, that's debatable. This is a very simple scenario but in my experience, probably not.
I worked for a company recently that had some IP in mineral processing, a very modular system, a lot of repetition, hundreds of kilometres of piping and thousands of tonnes of steel. Despite it being a "standard" design, it is still re-engineered every single time it was used, partly because of the regulatory requirements for documentation, partly because of local conditions (they can't procure unit A so get unit B, they don't have capacity to construct in a particular method, so everything is changed to suit another method of construction).
Copy and paste in large scale engineering in the built environment is a fools paradise. Geometry is just the tip of the iceberg. On one project I produced visual diffs on detail drawings for a while, but the feedback was that they weren't really required, most teams are so intimately linked to their design visually that they don't need them. What they do like, however are diffs on what drives that geometry (notes on calculations, specifications, product data-sheets).
I'm going to stop now before this gets more out of hand and less helpful.