Architectureとにかく聞かれます今年一年、色々な人から...プログラマー仲間で軽いノリで聞かれることもあれば、出先の現場の技術者やマネージャーの方から相談されることも。程度の差はあれど、jfluteの立場的に聞かれることがとても多いです。今までもTwitterやブログでも似たようなことは話してきましたが、今後も多いと想像されるので..."jfluteの考え"今まで質問されてアドリブで回答してきたことを、ちょっと整理整頓してまとめておきたいなと。使い勝手が向上していかないすでに5,6年前から、大きな改善はあまり行われておりません。厳密には1年ごとにリリースはされていましたが、ちょっとした改善が主な内容です。2年近くリリースされていません。話ではなく、すでにもう数年前からその状態だったと言えるでしょう。そこ気にしてなかったのであれば、少なくとも9月27日を強く意識する必要はないでしょう。保存書庫は、もともとユーザー同士の情報交換の場です。コミッターも含まれていますが、コミッターもユーザーの一人という感覚です。9月27日からMLに投稿して完全に無視されるかどうか?実際にはわかりませんが、ユーザー同士でコメントができるものであれば返事はある可能性は高いだろうし、単にどのユーザーも答えられないものであれば、返事はないだろうし。別に9月27日が境目で返事が来る来ないがガラリと変わるわけではないでしょう。使っているユーザーが多いのであれば、MLだけでなく、情報交換できるチャンスはいくらでもあるかと思います。バグや脆弱性が出ても直らない9月27日以降だったら必ず直らないのか?これもわかりません。一方で...9月27日より前だったら必ず直っていたのか?そうとも思いません。ボランティア精神で成り立っているオープンソース活動ですから、それが迅速に、かつ、必ず直っていたという保証もありません。Seasar-2.4はすでに互換性を重視したフェーズに入っていたので、あまり問題にならないものであれば、回避情報だけ提供して本体には手を入れない、って判断もあり得るかと思います。(実際そういうのあったかもしれません)もし、致命的な脆弱性が発生したとして、仮に本体は直らなかったとしても、まだまだたくさんいるユーザーの方々から、Twitterやブログなので回避方法などの情報が回ってくる可能性も高いでしょう。脆弱性を直したプルリクを送る人もいるかもしれません。オープンソースですから、みんなで直せるのです。ソースが爆発して動かなくなるそんなことはありません笑。良し悪しありますが、Javaは互換性を重視している言語なので、ずっと昔に作られたフレームワークであっても、正常に動く可能性が非常に高いです。実際にうまく動いているなら、問題なく利用することができるでしょう。心配事があるならすでに遅いSeasarのサポートに対して心配なことがあるとすれば、すでに数年前からその心配はあったと言えるでしょう。別に9月27日から心配が始まるわけではありません。サポートが終了しています。BlogSeasarだけ心配しててもしょうがないでしょう。(ブログ執筆時点)それなりにバグ修正や改善などが施されています。MLに質問や相談などする場合、最新版でないと、コメントする方もやりづらいです。何か本体に重要なバグや脆弱性の修正あった場合、最新版でないと、迅速に適用するというのもやりづらいです。最新版を使ってないというのは、9月27日より前のサポートも享受していないと言えます。これからどこかにサポートを探してお願いするにしても、最新版でないとそのサポートを享受しづらい状況と言えます。多くの現場で最新版を使ってないのをよく見かけます。Seasarのサポートを心配するのであれば、まずは最新版に上げるところから始める必要があるでしょう。フレームワークサポート業務の難しさどこか第三者の企業にサポートをお願いするという話が、ときに浮上します。してくれるところがあればいいですし、そうやってフレームワークにちゃんとお金を払っていく、という姿勢はとても嬉しいことです。難しいだろうと思っています。サポート業務で儲かるためには?ひとつ、フレームワークのサポート業務、で儲かっているという話を聞いたことがありません。そもそもサポート業務は、いつどこでどういう質問や要望が来るかわかりません。普段から、ある程度の時間の余裕を確保しておかないといざってときの対応ができませんし、フレームワークのインプットの時間も必要です。(Seasarに詳しい人だとしても、いまやっている仕事では別のフレームワークを使っているって人も多いでしょうから)逆に、そうしないと、別の仕事が忙しくて対応できないとか、その場でフレームワークのインプットすることになって、対応に時間がかかってしまったりしてしまいます。フレームワークのサポート業務をやるような人は、おそらく優秀な人でしょう。給料も高いでしょうし、それ以外の仕事も、色々な現場から高い単価でのオファーが来ていることでしょう。その人に時間の余裕を与えることは会社の機会損失です。一社だけのサポートだと、すごく高い値段になってしまいます。一社のために、優秀なエンジニアの機会損失を発生させることになりますから、その分の値段を乗せないといけないから。週5日で別の仕事をやっていたとして、サポート業務を与えるとなると、いざってときの時間の確保とインプットのために、その別の仕事を週4日に減らさないといけないかもしれません。すると週1日の分の単価がサポート代金に反映されます。そもそも、優秀なエンジニアになるために費やしてきた時間や体力や精神力などは計り知れないものがあるでしょう。それをキープするために今も努力していることを考えると、優秀なエンジニアの週1日はそれなりに高いです。BUZZmagなので、通常サポート業務は、何社ものサポートを同時に受注して、専任にさせることで時間の余裕を確保し、うまくノウハウを再利用して効率性を高めて、うまく儲けられるようにすることが求められます。うまくSeasarのサポートで、何社ものサポートを受注できる体制にある会社はなかなか多くはないでしょう。(また、それをやりたいと思うところも少ないかも)サポートのスコープは?ふたつ、サポートのスコープを決めるのは難しいこと。どのライブラリが対象?(判明したバグや脆弱性を必ず直す保証をする?)そもそも9月27日より前だって、必ずバグや脆弱性が直っていた保証はありません。自分たちが作っていないフレームワークを、なかなか「必ず直す」という保証を低価格で受け持つのは、なかなか難しいでしょう。実際には、回避策を一緒に考える、というような業務支援が現実的なところかと思います。(バグや脆弱性かわからない現象の質問を受け付ける?)バグや脆弱性かわからない段階での、発生した現象の質問を受け付けるとなると、結局現場での使い方や現場の業務仕様などを知らないと、判断ができないことが多々あります。結局、リモートだとメールで何度も何度もやりとりをすることになり、あまりスピードは出ません。(どのライブラリが対象?)Seasarは様々なライブラリに依存しています。Seasar本体だけなのか?依存ライブラリも含めるのか?依存ライブラリも含めると非常に複雑になります。サポート料金は跳ね上がることでしょう。いって依存ライブラリを外したとしても、グレーゾーンが多いので実質調査するときとかは、意識しないといけません。そもそもSeasarだけでも複雑です。いうのを決めるだけでずいぶん時間もかかるでしょう。これもやはり何社ものサポートを受けることができれば、この辺のノウハウが再利用できて効率的になるでしょうが、一社だけスポットで、とかになるとなかなか厳しい値段になるかと思います。なるので、実際に思い描いているサポート料金よりも、高い値段になりやすいと考えます。それでも払う判断をするかどうか..."別のことに使った方がいいのでは?"という考えも浮かんでくるでしょう。オープンソースのモチベーションそもそも、「Seasar本家にサポートを続けて欲しい!」と思うのであれば...オープンソースですから、コミッターがサポートしてくれるかどうかは、コミッターのモチベーション次第です。ユーザーが多くのフィードバックをしたり、「Seasarを便利に使っている」ということをもっと露出することで、モチベーションは上がってきます。コミッターの得にはなりません。厳密には使っているだけでも嬉しいこともありますが、とはいえ、極端な話フリーライドに近い状態だと言えます。いう選択肢だってあるでしょう。jfluteはEclipseに寄付しました。jfluteの日記そういった動きが出てくることで...またコミッターのモチベーションが復活して、サポートを続けるってこともあるかもしれません。別の人が「コミッターになりたい!」と言って、サポートを続けるってこともあるかもしれません。コードが公開されているわけですから、「サポートしたい!」という人がいれば、それは全然アリなわけで。オープンソースですから、みんなで盛り立てていけば盛り上がるのですユーザーの行動次第です。なければ、単に何も起きないだけです。いう分析からのまとめというjfluteの分析から...ひとつ、そもそも今までのサポートを享受してないのであれば、9月27日から極端に何か変わるわけでもないので気にしない、何かあればSeasar-userメーリングリストに投げる要は、別に今までもあんまり気にしてなかったんであれば、これからもそんなに気にしなくてもいいんじゃない?って感じです。何か特別に聞きたいことや相談や要望があれば、ぜひ、Seasar-userメーリングリストに投げてみましょう。ユーザー同士で何か情報交換できるかもしれません。実際に、jfluteの身の回りの現場ではそんな感覚です。アップグレードしないと!そっちの方が優先課題です。Java6では動かないライブラリも出てきました。そのうち、Java7では動かないライブラリも出てくるでしょう。Javaのバージョンが古いままの方が実害が遥かに大きいです。...ふたつ、サポートを探すよりも、自分たちで直せるようにする、外部の力を借りるなら、それを支援してもらう方がいいなんといってもオープンソースですから、そもそも何か心配なことがあれば、自分で直せます。サポートに高いお金を払っても、それは自分たちのノウハウになりません。それよりも、社内の見込みのありそうなエンジニアに投資して、何かあっても自分たちで対応できるような体制作りにお金を使った方が建設的だろうと考えます。外部にお金を使うのであれば、外部の優秀なエンジニアに勉強会をお願いしたり、技術支援のサポートをお願いしたりする方が、ちゃんとノウハウが社内に残るのでその方が持続的なメリットになるかと思います。単なるサポートだと、単にお金が出ていくだけ、何もノウハウが社内に残らない可能性ありますし、サポートする会社がずっとサポートを続けるとは限りません。持続的な体制を作っていかないとジリ貧に陥る可能性があります。...みっつ、どうしても外部にサポートを求めるなら、ユーザー同士でまとまってサポートをお願いするスポットで一社だけ相手にサポートするという会社は、探してもなかなか見つからないでしょう。述べた通り、やりづらい理由がそれだけあるからです。サポートする会社がちゃんと儲かる仕組み、これを作り出せないとうまく回らないですし、仮にサポートしてもらったとしても長持ちしないでしょう。ちなみに、ユーザー同士でコミュニケーションを取って、互いにサポートし合うというのもアリですね。ういか、その場がまさしくSeasar-userメーリングリストと言えます。...よっつ、そもそも、Seasar本体のサポートを続けて欲しいならユーザーからどんどんSeasarへの貢献をフリーライドが必ずしも悪いわけではありません。フリーライドから貢献する人に変わることもありますし、フリーライドの方々によってシェアの土台ができて、それが活動のためのパワーになることもあります。ポイントは、フリーライドする人たちと貢献する人たちの割合の問題です。(サービスだと、無料会員と有料会員の割合に置き換えられるでしょう)無料でコミッターに明確な利益を与えずに使っているわけですから、何も行動しなければ、放っておけば、こうなるのは当然です。たくさんのユーザーが「Seasarに寄付」などの支援をしていたらもしかしたら、サポートは終わってなかったかもしれません。別のコミッターが引き継いだかもしれません。新しいコミッターが出てきたかもしれません。今からでもサポート復活を切に願うのであれば、そういった活動をユーザー主導でやっていく他ありません。そもそも、コミッターとユーザーに垣根はありません。思い切って社内のエンジニアをコミッターにするなど、様々な支援の形が想像できます。方法はいくらでもあります。作り、身近な現場ではそれで回っています。そちらを盛り立てていこうと考えています。現実リアルタイムで使っている現場もありますので、ちょっとずつLastaへの移行を促しながらも、何かあればコードを読んで調べることはあるでしょう。利用していることがほとんどなので、それの延長のような感覚です。今週末のSeasarカンファレンスに登壇してきます。Connpassそして、Seasarについて語ってきます。感謝の気持ちを込めて。いう話自体に、あまり意味がないと考えています。コミュニティや個人のオープンソースは、売ってる商品と違って、コミッターとユーザーのコラボレーションで成り立つものですから、極端な話、行動すればどうにだってできる可能性があるわけです。逆にコミッターだけでどうにかできるものでもなかったり。DBFluteでも時々聞かれますが、こんな感覚...サポートを終了する保証もできないんです仮にサポートを終了して、そして要望が来たとして...でもやっぱり時間があったらやっちゃうかもしれないし。嬉しい言葉も一緒だったら勢いで無理しても対応するかもしれないし(^^。しれーと「新しいバージョンをリリースしました!」とかってブログ書くこともあるかもしれません。逆に、いまサポートしてる状態と定義したとしても、要望やバグ修正を必ず対応できる保証だってないですし。体力と精神力、時間と生活資金の許せる範囲内で、ユーザーと共にjfluteがアドリブし続けてきた!ってだけで、サポートしてきたっていう感覚はないのです。サポートを終わりにするどころか始めてすらいない。「どういう意味合いでのサポート?」って踏み込まないと返事ができないのです。してくれる人を探すことを真っ先に提案するでしょう。その理由は、ここまでブログで綴った通りです。「将来、別のフレームワークを採用するから、SAStrutsに詳しくなっても役に立たないのでは?」そんなことはありません。フレームワークのコードを読んで理解することで、新しいフレームワークを理解するスキルも身についてると言えます。どこかの将来、また別のフレームワークで役に立ちます。そのノウハウを現場に積み重ねていくという方向性で進めていく方が、現場のためになると考えるのです。最近、こんなツイートをしました。再開したディズニーシーにはてなブログをはじめよう!jfluteさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。