jfluteが「Seasarサポート終了どうすればいい?」と聞かれたら...

とにかく聞かれます

今年一年、色々な人から...

プログラマー仲間で軽いノリで聞かれることもあれば、出先の現場の技術者やマネージャーの方から相談されることも。程度の差はあれど、jfluteの立場的に聞かれることがとても多いです。

今までもTwitterやブログでも似たようなことは話してきましたが、今後も多いと想像されるので...

"jfluteの考え"

今まで質問されてアドリブで回答してきたことを、ちょっと整理整頓してまとめておきたいなと。

何を心配していますか?

さて、Seasarサポート終了ということで、何を心配されていますでしょうか?

A. 使い勝手が向上していかない
B. MLで質問しても返事が帰ってこない
C. バグや脆弱性が出ても直らない
D. ソースが爆発して動かなくなる

A. 使い勝手が向上していかない

すでに5,6年前から、大きな改善はあまり行われておりません。

厳密には1年ごとにリリースはされていましたが、ちょっとした改善が主な内容です。(それはそれでありがたいものですが)

そして最終リリースは 2014-12-07 の 2.4.48, そう、2年近くリリースされていません。(ブログ執筆時点)

なので、"9月27日から使い勝手が向上しなくて困る!" って話ではなく、すでにもう数年前からその状態だったと言えるでしょう。

そこ気にしてなかったのであれば、少なくとも9月27日を強く意識する必要はないでしょう。

B. MLで質問しても返事が帰ってこない

Seasar-userメーリングリスト
 => Seasar-user 保存書庫

は、もともとユーザー同士の情報交換の場です。コミッターも含まれていますが、コミッターもユーザーの一人という感覚です。

9月27日からMLに投稿して完全に無視されるかどうか?実際にはわかりませんが、ユーザー同士でコメントができるものであれば返事はある可能性は高いだろうし、単にどのユーザーも答えられないものであれば、返事はないだろうし。別に9月27日が境目で返事が来る来ないがガラリと変わるわけではないでしょう。

まだまだ使っているユーザーが多いのであれば、MLだけでなく、情報交換できるチャンスはいくらでもあるかと思います。

C. バグや脆弱性が出ても直らない

9月27日以降だったら必ず直らないのか?
これもわかりません。

一方で...

9月27日より前だったら必ず直っていたのか?
そうとも思いません。

ボランティア精神で成り立っているオープンソース活動ですから、それが迅速に、かつ、必ず直っていたという保証もありません。

Seasar-2.4はすでに互換性を重視したフェーズに入っていたので、あまり問題にならないものであれば、回避情報だけ提供して本体には手を入れない、って判断もあり得るかと思います。(実際そういうのあったかもしれません)

もし、致命的な脆弱性が発生したとして、仮に本体は直らなかったとしても、まだまだたくさんいるユーザーの方々から、Twitterやブログなので回避方法などの情報が回ってくる可能性も高いでしょう。

また、脆弱性を直したプルリクを送る人もいるかもしれません。オープンソースですから、みんなで直せるのです。

D. ソースが爆発して動かなくなる

そんなことはありません笑。

良し悪しありますが、Javaは互換性を重視している言語なので、ずっと昔に作られたフレームワークであっても、正常に動く可能性が非常に高いです。

実際にうまく動いているなら、問題なく利用することができるでしょう。

心配事があるならすでに遅い

Seasarのサポートに対して心配なことがあるとすれば、すでに数年前からその心配はあったと言えるでしょう。

別に9月27日から心配が始まるわけではありません。9月27日から心配するのは "すでに遅い" と考えます。

...

ちなみに、Seasarを使っている現場で多く利用されているだろうと思われる Log4j のバージョン 1.x ですが、すでにサポートが終了しています。
 => Log4jバージョン1のサポートが終了 | InfoQ

そもそも、多くの人が利用されてると思われる、Java6 や Java7 ですが、こんな感じです。
 => Java 7とJava 6の今後について | Oracle Blog

Seasarだけ心配しててもしょうがないでしょう。

最新版使っていますか?

また、Seasarの最新版を使っていますでしょうか?最新版は、2014-12-07 にリリースされた 2.4.48 です。(ブログ執筆時点)

それなりにバグ修正や改善などが施されています。

MLに質問や相談などする場合、最新版でないと、コメントする方もやりづらいです。

何か本体に重要なバグや脆弱性の修正あった場合、最新版でないと、迅速に適用するというのもやりづらいです。

