Contour開発者の最後の内部会議で、プレゼンテーションを行いました。 私のプレゼンテーションでは、有名なロシアのIT企業を2つのコラムに分けてリストしたスライドがありました。 右と左の列の会社の間には1つの大きな違いがありました。
私は聴衆に質問に答えるように頼みましたが、あなたはどの会社と最もよく関わっていますか？ あなたの意見では、クールなエンジニアはそこで働いていますが、そこで開発することは興味深いですか？
会議で、同僚はほぼ満場一致で右の列から会社に投票しました。
彼らの違いは、彼らが積極的に技術と知識を広めることでした-オープンソースとわかりやすいマニュアルを専門家コミュニティと共有し、会議で話します。 彼らはオープンソースプロジェクトの開発に意図的に投資しています。 それらの多くの技術と説明は、特別に作成されたサイトtech.yandex.ru 、 opensource.mail.ru 、 techno.2gis.ru/ opensourceで公開されており、企業外の多くの開発者に知られています。
あなたが突然チャリティ（ほぼ）を行い、あなたの会社で同様のことをすることに決めた場合、私のテキストが質問に答えるのに役立つことを願っています：あなたはそれを必要としますか、どれだけのリソースが必要で、何が結果になりますか？ このようなサイトtech.skbkontur.ruをリリースしました 。
このようなサイトをContour用に作成することを長い間考えていました。 多くのチームは何とかオープンソースプロジェクトを取得しましたが、いくつかの理由でそれらを広く配布しませんでした。直接利益をもたらさないが、問題を追加して時間がかかるからです。 私たちには、やる気、これをやるべきかどうかの理解が必要でした。
私たち自身のために、3つの「理由」を明確に定義し、Google Dockに記録し、ファイルにいくつかの詳細を追加しました。これが一種の規制の登場です。 プロジェクトをオープンソースにしたいが、行動計画を持っていない人に役立ちます。
理由：
- 共通の利益：開発者の外部コミュニティと知識とスキルを共有します。 外国のオープンソースコードを無料で取得、変更、使用できます。誰でもオープンプログラムのコードを取得できます。
- 個人的な関心：おそらく誰かが私たちのオープンソースプロジェクトに触発され、それを作成したチームで働くようになるでしょう。
- テクノロジー企業のイメージ：内部タスクについて、開発者がテクノロジーと業界自体を前進させる方法について話すこと。
詰まったコーンと次のルール
私たちがオープンソースで最初に投稿したプロジェクト（ Habrの詳細を読んでください ）は、私たちが所有していたプロジェクトの中で最大かつ最も質の高いものになりました。 私たちは、彼の自立生活への準備に慎重に取り組みました。ドキュメントを作成し、特定の輪郭部分をきれいにし、規制のすべてのポイントへの準拠をチェックしました。 しかし、彼はかなり狭い聴衆と特定のアプリケーションを持っていましたが、パフォーマンスとして非難することはありませんでした。
最初に気付いたのは、オープンソースプロジェクトは、商用プロジェクトの副産物として現れたとしても、メインプロジェクトと同じ条件で存在するということです。 あなたはそれが誰かに役立つことを確かめる必要があります、あなたはそれをテストし、ライセンスを与え、付随するドキュメントを書く必要があります。 リリース後、マーケティングおよび広報イベント、伴奏、普及、会議でのスピーチ、および適応とアプリケーション機能に関するいくつかの記事を追加します。 次に、バグレポートとプルリクエストに対応します。 ただし、これは商用製品ではなく、オープンソースであることを忘れないでください。 これは、彼らが主な活動と並行してそれをしなければならないことを意味し、多くの場合、残余の原則または個人的な時間の不利益に応じて時間を割り当てる必要があります（あなたはまだマネージャーと同僚に事業の重要性を納得させることができます-私たちは成功しましたが、それほど簡単にはなりませんでした）:)
第二に、質の高い実装がなければ、プロジェクトは運命づけられます。 一連のルールを策定し、プロジェクトを公開する前に、コンプライアンスのために実行します。 同じものから始めることをお勧めします。
- 安全性 情報セキュリティ部門は、投稿内容を認識し、会社の商用サービスの機能を明らかにするコードをすべてプロジェクトから削除する必要があります。
- 品質。 悪いコードを公開しても、会社と作者のイメージを傷つけるだけです。 プロジェクトのコードレビューに経験豊富な開発者を何人か関与させ、欠陥を見つけて修正します。 同時に、一般に受け入れられている世界のオープンソース標準（英語、readme.txt、コードスタイル、changelog.txtなど）を順守しているため、その遵守は新しいコミュニティメンバーの入場基準を下げ、視聴者を拡大します。
- スケーラビリティ。 理想的には、プロジェクトはモジュール式で、スケーラブルである必要があります。 つまり、簡単に拡張できるはずです。 製品を簡単に拡張できるほど、新しいコミュニティメンバーのエントリーしきい値は低くなります。
- テスト。 レイアウトする前に、コードの操作性を確認します。この場合、自動テストを使用し、リポジトリとの統合を含むオープンテストツール（GitHub＆Travis CIなど）に依存しています。
- ライセンス。 コードのレイアウトは合法でなければならず、ライセンスは法務部と合意されています。 コードは通常、一般的なオープンソースライセンス（MIT、GPL、BSDなど）のいずれかで公開されていることを覚えておくことが重要です。 通常はMITを使用しますが、プロジェクト内にGPLでライセンスされているコードが存在する場合、プロジェクト全体もGPLでライセンスされている必要があります。
ドキュメンテーション 製品が大きすぎて1つのREADMEテキストで説明できない場合は、質問に答えるドキュメントを製品に添付します。
- 使用開始方法（クイックスタート）
- コンパイルとインストールの方法（ビルドとインストール）
- 実行方法（実行中）
- 編集をテストする方法（テスト）
- 設定方法
- 使用例は何ですか（例）
三番目。 1つのオープンソースプロジェクトは、企業に何も提供しません。 あなたがそれを非常にクールにして、それを出し、会議で話し、Habréで書いて、フィードバックを待つ準備をしたとしても...これは、苦しみの流れがあなたのコードをダウンロードしてあなたのサービスでそれを使用するためにその道のすべてをとることを意味するものではありません。
現在、私たちのサイトには10のオープンソースプロジェクトがあります。 それらはすべて、Konturの商用サービスの作業中に登場した関連製品、またはオープンソースからのニーズに応じて処理された製品です。 そして、これがオープンソースの重要なポイントです。製品またはサービスが完全と見なされることはありません。 特定の段階で得られるものは、チームワークの結果であり、さまざまな企業、都市、さらには国の人たちが加わった結果です。
私はオープンソースで追いついている人たちの中にいることを認めなければなりません。多くのプロジェクトはなく、ただ広がり始めています。 しかし、私たちにとっては、計画から逸脱するのではなく、開発の普及を開始することが重要でした。 このテキストを読んだ後、あなたの会社がオープンソースの分野で共有するものを持っていると判断し、あなたの時間とエネルギーを費やすのが残念でないなら、それは私がこの記事を無料で書いたことを意味します。