ITの経験を積む簡単な機会

麻酔科医のKon Kolivas は、Linuxカーネル用に独自のバージョンのタスクスケジューラーを開発しました 。これは、既存の実装がサーバータスクに適合していましたが、ユーザータスクに十分に対応していなかったためです。



偶然にLinuxハッカーに「変身」した Alexey Kuznetsovは、自分の職業を理論物理学者からシステムプログラマーに変えました。



ITジャーナリストのPyotr Semiletovは、主な仕事に加えて、オープンソースのテキストエディターTeaを10年間開発しています。



病理学者の専門を取得したLesya Novaselskayaは、オープンソースプロジェクトのテストに参加しています。



多くの同様の例があります。 これらすべての人々には共通点が1つあります。彼らはオープンソースプロジェクトへの関心を認識し、喜びと経験を得るために参加しました。 開かれたプロジェクトはプログラマー、そして開発ですでに豊富な経験を持っている人たちだけのためのものであるという神話がありました。 しかし、これはそうではありません。 オープンプロジェクトとは、ソースコードの開発だけでなく、テスト、技術サポート、ドキュメントの作成、マーケティングなどでもあります。 また、経験を積んで、あなたのような志を同じくする人々とのコミュニケーションを楽しむ絶好のチャンスです。 投票結果によると、オープンプロジェクトへの参加の主な障害は、プロジェクトへの参加方法の理解不足です。 したがって、この記事では、このようなプロジェクトに参加できる方法と能力を理解します。

新しいコードを書く

プロジェクトに取り掛かるには天才である必要があるとは思わないでください。 プロジェクトで使用されているプログラミング言語を知っている場合は、新しい機能を実装し、ベストプラクティスをプロジェクトに取り入れることを提案します。 プロジェクトのすべての開発者は、経験や資格に関係なく、コードを支援できます。 いくつかのプロジェクトでは、彼らは初心者により忠実であり、他のプロジェクトではそうではありません。 しかし、あなたの開発が他の人々に利益をもたらすなら、あなたのコードは見過ごされることはありません。



各プロジェクトには独自の内部技術プロセスがありますので、オプションを提案する前にそれらについて詳しく学んでください。 たとえば、PostgreSQLプロジェクトでは、すべてのプロセスが厳しく規制されています。コードの変更は、すべての変更を慎重に調査するすべての主要な開発者にパッチとして送信されます。 一方、プログラマーがメインリポジトリを「コミット」できるParrotなど、他のタイプのプロジェクトもあります。 プロジェクトがGitHubを使用している場合、おそらくプロセスはプルリクエストを介して配信されます。 行われた変更を含めるためのリクエストを通じて。 覚えておいてください：2つの同一のプロジェクトはありません。 コードを書き換えるたびに、チームで作業することを忘れないでください。そのため、スタイルがプロジェクトで採用されているスタイルと一致するように、可能な限りすべてを行ってください。 追加または変更するコードの一部は、一般的なコードから抜け出してはなりません。 コードの設計には好みがありますが、コードはプロジェクトで採用されている一般的な標準に準拠する必要があります。 それ以外の場合は、「あなたのスタイルが気に入らないので、自分のスタイルの方が良いと思うので、私と同じようにすべきです」と言っているのと同じです。

欠陥の優先順位付け

もちろん、コードはすべてのオープンソースプロジェクトの基礎ですが、コードを書くことはそれに参加する唯一の方法ではありません。 技術サポートは、多くの場合、新しい機能とバグ修正の追求において十分な注意が払われていません。 しかし、これはまさに初心者でもプロジェクトに入ることができる領域です。



たとえば、OpenVZプロジェクトには完全にオープンな欠陥管理システム-bugs.openvz.orgがあり、すべての既知の（修正済みおよび未修正の）問題がプロジェクトの全期間（ほぼ10年）にわたって収集されています。 バグトラッカーは、開発者とユーザー間のコミュニケーションメカニズムの1つです。 現在のリクエストに常に取り組むことで、プロジェクトに貢献する絶好の機会が与えられます。 システムを使用するには、 実力主義の原則に従って、プロジェクトマネージャーから付与される特別なアクセス権が必要になる場合があります。

