Neat

Is that an implementation of the processing API in C++, with livecoding? Interesting...

With regards to regressions coming from other users, that isn't something that can happen in share. Actually early thoughts about what share would be had me thinking about that question as i had the idea that any user could use any other user's name as a namespace to access parts of their code and call it directly. But that really isn't the case anymore, share just falls back on users cutting and pasting code that they find is interesting and integrating it into their own sketches, from that point it has no dependencies on the original author (though a relationship is made) nor can any one else modify your sketches.

Overall i would say Share headed in the direction of enabling co-operation over overt collaboration, its not really designed with the needs of teams in mind, but rather a community of independent creators having access to each others work.

About source control that is also an interesting story, as i had a long obsession with building the entire thing on top of a distributed version control system like git or hg. However in the end i wanted to keep the dependencies low (my goal was that if you can run processing you can run share without installing anything). And although i did find a could of single executable dvcs that could bundle along with the app, there was always something that didn't quite work with what i had in mind. So currently there is no source control (or history related options) exposed to the user. Though on the server everything will likely be source controlled.

It also wouldn't be too hard to define a protocol, there actually isn't much to it, its just documents sent and retrieved over http. I use uuids to identify resources, which should be portable across various applications.

Cheers
Yannick