GregBeaver在他的博客中写了关于PEAR、新的PEAR频道以及他看到的PEAR及其开发者的一些问题。Greg负责最新版本的PEAR和PEAR安装程序——以及PEAR频道的开发。上面引用的特定链接引用了PEAR-dev邮件列表上的一个线程……当我询问Cgiapp是否适合PEAR时，这是我发起的。
我一直怀着某种兴趣关注着Greg对频道的开发，但有一段时间我不太明白这有什么意义……直到pearified.net开始通过pear频道提供Smarty。通过PEAR安装程序安装Smarty非常简单——并且指出了一种分发PHP代码的好方法。
Greg在他的帖子中完全正确—PEAR最好的地方是安装程序。但是，存储库中也有一些很棒的代码。如果没有Log、DB、Cache_Lite、Pager和其他工具，我就无法完成我的工作；它们提供了一些小片段，这些小片段可以通过几行代码完成大工作。
然而，我也已经观察pear-dev列表超过六个月了，同时试图决定是否建议我自己的一些代码被列入。我觉得我拥有的代码绝对符合PEAR的精神——良好的、可重用的、可扩展的、可用于各种项目的胶水代码。然而，它也属于许多PEAR开发人员似乎厌恶的保护伞：框架。这就是整个线程爆炸的方式。
我仍然认为Cgiapp非常适合PEAR。但是，我现在不打算考虑它，原因如下：
- 我没有时间或精力去争论为什么我认为Cgiapp适合。如果我认为这是一个简单的论证，或者它只需要稍微调整一下Cgiapp，我就会立即去做。但从我阅读的回复我的查询的评论来看，PEAR的一些非常核心和直言不讳的成员似乎只是觉得任何类型的框架都不是PEAR的领域，我认为他们会有效地游说反对该提案。
- 我真的觉得Cgiapp应该尽可能地忠于它的Perl前身。我希望API相同，并且我希望它朝着相同的方向发展。我怀疑如果我要通过PEAR提案流程，我将不得不失去这种完整性才能通过审核。
- 随着即将发布的1.4.0版本中PEAR通道的出现，我没有理由不能在sourceforge站点上建立自己的PEAR频道—或加入pearified.net。我认为Greg在这里击中要害：渠道为PHP开发人员打开了可能性，尤其是对于可能不想或没有时间完成PEAR提案流程的PHP开发人员——或者提供不在PEAR范围内的软件包的开发人员。PEAR安装程序与渠道相结合，创建了一个令人难以置信的分发渠道。
我非常尊重PEAR，我看到它在过去的一年里取得了巨大的进步；如上所述，如果没有PEAR提供的工具，我几乎无法完成我的工作。然而，我现在根本看不出Cgiapp如何可能在PEAR中茁壮成长。我认为Greg对他的PEAR开发伙伴的警告绝对应该引起注意。如果PEAR希望吸引新的有才华的PHP开发人员，它需要超越自身。
