Currently setting up a Dynamo deployment for a +300 person company, and have opted for a different method to the usual. I’m developing an inhouse package likely deployed via executable file in future, currently downloadable and pasteable from a sharepoint whilst it’s in development phase. Using exposed Python nodes to help hide the complex functions, whilst keeping them open for learning for curious users.
Before my arrival most scripts used no custom packages, but heaps of Python (which is how a lot of companies roll that I’ve worked at or spoken to the managers from) - the packageless approach. In my opinion this doesn’t work, and is counter productive. It leads to unmaintained Python code, and scripts that a new user would not be able to understand at face value if they wanted to learn - preventing a culture of computation of emerging without a steep entry curve involving Python and Revit API understanding. An even worse approach is to ‘lift’ the Python code out of other custom nodes insitu on the canvas - both disrespectful to the package managers and then no-one even understands that Python block should something go wrong.
This means we effectively only use 2 packages for deployment for the average user, the in-house one and Data Shapes. For the power users, I keep a separate folder with the following packages (however most of them know how to manage their own packages anyway):
- Bimorph Nodes
- Clockwork for Dynamo 2.x
- Genius Loci
- Spring Nodes
In future my goal is to encourage the business to enable the package to be publicly available for company convenience, but a majority of it is repackaged from my own work with Crumple. This approach is actually fairly common - we have such examples as Wombat (Woods Bagot), archilab_grimshaw (retired, but for a time was company associated I guess) and various other packages and tools. There is always the risk with this approach that the ‘brains’ or architect behind them will move on (e.g. archilab_grimshaw), but if you do it right and involve enough people, it can form a collaborative effort and be de-risked to some degree.
So far I’ve found this to be quite straightforward, although moving away from using heaps of packages is challenging at times (I have to delve into the API often to rebuild/package functions I know exist elsewhere). Version management without the package manager is difficult, but possible. There is something to be said for the excitement factor of giving the company their own ‘toolbox’ as well, users now request new nodes and functions rather than just scripts as a whole. It gives them a wider understanding that Dynamo is not just about building magic buttons, but the intelligent pieces that go into them also.
Having said that, Orkestra is great if you can get your company to invest in it (paid solution) and is the best in show to me of that type of end user/low maintenance solution.