引き算の難しさ
フレームワークを作っている人にはいつもあるひとつのジレンマがあるんじゃないでしょうか。
それは機能追加によるフレームワークの肥大化です。
これはフレームワークに限ったことではないですね．任天堂が10年以上もソフトメーカーとしてトップを君臨し続けている理由がここだったりします．引き算がすごいうまいのです．足し算で機能を追加することは安易に考えてしまいますが，そうすると続編では前提の知識が必要になり敷居があがる．事実上PS2で崩壊したゲームソフトってのはどれもそんな問題を抱えていたりした．
ドラゴンクエストだって１は一人旅ということで敷居はかなり低かった．２は魔法も使えない一人旅でスタート．慣れてきたところで魔法が使える仲間が加入し，さらに進むと範囲魔法を使う仲間が現れる．３では職業や魔法が大幅に増えて敷居が大幅に増えてしまい，コアなユーザーには非常に評価が高いものの，初心者にはとっつきが悪くなってしまった．４ではまた1章は魔法の使えない戦士の一人旅からスタート，2章では魔法を使える仲間をコントロールし，5章では大人数でのPTとユーザーの敷居を大幅に下げた（もっとも主人公以外勝手に動いたので戦闘の難易度は高かったが，システムを理解するという意味において）．
日本車は欧米の車に比べてコンパクトで高品質でした．再生専用のウォークマンも機能を削ることから生まれました．初代PSやGCは非常に引き算がうまかったハードウェアだと思います．昔から日本はコンパクトであることが好まれています．
つまり「わびさび」です．
覚えやすいからとかそんな理由は後付でどうにでもなる．わびさびを感じさせるフレームワーク．そんなのでいいじゃないか，日本人だし．
バージョンに関しては実装しなくてはならないもの，優先度等をつけながらリストアップしてどのバージョンでどの機能が入っているのか，どの機能が増えたのかなくなったのか，それがしっかりしていればいいと思います．ようは互換性がどの程度あるかがはっきりとわかるかどうか．
長期的なことを考えるのならば，仕様はドキュメントでしっかりと用意したほうがいいですね．パッチをすぐにあてていくのはいいのですが，どうしても今実装されている内容が仕様という感じになりがちです．仕様と実装を分離して考えたほうがいい．JavaEE仕様とかそんな感じで．したがって仕様外の使い方は実装依存である，と．そうすると他の技術者からのパッチなどフィードバックも集まりやすいのではないでしょうか？
