オープンソース プロジェクトを終了させる

本オープンソースガイドでは、必要のなくなったオープンソースプロジェクトを終了させる、またはプロジェクトから撤退する準備が完了した時、企業やその開発チームがどのように「その日」を計画立てることができるかについて、アドバイスを提供します。プロジェクトをきれいに閉鎖させたり、活動を継続できる他の組織に移管したりすれば、企業は責任を持って活動のライフサイクルを見届けることができます。そうすることで、ユーザーに正しい見通しを提示でき、長期に渡ってプロジェクトコードに依存しているモノ（ソフトウェア）を確実にサポートでき、さらに、オープンソースコミュニティの中で責任感のある企業としての評価を保つことができます。

本ガイドは、あなたが新たな方向へと進んで行こうとするに当たり、プロジェクトが不要になる時期を判断し、プロジェクトへの関与をやめる方法を理解し、コード、リポジトリ、Webサイト、Wikiをはじめとする資産の処理方法を決定するための手助けをします。

内容

ガイド一覧 » GitHub上で貢献する »

このガイドの貢献者

David A. Wheeler Core Infrastructure Initiative (CII)

Jared Smith Capital One オープンソースコミュニティマネージャー

Christine Abernathy Facebook オープンソースデベロッパーアドボケイト

Guy Martin Autodesk Open@Autodesk ディレクター

Chris Aniszczyk CNCF COO

セクション 1

オープンソースプロジェクトのライフサイクル計画

ソフトウェア開発者がビジネス遂行に必要な新しいオープンソースプロジェクトを構想し、開発を始める時は、各プロジェクトの全ライフサイクル、すなわちその誕生から最終的な活動停止までに対する明確で、具体的な計画も組み込んでおかなければなりません。そのような計画作りは、企業の一貫したオープンソース戦略の一部として、その企業が司るすべてのプロジェクトにおいて行われるべきです。

そのようなライフサイクル計画とは、将来的にプロジェクトを閉鎖すること、関心のある他のユーザーグループに運営を移管すること、あるいは、企業として開発活動から撤退することなどに対する計画作りを意味します。この終末計画作りは、プロジェクト、プロジェクトのユーザー、また、プロジェクトを支えるオープンソースコミュニティに対する企業の責任の一部を成します。このような計画は、プロジェクトが終了したり、移管されたりする時に、他のユーザーが順調に移行を行なうために必要なものです。

なぜライフサイクル計画が重要なのか

オープンソースプロジェクトにおいて、終了の可能性に対する計画作りを行うことは決して独特なものではありません。同様のライフサイクル計画は、プロプラエタリーソフトウェアの開発活動でも、ITシステムのハードウェア展開でも、さらには、他の幅広いビジネスの意志決定でも行われます。オープンソースの開発活動に関して言えば、プロジェクトのライフサイクル計画には、プロジェクトのスコープとビジョン、および、成長予測のような従来から行われてきたライフサイクル評価と、コミュニティ構築や早期ユーザーの採用、および、ユーザーのフィードバックや貢献の組み込みに関する計画作りのようなオープンソース固有のカテゴリーが含まれます。

どんなプロジェクトであろうとも、開発がスローダウンにいたることや、ユーザーの採用が盛り上がった後に落ち込むことは自然なことです。大成功を収めたオープンソースプロジェクトでも、やがては、ビジネス計画が変化したり、あるいは、新技術とイノベーションがそれらにとって代わり、プロジェクトを作った人々にも、そのユーザーにも有用でなくなってしまいます。したがって、出口計画は円滑な移行を保証するために不可欠なのです。

セクション 2

「死んだ」オープンソースプロジェクトとはどのようなものか？

順調だったオープンソースプロジェクトに対する貢献数やコミット数が落ち込んだとしても、それは必ずしもプロジェクトが「死んだ」ということを意味するものではありません。それは単に、プロジェクトが成熟に達し、開発の目標を成し遂げ、また、大きな維持作業や更新作業を要求されることなくユーザーに活用されていることを意味しているのかもしれません。プロジェクトは順調に行っている可能性もあります。

