[development] Drupal's CVS policies... including 'foriegn' code in TinyMCE module?

[Michael Favia]

Karoly Negyesi wrote:
>> I don't understand what's so inconvenient in allowing external files. 
>>     
> It's very simple. When there is a security fix released for the 3rd party code then our repository necessarily will be some time behind -- if the maintainer is sloppy then seriously behind. I do not want Drupal distributing insecure code. Solve this problem and we can move on. 
>   
Im of the alternative opinion that most module maintainers will be a 
little more keyed into upstream progress for third party code than the 
average module user. While it doesnt solve your problem of "I do not 
want Drupal distributing insecure code." It does mitigate the real 
problem of drupal users actually using insecure code on their websites 
as it is outdated, etc. Why not centralize the management of the code, 
this is one of the purposes of version control systems in the first 
place. To avoid duplication of effort. This isnt drupal core we are 
talking about these are contrib modules that im sure have a number of 
flaws anyway because of their less robust testing and security audits.

Arguments "for" such a centralization:
* Ease of installation/upgrading use for user base.
* Less trouble diagnosing issues on modules with third party libraries 
because you have 1 fewer variable.
* Core Update Status Module to alert users automatically of new versions 
that include may include security updates.
* The average module maintainer is probably going to be paying more 
attention to the upstream project than the user and is thus more likely 
to be aware of issues and also has the power to roll in the fixes and 
release thereby notifying everyone involved.
* Module incompatibilities often require that people get a specific 
version of 3rd party library/code and this can be tough to instruct 
people to follow.
* fewer unnecessary bugs regarding library mismatches, etc

Arguments "against" such a  centralization:
* Third party libraries can and will fall behind the official source 
with regards to vulnerabilities, security patches, etc a vigi=lant user 
might know or fix theses issues faster.
* Duplication of code management with upstream.
* licensing (discussed LGPL, etc)
* module developer under less pressure to upgrade module to work with 
newest upstream version slows down innovation, etc

I for one think that a good argument is made for centralizing this code 
management and easing the burden of our users without impacting the 
module developers (it is optional right?) I don't see how it can't be a 
mitigating factor for migrating users off of old libraries if you accept 
the proposition that the average maintainer follows the upstream project 
closer than the average user. But perhaps this is flawed logic.

-- 
Michael Favia                   michael at favias.org
tel. 512.585.5650        http://michael.favias.org