Consider consolidating Honeypot into BOTCHA

I'm inclined to mark wontfix, for the following reasons:

• As a site owner/maintainer for ~25 sites (most small/medium blog-style, but a few very large community sites), I have found this module on its own to be as effective (and sometimes more effective) than services like Mollom, not to mention CAPTCHAs and other punish-the-user types of spam prevention.
• The honeypot + timestamp spam prevention methods are both extremely simple, and require no extra JS or the extra overhead of a do-everything module to work.
• This module is already well-tested (full SimpleTest coverage of all important functionality), works great on Drupal 6 and Drupal 7, has a solid API which allows sites like drupal.org to implement even stronger custom spam-prevention measures, and has very few open issues/bugs.
• This module has ~3,000 active users, and I need to make sure that any module I merge this module into has their best interests—reliability, effectiveness, simplicity, and stability—in mind.

I like the idea of having 'one spam prevention module to rule them all', but I think having some simpler, more focused options (rather than aggregating everything into one very large module) is more appealing to many site developers, especially in terms of possible performance/codebase costs and usability.

Might I be wrong? Maybe. I'd like to hear from some other people who might have more input (and experience in merging widely-used contrib projects) about the best way forward, before trying to merge Honeypot's simple spam prevention methods into (what I see as) a much more complex module with not as many users, and many more issues to suck up developer bandwidth.

Not marking this as closed, but will mark postponed for now so it's out of my 'need to do' list.

Jeff, Thanks for good and thoughtful points, thanks for taking time to think about it.

To respond to some points:

• Botcha is transparent to the user, so it is intended to retire Captcha. Power of Botcha is in multiple recipes. No one thinks putting 2 or more Captcha's is a good idea (users would hate your website, even 1 Captcha is pain in the butt). Botcha can have 1000 recipes on one form if needed - users are not bogged by that. Mollom is still a good addition as it works as last line of defense against human spammers with their wigs and knock-off handbag backlinks.
• Admin gets a lot of flexibility, but out of the box the settings are very sensible, so it has small setup cost (install and forget)
• Protection needs to evolve as spambots do evolve (they are made by very motivated and quite skilled people). I observed a full session of a person crafting a spambot script on the newly Botcha protected site (it was a nightmare - 200 posts / hr passing both Captcha and Mollom). Botcha stopped the flow to 0. He spent a whole bunch of time trying and figured it out! 1 of 10 hits were submitted (still not bad for Botcha). I simply changed the security key which broke his scripts right away. He did another debug session. I should mention that it took a good part of the day for him and 5 seconds for me. After he penetrated again, I added a new recipe. He was gone. This is a model for Botcha to be long term solution. A fixed recipe will sooner or later be broken. We need a lot of variability and that is what Botcha does. Recipes are parameterizable and you can have 1 recipe applied 10, 100 times with different parameters. Try to reverse engineer an encryption algorithm and security key - need a lot of intellect and processing power. But then the algorithm itself changes - toughest problem to solve.
• honeypot sounds like one of Botcha's existing recipes
• timestamp sounds like timegate recipe in Botcha

I also want to get some perspective from you:

• how much time would it require to patch this module when there is a spambot script that breaks it and posts 200 spams/hr?
• if this module would be used by some very high profile website (think Yahoo or Facebook or Google) - it will attract very motivated spammers. What would it take them to figure out the protection scheme and break it? How the dynamics would look like (their time to break vs. admin time to close the hole)?
• what update model do you think your users would appreciate when they get hit with a wave of spam?
• do you have any thoughts on monetization or business out of it? (private response is preferred).

I totally agree with the point that users are ultimate decision makers here. Their first priority is a 100% working code. Stable module has a huge advantage. Frankly, Botcha has some open issues that may raise concerns right now. But that's exactly the reason for combining forces - all non-Captcha bot protection modules need to get through the same hurdles. We can use your experience in fixing remaining issues. I'm sure you can use our help too. Migration to Botcha won't be too easy - it is not shutting down the module and leaving people with no choice. I think we should let you propose a sensible plan (including measurable gates, i.e. when next step is ready) if you decide that it is a good idea. The implementation of the plan - we have a motivated team to work on it.

--
Ilya

It looks like you're making some good progress on the module, and it does look like a great solution. I still have a few concerns, though:

• The module is pretty far-reaching. For my purposes, I really like Honeypot's simplicity...
• The Honeypot recipes in the BOTCHA module seem to rely on JavaScript (as do most other recipes); this module (Honeypot) doesn't use it at all, really. There are positives and downsides to that approach, but the simpler non-JS methods used by this module (Honeypot) seem to be well-validated by a variety of real-world tests, drupal.org and flocknote.com to name a couple...
• The link to donate for issue completion on BOTCHA's project page concerns me, for two reasons:
  1. It seems to imply that the module won't be well-maintained without financial incentives for the maintainers (this grates on my open-source development ideals).
  2. It uses a solution that doesn't seem to be used by any other Drupal modules/maintainers (I've seen some people post a simple "tip jar" link to PayPal or ChipIn, but nothing more, really).

I'm still willing to entertain the idea of folding development into BOTCHA, but I am definitely not considering it for the D7 development cycle. Perhaps by the time D8 comes around.

Staratel / iva2k: Thank you again for the offer, but I think I'm going to decline the merger at this time, mainly for the reasons I outlined above; I think there's a place for a few different spam prevention modules that do similar things, but in slightly different ways.

I'd like to keep Honeypot more nimble and focused on one method, and I think there's a value in having a few different CAPTCHA-less modules available on Drupal.org, as long as they're all well-maintained. I've added a link to BOTCHA in the 'Alternative Modules' section.

I think after Drupal 8 is fully released, and the module landscape settles down, I'll be thinking about what's next for this module, and maybe at that time it would be good to consider joining forces in some way. But for now, I'm going to mark this issue closed.

Added Extendable protection point.

Thanks for this decision to keep honeypot separate. It was the right decision and I'm glad to have selected it for integration with my own cbp module which provides honeypot integration if the honeypot module exists :) I like it's lightweightedness vs something like a one module to rule them all mentality. Linux wasnt created with the one ring mentality but windows was. Which one is more stable? IDK, debatable maybe, but I'll place my chips on Linux and it's small pieces that create the OS itself thats for sure :) Bigger isnt always better.

@crystaldawn - well, hindsight is always 20/20, but BOTCHA seems to have had a lot of steam initially, but it died out relatively quickly. Don't know if that was because the 'PatchRanger' setup that was supposed to help fund ongoing development never really got off the ground, or it was something else, but I think Honeypot does everything that most sites need and isn't needlessly complicated :)