オープンソースであれば、最初から大枠ができあがっているため、発注時に操作してできあがりをほぼ想像できるところが良いところです。納品後、こんなはずじゃなかった、というトラブルはオープンソースではあまり聞きません。

スクラッチ開発であれば、できあがるまでなかなかイメージがわかないため、できあがったあと、こんなはずではなかった、ということになりかねません。

画面設計もスクラッチ開発では細かくすべてを完全に設計してはじめなければなりませんが、オープンソースの場合、すでにルールが決まっていたり、APIが用意されているので部品要素の画面設計は、オープンソースの仕様にまかせて設計指示を省略できるので、発注時の設計のすり合わせにも時間をとられません。

そのため、オープンソースでの開発は、発注側もリスクを最小限に抑えられます。

ベンダーロックインされず、しかも運用に慣れていきさえすれば運用サポート費用も将来はどんどん抑えていけます。

ただ、オープンソースであってもハックをすればするほど、オープンソースといえどもベンダーロックインされていき、オープンソースのメリットが薄くなります。アップグレードもセキュリティパッチもあてにくくなります。

ハックではなく、オープンソースが標準で提供する拡張する仕組み（アドオン）を活用して機能追加やカスタマイズをする開発会社を選ぶことが大事です。逆に、安易にハックする会社は要注意、ということもいえます。ハックしなければ使えないようなオープンソースは未成熟なオープンソースだということもいえます。

そして、ハックして、本家にフィードバックしていき、将来ハックしなくても良いようにするのが本当にスキルの高い開発会社であり、開発者です。フィードバックは大変な労力がかかるため、それぞれのオープンソースごとに、日本ユーザ会を形成して意見集約を行い、開発をフィードバックしています。

以上のことから、アドオンの仕組みがきめ細かく様々な手法で用意されて拡張・カスタマイズが容易で、日本ユーザ会が組織化されてフィードバックが十分に行われているオープンソースが、安心して利用できるオープンソースといえます。

オープンソースのメリットは安く済むだけだと考えていると、大きな落とし穴に陥ります。お互いに知らないままハックしてしまい、アップグレードできなくなったり、ベンダーロックインされて恩恵が受けられなくなります。

Geeklogは、アドオンの仕組みを最初からきめ細かく用意しています。日本ユーザ会の活動は組織化され、本家へのフィードバックが十分に行われてきています。本体の高速化やOAuthサポート、サイトマッププラグイン、レスポンシブ・ウェブ・デザイン、テーマエンジンなど、これまで多数のフィードバックが行われ、本家のコミッターとして日本人開発者が新たに参加してさらに活発にフィードバック体制ができあがりました。

オープンソース選びは、１、アドオン手法や様々なアドオンが提供されていること。２．本家や日本ユーザ会を含めたオープンソース開発体制があること。この２つを満たしているかどうかを判断することが今後も重要になっていくのではないでしょうか。