何年かがすぎたが、Philadelphiaの開発者はソフトウェア工学のいくつかのトピックを気にかけていた。
He notices that if it behooves the industry temporarily, it will tolerate things that are slightly different, but it always holds its nose while doing so and will always retreat back to the familiar at first opportunity.
業界では、すべてのデータベースがリレーショナルでないことに気づいていた。
特に、80年代後半から90年代に掛けて、Smalltalkの喧伝によって、オブジェクトデータベースの可能性が示されていた。
たいしたドキュメントもなかったと記憶している。
Zopeに関するいくつかのことがらが、彼にとっては自明だった。
明確にされたのは、Zope自体の自動テストが必要だということだ。
さまざまなスキルレベルの人たちが十分な品質管理もなく疑問のある追加をしていた。
結果として、自分たちの首を絞めることになった。
あれほど魅力的に見えたweb上での開発モデルも、多くの欠陥を持っていることが明らかになった。
この方法では、自動テストを書くことは困難だった。
TTW(Through-the-web) モデルは、システムと密接にかかわっていたため、webモデルとかかわりのないコードを書くことが困難になっていた。
TTWセキュリティモデルの存在と、管理インターフェイスへの期待は、さらに先進的なコードを書くことをやっかいにしていた。
袋小路に追いやられていた。
なぜなら、新しいZopeユーザーをひきつけているものが、最初にそのシステムで成功した後に、撃退すべきものととらえられてしまっているからだ。
テストしやすいコードを書くためには、Digital Creationsのエンジニアは、Web上での開発やめなくてはならなかった。しかし、Zopeのためのコードをオフラインで書くのは、非常に腹立たしいことだった。
TTWコードモデルは死すべきか、もっと開発をサポートするツールが必要であることが明らかだった。
だが、UNIXで動くような、よりよいツールチェインを作る時間を誰も持っていなかった。
TTWプログラミングモデルは、社内外で幻想だったと感じられていた。
だが、それでも2001年はZopeは非常に成功した。
2001年のSoftware Development MagazineのJolt Product Excellence Awardを勝ち取り、雑誌の表紙をかざった
(この賞をもらったときは、この製品は、とても重要で、企業サイトを作る難しい仕事を速く、早く、さらに効果的にすると書かれていた：訳注よくわかんないけどものすごく賞賛されたようだ)
大きなメディア企業がこのプラットフォーム上にサイトを立ち上げた。
彼らにとって十分なできだった。
Digtal Creationもコンサルティングの成功を十分に受け入れていた。
さらなる利益も十分に得られていた。
主要なZopeメーリングリストは1日あたり100メッセージが流れていた。
メーリングリストのメールを受信を重要なサービスのイベントトリガーにしてもよいんじゃないかとジョークで言っていた。まるで時報のように新しいメッセージが昼夜問わず飛んできていたからね。
Zopeベースの新しいシステムがどんどん作られていた。CMF(Ploneのベースとなっている。)もその１つだ。
そんな感じでときはすぎ、Philadelphiaの開発者は、Zopeの次のバージョンが始まるのを見ていた。Zope3だ。
Zope3は、Zope2と互換性がなくなるようだった。互換性レイヤーはのちに作成されることとなっていた。だが、Zopeは完全に再設計、再構築されたていた。
すべてが書き直され、この作業はDigital Creationsのなかで多くの労力が注がれた。
Zope2を作った主要メンバーはフルタイムで作業した。さらに彼はチームの開発者たちの手助けもした。
Zope3はコンポーネントアーキテクチャをもとにしていた。これは開発してテストしたコンポーネントを入れ替え可能にするものだった。開発者が必要なもの、提供できるものサードパーティから提供されるものを必要に応じて入れ替えることができ、Zope2の柔軟性のなさとは対照的だった。
サブクラスよりも集約が好まれるようになった。ZCMLという、XMLベースのコンフィグレーション言語ですら作り出した。Zope2のような大きく1枚岩なシステムの代わりに、小さな部品の相互作用で構成されるようになった。
Philadelphiaの開発者は、これはすごいものになると核心していた。尊敬する賢い人たちが、これらの作業をしていたからだ。
Philadelphiaの開発者は、Zope3の何百、何千というコードを眺めていた。
開発チームは、よいテストの書き方を学んでいた。(だが、よいドキュメントの書き方には気づいていなかった）
Digital CreationsのすばらしいエンジニアたちはZope3の糞な部分も設計した。
少しずつだが、美しい核を持つ複雑なシステムになっていった。それでも、Zope2とは違っていた。Web開発のその他のものとも、大きく違っていた。
1，2年が経過した。最初のノンベータリリースまでに4年ほどが経っていた。
Zope2はこのときまで、ポピュラーな状態だった、だが、多くの人々はその未来やZope3に不安を抱いていた。
Zope3が最初にリリースされたときには、Philadelphiaの開発者は非常に落胆していた。（彼のDigital Creationsでの仕事は、Zope2を使ったコンサルティングだった）
難しすぎる。全体像がつかめない。貧弱なドキュメント。多くの人たちがいらだちを感じた。
さらに、Zopeを置き換えるようなものも増えていたし、人々はもっと単純に早く適切な代替手段を探し始めていた。
この間に、Digital CreationsはZope Corporationと名前を変えた。そして、少しずつベンチャーキャピタルにフォーカスしたビジネスモデルを欲しがるようになった。コンサルティング料よりも製品で稼ぐことを試みるようになった。
結局、会社はエンジニアリングへの投資を減らしていった（そして営業に注力していくようになっていった）
そして、Zope3の基盤が崩れてしまった。Zope2が使われているプロジェクトがある状態で、新しいZopeを作るための資金が出なくなったからだ。
Zope２とZope３の両方のプロジェクトを開始した主要な支援者は、売れる製品を作ることに注意をはらわないといけなくなった。
サードパーティからZope3へのオープンソースによる支援は重要だったが、Zope Corpolationの後ろ盾はなかった。そしてそれらの影響もあまり見られなかった。
Zope3は決して大きな注目を浴びることはなかった。
コンポーネントアーキテクチャのようないくつかのテクノロジーは、Zope2へと逆移植された。だが、この方法は、ただでさえ複雑だったZope2をさらに複雑にした。
BluebreamやGrokのようなプロジェクトでは、Zope3をベースとしたハイレベルなフレームワークだ。だが、これらもそれほど注目されなかった。
5年におよぶブランド汚しによって、人々はZopeが何なのかわからなくなってしまった。
Zopeとは何か？Zope2か？Zope３のことか？Zope Corporationka？PyPIにあるパッケージのことなのか？パッケージの集まりか？
それぞれすべて真実である。
ブランドネームというのは結局、大きな意味を持たなくなる。すべてを表すと同時になにも表していない。
恐ろしいことに、Djangoなどよくドキュメントがありよく設計されたシステムが登場するようになり、ブランドは急速に蔑みの対象と変わってしまった。