For me it was clear that JSON is bad, from many different sides. I don't like that in order to load this code, my image will need JSON parser. But Stephane, its easy to say what you don't like and more difficult to provide a plausible alternative. GemStone lacks own parser, and this was (as i heard) the reason to bring another parser into circle. I don't want to go and repeat myself on how you could do the same using plain smalltalk literal syntax. (If someone interested, lately we invented a "smalltalk object literals" which allow you to store any object into a textual file(s) using plain smalltalk array literal syntax, and read them back, but for this, of course, you will need smalltalk parser). Anyways, leaving aside JSON syntax, here's my feedback: In, methodProperties.json , a method metainformation is stored like: { "class" : { "compiler:" : "MartinMcClure 10/14/2010 20:35" }, "instance" : { "compiler:" : "MartinMcClure 10/14/2010 20:35", "isNotClobbered:" : "MartinMcClure 6/18/2011 08:24", "nextAvailableLocation" : "MartinMcClure 10/14/2010 20:40" } } Please, guys, do not repeat mistakes of the past, lets separate the Author field from date stamp. Then we don't need to enforce rules like "you can put anything into author name, as long as it contains no spaces nor punctuation characters" and other weirdness imposed by the way how data is stored. Or you prefer writing full name without spaces? I'm not. But i forced to do so, exactly because of things like that. It would be much nicer to have this field separate, then, for instance we could use email(s) as an author name, i.e. "Igor Stasenko" <siguctua at gmail dot com>. Years are passing, and who knows who will be looking at our code or why, but as to me, if people could quickly find a way to contact/identify original author, it would be a good plus. Same goes to "commentStamp" field, of course. And , of course, since it is git, and each method stored in separate file, having method's stamp in another file seems a bit superfluous. But i understand that letting git tracking this may be complicated for legacy code. If code would be born on git repository, you would not need any stamps aside git's ones. So, what i would propose , for a future perspective it to have a special file, containing 'meta-meta' information, like "what is the (version) of the format used to translate metainformation". So, later , if we would want to use different storage format for metainfo, we can easily migrate it without breaking everything. Even if we stick with json, we might require that (like migrating from one method stamp to another one, or adding extra meta-info etc). P.S. For me it is more important to have a working solution right now. So, we can rebase our code on git. I want to use it for our VM source code. Having everything stored in git repo is much nicer than having C pieces stored on git but smalltalk on monticello/metacello.. Managing this mess takes a share of time , every time we need to release new version. With Git it would be much much simpler: single repository to store all .. P.P.S. And keep going guys. :) -- Best regards, Igor Stasenko.