GitLabに懐疑的な人もいます-無料のCommunity Edition（CE）のサポートを停止すると言いますが、私たちは何をしますか？ 停止しないでください。 このトピックに関する記事の翻訳を公開しています。
最近、 オープンソースソフトウェア（オープンソース）のサポートに関するポリシーと、この開発方法への献身を修正しました 。 簡単に言うと、このポリシーは次のように説明できます。このプロジェクトをサポートするビジネスを忘れずに、プロジェクトの利益のために意思決定を行う必要があります。 この記事では、ポリシーのいくつかのルールについての考えを共有したいと思います。
オープンソースプロジェクトの管理の課題
Opensource.comのMatthiasStürmerは、 4つのタイプのオープンソースコミュニティを特定しました。
- 単一のキュレーターがいるプロジェクト（単一ベンダーのプロジェクト）
- 開発コミュニティ
- ユーザーコミュニティ
- インタラクションセンター（オープンソースコンピテンスセンター）
最後の3つのタイプは、分散開発プロセスによって特徴付けられます。 場合によっては、開発はコミュニティベースの非営利団体によって調整されますが、いずれにしても、このタイプのコミュニティには単一の資金源がありません。 そのようなコミュニティの例は、Apache、Rails、およびLinuxです。
それどころか、最初のタイプの「単一のキュレーターによるプロジェクト」は、プロジェクトの方向性を制御し、ほとんどの主要開発者に資金を提供する特定の商業組織に対する財政支援によって特徴付けられます。 このタイプのコミュニティの例は、WordpressおよびAutomatticです。 HadoopおよびCloudera。 ElasticsearchとElastic。
キュレーター企業がオープンソースプロジェクトの開発を扱うときはいつでも疑問が生じます-どの開発モデルを選択するのでしょうか？ 会社は、ビジネスニーズ、開発サポート、およびプロジェクトの浮揚性のバランスを取る必要があります。 さらに、プロジェクト自体とそのコミュニティは正確に資金で賄われているため、会社はプロジェクトから利益を得る必要があります。 ただし、クローズドソースソフトウェアとは異なり、オープンソースプロジェクトは分岐され、キュレーションされた会社の外部で開発を続けることができます。
私たちにとって、オープンソースは単なるライセンスではなく、一連の倫理的義務です
フリーソフトウェア運動の結果としてオープンソースが登場しました。 「オープンソース」という用語が90年代後半に始まったとき 、それはソースコードが表示され、修正されることさえあるという事実を強調しました。 また、この用語を使用して、ビールとの比較（「ビールのように無料」）を取り除くことができました。これは、製品の品質の悪さを示唆しています。 同時に、オープンソースという用語の導入は、商業組織によるそのようなプロジェクトの資金調達の基礎を築きました。 1998年以来、オープンソースは事実上の標準となり、品質の尺度となり、ベンダーロックインによってプロジェクトが独占されないことを保証しています。
しかし、「オープンソース」という用語の導入は逆の効果がありました-フリーソフトウェア運動の活動家のルーツ（「自由のように自由」）は力を失いました。 オープンソースの動きは、相互信頼を必要とするコラボレーションに基づいています。 オープンソースプロジェクトをサポートする営利企業がこれらの原則を無視すると、相互信頼が失われ、それなしではオープンソースの概念全体が機能しなくなります。
競争上の優位性を追求してコードをオープンにする企業は、すぐに発生する倫理的な問題を考慮する必要があります。 オープンソースは単なるライセンスの一種ではなく、一連の倫理的義務でもあります。 当社は、優れたオープンソースプロジェクトマネージャーのポリシーを策定することにより、これらの義務を引き受けました。
オープンソースプロジェクトの優れたマネージャーになるとはどういう意味ですか？
プロジェクトと会社のすべての条件とコンテキストを完全に理解するまで、マネージャーのポリシーを作成したくありませんでした。 数年後、状況とそれに対応する要件をよりよく理解できるようになりました。
まず、このプロジェクトがサポートするビジネスの現実を忘れずに、プロジェクトの利益について考える必要があります。 ポリシーを作成する際、これに問題がある他のコミュニティやプロジェクトの経験を考慮しました。 オープンソースプロジェクトを持つ企業は、しばしば次の点を批判します：
- プロジェクト開発の方向における透明な意思決定プロセス。
- オープンなコミュニケーションチャネルへの企業の参加。
- プロジェクトの利益を損なうために会社の利益を気遣うこと。
プロジェクト、コード、コミュニティ、ユーザーを完全にサポートしたい場合は、これらすべての点を考慮する必要があります。
一方、商業的な問題を忘れて、プロジェクトのニーズだけに集中することはできません。 結局のところ、商業的成功はプロジェクトの存在の前提条件です。
たとえば、経験豊富な営業チームは、トラブルを次のように共有しました。 10,000人を超える開発者のチームで作業するユーザーが1米ドルも払わないのはなぜですか？」実際、知的財産を販売する場合、無料使用に制限を設定できます。 営業担当者は次のように尋ねます。「無料版のユーザー数に制限を設定しないのはなぜですか？ 開発者は1000人未満ですが、Community Editionを使用できますが、大規模なチームではエンタープライズエディションを購入する必要があります。」経済的な観点から、このソリューションは正当化されますが、オープンソースのコンテキストでは意味がありません。
オープンソースは、30日後に製品へのアクセスをブロックできるシェアウェアモデルではありません。 製品は完全に無料です。 永遠に。
このような問題に直面しているのは当社だけではありません。 1年前、 ChefのAdam Jacob氏は次のように述べています。「さまざまなサービスパッケージに含める必要がある機能と、ビジネスを成功させたいという願望とオープンソースがインフラストラクチャの未来であるという誠実な信念とのバランスをどのように見つけるかを理解しようとしています「それは1年前でした。それ以来、シェフはプロジェクトマネージャーとして大きな前進を遂げました。
現在、コミュニティ開発担当副社長のナテン・ハーベイ氏は、このテーマに関するインタビューで次のように述べています 。「オープンソースと商業的利益の交差点で、権威、真正性、文化の問題が提起されています。」 -商業的利益またはプロジェクト開発？ これは非常に重要な質問であり、その答えは、単一のキュレーターがいるオープンソースプロジェクトで考慮すべきです。 ネイテンはこの問題に関する彼の主な原則を引用しています：「透明性が最も重要です」-私たちは彼に完全に同意します。
私たちのポリシーは何ですか？
オープンソースに関する私たちの見解は、私たちのポリシーに記載されているだけでなく、私たちの仕事のあらゆる面で追跡されています。 私たちは、あなたが外の世界から自分自身を閉じることによって競争上の優位を得ることはできないと信じています。 それどころか、ユーザーコミュニティとのコミュニケーションとコラボレーションのレベルを可能な限り高く維持するよう努めています。
- オープンソース開発。 チケットをパブリックトラッカーに送信できます。これは読み取り専用インターフェイスではありません。
- オープンビジネスを行います。 私たちのビジネスのポリシーと基本的なルールは、すべての来訪者に開かれています。
- 明確な開発戦略。 Directionドキュメントには、プロジェクトの現在の開発優先度と、今後のリリースのおおよその内容が含まれています。
このレベルの透明性は、他のリポジトリ管理プラットフォームの中でも単一のキュレーターと非定型のオープンソースプロジェクトではまれなクローズドソースソフトウェアでは前例のないものです（オープンソースかどうかは関係ありません）。 実際、ソースコード管理とコミュニティ作業の歴史は、意図的な難読化と信頼の破綻の物語に満ちています。 これらの間違いを繰り返したくはありません。GitLabが安全でオープンな共同開発の場になるには、GitLab自体がオープンソースプラットフォームでなければならないと考えています。
私たちのポリシーでは、やらないと約束したすべてのことに注意を払っています。 GitLab CE（Community Edition）とEE（Enterprise Edition）の違いを明確に概説し、すべての義務を明確に示すことでコミュニティの要件を考慮しています。
ポリシーを読むことをお勧めします。 公開されたので、実行するように要求できます。
GitLab CE Management Principlesをお読みください。
英語からの翻訳は、翻訳チーム「Brain and Partners」、 http： //nadmosq.ruによって行われました。メインの翻訳者はsgnl_05です