Shared publicly  - 
Quick idea that I need to get out before I go to sleep:

We need a site where we can submit links to out github repos for 3d printable designs and #OSHW projects. The site would crawl the repos and generate thumbnails using +Tony Buser's cloudscad and similar tools, and create a browsable directory with pages like +Gary Hodgson's githubiverse.

I'm calling this idea "ThingHub", but unfortunately I have way too much on my plate to build it right now. Anyone else what to take a crack at it? Got a better idea?

Gary Hodgson's profile photoMark Fairbairn's profile photoGeorge Hahn's profile photoMarcus Wolschon's profile photo
Where would it store the thumbnails and how would it parse assemblys and designs in a dozen of different CAD file formats?
You would never store read-only exports like STL in your versioning system. They are for release.
I don't think Github is a proper place for such a thing.
Especially as it doesn't help with navigating derivates and instead encourages extensive forking.
Marcus: Github by itself wouldn't, but something like ThingHub as described above is what is supposed to do that. Storing thumbnails in a DB along with text, user detail, a bunch of info about something, is hardly rocket science.

As for storing .STL's in a release: That seems like the old "No binaries in a repo" issue, which I see broken by everyone all the time, so I don't see it as a problem. Every time you create a named branch, you just need to build the .STL's, and you have binaries that can be fetched. At most the issue will be with linking to them all (hence something automated). As long as say ThingHub holds all the metadata (such as if it's a work in progress, a settled version, etc) then it shouldn't be an issue.

Having the ability to have "one" object but with multiple versions would actually be VERY useful IMO. Go to ONE place for the object but want an older version? Just select which version to browse and download from a dropdown that just selects the branch. Simple. None of this having 10 different objects on Thingiverse that hold each iteration of the same object by the same person.
Instead we have 10 user-repositories with no overview who based what changes on what version and is still developing or abandoned and an 11th and 12th one that you never find out exists at all.
Development Tracker does most of the things such a site as ThingHub needs: search, tagging, categories, descriptions, links and relationships, oauth signin.  The whole idea behind it is that it doesn't care where the project is actually hosted (github, personal site,, etc), it only tracks and links to it.  This also means it doesn't, and cannot, own or have rights over the project itself as it only holds metadata. (

It would be trivial to modify the current version ( into something more generic, suitable for all types of Things.  It's written in Java/Groovy (Gaelyk) and runs on Google App Engine - so at the moment, with low load, it's running for free (but of course would incur costs if it recieved any decent amount of traffic).  The project is there for the forking! :)

+Marcus Wolschon  - Github isn't the place for hosting the tracker as it can only hold static sites, and we need an application to do real work, but I think it is suitable to hold "landing pages" for each project. However, the javascript used in githubiverse-template ( to retrieve the project files and info from github is trivial and could easily be incorporated into a ThingHub.  Also, I don't think the tracker should have to parse design files - though that would be a nice to have.  I think it would quite reasonable to expect users to upload a few screenshots into a /media folder themselves.  Of course it would be very useful for there to be a standalone service which accepts e.g. an OpenScad file and returns a rendering of it - a project on the todo list.  
+Gary Hodgson   it might also be interesting to integrate "programmatic" creation of repositories, so that users would not have to manually create their repo, and then post it to "ThingHub" , to have a more "visual" way of adding stuff? (not that creating git repos & pushing them to github is that hard).
Certainly is must be visual.
I expect an "add file: [.....][upload]".
If I'm free this weekend, challenge accepted. Surely you could also crawl Githubs network graph to work out what is derived from what.
Looking forward to your thingiverse-clone.
Choice is usually a good thing.
Be sure to get a designer on board and a lawyer!
The Githuniverse github page template looks very nice.
It's missing access to versioning but that should be easy so solve.
A greater challange would be navigating a graph of derived works, finding designs, tagging, commenting.
All the things we have come to like in Thingiverse.
Like can be done using G+ and Facebook. Comments using some javascript service. But finding designs by name, keywords and tags and getting a big picture of the graph or ancestors (vs. list links "this is based on A,B and C and btw, I found D improving on my design but I never found out about E and F") needs something central.
+Marcus Wolschon Navigating the github graph shouldn't pose a problem. The get repository call of the api returns the parent repository ( and something called the "source" which I presume is the very first root project.  There is also a call to retrieve all the forks of a given project ( which would give the downstream repos.

I would probably implement commenting via because it takes almost no time to setup.  The tagging, search and browsing would be handled in the main app and is relatively trivial to implement.
+Gary Hodgson Each version of a design has multiple parents. I may have a version 1.2 where I incorporate a nifty new idea from XYZ in my design B that is based on A but not forked as I use different software and needed to rebuild everything using just the technical drawings but not the files.
So there's not much of a way around people manually defining parents like they do on Thingiverse.
We can limit it to parents that use Github too.
+Marcus Wolschon The parent ->forks relationship in github is 1:n, so no way of having multiple-parents.  I would probably try and implement it as I have done in development tracker - a collection of relationships which have a label ("Derived from", "inspired by", etc.) linking to the url or username/project it relates to.  (see the connections tab at: for example)  

The problem is then where to store this information, and how to standardise it over various projects from various sources. "Standardisation" is usually a perilous path to attempt!

[Edit:] I forgot to add, having such metadata does allow you to do interesting(ish) visualisations. For example the graph of relationships for the Prusa Mendel:   (It's still alpha so may not work, here's a screenshot:
Username is bad. People have dozens of projects. We could ease the current chaos of derivatives by linking to specuduc git hashes.
Agreed, by "username/project" I actually meant both username AND project, as this is the key used by gihub - for exactly the reasons you state.
I currently have it as a graph with directed arcs. The nodes are currently just the project URLS with a respective owner, and the arcs show what its derived from or parent of.
Add a comment...