On May 25, 2007, at 12:29 AM, andy@spiders-lair.com wrote:
As I see it, the commit of 3rd party libraries in Contrib generally should not be allowed as:-
a) It basically creates a duplicate code repository of code that should be availble from a single authoritive source. b) Uses Drupal.Org resources to effectively host "someone elses work". c) It's potentially a security risk, especially if maintainership is slack. Although problems aren't Drupal related directly it presents a sloppy view of the project as a whole imho.
a.) We wouldn't be distributing the library by itself; it would be packaged with some higher-level code. Nowhere on d.o would it say "If you want this library, get it here!" b.) As it relates to Drupal Core, contributed modules are ALREADY someone else's work. As it relates to Drupal as a whole, including GPL code form other sources is the very spirit of open source (as Jeff just said.) c.) If the maintainership is slack, the security risk is already there; the sloppy view of Drupal as a whole will already be there. It makes no difference if a 3rd party library is involved. Also, as a counterpoint: a good maintainer will monitor updates to a 3rd party library. And the good maintainer will always be more secure than the average user. I keep seeing the "security risk" reason repeated. But it seems people are really talking about the /perceived/ security of Drupal as a whole and not the /actual/ security of the average user's installation. Contrib modules are much more likely to get updated by the average user now that we have Update Status. But forcing a user to download and install a separate library means that library will most likely never be updated again. For /actual/ security, we need to allow 3rd party libs in Drupal's CVS (for the reason in c above). As a compromise, we could make contrib authors apply for special 3rd party library inclusion into CVS as Derek suggested and to then trust them to keep that 3rd party library well maintained. The CVS 3rd party lib application could be approved or denied based on the maintainers proven track record on previous modules. So newbie developers would be denied and maintainers like JJeff would need co-maintainers before the start of the project. (I'm not picking on you, Jeff! I love your code!) For /perceived/ security, maybe the best way to fix contrib from affecting Drupal core's good name is to put the distribution of contrib on a separate domain or sub-domain. Like 3rd- party.drupal.org or unofficial.drupal.org... Thoughts? - John