At some point last year, my Dynamo use evolved from occasional to hardcore. One of the reasons might have been the staggering development pace of the software since it was open-sourced to GitHub (or the fact that I was in desperate need of a BIM-savvy computation tool for my PhD thesis). What really got me hooked, though, was the package manager that Peter Boyer built (introduced with version 0.6.0 last September). Suddenly, there was an infrastructure to share custom nodes via the internet that didn’t involve email, dropbox or other makeshift distribution channels. As an added bonus, we were given a versioning system and an engine that was aware of package dependencies – definitely enough infrastructure to get started with publishing some custom nodes. This post is an opinion piece – I want to talk about why I’ve been making packages, why you should, too, and what, in my opinion, we as a user community still lack in terms of infrastructure.

Why I share

For those in the Dynamo community that do not know me, here’s some info on my background: I’m a trained architect with some programming experience and I work for the Chair of Computer Aided Architectural Design (CAAD) at RWTH Aachen University, Germany. My work is mostly focused on BIM and parametric design.
My Dynamo use can be categorized into four overlapping fields:

• Research:
  As I mentioned above, I use Dynamo for creating proofs of concept as part of my PhD thesis that lives somewhere in the terrible and wonderful world of model-checking. A lot of that work has not found its way into the package manager yet as it is still very much in a state of flux, but some of it that could be applied to general problems outside my immediate research interest is already online (like the Convex Hull 2D package I published recently).
• Teaching:
  Dynamo has become an integral part of our BIM.Parametrics classes. When preparing course content, I try to imagine what kinds of workflows students might want to use Dynamo for. When I find that certain components might be useful, but they don’t exist yet, I build them and share them on the package manager. One example: Last semester we had a class called BIM to Production that prompted me to create a number of packages that could help with evaluating models and preparing them for CNC milling (Subcategory Stuff, Sequence With Leading Zeros, Plane-Vector Intersection, Vector-Vector Intersection among others).
• Evaluation:
  In BIM.Basics, our introductory Revit class, we let students hand in their models at regular intervals during the semester in order to provide feedback on the model progress. Previously, this was done using checklists but we now use Dynamo for it as I was able to re-use quite a bit of what I have been making as part of my thesis project. This is probably where more than half of my published nodes come from (Select By Category is a good example). The package manager made it very easy to share all the relevant custom nodes with my teaching assistants that evaluate the models.
• Community:
  I try to stay up-to-date with what’s being discussed on the Dynamo forum and when I see an interesting problem that I may be able to recycle for a class I try to solve it. Quite a few of my packages are by-products of those activities (most recent example: Create Placeholder Sheets).

Screenshot of the monster definition that checks the final project submission of our BIM.Basics class – it’s actually too big for Dynamo’s built-in screenshot tool to process it…

Why you should share, too

So that’s my motivation for sharing – what’s yours? I realize that the majority of Dynamo users probably work in the “real” world, not in academia. I can see that some employers might object to making custom nodes available to the general public (or more precisely: their competitors). But let’s look at the bigger picture here – there are some good reasons for sharing custom nodes:

• Because it’s easy.
  A custom node doesn’t need to be ingenious – it just needs to be handy. My personal rule of thumb: if I use the same combination of nodes more than once, I at least consider turning that group of nodes into a custom node (unless it’s definitely project-specific).
• Because there is lack.
  However fast its recent development pace, Dynamo is still a very young piece of software. There are bound to be a lot of gaps functionality-wise and they are not going to go away by the end of next week or next month. But Dynamo makes it really easy to access the Revit API and create missing functionality. There are some people on the forum here that have only recently had their first experiences with the Revit API and are already making Python-based custom nodes that make Revit do things it cannot do with the built-in Dynamo nodes only.
• Because it’s right.
  Dynamo is an open source project and it’s a free product. So it’s safe to say that sharing custom nodes is very much in the spirit of Dynamo. If you’re using custom nodes from the package manager, please consider giving something back to the community. In the end, everybody profits if there is a more diverse ecosystem of packages.

At the time of writing, there are 244 packages by 70 authors in the package manager. That’s less than four packages per author. I am sure we can do better than that.

Can’t decide if it’s worth your while to create a custom node? Here’s a quick test for you…

Why we need (even) more (or better) infrastructure

So now that we’ve had the package manager for a couple of months, is everything hunky dory? The short answer is: “Yes, but…”. I would be lying if I said I am not a package manager fanboy, but nonetheless I’ll try to make a quick case for some additional or improved infrastructure. Here’s my entirely subjective list of topics that may have to be addressed sooner or later (incidentally, most if not all of them have already been raised as issues on the GitHub site):

• Collaboration:
  This topic was recently discussed on the forum: We need the ability to post changes or improvements to packages that are not our own. Apparently the database structure of the package manager is already designed to support multiple package maintainers in the future, so let’s keep our fingers crossed.
• Examples:
  Did you know that there are a ton of Dynamo examples for built-in nodes on GitHub? The developers use those files to test new builds of Dynamo for errors, but you can learn a lot about how each built-in node works just by going through those *.dyn files. I think we need simple examples like that for packages as well. I make it a habit to build an example file for each package I upload and make them available online, but I’d much rather be able to include them as part of the package.
• Workflows:
  It’s great to be able to share custom nodes through the package manager, but I’d love to see that same functionality for sharing entire workflows. Now imagine how cool it would be if that functionality came with the same dependency checks that you’re accustomed to when downloading a package. You could download a *.dyn file and all the packages it requires to run correctly. And yes, we have the forum to post workflows – which is a good thing. But workflows evolve and they, too, would benefit from the versioning capabilities of the package manager – as would additional files like a Revit sample file.
• Usability:
  Have you ever tried installing a new version of a package that has a lot of dependencies? Welcome to alert box hell. And how did you actually know there was a new version? Dynamo surely didn’t tell you – but wouldn’t it be nice to get update notifications for all your installed packages when you start Dynamo? Or deprecation warnings, for that matter? And wouldn’t it be less disruptive to be able to search for packages using the search field of the node browser rather than having to start the package manager for it?

These are just some ideas – head over to the GitHub site to submit your own. And don’t forget to make some packages soon…