The request to remove the code you mentioned above was only made after it was already booted. The requirements keep changing from day to day. That’s one of the major issues.

Scott, can you clarify?

The code I highlighted above is from the classcompatibility.php file.

As far as I can tell that code was introduced a while back, and existed up through version 1.9.19. Then in October, you modified or removed that code in version 1.9.20, and instead put code in to a MU plugin that was designed to prevent loading of PO. My impression is also that you did that because of a change the PO author had made to prevent WPSS from functioning, as his way of defeating the 1.9.19 code.

Then the WP team told you to remove the MU, and you did that with version 1.9.21 (or at least the code targeting PO) -- and did in fact issue that right away. But the same time you restored the classcompatibility file code from version 1.9.19.

So my guess has been that when you removed the MU code and reported that, the WP team initially thought that everything targeting PO had been removed, but then subsequently they became aware of the restoration of the classcompatibility code (the stuff that starts at around line 306)

Going back to my "no pets" analogy, I guess this would be like a tenant who has a chihuahua in the apartment for months without problems, and then trades the chihuahua for a labrador retriever - and then the landlord says "the dog" has to go. So the tenant trades back - gets rid of the lab but recovers the chihuahua, thinking that the problem was with the dog's size - but then the landlord learns about the chihuahua and is doubly ticked off because the landlord meant no dogs of any kind.

So I certainly see the source of the miscommunication. And if in fact you had no communication at all from the WP team between the day that you put out version 1.9.21 (removing the MU code) and the day of the removal ... I agree that's a bad way to handle things.

But I think you know now what they want and why they want it. If you want to be angry over the process or the words used ("guideline" vs. "rule", etc) that's your right --- but I am a problem-solver by nature, so when I work on projects I try to overlook process and personalities and focus on end results instead.

Is there any process or solution that would make you feel willing to restore some version of Spamshield to the WP repository?

Perhaps following the model of offering a basic plugin on WP along with a more fully-featured premium version?

I can tell you that I am finding that there is not another plugin currently in the repository that meets my needs as well as Spamshield. I am experimenting around with others, but each has its own set of shortcomings. So I would love to see Spamshield come back, at least with the basic anti-spam functions.

At the same time, I am guessing that you are going to have a hard time finding a distribution channel that will bring Spamshield to as wide a body of users as the WP repository. I am assuming you'll have to go to a fee based model at a site such as envato & codecanyon. Perhaps I am mistaken ... but that's what I am expecting.

So I would just suggest that you focus on end results and where you want to be. It's normal in this world that people have disagreements from time to time-- and easy to walk away in disgust. The harder thing is to move past the anger and work on finding a path to a solution that may involve compromises from all sides.