中間バージョンをテストする

ソフトウェアテスターのコミュニティでの調査は、プロのテスターからのオープンソースソフトウェアのテストに興味があることを示しました。 多くの人がそのようなプロジェクトに参加したいのですが、どこから始めればいいのかわかりません。 同様に、どのプロジェクトでも（商業プロジェクトであっても）テスターは常に不足しています。 バグを検出してソートすると、開発者が問題を見つける時間を大幅に節約できます。 ユーザーが「このような手順を実行するとプログラムが機能しない」と書いた場合、この問題の原因を突き止めるのに面倒くさくないでください。 問題は再発しますか？ 一連の特定のステップを繰り返すことでそれを実証できますか？ 問題を特定のブラウザーまたはディストリビューションに限定しますか？ 問題の本当の原因がわからない場合でも、考えられる原因の範囲を絞り込もうとすると、開発者が問題に対処するのに非常に役立ちます。 あなたが何を理解したかに関係なく、バグにコメントを追加して、誰もがそれらに慣れることができるようにします。



私自身の経験から、オープンソースプロジェクトには新しい機能を十分にテストするのに十分なリソースがないと言えます。 したがって、ソースコードリポジトリのメインブランチに重大な変更を加える前に、プロジェクトはテストのためにできるだけ多くの人を引き付けようとします。 この方法は、テストの呼び出しと呼ばれます。 このプロジェクトのコミュニティが持っているハードウェアおよびソフトウェア構成の数を持つプロジェクトはありません。 OpenBSDプロジェクトの開発者は、テスターとユーザーの注目を集めるために、 ニュースに新しい機能が登場したことを発表しました。 OpenVZプロジェクトでも同じことを行います。テストに使用できる新しい機能のリストを公​​開しています。



テストに参加して、製品がいずれかのプラットフォームで動作することを確認できます。 原則として、新しい「ビルド」をビルドしてインストールし、製品をテストする必要がありますが、非標準のハードウェアを使用する場合、プロジェクトにとって特に重要です。 このような状況でもアセンブリが機能することを確認すると、プロジェクトマネージャーが現在のリリースステータスを判断するのに非常に役立ちます。

テストを書く

ほとんどのプロジェクトは、コードをテストするために設計されたソフトウェアパッケージを使用しますが、新しいテストを追加する可能性を提供しないような複雑なものを想像することは困難です。 C用のgcovなどのテストツールを使用して、既存のテストではテストできないソースコードの領域を特定します。 次に、適切なテストを追加して、必要な機能をテストできるようにします。

バグを修正して新しい機能を追加する

問題を修正したり、必要な機能を追加したりするパッチは、オープンソースプロジェクトに参加するための一種の古典的な方法です（覚えているなら、フリーソフトウェアの動き全体はこれから始まりました ）。 この方法は、Linuxプロジェクトに参加したいが方法がわからない人のために、CTO VirtuozzoのJames Bottomleyによっても推奨されています。 通常、彼はAndroidのSIPクライアントの機能を変更する必要がある場合の例を示します。 彼は必要な機能の欠如を発見し、パッチを作成してSIPdroidプロジェクトに送りました。



新しい機能を作成するとき、修正したコードの一部をテストするテストを追加すると便利です。 一部のプロジェクトでは、すべてのバグ修正に適切なテストを伴う必要があります。 なじみのないコードをマスターするときにメモを保管してください。 バグに対処できない場合でも、何をどうやって見つけたのかをチケットに記述してください。 これは、あなたの後にバグを扱うチームメンバーを支援します。

プロジェクトインフラストラクチャの維持を支援する

