ERP, CRM and KM Notes

Adempiereのコミュニティの本家はこちらとAdempiere Bazaarのウェブはこちら。

ユーザーコミュニティの分裂問題に発展するきっかけとなった白熱議論の火付け役でもあるマレーシア人ユーザー氏（red1氏）は、このプロジェクトの中心人物の一人でもある。

コントリビューターに対する無視の度合いが過ぎるようになり、膨大なユーザーコミュニティよりもベンチャーキャピタルやパートナー（高額なパートナー契約料を支払っている人）を優先しているとユーザーが感じ始めて、彼らとComPiere社との間で折り合いがつかなかった期間を経て、ついに彼らが動き出した、という経緯がある。

ここで私なりの総括をば。
ComPiere社（この大文字Pは会社名を指す）が限られた社内リソースを使って開発できる部分にはもちろん限りがある。開発の優先度をオープンなユーザーコミュニティよりも、高額な契約料を支払うパートナー優先というのは当然のことである。

そしてJ.Janke氏の思想としては、全世界の商慣習を取り込むことは不可能であるので、できるだけ汎用度の高いものを基本機能として取り込み、製品デザインとしては、機能拡張をしやすくする。その上で、諸国のパートナー達、またはユーザー自身が、その国特有、又は業界特有の商慣習を付け加えていく。そしてその拡張機能も、出来れば彼の思想を受け継ぎ、他者向けに拡張しやすい設計で公開していってもらえればいいと、そういうことだと思う。

しかし。

J.Janke氏の大きな失敗というのは、やはりコントリビューターの努力の全てを「mess」の一言で片付け、その自称コントリビューターのために自分の貴重な時間を奪われたと言い切ったことであろう。優秀なプログラマーであれば、システムデザインやコーディング、データ定義の細部に至るまで、自分なりの美意識を貫いて完成度の高いものを作りたいという欲求があるはず。自分の名前を冠するのであれば尚更、そのチェックは厳しくなる。彼は年齢的にも私よりも上で、メモリ節約のためにビット操作の技術を競うような時代も経験しているはずで、そういう人から見ると、汚いコーディングは許しがたいだろう。

経験者語る、であるが。
以前メインフレームのSEだった頃、元号対応（昭和から平成）で、仕様書のないCOBOLのプログラムの元号使用部分だけを抜き出し修正をかけるという体力勝負の仕事をやったことがあったが、正直言ってヒトのプログラム読むのってキツイ。だからコントリビューターがドキュメントも付けていないプログラムを送りつけてきて、それを解析して取り込むべきか否かを判定するJ.Janke氏の作業量とエネルギーも相当なモンだと思う。その結果、何のメリットもなかったと判断した時の彼の徒労感も相当なもので、思わず「時間を費やした私がバカだった」と言ってしまった彼の気持ちもわからないではない。

ということで、このコミュニティベースの開発プロジェクトが別に出来たということも、当然と言えば当然かも。他のコマーシャルオープンソースのプロジェクトを見ても、まぁ製品版とオープンソース版では機能そのものさえも違うことが多々あるし、ユーザーコミュニティで広範なユーザー向けに色々と機能を追加できるというのもまた魅力あることである。そして事実、そのコミュニティベースで、J.Janke氏の考えるような、要するに彼の眼鏡にかなうような製品が出来てくるとは考え難い。将来にわたっても両者が同一線上にいるとは考えられない。よっぽどプロジェクトをうまくコントロールしないと、（ドキュメントの統一だとか、開発ルールだとか）、実際、実務上で動かせる保証のあるレベルに持っていくのは難しいし、もちろんファンドを受けていなければ、彼らの努力をどうやってペイするのか？という問題もある。私もできればルックスあたりでコントリビュートしたいと思って開発環境を整えたのだが、いかんせん時間がない。そうそうunpaid workに時間をかけられない事情を誰しも持っている。

ユーザーとしては両方を見ていかないと。

もう一つ、今日付けの「まつしたひろ氏のブログ」で紹介されていたオープンソースソフトウェアベンダーとベンチャーキャピタルとの関係図が興味深い。ComPiereを取り巻く同じような関係図を作ってみると、面白いことが見えてくるかも。