diff --git a/docs/extensions/customization-strategies.md b/docs/extensions/customization-strategies.md
index 662310f3e8ae2f06049edfb2bfc199d4c48094d1..f642b8081263881984591603470c7bf8434cca2c 100644
--- a/docs/extensions/customization-strategies.md
+++ b/docs/extensions/customization-strategies.md
@@ -1,6 +1,10 @@
-# Customization Strategies
+# Packaging
 
-Building a CiviCRM extension is the *recommended* way to customize CiviCRM, but others strategies exist too. This page summarizes some of the advantages and disadvantages of each strategy. 
+When developing an enhancement for CiviCRM, one writes code based on Civi's programming interfaces, such as APIv3, `CRM_Core_Page`, or `CRM_Report_Form`. You need to put this code in some kind of *file* or *package* that can be *installed* on a CiviCRM system.
+
+The best-supported approach is to develop the package as a native *CiviCRM extension* -- this package format works in all CiviCRM environments. However, there are other packaging formats (such as Drupal modules and WordPress plugins). How do they differ? Well, from Civi's perspective, code is code regardless of the packaging -- but the tutorials, glue-code, tools, and culture may differ. For example, you can write a subclass of `CRM_Report_Form` and put it in either a CiviCRM extension or a Drupal module, but a few lines of glue-code would be different, and the code-generator (`civix generate:report`) is only tuned to output native CiviCRM extensions. 
+
+## Comparison Matrix
 
 | Capability | CiviCRM Extension | CiviCRM Custom PHP/Tpl Dir | Drupal Content (Smarty) | Drupal Module | Joomla Plugin (Civi v3.3+) | WordPress Plugin (Civi v4.6+) | 
 | --- | --- | --- | --- | --- | --- | --- |