最新版を使ってないというのは、9月27日より前のサポートも享受していないと言えます。これからどこかにサポートを探してお願いするにしても、最新版でないとそのサポートを享受しづらい状況と言えます。でも、多くの現場で最新版を使ってないのをよく見かけます。

Seasarのサポートを心配するのであれば、まずは最新版に上げるところから始める必要があるでしょう。

フレームワークサポート業務の難しさ

どこか第三者の企業にサポートをお願いするという話が、ときに浮上します。

もちろん、してくれるところがあればいいですし、そうやってフレームワークにちゃんとお金を払っていく、という姿勢はとても嬉しいことです。

でも、なかなか難しいだろうと思っています。

サポート業務で儲かるためには?

ひとつ、フレームワークのサポート業務、で儲かっているという話を聞いたことがありません。

そもそもサポート業務は、いつどこでどういう質問や要望が来るかわかりません。普段から、ある程度の時間の余裕を確保しておかないといざってときの対応ができませんし、フレームワークのインプットの時間も必要です。(Seasarに詳しい人だとしても、いまやっている仕事では別のフレームワークを使っているって人も多いでしょうから)

逆に、そうしないと、別の仕事が忙しくて対応できないとか、その場でフレームワークのインプットすることになって、対応に時間がかかってしまったりしてしまいます。

フレームワークのサポート業務をやるような人は、おそらく優秀な人でしょう。給料も高いでしょうし、それ以外の仕事も、色々な現場から高い単価でのオファーが来ていることでしょう。その人に時間の余裕を与えることは会社の機会損失です。

なので、もし一社だけのサポートだと、すごく高い値段になってしまいます。一社のために、優秀なエンジニアの機会損失を発生させることになりますから、その分の値段を乗せないといけないから。

例えば、週5日で別の仕事をやっていたとして、サポート業務を与えるとなると、いざってときの時間の確保とインプットのために、その別の仕事を週4日に減らさないといけないかもしれません。すると週1日の分の単価がサポート代金に反映されます。

そもそも、優秀なエンジニアになるために費やしてきた時間や体力や精神力などは計り知れないものがあるでしょう。それをキープするために今も努力していることを考えると、優秀なエンジニアの週1日はそれなりに高いです。
 => イラスト料を値切る顧客に「ご自分でどうぞ」 | BUZZmag

なので、通常サポート業務は、何社ものサポートを同時に受注して、専任にさせることで時間の余裕を確保し、うまくノウハウを再利用して効率性を高めて、うまく儲けられるようにすることが求められます。

ですが、うまくSeasarのサポートで、何社ものサポートを受注できる体制にある会社はなかなか多くはないでしょう。(また、それをやりたいと思うところも少ないかも)

サポートのスコープは?

ふたつ、サポートのスコープを決めるのは難しいこと。

o 判明したバグや脆弱性を必ず直す保証をする?
o バグや脆弱性かわからない現象の質問を受け付ける?
o どのライブラリが対象?

(判明したバグや脆弱性を必ず直す保証をする?)
そもそも9月27日より前だって、必ずバグや脆弱性が直っていた保証はありません。自分たちが作っていないフレームワークを、なかなか「必ず直す」という保証を低価格で受け持つのは、なかなか難しいでしょう。実際には、回避策を一緒に考える、というような業務支援が現実的なところかと思います。

(バグや脆弱性かわからない現象の質問を受け付ける?)
バグや脆弱性かわからない段階での、発生した現象の質問を受け付けるとなると、結局現場での使い方や現場の業務仕様などを知らないと、判断ができないことが多々あります。結局、リモートだとメールで何度も何度もやりとりをすることになり、あまりスピードは出ません。

(どのライブラリが対象?)
Seasarは様々なライブラリに依存しています。Seasar本体だけなのか?依存ライブラリも含めるのか?依存ライブラリも含めると非常に複雑になります。サポート料金は跳ね上がることでしょう。かといって依存ライブラリを外したとしても、グレーゾーンが多いので実質調査するときとかは、意識しないといけません。

そもそもSeasarだけでも複雑です。なのでいっそ、脆弱性が発生した時に致命的になりやすいWeb周りのフレームワークだけということで、"SAStrutsだけサポート" ならまだ現実的ではないかと。

