I’m a big fan of github, and I think it provides an excellent set of resources for hosting 3D printing projects. Recently I had the idea that it would be useful if these projects were able to utilise Github Pages to provide a project landing page, showing similar information to that found on Thingiverse.
It sounded like a fun little diversion so I threw together something called githubiverse. It currently consists of a Github Pages template: drop this into the gh-pages branch of any github project, add a little configuration, and your github pages will display the source files, STLs and any images, along with some other information. The beauty here is that the content is dynamically pulled from the github repository so it is always up to date.
The screenshot doesn’t do it justice so here is an example site: garyhodgson.github.com/githubiverse-tst. The project has a master branch which contains folders for source files, STLs and images. The project also has a gh-pages branch which contains the template. Within this, _config.yml contains the configuration parameters that allows the gh3 github api client to connect to github and pull the information. Because it’s dynamically generated it’s a little slower than a standard website, but I think it’s an acceptable compromise for always having the latest information.[Update: The way I have used Thingiview means that only ascii STL files are correctly displayed. I’ll see if I an find a way to also load binary STLs.]
To get an idea of how other projects might look I took a few screenshots (via locally running instances) for Nophead’s Mendel90 and Josef Prusa’s PrusaMendel:
There’s a few pros and cons to consider.
- + Free hosting of project site by github.
- + Easy to set up.
- + Always up-to-date.
- + Easy to change the look and feel to suit your needs.
- – Depends on Github, Github Pages and the API – any changes to the terms and conditions, or future availability, of these services could impact the site.
- – No search function, tags or commenting system (although this could be remedied).
An interesting advanced use case is the ability to use the same core template across many projects. You could fork the githubiverse-template project and edit the html/css as you wish. Then, in each project’s gh-page branch create a submodule referring to this fork. All that’s left would be to create a _config.yml file with the details in the root project gh-pages branch and an additional entry defining the source of the jekyll site as being the submodule folder. I’ve added details on how to do that in the project’s readme. The benefit of doing this is that each project can be updated solely through updating the template submodule. [Update: it seems I had forgotten to actually test this method when deployed to github, whilst it works locally via Jekyll it seems that github modifies the source folder settings during the build. Thanks to dzach for finding this out the hard way. I’ll see if there is a way around this as I feel having a shared template system would be quite useful.]
Another idea is to edit the template to utilise the blog aspect of jekyll. The Slic3r.org site runs on Github Pages and already does this to announce releases. The blog could be a development log, release history, or news section for example.
To address the search and discovery aspect I considered trying to implement some form of tracker service, whereby projects could register themselves and use the service for searching, browsing and tagging etc, also as a Github Pages site. However I realised that something like the RepRap Development Tracker would do the job perfectly well, as this is agnostic to where a project is hosted – it only categorises each entry and refers to the originating pages.
Development Tracker is currently tailored specifically for tracking reprap and 3D printing parts and projects, but it wouldn’t take much to make it more generic and suitable for tracking all sorts of projects. And of course the underlying software is open source, so anyone can fork and go!