Someone clueful will no doubt solve the loading latency and resource usage issues. However, to me the more interesting question is: “How should a communal project Livebook for Elixir developers be structured and implemented?”
Since I’ve come up with a bit of a wishlist, here is a speculative description of what this resource might look like. Comments and suggestions welcome… (ducking 
)
-r
Like @Adzz, I really like the notion of having Hexdocs-based Livebooks (and assorted other resources) made available as a “starting point” for my Livebook project notebooks. Here’s a possible use case:
Starting a new project, I instantiate a new project notebook, based on a specified Git branch. This branch might be a group or individual effort; either way it represents someone’s idea of a useful collection.
The notebook would typically have sections containing example code, library documentation, tools, etc. Some of these would be turned on by default; others would be included and described, but commented out.
Most of these items would be well known and popular, but others’ inclusion might be based on personal preferences. In any case, collectively they would make a well-tuned starting point for projects of a particular nature.
After downloading a canonical starting point, I would start it up. At this point, the Livebook would access and fold in preferences set in local control files. At this point, I would have a “live” notebook, ready for customization for a project.
Of course, this is merely the starting point; some of the gnarlier problems deal with how to handle continuing divergence of local notebooks from current practice, etc. I submit that these sorts of issues are already dealt with in various ways (eg, diffs and patch files). That said, I’ll be as interested as anyone to see what might be done in practice.
.
