セカンドシステム症候群の三重苦や継続的なサポートのなさ、ブランドは傷つき、"Zope"の名を過去のものにした。
PythonコミュニティでもZopeに関連したものを使ったことがない人々に、過剰なエンジニアリングや技術者の自己満足ととらえられるようになってしまった。
オリジナルのZopeアプリケーションサーバーであるZope2の評判は、未だモノリシックでお粗末な設計に苦しんでいること以外は文句の付けようがなかった。
ブランドは許容を超えてしまった。
そしてZopeの言葉がつくものはほんの少しの尊敬と、悪いイメージを持ち始めた。
かろうじて、この評判はweb開発に関係している部分だけだった。（？PythonはWebだけではないので、それ以外の業界ではそういうイメージを持たれなかったということか？）
ブランドの崩壊はあったが、それでもPhiladelphiaの開発者は、Zopeの再構築は技術的に成功したと考えていた。
ZopeのオブジェクトデータベースであるZODBはZopeから切り離され、独立に利用できるようになった。
コンポーネントアーキテクチャは複雑な入力に対して、非常に迅速な処理を行うのに有用なことを証明した。
Zope3のインターフェイスシステムは、インスタンスベースのダックタイピングを構造化できた。そして、これはAPIドキュメントを書きやすくした。
Philadelphaの開発者にとってのZopの存在意義は、宣言的なコンテキスト依存のセキュリティシステムだった。
これは完全に混乱していた。これらは再利用はできないが、アイディアは再利用すべきであった。
オブジェクトグラフ上を"traversal"してセキュリティコンテキストを決定するというZopeのコンセプトはZope2やPlone界隈では常識であった。
そして、そのころ、それに変わるものは競合のシステムは持っていなかった。
そして、もうみんな気づいているだろう。Philadelphiaの開発者は私のことだ。そして、これらはすべて私の経験してきたことだ。
この経験を振り返ることが楽しいことだとはいえない。Zopeがこのような結果になってしまったのは、私も大きく傷ついた。
これらの経験は、私にいくつかのことを気づかせた。
多くの開発者はとてもとてもリスクを嫌う。彼らは小さなステップを好む。またはまったく変化したくない。彼らに技術的な関心のないことを認めないといけないし、彼らが好まない方法を使わないのも認めなければならない。
他の開発テクニックや技術と一緒に使えないような、完全に統合されたモノリシックなシステムの魅力は、徐々に消えていく。そして、魅力が消えていくと、忌むべきものに変わるのだ。
モノリシックシステムによるこうした問題に対する自然な反応は、すべてを完全にプラッガブルにすることだ。だが、これは罠だ。
テストは非常に重要だ。ドキュメントはもっと重要だ。
複雑なシステムを入れ替えるなら、もっとシンプルにしていかなければならない。複雑さを追加してはいけない。
ブランドは重要だ。○○とはなにか？という質問には１つの答えだけを持つべきだ。Subletyとブランディングを混ぜてはいけない。混乱をもたらすだけだ。
PyramidはZopeの影響を大きく受けている。それはとても広範囲に及ぶ。派生物だ。Zopeがなければ、Pyramidはなかったとはっきり言える。
だが、同時にPyramidはZopeへの回答だ。
Pyramdiを作ったのは、Zopeの良さと偉大さを理解しているからだ。
その一方で、zopeの名前を持つパッケージをいくつか使っている。これらはZopeと関係なく十分再利用できるようになっているからだ。
PyramidはPylonsやDjangoからも大きく影響を受けている。だが、皮肉なことに、これらのシステムはそれほど良く作られていなかったため、簡単に再利用できるものはなかった。
Pyramidはzope.interfaceを以下のことに利用している。
宣言的なコンテキスト依存セキュリティ機能のためにコンテキストを発見する（ACL認証機構）
コンテキストベースでのビューを発見する機構。（たとえば例外ビュー）
Pyramidはzope.deprecationを、フレームワーク利用者にAPI廃止を通知するために使っている。
これは、まったく依存関係をもたず、１００行ほどのコードしかない。Zopeアプリケーションサーバーとはまったく関係のないものだ。
Pyramidを使う分には、これらのことはまったく気にする必要はない。
フレームワークの開発者はこれらのことを知っている必要があるだろう。
これらをフォークして名前を変える方法もあったし、Zope懐疑論者に知られないようにしても良かった。まったく違う名前でリリースしなおしてしまえば、もっと評判が良かったかもしれない！
だが、zopeが悪だと単純な二元論を持つ人たちのために名前を変えるだけのためにフォークするのは、何百人という貢献者のたちへの冒涜だ。
彼らはZopeブランドの悲劇にかかわらず、賞賛と尊敬に値する人たちだ。
彼らは私がしてきたよりも（そして将来にわたってもきっと）PythonのWeb開発に多くの貢献をしてきている。きっとこれを読んでいる読者たちよりも。
zopeは悪、pyramidはzope、だからpyramidは悪だという議論をしている人たちには、もっと勇敢になってもらいたい。
Within your first ten minutes of evaluation, considering the stuff I've written above, please try to momentarily entertain the notion that the history of Pyramid's Zope dependencies isn't written entirely by hapless dunces.
PyramidがZopeに依存している理由が不運な劣等生について書かれたものではない（訳注：フレームワーク上の欠陥ではないという意味？）ことを書いてきた。
If you need a concrete positive replacement, try to think of something like this:
Mac OS X today ships with zope.interface out of the box and that sort of deployment effects more users than you and me put together plus all of our friends (and maybe even all of their friends) will likely ever influence.
Consider that the common wisdom you've gained from Reddit or that guy who used Zope-the-application-server for one day in 2002 may be irrelevant.
訳注：このあたり、ぜんぜん意味わかんない
批評は、あなたがたが最初にPyramidアプリケーションを書くときまでの貸しとしてください。
それでもまだ信じられないのであれば、そのような批評を歓迎します。