IFC, not DWG
Autodesk and the Open Design Alliance are today announcing that the former joining the latter for the ODA's expertise in IFC (industrial foundation classes), used for data exchange in the AEC world.
The news comes as a shock to those who know the history of Autodesk's law suits against the Open Design Alliance, as well as the history of the ODA being formed originally to open up the DWG format, which, at the time, Autodesk refused to document. ('We have an open format, it's called DXF', was the famous excuse from Autodesk at the time.) Given that Autodesk repeatedly for years also sued a number of the larger members of the ODA, I wonder how well the news is being taken internally -- on both sides.
IFC Only
Autodesk's only interest in the ODA is for its IFC libraries, now that BuildingSmart has made the ODA the official supplier of APIs and SDKs. BuildingSmart is the organization that defines the content of IFCs.
The move is steeped deeply in irony, as it was Autodesk itself that came up with IFCs (and object enablers) to solve the problem created by AutoCAD Release 13's user-definable objects (a.k.a. custom objects) -- how to exchange data between AutoCADs that don't understand specific custom objects. Autodesk later handed the troublesome IFCs to an external organization, who, over the decades, expanded IFC to become the de facto exchange format among BIM and AEC programs.
To this day, custom objects continue to dog DWG editors, just as IFC remains an unsatisfactory exchange medium, except that there is nothing that improves on it.
The Reason(s)
Autodesk's joining of ODA is part mea culpa and part cost savings. As Autodesk said in a blog post today:
In one of my recent posts responding to some of the constructive criticism we’ve received from our architecture customers, we promised to do a better job of listening to our customers, engage in an open dialogue, and do better where we’ve fallen short.
One of the areas highlighted was progress with our products on international data exchange standards, specifically the need to better support IFC, an open file format increasingly used by our AEC customers.
The cost savings come from the ODA charging relatively modest fees to access its APIs and SDKs as compared with other tools providers. Autodesk, I believe, was already using someone else's IFC toolkit, which I suspect may have cost the company more in license fees.
No DWG
Another surprise is that the agreement is for IFCs only, no access to DWG or contributions to the same. As it is Autodesk that defines the DWG format, I would have thought they could -- finally -- start contributing to the ODA, so that there is no longer that six-month lag between Autodesk changing the format and the ODA releasing its APIs to members.
On the other hand, Autodesk is showing less and less interest in AutoCAD. At one time, Autodesk was changing the DWG format every year. Upon complaints from customers and third-party developers, it promised to change it only once every three years. Now the company can go five years and longer with no changes. This is good, as it brings stability to the entire DWG editor industry.
So, perhaps the ODA doesn't need Autodesk's contributions to DWG, especially as it is the ODA has taken the lead in enhancing the DWG format.
IMO, AutoCAD is EOL. Nice to have for a quick & dirty drawing, but no longer for every day use - that's a job for the verticals. I think Autodesk is of the same opinion, seeing the 'improvements' over the last years releases; mostly bells and whistles, although importing PDF is a nice addition - for the time being...
Posted by: Simon Weel | Sep 22, 2020 at 12:56 PM