One of my great hopes for Grasshopper 2 is that it moves more in the direction of a proper platform for makers – including all of the tools required to deliver high-quality products to end users without the need for any Grasshopper knowledge or skills.
Grasshopper is in my mind one of the great visual programming platforms thanks to David’s unusual skill in both technical deployment and UX; it is a truly great environment that is a pleasure to use and intuitive enough to be approachable. That has contributed to its immense success in the design community. That said, Grasshopper was clearly developed as a single-user tool development platform, and it requires a substantial amount of work to deploy user-facing tools that are scalable.
As Grasshopper has matured, it has become more and more capable and can be hacked to a level that hints as its power as a maker’s platform. At NBBJ we have been focused heavily on building our own internal infrastructure to support in-house tool deployment, to any user regardless of Grasshopper skill. In fact, we have gone to great lengths to ensure that our users don’t ever need to touch Grasshopper or even see it. That includes but is not limited to the following:
- UI – we built Human UI (now open sourced) to allow for complex interfaces that hide the GH canvas from users
- Dependency management – Andrew built our own in-house dependency manager for ensuring consistent plug-in deployment across our firm (Yak now looks promising!)
- Cloud analytics – I built a custom analytics plugin for reporting usage of our platforms (Rh/GH) and our deployed tools (with UI-level event reporting)
- One-Click Installers – For deploying tools to any of our firm’s machines, regardless of software/plugins installed.
- Custom data models – For storing metadata and configuration information at the file level, to allow tools to work with any Rhino file you might open
- Two-way binding with Rhino – For synchronizing GH-built interfaces with the Rhino interface (involves a lot of dicey event listening and flow control)
- Connection to web APIs and big data sets
This last one is perhaps the most controversial but also perhaps one of the most important, in my mind, because it is necessary and useful for creating a marketplace that encourages innovation in the AEC space. In my mind, the biggest thing that is lacking in the industry is a proper platform for AEC computation professionals to produce deployment-ready tools that they can monetize, which would constitute a new revenue model for a service industry that is threatened by technology and software providers.
McNeel is perhaps the Robin Hood character in this narrative – McNeel has always been very friendly to students and educators and has an ethos of knowledge sharing and inclusive development. Those are all great things. That said, to allow users to have granular control over their work product, and in fact to provide a mechanism for AEC professionals to monetize their work, should not be viewed as an assault on those values, but rather as a great gift to the community – “Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime.”
In a technology landscape where big fish gobble up all of the innovation, the little players have very little influence and very little opportunity to dedicate resources to innovate. (Sorry, now I’ve conflated the fish metaphor.) Regardless, AEC firms are reluctant to fund full-on development of scalable tools, 1) because not many people are doing it yet (because GH1 doesn’t cater to it OOTB), and 2) because it is difficult to see immediate results – even then, it is limited to the sometimes intangible impact you can have in a single organization. A recurring revenue stream, on the other hand, could turns heads at the leadership level – the people who sign the checks. Imagine a technology team at an Architecture firm develops a tool that they are then able to license to other AEC professionals. It is a success and starts bringing in revenue for the firm. That revenue is the argument that the team uses to fund further development, expand their team, and hone their focus around tools that can deliver value to the industry – because it promises future growth of ongoing revenue.
Of course, this is an idealized scenario, and perhaps only a handful of firms would focus their efforts on building tools for external deployment. But I contend that building the tools to deliver at scale to non-computational users would both encourage innovation to appear out of the woodwork, and would result in meaningful new products that make our lives easier as designers, scaling up the impact of Grasshopper in the industry well beyond where it already is.
You’ll note that the maker platform for AEC has been a holy grail in tech circles for some time – but I would contend that Grasshopper has a running head start, with a huge, talented community and battle tested UX paradigm. I would love to see it take the next step and become a true maker platform with a marketplace model. Could Grasshopper 2 be that opportunity?
Design Computation Team Leader, NBBJ