などなど、こういうのを決めるだけでずいぶん時間もかかるでしょう。これもやはり何社ものサポートを受けることができれば、この辺のノウハウが再利用できて効率的になるでしょうが、一社だけスポットで、とかになるとなかなか厳しい値段になるかと思います。

希少性の金額を出せる?

といったもろもろから、"希少的な案件" になるので、実際に思い描いているサポート料金よりも、高い値段になりやすいと考えます。

それでも払う判断をするかどうか..."別のことに使った方がいいのでは?"という考えも浮かんでくるでしょう。

オープンソースのモチベーション

そもそも、「Seasar本家にサポートを続けて欲しい!」と思うのであれば...

オープンソースですから、コミッターがサポートしてくれるかどうかは、コミッターのモチベーション次第です。

ユーザーが多くのフィードバックをしたり、「Seasarを便利に使っている」ということをもっと露出することで、モチベーションは上がってきます。

通常、コミッターとユーザーに金銭関係はありませんから、"ただ密かに使っているだけ" では、あまりコミッターの得にはなりません。厳密には使っているだけでも嬉しいこともありますが、とはいえ、極端な話フリーライドに近い状態だと言えます。

Seasarは募集していないかもしれませんが、"寄付する" という選択肢だってあるでしょう。例えば、jfluteはEclipseに寄付しました。
 => Eclipseに寄付しました | jfluteの日記

そういった動きが出てくることで...

またコミッターのモチベーションが復活して、サポートを続けるってこともあるかもしれません。別の人が「コミッターになりたい!」と言って、サポートを続けるってこともあるかもしれません。

サポートが終わったからといって、"必ずサポートを終わりにしないといけない!" わけでもありません。コードが公開されているわけですから、「サポートしたい!」という人がいれば、それは全然アリなわけで。

オープンソースですから、

みんなで盛り立てていけば盛り上がるのです

ユーザーの行動次第です。
でなければ、単に何も起きないだけです。

という分析からのまとめ

というjfluteの分析から...

ひとつ、

そもそも今までのサポートを享受してないのであれば、9月27日から極端に何か変わるわけでもないので気にしない、何かあればSeasar-userメーリングリストに投げる

要は、別に今までもあんまり気にしてなかったんであれば、これからもそんなに気にしなくてもいいんじゃない?
って感じです。

何か特別に聞きたいことや相談や要望があれば、ぜひ、Seasar-userメーリングリストに投げてみましょう。ユーザー同士で何か情報交換できるかもしれません。

実際に、jfluteの身の回りの現場ではそんな感覚です。それよりも、早く Java8 にアップグレードしないと!そっちの方が優先課題です。Java6では動かないライブラリも出てきました。そのうち、Java7では動かないライブラリも出てくるでしょう。Javaのバージョンが古いままの方が実害が遥かに大きいです。

...

ふたつ、

サポートを探すよりも、自分たちで直せるようにする、外部の力を借りるなら、それを支援してもらう方がいい

なんといってもオープンソースですから、そもそも何か心配なことがあれば、自分で直せます。

サポートに高いお金を払っても、それは自分たちのノウハウになりません。それよりも、社内の見込みのありそうなエンジニアに投資して、何かあっても自分たちで対応できるような体制作りに
お金を使った方が建設的だろうと考えます。どうせ外部にお金を使うのであれば、外部の優秀なエンジニアに勉強会をお願いしたり、技術支援のサポートをお願いしたりする方が、ちゃんとノウハウが社内に残るのでその方が持続的なメリットになるかと思います。

単なるサポートだと、単にお金が出ていくだけ、何もノウハウが社内に残らない可能性ありますし、サポートする会社がずっとサポートを続けるとは限りません。持続的な体制を作っていかないとジリ貧に陥る可能性があります。

...

みっつ、

どうしても外部にサポートを求めるなら、ユーザー同士でまとまってサポートをお願いする

スポットで一社だけ相手にサポートするという会社は、探してもなかなか見つからないでしょう。すでに述べた通り、やりづらい理由がそれだけあるからです。

サポートする会社がちゃんと儲かる仕組み、これを作り出せないとうまく回らないですし、仮にサポートしてもらったとしても長持ちしないでしょう。

ちなみに、ユーザー同士でコミュニケーションを取って、互いにサポートし合うというのもアリですね。とういか、その場がまさしくSeasar-userメーリングリストと言えます。

...

よっつ、

そもそも、Seasar本体のサポートを続けて欲しいならユーザーからどんどんSeasarへの貢献を

