DraftSight Will Go Far
This is a sequel to my post “How Far Will DraftSight Go?” wherein I wondered how much Dassault Systemes will be willing (or be allowed to by Graebert) to enhance DraftSight. I have been speaking to Aaron Kelley, the Director of DraftSight, and have learned quite a few interesting things.
For starters Dassault Systemes has its own full fledged development and QA team for DraftSight which works closely with the Graebert team in Germany. In fact they developed some of the stuff in DraftSight themselves which has or will find its way into ARES, the CAD engine developed by Graebert on which DraftSight is based.
But here is one thing that I found really interesting. A CAD application is basically just a framework that comes with its own bells and whistles. What gives it the real power is the API that the CAD vendor exposes to third party developers who use it to develop plug-ins and vertical applications that increase the power of the CAD system many fold. ARES is built over the ODA platform and can be extended with the DRX SDK. At SYCODE we are currently porting our DRX plug-ins over to ARES. I thought that since DraftSight was also based on ARES, it would be a trivial task to make the same ARES plug-ins work with DraftSight as well. But here is the thing, Dassault Systemes is not going to support the DRX programming interface with DraftSight. I am not exactly sure why, but I guess it may be part of the deal with Graebert so that DraftSight does not cannibalize the sales of ARES itself. So Dassault Systemes is going to create their own API (not related to DRX) that will let third party developers write plug-ins that extend its capabilities. Why? In Aaron’s words, “We are creating our own API so that we have control over its direction. It is part of our business model“.
Just the fact that they are doing this says a lot about the kind of importance Dassault Systemes is attaching to DraftSight. This is not like how SolidWorks treated their 2D Editor which they took from the ITC along with all its problems, put a new name on it and shipped it to SolidWorks users. Looks like this time it is going to be different and companies operating in the AutoCAD clone market (and maybe Autodesk itself) may start getting worried. This is what Aaron had to say about future plans for DraftSight:
“Our approach is to be open and even share our direction and problems with the community. We just do not have those up on the community site yet. We are still evolving the site as well (it is in Beta). We plan on release a Public Beta 2 this fall which will have more local language support for the help files (and adding a version of DraftSight for our friends in Turkey), we also plan on releasing the first version of the C++/COM API. We certainly are looking at requests from users too, but the development cycle is really short for the next release. We will also be looking to fixing issues found by users. We are looking to launch an Alpha of the MAC OS version in October time frame as well as an Alpha of Linux shortly thereafter.
On 2D parametrics – I need to see a better way of implementing the technology than I have seen presently or in the past. I think they are too hard to work with. In 3D , your sketches are typically simpler than in 2D drawings so they work for the most part. Parametrics can get you into trouble especially in more complex drawings. The usability team at DS SolidWorks has some cool ideas on implementation, but I do not see us doing this in the short term. If the community demands it – we will reconsider.
On new functionality – We work with Graebert closely on new functionality. Sometimes, we develop stuff ourselves or pay for outside development to get things in the product(s). For example, the UI widget is in DraftSight first developed by DS SolidWorks developers and then we hope it will be in Ares.”
I guess if you wanted to know whether Dassault Systemes was really getting into the 2D CAD market with DraftSight or just fooling around, you now have your answer.