DevOpsエリアに興味がありますか？ この方向は現在非常に人気があります。 優秀なDevOpsエンジニアを見つけるのは非常に困難です。これは私たち自身の経験から知っています。 インフラストラクチャのオープンな開発が行われているプロジェクトで経験を積むことができます。 これらは、 Fedora Linuxプロジェクトであるウィキペディアのようなプロジェクトです。 OpenVZは、この方向で最初の一歩を踏み出しているだけです。



プロジェクトコンポーネントの継続的統合プロセスのセットアップ、Linuxディストリビューションのコンポーネントのパッケージ化 、開発者の環境の自動セットアップ-これらもDevOpsタスクです。

ドキュメントの作成と翻訳

ドキュメントは、プロジェクトの日常的なコンポーネントであり、多くの場合無視されます。 さらに、ドキュメントの問題は、プロジェクトに精通している人ではなく、プロジェクトに精通している人の観点から書かれたという事実によって引き起こされることがよくあります。 プロジェクトのドキュメントを読むときに「プログラムの使用方法を既に知っているかのように書いたように感じる」と思ったなら、それが何であるか理解できます。 非常に多くの場合、側からの新しい見解は、プロジェクトの直接参加者が気付かないかもしれない現在のドキュメントの欠陥を明らかにします。 さらに、プロジェクトを動的に開発する場合、ドキュメントはすぐに時代遅れになり、最新の状態に保つ必要があります。



何らかの理由でこれを行うことが「軽薄」だと思う場合、あなたは間違っています。 オープンプロジェクトへの「深刻な」または「軽薄な」貢献はありません。 たとえば、OpenBSD開発者（同時にCERNの従業員）であるIngo Schwarzeがmandocユーティリティを作成しました。これは、OpenBSDだけでなくFreeBSD、NetBSD、DragonFlyBSDでもドキュメントページをフォーマットし、フォーマットを整えるために使用されます。プロジェクト内の既存のドキュメントページ。 彼は BSDCan 2015でこれについて話しました。したがって、それはあなたにとって何が面白いかによって異なります。 興味があれば-それを取り、それをしてください！

他のユーザーの問題を支援する

チームをまとめる最善の方法は、他の人を助けることです。 プロジェクトの継続的な成功のためには、質問、特に初心者からの質問に答えることが特に重要です。 彼が必要なドキュメントを読んで答えを見つけることができる質問をしても、この時間は無駄になりません。 さらに、チームの新しい、感謝の気持ちのある、アクティブなメンバーを受け取ります。 誰もが何かから始まり、プロジェクトが発展し続けるためには、プロジェクトは常に人員の流入を必要とします。

お気に入りのプロジェクトを宣伝する

ブログがある場合は、プロジェクトで得た経験を共有してください。 ソフトウェアの使用中に発生した問題と、それをどのように解決したかについて教えてください。 したがって、1石で2羽の鳥を殺すことができます：同僚のプロジェクトへの注意をサポートし、将来参加する人のための有用な情報データベースを作成し、既に説明した質問への回答をウェブで検索します。 技術的な成果や研究について語るブログは、技術的な問題の開発と解決における実際の経験を共有する素晴らしい方法でもあります。これは、新しい仕事を探すときに役立ちます。 多くのプロジェクトには、プロジェクト参加者のブログからのエントリのアグリゲーターがあり、伝統的に「惑星」と呼ばれています： OpenVZ惑星、 Linuxカーネル 、 Perl 、 Freedesktop 、 Gnome 、 Debianなど。 熱心な人々の記録は、プロジェクトに関係がない場合でも興味深いものになります。

設計する

デザインは、ほとんどのオープンソースプロジェクトの災難です。 退屈なサイトでは、技術的な人が見た目ではなく実装に専念しているという理由だけで、説明のないロゴがプロジェクトに付随しています。 したがって、デザイナーの参加は大歓迎です。 StackExchange Webサイトのユーザーは、 「グラフィックデザイナーがどのようにオープンプロジェクトに貢献できるか」 、 「デザイナーがどのようにオープンプロジェクトに参加するように動機づけられるべきか 」という質問に答えようとしましたが、意見は分かれていました。 また、RedHatのデザイナーは、オープンプロジェクトへのデザイナーの積極的な参加の必要性を認識し、オープンプロジェクトとデザイナーがお互いを見つけるのに役立つサイトを作成しようとしましたが、プロジェクトの成功した適用の事実については聞いていません。



