No. And don't expect it.
Did you ever get the feeling that Revit is really neat and seems like you are swimming in a vast ocean (ecosystem) of features and support but when you drill down into any particular feature at a certain point, you quickly reach the bottom of the "hole" that only reaches as deep as what the folks at Autodesk decided to implement and that's it? Did you ever feel like there is a lot of slick packaging and marketing, especially at the "edges" and once you reach that edge, there just isn't a bunch of third party and/or open source support extending the edges constantly further and further out? Did you ever notice that you can't just call vendor X and get Revit files or at best you might get a bunch of DXF's and have to patch them in yourself?
Compare that to for instance the "Contacts" database in an Android phone. It is stored in a file format called SQLite that is free software (and the SQLite API is freely accessible within your phone). This is a binary format. You CAN do a "jailbreak/root" and get access to the actual raw databsae file and there are free open source programs that can read/write it but you don't even have to do this. It can be exported into an open and documented "contact" format that is supported directly on IOS (iPhone), almost every E-mail system (even Outlook) and contact system database out there. You can simply "share" contact information with anyone, anywhere, without ever even thinking about how to turn it into a compatible file format or have to modify/fix the contact...it just simply "works" like some kind of magic. The contacts database can also automatically import/export from several online "cloud" type systems transparent to the end user so backups and conversion/translation is pretty much automatic. In fact most users just assume that they have a list of contacts in their "phone app" and "texting app" and don't even realize that there is a separate Contacts app running the SQLite database in the background. It just works and it is compatible with almost everything, everywhere. Don't you wish Revit was like this?
Autodesk is simply using a business strategy developed originally by Microsoft. Microsoft is a huge player in the software market so like it or not we all have to deal with the 800 lb. gorilla in the room. Microsoft also makes their attempt to be "open" but it's a business strategy called "Embrace, Extend, Extinguish". It works like this. First they say they are "open" and they are joining the "open" world by publishing say a format or developing an "open framework" or "API" such as say a web browser with built-in compatibility with say Java. That's embrace. Then they Extend it with a plethora of totally incompatible features like "ActiveX" and promote and use it extensively in all of their own software so that end users quickly notice that everything "just works" with everything in Microsoft's software (iExplore) but not the other way around. Many of the "cool" features are really just clones of existing ones from competitors but purposely incompatible in some way. That's "Extend". Finally the last stage is to simply break compatibility altogether after enough users are lured into using the "extend" functions. That's "Extinguish". This was the entire purpose of ".NET"...to extinguish Java and any resemblance to compatibility with any other competitor's software. And if you've ever had to update your ".NET" frameworks and then noticed that it broke half of the other programs on your PC, there is a very good reason for doing this. There is a software program called "Mono" that clones .NET so that non-Microsoft operating systems such as Linux, OSX, and probably Android and IOS can run .NET software, and Microsoft has been making every effort to Extinguish that one, too. The new Windows 8/10 "Edge" web browser is similar. The .NET and fake Java systems have basically been rejected by the market so Microsoft had to restart back at "Embrace" again and is busy working on the next generation of "Extend" strategies to break compatibility in Windows 10 starting with moving all your documents into a captive system called "Office365" where you can no longer even get your documents out of the cloud-based "prison" without monumental efforts that mostly destroy compatibility.
https://en.wikipedia.org/wiki/Embrace,_ ... extinguishIn the CAD world, let's say that we publish an "open" CAD file format. Let's call it DXF. The initial version gets published and suddenly there is a flurry of software ecosystem development as suddenly the CAD monolithic software can be made to do all kinds of useful things. Then the proprietary software company extends the CAD software with a bunch of extra features that show up as encrypted binary blocks that are simply unreadable at worst and undocumented at best within the "open" file format. Many of them are simply clones of the various open source projects out there which users have to jump through hoops (install) to use rather than the built-in feature. That's extend. The last time the DXF format was updated was 2007 (over 10 years ago) and even at that time probably 80%+ of every drawing file in DXF format was intentionally encrypted/obscured/undocumented, even if it duplicated features already found in the DXF file format so there was really no need outside of a business one to break compatibility. Then the software company simply eliminates compatibility altogether in a new software package that is even incompatible or barely compatible with the other software packages that the same company sells. Let's call it "Revit". Yep, that's what you are dealing with. In fact they even go out of their way to make Revit versions incompatible with each other to force users not only to use Revit and Revit software exclusively but even to force them on the upgrade treadmill every 2-3 years. This also totally eliminates any chance that a competitor or even a third party will ever develop a functional "bridge" software package and discourages even the attempt at doing so.
This is the fundamental problem with Revit in general...it is a really powerful software ecosystem but one that doesn't play well with others. Autodesk INTENTIONALLY breaks compatibility constantly to force you to use their software and their's alone without working with anyone or anything else. The goal is to constantly update their software to force the users to pay big time license fees to constantly upgrade their software and to prevent them from ever being able to work with other vendors. As long as you can do mechanical or electrical analysis within the Revit system, it's not too bad. But the moment that you attempt to do for instance CFD or FMEA in a package outside Revit, you run into this same model translation problem. Revit kind of sort of supports CSV imports/exports for some things but most of the time all of your drawings are captive within the Revit system and simply cannot escape.
Even if Revit wasn't intentionally incompatible with everyone else, let's consider for a moment what would be required. As an example, SKM which is one of the oldest and very popular power system analysis packages works very similar to Revit. It has a component database in the background that contains all the details about how your system is connected together, several libraries of components (thousands of components), and a bunch of auxiliary files such as drawings (that are almost an afterthought and very fluid, unlike Revit where they are central to the system), and various human and machine readable reports and some very small configuration files that are also human readable. The component database is a binary file as it is in Revit but unlike Revit you can export/import it in CSV (text table) format which makes it trivially easy to read/write it in Excel or read it into your favorite external processing tool (I like to use Python for this) to make mass changes or even mechanically create/edit/update the files. You can then re-import it back in either via the GUI or via command-line tools, and even execute the analysis functions so that it is possible to "drive" it entirely from a scripting system like Python. Although the binary database format is definitely not "open" it is accessible to the point where it is at least theoretically possible that by developing a "dictionary" which can freely translate say "250 A Class RK5 fuse" in SKM to some other system and back again, it is possible to develop an external export/import engine to do what you describe between software packages. It would be time consuming given the fact that there are around 10,000 components in SKM's base library alone (ignoring all the ones that customer requests have created that you can get when you call and ask for one). But it's at least possible to do this with SKM and with most of the other power system analysis packages. The amount of time in developing the dictionary is so much and the target audience is so small that it would only make sense to do it as a commercial endeavor but I'm afraid the license fees would be so high that the project would probably never pay off. Given a database of 10,000 objects it would probably take some development time to figure out exactly what is needed but say we can amortize this out to around 5 minutes per object on average, or 50,000 minutes of time. That's about 833 man-hours or 35 man-years of time. That's well beyond hobbyist effort and given the very narrow audience doesn't make sense as an open source project, nor does it make sense as an in-house project since the "labor intensive manual conversion" cost is far less. Considering that new releases of Autodesk software formats come out about every 3 years (SKM is a little slower) then the 35 man-years has to be done on the same cycle or you never get to a product before the file and library data updates again so it has to be done in 3 years, requiring at least a 12 person team to do this with a 3 year development cycle. Assuming fully loaded labor costs including overhead of about $80,000 (technical/clerical positions here), and not even considering profit margins, the cost is nearly $1 MM to do this. With the market probably being about 20% of the cost of the base software packages we can probably only charge about $1250 per copy for the mythical translator application, so we'd have to sell at least around 1,000 copies or more just to break even. I might be wrong here but it seems like the market might not be that big especially considering that we need to find that many buyers that own and want to use two specific software packages. The effort is about the same even if we add more software packages so that for instance if we want compatibility with both SKM and ETAP (capturing most of the market) we're looking now at $2 MM.
In the CAD world there are some attempts at developing similar "open" systems from almost every competitor except Autodesk. There are also truly open source CAD systems but so far frankly they are nowhere close to displacing the big players (Bentley, Autodesk, Solidworks) or they are very specialty such as FLUENT. Google Sketchup for instance obviously simply isn't in the running except for very basic CAD functions.
The only system that I'm aware of right now that offers such an "integrated" environment is CYME which is really intended as sort of a "Revit" for utilities that contains relay programming, Arc flash, and power system analysis in one package. But as systems go it's very specific to a very small market. It works with it's specific hardware/software ecosystem only. Let's just say that the arc flash package is not popular for a very good reason. It looks on the outside like its a great solution, but it's not.
And in answer to your question, can you name one BIM out there that makes any attempt whatsoever to be open source or open format? I can't either. They all stink at this. Part of the problem is that BIM's are not daily use software like a cell phone. But the other problem is that in a lot of ways, it's not really yet "mature" software such as E-mail. So that's why for instance we have Gmail and Sketchup. Sketchup is pretty close to where the CAD/CAE world was at in the 1990's whereas Gmail is one of the leading E-mail systems. We got there because the underyling E-mail file format is almost unchanged from vendor to vendor and is at this point as open as it gets. There isn't any such thing as an open file format for CAD yet. FSF has made an attempt to basically do this with DWG but it's not really that good yet.
