Discussion about future collaboration for D7

I can see how you would leave with the impression that this was a "joke" module being done for fun...

Not at all. I assumed that this was a serious module written because it is a cool idea and in order to learn about this type of thing. I didn't mean to imply that I thought this was frivolous.

I put a lot of time into evaluating the modules you mention...

While ShortURL provides a nice API for integrating a site with URL shortening services, and URL Shortner provides this service in Drupal...

Those are contradictory statements -- you got the names of the modules wrong and their purposes reversed. ShortURL allows shortening URLs on the same domain, while Shorten URLs provides an API and UI for accessing a number of URL shortening services including ShortURL.

I found it all to be a bit confusing and overly dependent. What was missing was a nice integrated module to simply turn a standalone Drupal site into a URL shortener site.

Really? All that's required to get them to work is to enable both modules. No configuration necessary for most sites. But I would love to hear any suggestions you have about how to make them simpler. And the "overly dependent" thing is disingenuous, because ShortURL and Shorten URLs combined add up to about 27.3KB whereas ShURLy is 44KB.

If there are elements of ShURLy that could be useful to any of the other modules, feel free to borrow some code!

There are certainly things in ShURLy that are not in ShortURL/Shorten URLs, and vice versa. But it would be nicer if we could work on this together instead of duplicating work.

However, choice, change, and competition are the basis for a healthy ecosystem. I think users should have a choice, and for those who want an simpler, single-purpose module to do this, ShURLy represents a great option.

Look, I appreciate that you want to defend your work, but no one thinks it would be a good idea to go out and create another module that does exactly the same thing as Views. Same idea. Competition is good for a marketplace, but collaboration is better in an open forum where there's limited manpower. Drupal modules are not part of a marketplace. It's the Drupal Way to collaborate, and there's even a whole page recommending it in the documentation.

I agree with you that it would be nice to have Shorten URLs and ShortURL combined into a single package. I'm also not attached to the namespace, although I think it's an easier namespace to find. I do think that there should be a logical separation between the services API and the user interface (Views + forms), but that can be done with submodules rather than separate packages.

I'm not requesting that you just throw away the work you've done on this. There is clearly substantial thought put into this project. However moving forward I would like to find a way to work together instead of wasting both of our time trying to build the same features.

One easy way to do this would be to create a unified package for Drupal 7 that all three of us (you, myself, and irakli) could collaborate on. Would you at least consider this option?

Marking as active pending feedback.

I tested out ShortURL / URL Shortener and found them to be clunky, confusing, and awkwardly architected. I found the user interface to completely ignore any of the existing design patterns for URL shorteners. I found them not to implement about half of the features which I wanted out of a URL shortener (web services, custom URLs, request rate limiting, click tracking, user-owned short URLs, and more). I also found that the database schema -- the actual core way that the data was stored -- didn't seem to offer support for these types of options, so it was unclear to me these features could be added. In short, my first impression of these modules was not great.

I prefer to hear feedback like this. It's something concrete that I can take and move forward to improve on. I can't speak for ShortURL but I know that the architecture of Shorten URLs would allow adding most of the features you mentioned without any restructuring. In fact some of them have been added already since you first wrote ShURLy.

Specifically WRT request rate limiting, I'm curious why you backported the D7 implementation instead of making use of D6's flood control mechanism?

I apologize for getting the names confused in my description, but this is part of the problem with them. It's confusing what each does and how they work together.

Fair enough.

It seemed like suggesting a complete rewrite of these modules in order to implement my opinions for how a URL shortener should work (and keep in mind that one of my criticisms is that this shouldn't be two separate projects) would have been selfish and, more importantly, insulting to the developers who obviously put a lot of time and work into these modules.

If someone ever opens an issue in my queue saying "I have a lot of ideas about how to take this module to the next level and I want to write a new branch from the ground up," I would be open to that. You're correct that I would probably be offended by an issue worded in a way that suggested the current branch is inadequate and needed to be completely rewritten. But regardless, I would have appreciated an email just to let me know what you were doing and to get my thoughts.

The last thing I want to do to discourage anyone from contributing to Drupal, so it hurts me to feel like I've been pushed into criticizing your modules.

I'm the author of a number of different modules, many of which are used by thousands of websites according to drupal.org statistics. My issue queues are some of the best-maintained on the site, with the number of open issues typically at 1-3%. I have a lot of time and experience invested in Drupal. You're not going to scare me away. I would rather hear honest feedback.

Likewise, I think your criticism of my contribution is starting to go a little too far.

I'm sorry you feel that way. My comments are intended as a request for collaboration, not a criticism of your efforts.

As the CEO of Lullabot, I simply don't have the time become part of a team and try to coordinate efforts. And to be clear, I'm not even sure that efforts can be coordinated.

I'm not talking about a coordinated team effort. I'm talking about three people having CVS access to the same code. The result would be less of a time commitment on your part. I do appreciate your time limitations, and thank you for taking the time to engage in this discussion thus far.

However, if you insist on having competing efforts, I have two questions:

1. Do you intend to actively maintain ShURLy on drupal.org?
2. Do you intend to port ShURLy to Drupal 7?

If the answer to #1 is Yes, I think you're missing an opportunity to reduce the amount of time you're spending on this.

If the answer to #2 is Yes, I want to encourage you to give irakli and I a chance to demonstrate that our modules can support the functionality you need, since a port to Drupal 7 will certainly give us the opportunity to re-architect and even combine our modules where necessary. I hope and believe that at that point you will find that competition is no longer necessary.