プロジェクトにとって興味深く有用なタスクを探し、それらを解決してください。 プロジェクトへの参加方法はプロジェクトごとに異なる可能性があるため、プロジェクトに参加するためのオプションの説明が記載されたページは素晴らしい出発点になる可能性があります： OpenStack 、 OpenVZ 、 FreeBSDなど。 プロジェクトにこのようなページがあるという事実は、他の人々に開かれていることを示唆しています。

すべての言葉を事実でバックアップするために、オープンソースプロジェクトで専門的な経験を積んだ3人のフィードバックを収集しました。

Yandexの開発者であるAlexander Yurchenko氏：

私は、無料のOpenBSDオペレーティングシステムのコアの公式開発者として、1年以上にわたってお金のための最初の本格的な仕事（組み込みシステム開発者）になりました。 公式-リポジトリへの書き込みアクセス権があるという意味で。 それ以前は、私はその年から「観客」であり、開発者にパッチを送っていました。



そのようなプロジェクトへの参加は素晴らしい経験をもたらすと言わなければなりません。 優れた大規模なオープンソースプロジェクトには、開発者がインタビューに通常必要とするすべてのものがあります。有能な設計、優れたコーディング、バージョン管理システムとバグトラッカーを使用するスキル、ピアレビュー、チームワークなどです。 など したがって、このような雰囲気で1〜2年料理をしていれば、シニア開発者の位置に対応するレベルに簡単に成長できます。



実際、それは私と一緒でした。 私は正式な仕事の経験（労働者）はありませんでしたが、すぐに上級開発者になりました。 そして、最初の週の後、トライアル期間は3ヶ月からゼロに短縮されました:)

キリル・ゴルクノフ 、OpenVZ、CRIUプロジェクト開発者：

私は偶然OpenVZに出会いました。 彼の仕事では、主に応用プログラミングに従事し、システムプログラミングとの交点はほとんどありませんでした。 ある時点で、最初の64ビットラップトップ（AcerとAMD Turion 64を搭載）を入手しました。Windows64ビットが手元になかったため、Gentooをインストールしました。 私はその時までLinuxにほとんど知識がなかったので、古代のRedHatをプレイしていましたが、特に感銘を受けず、このOSは現在の作業タスクを解決するのに適していませんでした。 Gentooでは、ラップトップは多少動作しましたが、一部のドライバーは標準のカーネル供給に含まれていなかったため、ソースから独自のカーネルを構築する必要がありました。 ここで、カーネル自体ではなく、カーネル構成プログラムで最初のバグを見つけました。 私はネットワークを検索しました-問題の解決策はありません。まあ、私は自分でそれを修正しようとすることにしました。 多くの関連タスク（カーネルの組み立て方法、使用するツールなど）を処理する必要があることがわかりました。 パッチを作成し、ニュースレターに送信しました。 驚いたことに、コアメンテナーはそのような「曲がった」パッチに対しても非常に好意的に反応しました（先を見て、私はそれをやり直さなければならないと言います。パッチはまだ嫌で、すぐに「ゲートからのターン」を与えなかったからです）初心者を笑う：彼らは何をどのように説明し、それを正しく行う方法を示した。



コア自体は、それがどのように機能するか、どのアルゴリズムが使用されているかにさらに関心がありました。 この点で、プロジェクトの「オープン性」は非常に貴重なサービスを提供します。特定のタスクがどのように解決されるかを見ることができます（理論的ではなく現実的です）。 多くの場合、「ある種の質問ではなく、なぜそうなのか」という質問が発生しました。ここでは、コードの作成者からフィードバックを得ることが非常に役立ちます。 オープンメーリングリストは、開発者が何をどのように尋ねるかを許可するだけでなく、さらに重要なこととして、一種のナレッジベースとして機能します。問題とその解決方法については、アーカイブでいつでも検索できます。