一方で、そのプロジェクトを採用する人やコードを利用する人の数が急激に減少しているなら、関心が弱まり、プロジェクトが死にかけている兆候なのかもしれません。他の有効な指標としては、一般的なプロジェクト活動のレベルや、さらには、ユーザーが問い合わせを行っているか、コードに関するオンラインの議論に参加しているかといったものも含めることができます。

![](https://www.linuxfoundation.jp/wp-content/uploads/2018/01/alert-300x300.png =100x100)

注視すべきトラブルの兆候

死んだ、あるいは、死にかけているプロジェクトは、問題の存在によってわかることもあります。たとえば、開発の方向に関する考え方の差を解消できないとか、あるいは、それまで積極的に参加していた貢献者からもたらされるエネルギーが失われたといったケースです。その開発者は、より強い興味を感じて他のプロジェクトへ移って行ったのかもしれません。プロジェクトを継続すべきか、終わらせるべきか、あるいは、そのまま放置しておくべきかといった質問が、あなたのチームやコミュニティのメンバーの間で同時に出てくるプロジェクトは、衰退への明らかな兆候を示しています。他の指標は、コードに対するセキュリティ脆弱性のパッチや更新がコミュニティによって提供されなくなることです。

「だれも質問を上げなくなったり、だれも貢献しなくなったり、新規にソフトウェアを採用するユーザーがなく、だれも依存性のあるソフトウェアを作らなくなったなら、また、だれかがソフトウェアを利用しているという証拠を見出せなくなったなら、大きな警告灯が点灯している可能性があります。まったく問題ないのかもしれませんが、それでもプロジェクトが死にかけていないかチェックしてみる必要があるでしょう。」
Dr. David A. Wheeler – オープンソースエキスパート。Linux Foundation の Core Infrastructure Initiative (CII) で２つのプロジェクトを指導

これらの兆候の表れは、しっかりとしたデータがあっても正確な判断を誤る可能性があります。コードは、直接ダウンロードされるのではなく、他のアプリのパッケージマネージャーを経由して間接的にアクセスされているかもしれないからです。これにより、プロジェクトのライフサイクルが進むにつれ、どれくらいの数のユーザーがいるのかを正確に知り、追跡調査するのが難しくなります。

セクション 3

なぜプロジェクトの終了計画を発足前から作成するのか？

オープンソースプロジェクトの計画作りにおいて、将来的にそのプロジェクトをどう終了または移行させるかという意志決定は、プロジェクトのライフサイクル計画の重要な部分となります。

なぜでしょうか？コミュニティやユーザーを保護する計画なしにプロジェクトから撤退することは、オープンソースコミュニティやプロジェクトにおける組織の評判を大きく損なう可能性があるからです。オープンソースソフトウェアプロジェクトを管理している方は、他の人々がそのプロジェクトに依存していること、そして彼らの継続的な利用はあなたの管理・監視作業に依存していることを忘れないでください。確かに、あなたの会社はプロジェクトの方向やステータスを変更するような選択を行うことができますが、あなたの責任の一端には、ユーザーがニーズに対応した将来計画を立てることができるように、そのような変更をプロジェクトのユーザーに明確、迅速、かつ、オープンにコミュニケーションすることが含まれています。その意図をユーザーとコミュニケーションすることなしに、プロジェクトをクローズし、そのコードを取り除くのは、無責任と言わざるを得ません。

会社の評判を守る

ユーザーを見捨てることは、あなたの意図するところではないはずです。オープンソースの世界で、これは軽く考えるべきことではありません。だからと言って、プロジェクトの始動前から出口計画を詳細化する必要があるというわけではありません。しかし、頻繁でオープンなコミュニケーションをとることは、あなたが十分な予告なしにプロジェクトをやめないことや、ユーザーが放置されるのを防ぐためにあなたが行動することをユーザーに保証する助けになります。また、容易にフォークできるコードを開発、構築、および普及させることによって、あなたがプロジェクトへの関与をやめてもプロジェクトを他者に柔軟に任せることができるでしょう。あなたのライフサイクル計画において、撤退手順のすべてを公表する必要はありませんが、それでも、プロジェクトを円滑に、しかも責任を持って閉鎖または移行する意図があることをユーザーに知らせることはできます。

多様な貢献者を求める

コード貢献者が多様性のあるグループで構成されることは、新たなアイデアを集め、より奥深い問題解決能力を生み、より多くの目がコードに注がれるため、プロジェクトの成長を助ける重要な要素となります。また、後でプロジェクトを終了または離脱することを決定した時にも役立ちます。多様性のあるコミュニティがプロジェクトの活動に関わっていれば、プロジェクトを保守することに関心のあるコミュニティメンバーが存在する可能性もあり、将来の推移に関する選択肢も広がります。プロジェクトから離脱する決心をする時は、プロジェクトの解散を公表するより、プロジェクトを管理して継続しようとする人に譲りたいと思うものです。

このような初期段階の準備が、プロジェクトに健全なエコシステムとビジネス上の依存関係を築く信頼レベルを確立し、プロジェクト成功の基礎を作ります。

「プロジェクトを開始する時は、人々の信頼を得て、プロジェクトに参加することやコードを使用することに対する彼らの不安を軽くしようとするものです。その後で、もし「このプロジェクトはもうすぐ無くなってしまう」などと言えば、信頼を損ねることになります。そうではなく、「プロジェクトはいつか終了するかもしれないが、プロジェクトがうまく行くように最大限の努力を尽くす。そしてユーザーを見捨てないことを約束する。」と言うべきです。ユーザーに対して、何が起きているかを逐次知らせるつもりであることを伝えてください。また、ユーザーに移行の時間を与え、彼らの移行を支援するように取り組んでください。それがとても助けになるでしょう。」
Dr. David A. Wheeler – オープンソースエキスパート。Linux Foundation の Core Infrastructure Initiative (CII) で２つのプロジェクトを指導

セクション 4

プロジェクトの終了・撤退時期を決定する

理由が何であれ、オープンソースプロジェクトを終了したり他の法人へ移管したりするべきかどうか、または企業がプロジェクトに参加するのをやめるべきかどうかを判断する時が来るでしょう。その理由は、あなたの会社のビジネス目標が変わり、プロジェクトがもはや会社の新しい方向に合わなくなったからかもしれません。あるいは、活動を主導していた主要な人物やチームが会社を離れたとか、参加者、ソフトウェアの更新、使用者といったプロジェクトの成果指標が、最新のユーザーデータで急激に落ち込んでいることかもしれません。さらには、コミュニティのメンバー間でプロジェクトの将来に関して意見の相違が発生し、変化が必要になったといったことが理由となることもあります。

意見の相違がプロジェクトの方向に影響を与える

プロジェクトのスコープとか、技術的な問題とか、あるいは、ライセンスの方式などに関連して、コミュニティ内で意見の相違が発生すると、あなたはプロジェクトを分裂させて、関心のある人々が自分たちに重要なものを追求できるようにしたいと考えるかもしれません。そのような問題が、1991年、Linus TorvaldsのLinux開発を触発しました。Torvaldsは、Andrew S. Tanenbaumが大学生にコーディングを学習させるために開発したUNIX風のOSカーネルMinixを実験的に使っていましたが、Minixが根本的に異なったスコープとビジョンに基づいて開発されていると判断したので、Minixから離れて、彼独自のOSを作りました。

プロジェクトのスコープは時間が経つと間違いなく変化し、必要に応じて調整されることがあります。しかし、プロジェクトがもはや必要でなくなったなら、解散や移管の候補になるでしょう。プロジェクトの目的を変更し、既存ユーザーを満足させる方策を見出すか、新規ユーザーを必要とする機能を組み込むこともできます。しかし、それでもあなたのソフトウェアをだれも必要としないなら、プロジェクトは終わっていると言えるでしょう。たとえ世界で一番優れたソフトウェアであっても、その機能を必要とする人がいなければ、だれもそのソフトウェアを気にしません。

「そのようなことはいろいろな状況で本当に発生します。私たちは、プロジェクトやそのコードを使わなくなることもあります。その理由は、私たちが単に他のソフトウェアに移行したとか、そのプロジェクトを保守していた人々が他のことに取り組んでいるとか、Facebookを退職したとかかもしれません。おそらく、そのプロジェクトをサポートする人はいなくなっており、私たちのアプリでも使わなくなっているかもしれません。いくつかのプロジェクトは沈静化してしまっており、基本的に使用されるのを終えています。」
Christine Abernathy – Facebook社、Open Sourceチーム所属デベロッパーアドボケイト

ユーザーの現場における事例

ビジネスユーザーの場合、オープンソースプロジェクトを終了するかどうかの決断にはたくさんの要因があります。ソフトウェアメーカーAutodeskでは、約190のオープンソースプロジェクトが作られ、使用されていますが、プロジェクト開発への参加者が減少すると、コードが全盛の時期を越えたことを明確に示すとみなされ、かつて成功していたプロジェクトでも「保守モード」に置かれる可能性があります。そのようになってしまうと、コードは活発に保守されなくなり、ユーザーが質問を上げても回答されたり、されなかったりします。そのような場合、プロジェクトのコミュニティメンバーは、使用を続けることはできますが、コミュニティによるサポートは提供されません。

Facebookも、同様に使用状況を指標として、パッチや保守の要求などをモニターしています。同社はこれまでに400前後のオープンソースプロジェクトを生み出し、進行中のプロジェクトの「運命」を定期的にレビューしています。Capital Oneでは、20前後のオープンソースプロジェクトが開始され、利用されていますが、同社のニーズに従って、プロジェクトは定期的に他の組織に移管されるか閉鎖されています。

セクション 5

どのようにオープンソースプロジェクトを終了させるか

オープンソースプロジェクトの終了や移管のために何をするにしても、あなたにできる一番重要なことは、すべてのステップにおいてユーザーに率直であることです。あなたの意図に関してオープンであることは、将来の作業で共に活動する可能性のあるすべての開発コミュニティの信頼を確立するのに役立ちます。

行動することを決めたなら、プロジェクトを終了させるのか、他の組織に移管するのか、あるいは、単に関与をやめて撤退するのかを決めなければなりません。

移管することがいかに有効か

継続して保守することを希望する他組織にプロジェクトを移管すれば、プロジェクトのデータやその他の資源の移行を直接的に促進することができます。このアプローチにより、現行コミュニティとそのユーザーの懸念とリスクを軽減できます。プロジェクトが共通または標準のインターフェースを採用していれば、簡単にユーザーの手持ちデータを抽出して移動させたり、必要に応じて他の類似コンポーネントで置換したりできるでしょう。もちろん、多くのオープンソースプロジェクトはユニークな機能を提供しているので、そのようなやり方が常に上手くいくとは限りません。それでも、プロジェクトのライフサイクルの早期から共通または標準のインターフェースを提供および採用すれば、このような移行処理が簡単になるでしょう。

プロジェクトの移管時に必要な更新を実施する

プロジェクトを移管すれば、当初の開発コミュニティによって最初に開発・育成されてから長い時間が経った後のコードも、他のユーザーに継続して使用してもらえます。もちろん、コード以外のものも影響を受けます。移管されるものには、ドキュメント、貢献者契約（CLAｓ）、プロジェクトリポジトリ、Wiki、Webサイトのほか、後にサポートのインフラとして使用されるものもありますが、そのシステムは見直され、更新される必要があるでしょう。移管は、通常の移管手続きを通して行うこともできますが、プロジェクトドメインやその他の資源を新しいユーザーグループにフォワード（転送）することによって行うこともできます。

移管する代わりに、プロジェクトを新たなホストシステムに移動し、コミュニティのメンバーを照会サイトに送ってアクセスしてもらい、プロジェクトへのアクセスを完全に遮断することなく継続することもできます。

「いつもそうなる訳ではありませんが、過去に、私たちのプロジェクトの1つを他の会社に移したことがあります。それを行うための厳格なルールはありません。通常は、単に他の組織に移すだけです。私たちのグループの間で移すとなると、私たちは社内を調べて、まだ誰かに使われていないか探します。私たちのオープンソースプロジェクトについては、社内の採用を目指しています。ですから、プロジェクトはまったく異なったチームで利用されているかもしれません。そのような人々が喜んで保守してくれるなら、そのチームに移管します。これなら簡単です。単に、所有者を示すラベルを変えるだけですから。」
Christine Abernathy – Facebook社、Open Sourceチーム所属デベロッパーアドボケイト

プロジェクトを即座に消滅させる

組織によっては、いろいろな理由、たとえば法務的な懸念や競合上の圧力を考慮して、単純に時代遅れになったプロジェクトを消滅させ、活動から撤退したいと考えるかもしれません。あなたの会社が打ち出す方向性は、ひとえにあなた次第です。この場合、コードは消去される必要はなく、その代わりに、アーカイブされるとか、「リードオンリー」にされ、なおも他の人々によって利用されて、あなたの関与なしに新プロジェクトにフォークされるかもしれません。また、アーカイブサービスを提供するサイトに移され、そこでユーザーのために保存されることもあります。

忘れてはいけないのは、あなたの会社がコードのことを気にしないからといって、既存のコミュニティも気にしないということにはならない、ということです。したがって、計画の進展とともに、コミュニティの人々がコードをフォークし、あなたの関与なしにそれを利用できることを知らせる必要があります。その際、あなたのプロジェクトのオープンソースコードに依存しているユーザーに向けて、重要なプロジェクトについてユーザー自身でコードのミラーサイトを作ったり、セーブしたりすることが賢明な措置であることを再認識させるのがよいでしょう。コードはやがてなくなってしまう可能性があるため、ユーザーにとって、バックアップやミラーは必須の処置です。

あなたの選択がどんなものであろうと、それを効率よく進めるためには、着実な撤退計画が混乱を防ぎます。つまり、興味のありそうなユーザーと明確で早期のコミュニケーションをとり、影響を受けるユーザーが作業を完了し、必要に応じて代替プラットフォームへ移行できるような余裕あるスケジュールを立てることです。ユーザーは、どれくらいの時間があれば十分なのでしょうか？それは状況によって異なります。少なくとも6か月以上前から始めてください。鍵は、妥当な見通しを提示し、あなたの計画について明確かつ頻繁にコミュニケーションすることです。

会社がプロジェクトを他のグループに移管する場合、ユーザーには、彼らの利益を保護するために何が行われるのかについて最新の状況を伝えるべきです。

「最善の方法は、あなたのプロジェクトの状態について、正直に明確に説明することです。もはやあなたがプロジェクトをサポートしていないか、終了させる過程にある場合は、あなたのコードを偶然見つけた人たちに、その状況がはっきりとわかるようにしてください。コードが保守されていないことが彼らにわかるようにしてください。そうすれば、新規ユーザーがコードを使用し始めたり、コードがそこにあるとか、あなたがこのプロジェクトを支援して開発を続けているとかいう『暗黙の期待』を持ったりすることはありません。」
Jared Smith – Capital One オープンソースコミュニティマネージャー

円滑な移行に向けた作業

作業できるパートナーが確保できたら、製造を中止する製品を扱うように、プロジェクト撤退を進めてください。まず、当該プロジェクトに対して、あなたの組織は、特に開発者の作業時間の観点でどんなことができるのかを決定し、円滑な移行に備えて新しい組織と緊密に作業してください。実際の移管の完了までに数か月を要するという見通しを必ず明らかにし、その後すべての必要な手順が完了した時に、新しい所有者にプロジェクトを公式に移してください。

それにもかかわらず、発生するかもしれない問題は、あなたの旧プロジェクトを引き継ぎたいグループが、将来の運用を託すのに好ましくないケースです。このようなことは起こりえます。あなたは、行動計画を立てなければならなくなります。このような状況にどう対応しますか？あなたが自分のコードに対するこだわりが強く、あなたの会社や理念的方向性と相容れないような他グループへの移管を取りやめることを検討するなら、プロジェクトを終了するべき時ではないかもしれません。それほど強く気になるのであれば、そのプロジェクトから離脱すべきでない理由があるでしょう。

明確なコミュニケーションの重要性

移管、終了、あるいは、名称変更されるプロジェクトの新たな方向性について明確にコミュニケーションをとることは、移行の後であっても、引き続きあなたの責任です。新たな運用者と共に、プロジェクトの状況について開発者とコミュニティのメンバーに率直に知らせ、彼らが継続して利用するようなら、今後どのようにプロジェクトが保守されるかについての詳細を伝えてください。また、移動後に参加者がプロジェクトの場所を見つけ、貢献やコード利用を継続できるように、プロジェクトのWebサイト、ソーシャルメディアチャンネル、およびネットワークに繋がったコミュニティ資産を更新するのを忘れないでください。

これらすべての情報を下流の組織やユーザーともやりとりすることを忘れないでください。その対象には、企業、非営利組織、コードを利用している人々のほか、開発サイクルに直接関わっていないためにプロジェクトの解散や移管に気付かない人々も含まれます。特に、プロジェクトが良く知られていて、相当数の支持者がある場合は、Webサイトやソーシャルメディアチャンネルなどの手段を通じて、何が起きているかについて知らせてください。

「一番大切なことは、変更についてコミュニケーションをとり、コミュニティにその計画のことをできるだけ早く説明することです。プロジェクトが保守されるのかどうかについて、ユーザーを困惑させてはいけません。私の意見ですが、大体において良いコードは生き続けます。ですから、あなたが良いコードのプロジェクトを運営していたのであれば、GitHubから何かを取り除いたりしないで、『このプロジェクトは今後、積極的には保守されませんよ。』と言う見通しを示すのがよいでしょう。」
Guy Martin – Open@Autodesk ディレクター

プロジェクトのリポジトリで最新情報を提供する

プロジェクトの変更に関する情報を書き込むべき重要な場所は、GitHub上のプロジェクトのリポジトリやその関連の場所です。参加者にメッセージが届くように、Readmeファイルなどで、何が起きているのかを説明する詳細な情報を提供します。

移管計画の進行に伴い、新たな運用者へ公式に必要な資産を移管します。実際の資産を従来の会社に置いたまま新たな管理者を迎え入れるのなら、移管の影響を受けるコードの著作権を保持したまま、新たな運用者の選択するオープンソースライセンスのもとで使用させることができます。

プロジェクトのリポジトリを適切に整理するために、特定のエリアを設定し、社内でサポートされていないすべての移行済みオープンソースプロジェクト（たとえば、https://github.com/twitter-archive）を保存して利用できるようにすることを検討してください。このやり方によって、当該プロジェクトは、コードを入手しようとするユーザー向けに利用可能となり、また、初めてアクセスするユーザーもプロジェクトの状況を説明するReadmeファイルを見つけることができます。このリポジトリの特別な領域は、ユーザーが活動中のプロジェクトと退役プロジェクトの違いを明確に理解する助けとなり、同時に、企業も活動中のリポジトリに置かれた最新のオープンソースプロジェクトを確実に紹介できます。

アーカイブ作成のコツ

プロジェクトのアーカイブ作成にはいくつかのステップがあります。たとえば、プロジェクトをリードオンリーに変えることは、URLを変えることなく、プロジェクトがアーカイブ状態になったこと、および、以前と同じ形での定常的な更新を受け付ないことを明確化する助けになります。

また、たとえば、継続して利用するためにコードを入手し、フォークする方法を示すなど、ユーザーにプロジェクトに関する明確な代替計画を提示することも重要です。そのような責任の一部として、ユーザーに対してあなたへの連絡方法を提示するべきです。それによって、ユーザーは、彼らが作成したフォークを一覧にして、他の関心あるユーザーに利用させることができるようになります。このような支援策を提供する会社もあれば、しない会社もあります。

リポジトリがアーカイブされると、GitHub上で、コラボレーターやチームを追加したり、削除したりできなくなり、イシューはリードオンリーになります。アーカイブ状態のリポジトリに修正を行うには、まずリポジトリをアンアーカイブして、アーカイブ状態を解かなければなりません。詳細については、以下のGitHubドキュメントを参照してください。 https://help.github.com/articles/about-archiving-repositories/

プロジェクト閉鎖時のインフラ更新

プロジェクトの終了は、プロジェクトのインフラストラクチャとサポートにも影響を与える可能性がありますが、プロジェクトの構成、構築方法にも依存するので、ケースバイケースで判断する必要があります。プロジェクトによっては、コード内の少量部分のみを使用させ、保守していることもありますが、そのような場合はあまり大変ではないでしょう。また、プロジェクトがすべてコードでできており、リポジトリに投稿されている場合は、プロジェクトの移管や保全にさらなる処置を採る必要はなく、なすべきことを完了しているでしょう。

しかし、作業のために各種のバックエンドツールを使っているようなプロジェクトでは、閉鎖の前にかなりの骨折りが必要となります。それらの中には、テストインフラのように、たくさんの用途のために共用してきたサービスも含まれる可能性があります。そのようなテストインフラは、プロジェクトで使われていたものかもしれませんが、そのコードは移管前に除外し、他のソフトウェアのテストツールとして使えるようにしたいと思うでしょう。このような問題を解決するのは少し難しいかもしれませんが、望めば実行可能です。

「企業は、オープンソースにおけるサクセッションプラン（後継者育成計画）の作成で、本当に良い仕事をする必要があります。妥当な計画を作ることなく何かを放り投げ、会社の外から人々をかき集めて貢献者にしてしまい、その後で、プロジェクトは永久にこんな方向になると予想されますなどと言うのは、無茶です。会社の内外に関わらずコミュニティのメンバーがプロジェクトに関わり始め、人生の一部をそれに捧げ、最終的にはコミュニティの先輩となって引退することに対して準備を行い、そのようなことに対するサクセッションプランを作ることが必要です。」
Guy Martin – Open@Autodesk ディレクター

強い心を持って

あなたのやることに関して、ユーザーを見捨てるものだと非難する不満ユーザーや「トロール（荒らし）」などから、否定的なコメントやリアクションが公けに書き込まれることもあるかもしれません。しかし、大部分のユーザーは、時とともに優先度が変わることや、大企業でもプロジェクトが成熟すれば最後にはオープンソースプロジェクトを停止せざるを得ないことをわかっているはずです。どんな企業でも時にはこれを実行しなければなりません。コメントを個人攻撃だと捉えないでください。

セクション 6

結論

オープンソースプロジェクトの閉鎖、移管、または離脱は、ある時点において企業が不可避的に選択するステップですが、必ずしもつまらない仕事とは限りません。しっかりと計画し、明確で広範なコミュニケーションをとり、法務的な業務や手続きを着実に完了することで、関連するすべての人々が満足するオープンソースプロジェクト移行が実現します。

プロジェクトの最初の段階の計画作りにおいて、オープンソースプロジェクト閉鎖のための明確でわかりやすい計画を作成し、保持することは、プロジェクトの健全なライフサイクル管理計画を保証することになります。これらの計画は、高い目標を持ったプロジェクトの開始時点から、より静穏な終了時点まで、オープンソースプロジェクトを可能なかぎり効率的に運用し、成功する助けとなるでしょう。