Offering to maintain Spamicide (for merge it with BOTCHA) [#1880332]

@lipcpro Let me invite you to our dream-team of non-CAPTCHA (ie invisible to end-user) spam fighters:

iva2k (BOTCHA founder and maintainer)
Dustin Currie (un.captcha.lous founder and former maintainer (un.captcha.lous merged with BOTCHA), BOTCHA maintainer)
deeporange1 (JS Validate Forms founder and former maintainer (JS Validate Forms merged with BOTCHA), BOTCHA maintainer)
Staratel (BOTCHA maintainer)

Don't you think that together we could do more than each alone? We miss you, lipcpro.

Here you are some points why you should join us:

Extendable and configurable protection: Each way of spam protection is a Recipe, which has its own logic of form submission handling. Recipes are bundled into Recipebooks, which are applied to the forms. The list of available recipes: http://drupal.org/project/botcha#recipes-included.
Selenium-tests for all major browsers (Firefox, Google Chrome, Opera, Internet Explorer plus possibility to extend): It means that JavaScripts-recipes work as expected - always, guaranteed. If you see something strange - you could just launch all Selenium-tests to see what's wrong and post an issue to Drupal.org. Brief Howto-instruction (both installation and usage of Selenium) is inside the Selenium-tests file.
Handy UI: UI lets you to turn on or off recipe applying per each form. It helps to avoid critical situation when one or more recipes doesn't work as you like: you should just turn them off and post an issue to Drupal.org - and your site would not be affected by any discomfort.
Fully test-covered: Tests covered almost every line of the code. Plus tests' structure has been unified - and now it is really simpler to maintain it.
OOP-style: BOTCHA is moved to OOP-architecture. It means that all "entities" that take part in BOTCHA functionality are turned into classes. That gives more flexibility to extend and freedom to modify.
Like MVC-application: The module's internal structure looks like real MVC-application. It gives a chance to separate logic of the application and the layer of interoperability with Drupal platform - that means that the BOTCHA is going to become more version-independent. I hope in the future we would see a Drupal-version-independent BOTCHA module. It eases maintainership of the module.
Module as an Application: Each hook implementation is a method of Botcha class, which extends abstract Application class. Turning a module into a class gives a lot of opportunities, such as applying "Decorators" (see http://en.wikipedia.org/wiki/Decorator_pattern) to a module as a whole. For now we have Logger decorator implemented (Logs every method call into a file - for development purposes, turned off by default), Cacher is planned. See Moopapi project page for more details: http://drupal.org/project/moopapi.