実務経験のない初心者プログラマーにとって、このような環境は、私がこれをすべて必要とするかどうかを理解するために、自分の手を試すための単なる肥沃な地面です。



それは私とほぼ同じでした。数年の間、私はコード内で何かを支配し、パッチを送信し、手でコードを受け取りました。 このような経験は、事実上非常に貴重です。 そして、何かがうまくいき始めたら、求人がすぐに表示されることを確信できます。 OpenVZのLinuxカーネル開発者との道を横断しました。 それで、彼らはバニラコアについてはもちろん忘れずに、OpenVZコアと関連プログラムで一緒に作業することにしました。



プロジェクトのオープン性は、実用的なプログラミングを学習する際に非常に重要な助けになりますが、プロジェクトはプロジェクトによって異なることを理解する必要があります。また、オープン性だけではコードの品質が保証されません（コードをgithubにアップロードすると、良いコードにはなりません） 同様に、クローズドソースコードはアプリオリに良いものでも安全なものでもありません。

アレクサンダー・ポリヤコフ 、開発者

私の物語には、オリジナルのものは何もないと思います。 これが通常どのように起こるか-ある種のソフトウェアの使用を開始すると、突然その中の何かがうまくいかないか、何かが欠けているか、厄介な妨害があります。

オープンソースの場合、自分で修正することができます。 だから、それはconfig.hcを介した設定が再コンパイルによって私を悩ませたdwmウィンドウマネージャでした：最初にxrdbを介して設定を追加し、次にクリックしてフォーカスなど このような変更は、プロジェクトの最小限のガイドラインに対応していなかったため、分岐する必要がありました。 DragonFlyBSDもほぼ同じです。サイト上の魅力的なテキストは面白そうに聞こえましたが、FreeBSDは疲れましたが、突然、英語とエネルギー管理（ACPI）以外の言語のサポートが不十分であることがわかりました。 私は、FreeBSDのより新しいバージョンからコードの必要なセクションの移植を開始しなければなりませんでした。 IRCチャンネルの他の開発者は多くのことを助け、何が起こっているのかを説明し、問題に対処するのを助けました。 そこで、カーネルお​​よびシステムライブラリの開発である程度の経験を得ました。 私たちはこれでいくらかのお金を稼ぐこともできました-モスクワの人がDragonFlyBSDを実稼働で使用していて、ACPIとそれ（のような）で何らかのレイドドライバーを強化したかったのです。 メールで連絡されたgitログで私を見つけました。

OpenBSDでは、ささいなことにいくつかのパッチを投げました-便宜上cwmで何かを仕上げました（wmではすでに特別でした）。kshでは、いくつかの妨害を修正し、viモードを改善しました。 このプロジェクトでは、新しい貢献者への態度は最高ではありません。それを自分で理解し、その後でニュースレターに書くことを前提としています。 エントリのしきい値は高く、最も永続的なもののみが生き残りますが、コードは良好です。

私は9frontにも参加しました ：私はWiFiのドライバーを完成させ、すでに私に馴染み深いACPIを作りました 。 おそらく、AMLインタープリターの最小の動作実装を持っています。 また、カーネル自体は（「通常の」OSと比較して）非常にコンパクトであるため、理解しやすくなっています。 私はインタビューでそれについて自慢しましたが、それがどれだけ役立ったのか（またはその逆）-私は知りません。



さて、ここでオープンソースプロジェクトの経験を得ることができます。 主なことは、カーブコードを送信することを恐れず（誰にでも起こります）、落ち着いて（彼らが彼をscるとき）、本当に興味深いプロジェクトを選択することです。 そして、あなたは経験と喜びを得ます。 雇用主がGitHub（Hello、Google！）でのコミットまたはプロファイルによってあなたを見つける可能性はまだあります。