PostgreSQL Elephantが
さらに別のリリースに向けて前進している間、私はソフトウェアのユーザーが果たすべき役割についてかなり
考えてきました。そのユーザーインターフェース
デザイン。今日、私はデータベースパラメータを
人々が心配しなければならなかったものにする何かを提案しました、そしてそれはどのように設定するか全く明白ではなく、そしてその値を大部分自動にします。これはかなり
明確な前向きな変化です。ユーザーはイライラし、適切なデフォルトの動作が確立され、そのデフォルトの動作がパッチとして提案されました。それが適用された場合、私はそれを悪い決定だと考える人を見つけることにショックを受けるでしょう。
決定。
データベースのチェックポイントを中心にユーザーインターフェースを作り直す方法についても同様の議論がありました。
現在、
現在、チェックポイントによってデータがディスクに書き込まれる速度は、ユーザーが指定できる3つの値によって
影響を受けます。これらの間の相互作用は
複雑さを反映する方法ではありますが、十分に文書化されており、一部のユーザーはそれが提供する動作が
うまく機能していると感じています。一般的なユーザーにとって物事を
より良くするために、現在のコードに比べてパフォーマンスが低下する場合がある
可能性は十分にあります。
パラメータの有効なスケールを変更する
異なる実装を使用すると、微妙なタイミングの変更が発生し、
必ずしもすべてがポジティブになるわけではありません。この状況で、開発コミュニティとして私たちができる最善のことは、
その呼び出しを行うのに十分なベンチマークデータを収集することです。
最悪のシナリオを改善することは、以前の実装に比べて
物事をわずかにデチューンする可能性があります。
最終結果の調整が簡単であることが判明した場合、
ここで提案したように、複数の
複雑な設定を単一の設定に置き換えると、平均してより良い方向になります。
より良いアプローチを取得するために、
古いアプローチを手放す必要がある場合があります。
しかし、これは、ユーザーが依存する行動を破ることについて私たちが懸念していることです。
下位互換性に大きな焦点が当てられており、PostgreSQL開発の古いアプローチを削除しない方法で
追加するだけです。ただし、
選択の余地がない場合もあります。つまり、新しいアプローチに向けて前進する必要があります。
古い行動と新しい行動の両方が完全に合法である場合、
明確な多数意見でさえ到達することは困難です。これは、ユーザーインターフェースデザインの
ケースであることがよくあります。
適切なツールと専門家でベンチマークを行うことはできますが、
オープンソースコミュニティで行われることはめったにありません。
非常に個人的な意見の組み合わせからコミュニティのコンセンサスを得るのは困難です。
今日、いくつかの更新を取得することで、開発者としてユーザーのフィードバックを処理しない方法を改めて思い出しました。
gnome-私の名目上の
優先コマンドライン端末であるターミナルは、キーボード入力を処理します。この問題は、ほぼ正確に2年前に、
Ubuntuトラッカーで最初にバグレポートになりましたが、
リグレッションの根本的な原因、つまりGNOMEの1つによる意図的な変更にのみ移行しました。
開発者は、不適切と判断した動作を排除します。修正を要求するチケットが開かれましたが、関係者全員を侮辱する以上のことはありませんでした。
私は後者のチケットの歴史で十分に活動しているので、ここで議論を繰り返す必要はありません。
基本的に、私が望んでいたのは
以前の動作に戻すことを可能にするチェックボックス構成オプション。私はそれを実行するために
作業を開始し、回避策を提案するためにコードを掘り下げました。
これがマージされる方法はないことに気づいただけで、私の
提案は、
すべての人を喜ばせる共通の基盤を見つけようとすることに焦点を当てていました。ただし、開発者がそれを気にしないことは明らかです。
彼らは好きなようにやっていて、
他の人は関係ありません。これが重要であると見なされるには、「
数百」の苦情が必要だと言われましたが、
ターミナルでのコントロールキーの使用は、
最も人気のあるものではないことを考えると、頭がおかしくなります。 。数十件の報告があり、
受け取ったすべての苦情は、優先される解決策にまとめられました。
同意しなかったのは、開発者の1人だけでした。
PostgreSQLコミュニティは、ユーザーが望むものを提供するだけでなく、技術的に純粋なソリューションを好む開発者で溢れているという苦情が寄せられています。
br />これは、
表示テーブルの追加に対する継続的な抵抗など、ある程度は当てはまります。 データベース内の
データベースを見つける別の方法として。しかし、その議論はすべて、議論が非常に複雑な意見を与える
トピックに関するものでした。多くの人が
双方に強い意見を持っています。このgnome-terminalの問題の場合のように、すべてのユーザーが
設計に同意する場合、
これらの意見をまだ正しくないとして拒否することは、開発者の傲慢さの高さです。
この種の興味深い例の1つは、PidginIMソフトウェアの開発者が
チャットウィンドウのテキストサイズ設定の動作を変更することです。プログラム。
ユーザーは反抗した。 CodingHorrorでの
分析による新旧の動作の良い例があります。
開発者がフィードバックを無視しているように見える方法で、誰もが気になりました。
彼らの認識は、
ユーザーの考えに関係なく、
彼らは自分たちのデザインが古いものよりも優れていると感じたため、
コミュニティのフィードバックは開発者とは無関係であるというものでした。誰かが古い動作を復元するためのプラグインを作成しました。
そして、公式の分割がありました。結果として得られたフォークの
ステートメント
は、元々は「Fun Pidgin」と呼ばれ、現在は「Carrier Instant Messenger」と呼ばれていますが、
ユーザー中心であると感じる方法について興味深い読み物です。開発は機能するはずです。
これに関するJeff AtwoodのCodingHorrorディスカッション
は、このようなフォークが判明する可能性のある4つの方法を示唆しています。彼は
非常に重要なものを除外しました。
コミュニティの取り組みを分割することで、両方のフォークが死に、どちらも代替案と競争するのに十分なリソースがない
可能性があります。ピジンはまだ
死んでいませんが、「カーテンを駆け下りて
出血の合唱団に加わった」ことからは少し離れていますが、
以前ほど重要ではなく、この全体の大失敗は彼らの大義を助けませんでした。
Ubuntu 9.10の時点で、CanonicalはPidginをプライマリIMクライアントとして
非常に人気のあるLinuxディストリビューションに置き換えました。代わりに、彼らはその代わりに
GNOME共感を置きました。
Pidginコミュニティが崩壊せず、そのような悪いPRに関連付けられていなかったら、それはまだ起こっていただろうか？おそらく、しかしそれは確かに彼らのケースを助けませんでした。
同じ種類のユーザーを知らない
gnome-terminalのような人気のあるGNOMEプロジェクトに関して
決定が下されていることはおもしろいです（私はむしろ笑います）泣くよりも）
同様の状況に向かっています。 2か月前、Ubuntuが
次のリリースで完全なGNOMEソフトウェアスタックの使用から大幅に離れることが発表されました。そこで起こったことに注意してください。
マークシャトルワースは、プロのUIデザイナーを雇い、
彼らを配置して、デスクトップユーザーの経験に
より効果的であると考え、その結果をGNOMEコミュニティ。
この非常に価値のある作業を受け入れてCanonicalに感謝するのではなく、
その調査を行ってくれたのではなく、
中立的な立場があり得ないほどの基本的なアイデアを拒否しました。 Ubuntuは現在、「ユーザーが望むことを実行する」ために残された唯一の道として、Unityプロジェクトに向けて大きな道を進んでいます。私がこの1つの煩わしさに遭遇してから何年にもわたって、GNOME開発者との私自身のやりとりに基づいて、
マークが得た反応は私を少し驚かせません。
このUnityの分割がどのように行われるかがまだはっきりしていない
段階にあります。私が期待しているのは、
このすべてが一種の二重の失敗につながることです
。
それ自体では、最初は有用なものを何も生み出さない、重複した開発がたくさんあります。最初のリリースは
ひどい品質管理になります-このようなものが正しくなるには
永遠にかかります。そして、開発者ベースを分割することで、
どちらのグループにも、良い仕事を終わらせるのに十分な人数が残っていない可能性があります。
私たち全員に、複数の貧弱なLinuxデスクトップオプションが残っています（再び）統一されたものではなく、誰もが
改善するために並んでいます。ノキアが
Qtのライセンスを改善してきた方法で、Qt+GNOMEの両方を持つことを
排除する方法を最終的に検討できるようになることを期待していました。その代わりに、Linuxはまだ開発プロジェクトを
ミックスの上に置いており、それをすべてのもののUnityと名付けることは、
ひどい冗談です。
しかし、私はデータベースについて話していました…PostgreSQLの興味深い点の1つは、生成されたフォークの数です。
寛大なBSDライセンスは、複数の
クローズドソースの商用フォークにつながりました。私はかつて
1つを作った会社で働いていました。 Netezzaは、これらの最初のものであり、最終的に本格的な商業生産に発展しました。
また、Greenplumデータベースは最近EMCによって購入されました。
これは非常に成功した製品です。
起こっていないのは、オープンソースフォークのいずれかがメインディストリビューションの実行可能な代替品になっていることです。
大手企業がエンジニアリングに役立てることができるような大規模なリソースがない限り、
コミュニティにアイデアを受け入れてもらう方が、
試して独立した実装を行うよりも簡単です。そのうちの。ストレートコミュニティ
PostgreSQLは正しい選択であり続けます。
PostgreSQLコミュニティは多くのことを主張しており、
人々が求める多くのことに敵対しています。
やりたくないリストもあります。
これらは、ほとんどの場合、技術的には
、要求している人には必ずしも明らかではない欠点なしに構築することは不可能です。ユーザーが、変更によってデータベース内の何かへのより良いユーザーインターフェースが得られる理由を主張し、
それが問題を引き起こす理由について、技術的な異議はありません。
その変更が考慮されます。私がコミュニティで見たことがないのは、
満場一致で明確なユーザーの好みに対抗する開発者の誰もが
、そのオプションを
欠点なしで利用できるようにすることができるということです。そのようにそれが好きではありません。あなたが
傲慢がひどく謙虚さを打ち負かしたところにさまよっているオープンソースプロジェクトの開発者であるなら、あなたのユーザーが
フォークするのに十分な怒りを持っていても驚かないでください。そして最近のある日、
人々が本当に望んでいることに注意を払うフォークや再実装があなたに取って代わられることに気付くかもしれません。