フリーライドが必ずしも悪いわけではありません。フリーライドから貢献する人に変わることもありますし、フリーライドの方々によってシェアの土台ができて、それが活動のためのパワーになることもあります。

ポイントは、フリーライドする人たちと貢献する人たちの割合の問題です。(サービスだと、無料会員と有料会員の割合に置き換えられるでしょう)

無料でコミッターに明確な利益を与えずに使っているわけですから、何も行動しなければ、放っておけば、こうなるのは当然です。

まあサポートが終わった原因は、そういうこととは無関係かもしれませんが...(そこはSeasarコミッターの方のブログを参照)

もし仮に、

o たくさんのユーザーが「Seasar便利だ」と露出していたら
o たくさんのユーザーが「Seasarに寄付」などの支援をしていたら

もしかしたら、サポートは終わってなかったかもしれません。別のコミッターが引き継いだかもしれません。新しいコミッターが出てきたかもしれません。

もし、今からでもサポート復活を切に願うのであれば、そういった活動をユーザー主導でやっていく他ありません。そもそも、コミッターとユーザーに垣根はありません。

思い切って社内のエンジニアをコミッターにするなど、様々な支援の形が想像できます。方法はいくらでもあります。

jfluteの思い

jflute個人的には、すでに、Seasar をフォークした Lasta Di, そして、SAStruts をフォークした LastaFlute を作り、身近な現場ではそれで回っています。どんどんそちらを盛り立てていこうと考えています。

なので、Seasar本体のソースコードに対して、何をアプローチをすることはあまり想像できませんが、 現実リアルタイムで使っている現場もありますので、ちょっとずつLastaへの移行を促しながらも、何かあればコードを読んで調べることはあるでしょう。まあ、SAFlute や DBFlute を利用していることがほとんどなので、それの延長のような感覚です。

今週末のSeasarカンファレンスに登壇してきます。
 => Seasar Conference 2016 Final | Connpass

そして、Seasarについて語ってきます。
感謝の気持ちを込めて。
 => えむさひこくぼ | SeasarConf

...

そもそも、企業が提供しているわけではないオープンソースにおいて、"サポートが続く続かない" という話自体に、あまり意味がないと考えています。コミュニティや個人のオープンソースは、売ってる商品と違って、

コミッターとユーザーのコラボレーション

で成り立つものですから、極端な話、行動すればどうにだってできる可能性があるわけです。逆にコミッターだけでどうにかできるものでもなかったり。

DBFluteでも時々聞かれますが、こんな感覚...

サポートを終了する保証もできないんです

仮にサポートを終了して、そして要望が来たとして...でもやっぱり時間があったらやっちゃうかもしれないし。嬉しい言葉も一緒だったら勢いで無理しても対応するかもしれないし(^^。しれーと「新しいバージョンをリリースしました!」とかってブログ書くこともあるかもしれません。

逆に、いまサポートしてる状態と定義したとしても、要望やバグ修正を必ず対応できる保証だってないですし。それをサポートと言えるのかどうか?

単に、今まで十年間、

体力と精神力、時間と生活資金の許せる範囲内で、ユーザーと共にjfluteがアドリブし続けてきた!

ってだけで、サポートしてきたっていう感覚はないのです。サポートを終わりにするどころか始めてすらいない。(むかしはこんな深く考えてなかったので、サポートという言葉を曖昧にしたまま、するしないって話をしたこともあったかもですが、いま考えるとこんなニュアンスですね)

だから、
DBFluteのサポートは続けるんですか?」
って聞かれたとしても...

「どうして欲しいですか?」
って聞き返して相談してから考えることだし、

「どういう意味合いでのサポート?」
って踏み込まないと返事ができないのです。

...

何かもっとSeasarに対して強いサポートを求む、って相談されたら、どちらかというと、ソースコードリーディングなどの勉強会など、"現場がSAStrutsに詳しくなっていくための支援" をしてくれる人を探すことを真っ先に提案するでしょう。その理由は、ここまでブログで綴った通りです。

「将来、別のフレームワークを採用するから、SAStrutsに詳しくなっても役に立たないのでは?」

そんなことはありません。フレームワークのコードを読んで理解することで、新しいフレームワークを理解するスキルも身についてると言えます。どこかの将来、また別のフレームワークで役に立ちます。

なので、どうせなら、

そのノウハウを現場に積み重ねていく

という方向性で進めていく方が、現場のためになると考えるのです。