カスタマイズしないとどうなるか

カスタマイズをする場合

以前の職場でカスタマイズありのミドルウェアの経験もあるのでそれを書いておく。

カスタマイズ相談された場合

まずは打ち合わせ。とにかく打ち合わせ。既存製品に対する機能追加、機能変更、最悪なのが機能削除。コードを削る必要がある。

カスタマイズ用の仕様書を書き起こし、見積もりを作る。ここまで無償対応。発注が来るかどうかは見積もり次第。

営業としてはカスタマイズすればするほど売上が上がるので積極的にカスタマイズを受け始める。

地獄の入口へようこそ。

注文から提供まで

注文が来るまでは何もできない。ただ、注文が来た時にカスタマイズをするためのリソースはあるていど開けておく必要がある。

価格交渉などを色々経て注文がきて、開発へ。提供はまだまだ。

まずはベースとなるソフトウェアのフォーク。ビルド環境やリリース環境もそれに合わせて用意。既存のテストは使えなくなる事が多いので、機能が削除された部分に対してのテストは削除。

さらにカスタマイズに特定の OS 対応が含まれていたらそれに合わせた環境も構築する必要がある。たとえば Linux 向けの製品の Windows 対応とか。

ドキュメントもカスタマイズ部分だけの書き起こしで終わらせたいところだが、残念ながらそうはいかないので１からカスタマイズ向けのドキュメントを書き起こす必要があることがほとんど。

そしてやっと提供へ。

そして地獄のサポート対応へ。

サポート対応

カスタマイズして提供したが 10 あるとする。もちろんベースとなる製品のバージョンはそれぞれ違うので、完全にちょっと似ているだけの別 10 製品があるのと同じ状況になる。

ソース、提供バイナリ、ドキュメント、環境が全て似ているようで似ていない状況。

問い合わせが来なければまるもうけ、来たら地獄。

アップデート版の提供

追加開発ということでアップデート版を提供することがある。カスタマイズの場合は基本的には継続開発を行わないので、お金をもらってアップデート。その時にフォーク先からのマージをしようとしてもそこにはお金を出してくれないので、古いまま。古いまま機能を更新してアップデート。

ベース製品の開発を前に進めれば進めるほど差分は大きくなる。ただその差分を埋めるためのお金は出してくれない。

つまりアップデート版は機能追加したよりベースから離れた別製品になる。