あき
attin****@kk*****
2005年 8月 26日 (金) 22:20:36 JST
あきです。 返信が遅くなりました。 > 竹添です。 > > あき wrote: > >>上記のように私としては本体には手を入れず、拡張パックという形での配布 > >>を希望します。個人的にもblog-kitなんてのは前から作りたいなーと思って > >>ましたし、CMS向けパックについても実装して欲しい機能があったりします。 > >>この場合、拡張パックの形式も規格を決めておいて、同じ手順でインストール > >>できるようにしておくといいですね。 > > > > > > 了解致しました。 > > 他の方の意見に、「ディストリビューションが良い」という意見もありますが、 > > まずは『拡張パック』という方向で検討してみます。 > > 前言を翻しますが、要はコア（や標準添付のプラグイン）に手を入れること > を問題にしているだけなので、コアに手を入れてなければ、配布形態として > コアと拡張部分をセットにして、すぐ動作可能な形態で配布するのはありだと > 思います。 了解致しました。 拡張パックで計画中です。 ただ、計画していて感じることですが、やはり拡張だけでは全ての要求を満たす ことはできません。 CMS用ということで見栄え優先の機能を求めると、推奨タグ・推奨の作法だけで は実現できない機能はたくさんあります。 （tableタグを使ったレイアウトの整形や文字の拡大・色付き修飾など・・・） 理想と現実は違いますね。 （見栄えに拘るなら、いっそHTMLタグとかじゃなくてJavaとかの道を選ぶべきな のかな？とも思えてきました。そこまでやる気はないですが・・・） > ただ、すでに導入済のFSWikiにCMS向け拡張をインストールしたいという話も > あると思うので、拡張部分のみを拡張パックとして別途配布する形もあると > いいなと思います。 この案には賛成ですが、競合するプラグインを使用されていた場合は該当箇所を 適宜修正してもらう必要は出てきますね。 やはり、どのプラグインを組み合わせるべきか一人で決めるべきでない気がしま す。 公の場で議論をした方が良いかもしれません。 試行錯誤や意見を聞きながら進めていきたいですし・・・。方法を考えます。 > > >>ただ、その「ディストリビューション」ははユーザと開発側の間に立つ営業／広 > >>報／サポートのような物だと思っています。 > >> > >>ディストリビュータはコードを書いて機能を追加していくより、なるべく既存の > >>部分を利用して、それを組み合わせてユーザに応用例を示す事に集中した方が良 > >>いと思います。ない部分はある程度作っていく必要がありますが、コードを書く > >>という事はそのサポートを行なわなければならないという事でもあり、全体的な > >>パッケージングを良くするための作業時間が少なくなります。 > > > > > > そのとおりです。 > > 本家との枝分かれではなく、「本家とは組合せを変えて応用例を示す」です。 > > 「無い部分の作成」についてですが、私は原則、それは「無い」ことを想定して > > いました。 > > しかし、佐久間殿が仰るような「本家そのものの弱点を補強する」という視点か > > らディストリビューションの在るべき姿を考えた場合、有った方が良いのかもし > > れません。 > > ですが、それも竹添殿的には、「本家側で対応すべき」なのだと思います。 > > ない部分といっても、プラグインで対応できる部分であればガンガンやって > いただいて問題ないです。 なるほど、切り分けが明確になりました。 > > プラグインで対応できない点については、コア側でそういった口を用意して > やることになるかと思います。ここをディストリ側の独断でやるのであれば > フォークするのと同じだと思いますが、あきさんから要望を出していただいて > それをコアに取り込めばいいんじゃないでしょうか。 > > 「本家側で対応すべき」ではなく「本家側で対応できるのにディストリ側で > 対応することはない」ということです。FSWikiプロジェクト内でやるので > あれば、そのメリットは活用すべきです。 了解致しました。 > > > 以下、余談で、私が感じていることと、今後の提案です。 > > プラグインを始め、いろいろなパッチの案が投稿されたりしていますが、現状、 > > パッケージ内に取り込まれる確率って、かなり低いように思われます。 > > おそらく、竹添殿の判断で、安全性が高く、かつ必要性が高いと思われる機能だ > > けを厳選して取り込んでいくと現状のような感じになるのでしょうが、意外と有 > > 用なものなのに見過ごされているものって私の目から見ていて多いと思います。 > > 基本的には機能追加よりもバグ修正が優先ですね。あと、必要性が感じら > れても性能面で問題がありそうなものについては取り込みを見送っている > ものもあります。 なるほど、確かにバグ修正関連は取り込まれています。 性能面とは、察するに速度の問題ですね。 ＃私は決して遅くはないと思うのですが・・・。 ＃（mod_perlではなく）CGIで、DBMSも使ってませんからね。それを考えれば ＃十分高速だと思うのですが・・・。 > > 最近はFSWiki本体がかなり肥大化していますので、メンテナンスコストも > 考えると、よほどのものでなければ新規プラグインや、新機能を追加する > ようなパッチは取り込まない（というか、取り込めない）という感じです。 バージョンアップというものは、機能が改善されたり増えたりするものですから、 肥大化していくのは至極当然のことだと思います。 メンテナンスコストが高くつく、というのは・・・・、そうですね。 「気持ちは有るが取り込めない」という状況は察しがつきます。 きちんとコアの事情や周りの機能を意識して設計されたパッチばかりであれば 組み込みも容易なのでしょうが、特定の目的のためだけに、周りの機能との関連 も意識せずに設計されたパッチも併存するような状況下では、「どれを組み込む べきか？」という選定すらもままならない気はしますね。 ・・・ということで考えてみました。 前回のメールにも書きましたが、 ----------------------------------------------------------------------- ・・・、現状の投稿システムは投稿者が主体で、オフィシャルサイト側 としては、何ら干渉もせず、保証もせず、の状態ですから・・・。 ----------------------------------------------------------------------- こういった部分は改善できるなら改善していくべきかもしれません。 「自分が便利だと思う物を作ったよ。同じように便利だと思う人は使ってね。そ の代わり自己責任だよ。」という人もいれば、「自分が便利だと思う機能を作り ました。同じように便利だと思ってくれる人がいれば使ってください。何か問題 点や要望が有れば改良しますので言ってください。」といった人もいるわけで、 これら両者を混同してしまう現状のシステムは、惜しいことをしていると思いま す。 前者のような有志者の力はとても有力ですし、プロジェクト運営者側としては、 こういった有志の力は大いに活用すべきだと思います。 そこで、私が考えた案ですが、 （実は前回書いておきながら、送信を見送った部分です） ---------------------------------------------------------------------- 『承認システム』の導入 現状では、本家の機能を無視したもの（例えば、Farm機能に未対応のもの）や、 対応バージョンが記載されていないもの、セキュリティ上の問題を抱えている もの、の区別が全くされないまま共存してしまっています。 作者（竹添殿）に認められたプラグインについては、ステータスが「リリース 済み」となり、互換性が保証されますが、そうでないプラグインでも、有用な プラグインは数多くあり、問題を抱えているプラグインと切り分けがされてい ません。 これでは、ユーザは混乱するばかりです。（現状がそうです） ですので、投稿されたプラグインを審査する機構を設け、それに合格したもの については「提案」以外のステータス、合格しなかったものについては「却下」 とするのです。（「保留」というのがあるので、そちらでも良いかもしれませ ん） 「却下」とする場合は、そう判断した理由をコメント欄に記載し、プラグイン 作者の自発的な修正を促します。このようにすれば、良質な（互換性のある） プラグインのみが生き残るでしょう。 ディストリビューションという展開になった場合も、特定のディストリビュー ションに限定したプラグインであれば、ステータスは「却下」としてしまえば 良いのです。 たとえ「却下」となっていても、使う側がその問題点を理解し、それでも可と 判断すれば使うでしょう。 問題は、誰が審査するのか、というのと、現状のbugtrackプラグインのままで は運用が厳しい、というところでしょうか。 他にも問題点はあるでしょうが、こういった方向で考えていくのはいかがでしょ う？ ---------------------------------------------------------------------- というのがあります。 実際には現行のものを置き換えるのは大変でしょうから、新たにそういった コーナーを新設する、という方法でも良いかと思います。 コア標準のプラグイン（及びコア拡張）として取り込んでもらうことを目的に 投稿を行うコーナーを新設するのです。（今までのように、「使いたい人は使っ て」ではなく、「こんなの良いと思います。採用して頂けませんか？」というコ ーナーです。明確な違いだと思います） もちろん本体への取り込みを意識しての投稿な訳ですから、いくつかの制約 （例えばGPLライセンス固定、メンテナンス義務等）を設けるのも有りだと思い ます。 オープンソースなので強制は難しいかもしれませんが、『本体に採用するための 条件』という名目であれば納得して頂けると思います。 現状のような「投稿者主体、干渉もせず、保証もせず」の状態では有志の力が 活かしきれないと思います。 誰しも、他人のソースは触りにくいですが、自分が作成したソースならメンテナ ンスも容易なはずです。 そもそもの投稿の動機はボランティアなわけですから、上記のようなシステムに すれば（『開発者の一員』という意識を持たせることができれば）、メンテナン スに前向きに協力してくれる有志者も増えてくると思うのです。 ＃同じプラグイン作成者として、自分が作成したプラグインが公式に認められる ＃というのはやはり嬉しいものです。その嬉しさのあまり、「もっと頑張ろうか ＃な？」って気になりますし、それは私だけじゃなく他の作成者も同じだと思い ＃ます。 有志者への動機付けに成功すれば、プロジェクト全体にも活気が出てきますし、 開発速度という意味においても、相乗効果が期待できるのではないかと思います。 > > > ということで、私は私でコア側に是非取り込んで頂きたい機能のピックアップを > > 進めますが、皆様も、過去に出た要望、投稿パッチ、投稿プラグインの中から、 > > 「これは有用なので是非本家にも取り込んで欲しい。取り込むべきでは？」とい > > うピックアップして挙げて頂けませんか？ > > そして、本当に取り込むべきか否か、皆で議論しませんか？ > > ひょっとすると、本当に竹添殿が見落としてしまっている有用な機能というもの > > も、出てくるかもしれません。 > > また、何らかしらの理由で（多くはセキュリティ上の都合だと思いますが）本家 > > への採用を見送っていたものも、有用とあらばその問題点を改善して取り込もう > > か、という方向に動いていくかもしれません。 > > いかがでしょうか？ > > これは是非お願いしたいですね。見落としてるものもあると思いますので。 > > ただ、例えば新規プラグインを取り込んだ場合、永久にメンテナンスコストが > 発生するわけです。これが現在積極的に標準プラグインを追加していない大きな > 理由です。プラグインのメンテナンスや、拡張パッケージとして有用なプラグ > インをまとめてパッケージしてくれる方がいらっしゃれば…と考え、募集して > みたものの、そこに手を挙げていただいた方はいませんでした。 一応、手を挙げたつもりだったのですが・・・。（笑） ですが「プラグインをメンテナンスする」と言っても、他人が作ったものですか らね。 単純なものなら良いですが、人それぞれに拘りや癖というものが有りますから。 他人に改良されることに違和感を覚える人もいるかもしれませんし、自分が作成 するプラグインとは違って、なかなか手を入れにくいのも事実です。 > > というわけで、プラグインやパッチを取り込む際には有用性、安全性、性能面 > などももちろん判断基準になりますが、現時点ではメンテナンスコストという > 点が大きな障害になっています。 > > > 余談ですが、ここで一つ確認をさせて下さい。 > > GPLライセンスって、他人が作ったソースを流用して（改良して）、同じGPLライ > > センスの元、公開して良いのですよね？ > > その場合の制約って何かありますか？ > > あまり他人の作ったプラグインに対し修正を入れ、バージョンアップしたものを > > 公開している例って見かけないもので「マズイのかな？」、と気になっているの > > ですが、どうなんでしょう？ > > 問題ないです。ただ、元の開発者に対するリスペクトは必要かと思います。 了解致しました。
Fork