I am trying to setup a repository of reusable code. I was thinking about having each reusable code module have a certain “Maturity Level” rating. The rating would be defined a
Kit mentioned the most important problem: the reuse. the rest of the idea is nice, but it's not more than a detail.
i mean, i myself have trouble maintaining my very own reuse library. sometimes i do an implementation that is very project-specific, or i do the n-th prototype for some idea, and none of those ever gets into my library.
if you really succeed in having a code reuse library, that is used and maintained by many developers, in a disciplined way, than that's victory. you need a version control system and a bug tracker, the latter being used by both project owners and users. you need communication and means of contribution. having a handful of devs using a project dramatically improves its quality. implementation gets better. documentation is created. API and feature design are on a much higher level. a committee is a nice thing, but it cannot decide, how good given code is, without actually using it. it can decide whether the code meets specific standards, but meeting standards is not sufficient for good libraries.
you need to do your best to make sure, you don't have tons of code snippets floating around, all of which can more or less do something. ok, any design decision has pros and cons, but i think, it makes more sense to start with ONE project for a given task, and branch it, if really necessary, but keep alive communication between project teams, and consider (partially) merging back.
don't worry too much about categorizing the quality of different projects. if a project is bad, then users/devs will push it to a better level. most people are clever enough to see, when a library is good, and when it isn't. you really need to put your energy in these symbiotic effects, rather than trying to burden participants with strict rules.
just my 2 cents ... ;)