Why make a duplicate project?

So there really is no actual reason for this module to exist except that more choice makes you happy?

That's not just odd, it's against the Drupal project rules.

Do not try to duplicate functionality because "you don't really like how it's done there". That only adds clutter. Work to improve an existing module rather than introduce yet another random module, as that leads to confusion and frustration for the development, support and end user communities.

If your only reason really is to have duplicated code for the sake of having duplicated code, I'd suggest this be removed altogether. Is there actually no advantage of choosing this one over the other one?

The existing piclens project includes piclens lite.
So are you saying this module doesn't also support normal piclens full feeds and actually does less than the existing, working one?

I don't want to pick on you, but why close it without answering the question?

Why is this a totally duplicate project? What do you think you've done better or different that you needed to add this entirely new module?

I don't see any advantage from this duplicate module, even from your demo that's not in the Original piclens.module demo
What is the significance of pointing out that it's called "piclens lite" if it's really fully piclens, and just includes the lite version? Because the original project had already got the name? Well, that just shows that problem wasn't that you weren't aware the other one existed (which would be an OK excuse) ... did you see it and decided to double-up the job anyway? OK. I'm sure it was a fun exercise, but isn't it possible that publishing it alongside the earlier one without any explanation of why will be confusing to downloaders?

Too often new modules are contributed that do nothing new, instead, they only do it in a different way. We are then stuck with two modules that offer nearly similar functionality, but neither do it well enough. This leads to confusion, clutter, and a lot of inefficiency.

... To reduce this confusion and clutter, can you describe in any way or reason why a user should choose between the first piclens.module and your version?

So this is a utility module that's built to extend your img module... Not stand-alone, and not compatible with the other Drupal ways of displaying images and galleries.

Well at least that describes it a little bit. Good start.

I don't want to stifle creativity, and I know it's more fun just making your own modules than it is paying attention to how other folk have done it. But once you see it's been done, you really have to consider working together and contributing, rather than competing and confusing.

Yes, I can see why you would have had objections to your img module. I still can't see what benefit it has over the widely used alternatives, and your project page is incredibly unhelpful to anyone trying to decide which one to use. There are a confusing number of alternative image modules out there, and it's an obstacle to anyone knowing which one is right for them. If you are knowingly going to throw up another module that almost-but-not-quite the same as existing ones, at least describe what's different about it and why anyone should use it on your project page - not just have a meaningless marketing slogan "The easiest way to display images in posts, comments.".
Yep, I'd call it a duplicate, but as long as the pros and cons of that choice are described adequately, I'm not the one to be challenging about removing stuff.

I do still think that what you've got here is 80% duplication of functionality with piclens.module, and that you could easily have got what you wanted by adding just one callback hook to piclens.module ... probably only a few lines long. Maybe your function for turning attachments into a feed could be useful more widely also. Adding hooks for outside modules to talk to is good Drupal practice, and encouraged.

You don't need to be so hostile. Normally when I find developers working on related projects they are happy to find ways in which their modules can be made to work together. Usually just by opening up a few hooks, and resulting in tighter, smaller code.

Hey, somebody's already done something like this - perhaps you should see where that's going, maybe get on board, rather than building your own straw house.

This is all cool by me.
A little bit of centralization of the concepts will pay off for everyone.

Thanks for that vrencianz!