Really they are only open-sourcing GovDelivery. There's a lot of questionable code in there. Is this really how you'd do this?
// the user may have put in an address of the form "Full Name" <email@domain.tld> instead of just the address,
// so we want to filter to the right address
function govdelivery_filter_email($address) {
// borrowed from the drupal valid_email_address($mail) function
$user = '[a-zA-Z0-9_\-\.\+\^!#\$%&*+\/\=\?\`\|\{\}~\']+';
$domain = '(?:(?:[a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9])\.?)+';
$ipv4 = '[0-9]{1,3}(\.[0-9]{1,3}){3}';
$ipv6 = '[0-9a-fA-F]{1,4}(\:[0-9a-fA-F]{1,4}){7}';
// setup an array for the matching expression
$matches = array();
// the regex below is adapted from drupal's valid_email_address($mail) function
preg_match("/$user@($domain|(\[($ipv4|$ipv6)\]))/", $address, $matches);
return $matches[0];
}
The module uses MySQL-specific functions (FROM_DAYS, TO_DAYS, FROM_UNIXTIME) so it is not portable. Relying on these instead of the PHP equivalent makes me wonder how many other shortcuts are in there.
Several undefined constants are referenced (NAGIOS_STATUS_*).
I'm not sure what's going on in odmService.php.
The module was authored by Chris D'Antonio of Acquia (which we can assume has a contract with Uncle Sam), aka http://drupal.org/user/250704
If you use Drupal much at all, you'll find that, while the core is cross-database, 90% of contributed modules are MySQL-only. It's what you get when you don't provide an ORM, I guess.
Internal code is always very specific to the platform upon which it's installed. It's hard to justify spending time to make software run in environments you're not using.
Now, there's a school of thought which holds that you shouldn't open-source something without going through and auditing it for local-isms. There's another that holds that it's better to get the software out there.
I'm not sure into which of those schools I fall personally, but if getting this stuff open-sourced was a bottom-up effort, it'd be hard to get the higher-ups to say 'yes' and then immediately ask them to invest a ton of developer time on the process.
>Internal code is always very specific to the platform upon which it's installed. It's hard to justify spending time to make software run in environments you're not using.
I'm having a lot of fun with that right now, knowing that we're doing a migration in the next year or so, but not having a clear path to write my code so it will carry over to the new platform.
Of course, we still don't have nailed down what that platform will be, but so it goes. It's just painful to write code you know will be obsolete inside of a year.
But your criticisms primarily address portability and well-packagedness which was probably not an original design requirement. Now that it is open source it may be an issue, but is it a valid target issue for tax dollars?
I believe this is an appropriate point for the community to step in.
These aren't worthless modules either; they all address needs that core Drupal lacks. Node Embed particularly sounds useful to me.
It's a minor nit to pick, but I believe the majority of this was done pre-election, and hence, paid for out of campaign dollars. That isn't to say that some of us didn't pay for it, but the initial development of these plugins was almost certainly not done with taxpayer money.
If you're ever in the DC area, I'll be more than happy to depress you with all of the ways in which taxpayer money is all but thrown away by the millions, but in this particular instance, I think we're okay.
Several undefined constants are referenced (NAGIOS_STATUS_*).
I'm not sure what's going on in odmService.php.
The module was authored by Chris D'Antonio of Acquia (which we can assume has a contract with Uncle Sam), aka http://drupal.org/user/250704