Marcello Sgambelluri cornered Autodesk’s Matt Jezyk and Zach Kron and grilled them with questions about the origins and direction for Dynamo.  We thought we’d share the thread.  Hear more on these subjects at Marcello’s upcoming RTC talks and on his blog.

Why was dynamo created?
[matt] Ian Keough created it to smooth out building design workflows while he was at Buro Happold in NYC, because he was constantly working between Rhino and Revit transferring data. The basic thesis was we should be able to teach Revit to do computational design in the same way that Grasshopper can drive Rhino.
Why did Autodesk decide to invest time into it?

[matt] I made a business case to have some of our guys start contributing to the open source project because 1) I’m a huge geek and had already invested many nights and weekends programming Dynamo and contributing source to github 2) there was something there that can help combine these two different camps of computational design guys and BIM guys. I think this has been born out – the market is quite responsive to “Computational BIM” and is adopting it.

Was it really a competitor to Grasshopper?

[matt] We did not set out to build a GH clone. Yes, they both use visual programming concepts. Yes they both are used in AEC to solve similar problems. The way you think about things is different in Dynamo (driving families, recursion, optimization workflows, no baking to make real objects)

[zach]  Dynamo’s clearly in a similar area as Grasshopper.  Many designer think about buildings in a systematic or rules based way and these tools allow people to more directly address abstract constraint systems without having to develop their own custom code. The Grasshopper folks were smart about this and recognized trends in capturing procedural workflows that have existed for a long time in Engineering (see Labview, Mathlab, Simulink), Music and Multimedia (Cycling74 Max, VVVV, others), and animation (SoftImage, others). Us architects are pretty consistent in the adoption of new technologies and ways of working after they have been proven out in other fields. Revit was birthed in a similar way out of the mechanical engineering world, where parametric models and coordinated drawing sets had been managed in software for years.

So Dynamo comes from similar requirements, but addresses them from a different starting point. Where Grasshopper works on top of CAD(Rhino), Dynamo is starting from BIM (Revit), and so the engagement with the building is different. While Dynamo does handle raw geometric stuff like CAD does, it really thrives on manipulating building components and systems. So, in a similar way that Revit can model walls and roofs by making a series of long skinny extrusions like CAD, it is more suited to manipulating sketch based objects like Walls that have a relationship to a larger building system.

Somewhat paradoxically, while Dynamo starts from a very specific workflow (making Building Information Models), its internal architecture is fully independent of any one software platform and becoming more independent every day. Dynamo can run as a standalone application, and while we are making the hooks into Revit deeper and broader, we are also developing the core computational functionality to be able to run on many other tools. Third party developers have already made prototypes of Dynamo that run on mechanical, animation, and structural tools.

What were the early water-cooler conversations about Dynamo? 

[matt] There are some good “creation myth” stories here – Ian showed this to me at ACADIA in 2009, then he moved to LA from NYC, then took a job at Vela working on an Ipad 3d viewer, then he entertained the idea of open-sourcing it.  I remember having lunch with him in LA and said if you open source it I’m pretty sure I can justify putting some guys on it. He did that , then Zach and I taught a class using Dynamo at AU 2011 I think – “Parametric Supermodels”.  We had an intern working on Dynamo that spring and he rebuilt the underlying engine.  That same spring Vela was acquired by Autodesk.  Ian and I were on the phone talking the day it closed and realized we now work for same company. Later that year we put more guys on it. Ian came over to our group full time about year ago in Jan/Feb 2013 and we now have a full dev team working on Dynamo. We merged the Designscript and Dynamo teams in the Summer of 2013 to deliver the DesignScript engine driving the Dynamo application.

Was the link to revit an afterthought? Was Dynamo developed as a stand alone?

[matt] Revit is and was the main focus. We have worked to ensure Dynamo does run decoupled from Revit and can be integrated with other applications easily, currently we have Inventor and Maya connections with more coming.

What is the future of Dynamo as much as you are allowed to explain.

[Zach] The awesome thing about working in open source is we can be really transparent about what we are working towards. You can see where we are headed in the short term by just watching what is going on on Github.

First of all, Dynamo is part of an open community. The team believes that our users are the smartest people around, and we are committed to facilitating their contribution to this tool. The source code will remain open for users to download, rebuild, and contribute back to make it better and more appropriate to their needs. The existing toolset for users to exchange workflows (the Package Manager) will be expanded to allow users of many different backgrounds to contribute code by exchanging node workflows (custom nodes), scripts (from various languages), and compiled libraries.

We are also going to continue developing a deeper integration with BIM. The current implementation of Dynamo (0.6.3) comes from an emphasis on the early design process. While we are building out this functionality (primarily with an enriched geometry toolset) we will continually add more tools that address the breadth of the capabilities in Revit.

AEC is a collaborative design process and there is no one tool for everything. We’ll continue to expand our support for interoperability with multi-disciplinary tools (like Excel and Arduino), as well as more building specific tools (like daylighting, structural analysis, and others).
Dynamo has a discreet computational engine that manages things that are generic to procedural design, such as list manipulation, math, logic, input/output, visualization of data, etc. This allows Dynamo to be used as a stand-alone computation tool for those who want a light weight introduction to this design process.
While this core functionality currently points at Revit (pulling information out of Revit as well as pushing into ) it can be pointed to different tools. If fact, the development versions of Dynamo load the Revit functionality as modular pieces, similar to how Excel functionality is exposed. The Dynamo team has a particular expertise in Revit functionality, and we are actively working with users and developers with backgrounds in other applications who want to expand Dynamo to address workflows in these other tools.

What does it really mean to be open source?

[matt] Free as in speech and free as in beer.

[Zach] Open source means that users can see how and why the application does what it does.  It means users can develop the application to do specific operations the way they want it to.  It also means that users can be developers.

Why are all users considered developers? Is it because they can upload custom nodes?

[matt] Dynamo lowers the barrier to entry for customization. You can enter where you feel comfortable – creating custom nodes, writing python scripts, writing in other scripting languages, all the way up to writing compiled C# and C++ code. all of these can be shared internally in your office or externally via the package manager (binary file sharing coming soon via package manager)