オープンソースプロジェクトの管理方法

Question

私は暇な時にいくつかのプロジェクトで小さなチームで働いています。我々は、私たちがサークルに入っているように見えて、私たちの製品を開発することができないという問題を抱えています。しかし、これは私の仕事の間は問題ではありません。対面コミュニケーションの欠如は生産性に大きな影響を与えているようです。

オープンソース開発コミュニティで使用されているソフトウェアや方法論の例があります。

Answer 1

「オープンソースプロジェクト」は非常に幅広いプロジェクトであるため、これは難しい質問です。私は、プロジェクトが単一の統合目標（おそらく、関連する目標のセット）を持っているということを定義するのが特徴だと思います。

オープンソースのメーリングリストはありますか？私はfavorite distroのメーリングリストに登録しており、開発者は1日に何度も電子メールを送ります。また、IRC /インスタントメッセンジャーなどのコミュニケーションの手段もあります。

私はRoRの開発者ではありませんが、私はGetting Realからいくつかのインスピレーションのためにスキミングすることをお勧めします。

Answer 2

私の推測では、プライベートプロジェクトはすべて開発者によって実行され、コード化されています。開発者は開発を続けることが知られています。大きな違いは、私の経験では、会社は、いつ物事が完了したかを定義できる管理者を経験しているということです。私は目標を定義し、何が完了したかを決めるという作業に誰かを置くことをお勧めします。

Answer 3

ここには本当の方法論は、私は2つのことが重要であると思う：

1. は、明確に定義された目標と 責任を持っています。
2. 各開発者に 割り振り部分の仕方を最後に伝えさせてください。

オープンソースプロジェクトでは、唯一の本当の、そして最も強い動機づけは、製品をコーディングするのが楽しいことです。上記の＃2に関連して、人々が何をすべきかを伝え、それに同意しない場合、その動機は不足している。もちろん、他のタイプの関係のように、常に譲歩してくれることもあります。私は（プロジェクトの大きさと運動量に応じて）少なくとも週に一度または月をお勧めします顔時間について、Skypeは会議に顔を持つための素晴らしいです

また、

Answer 4

私が上してきました開発者よりも多くの話し手があったいくつかのプロジェクト。私の傾向は、話し手を無視してコーダーに耳を傾けることです。それでも、通常はパッチを受け入れる担当者が1人います。軽く踏み外さなければならない政治的な問題があるかもしれませんが、すべての目的と目的のために最終的な発言はあります。

Linusには、同じ問題でかなり有名な問題がいくつかありました。 2006年からこのスレッドをメモしてください：Talk is cheap. Show me the code.

もう1つ。コメントにはコードがあり、書き換えが多いと言っているので、Eric RaymondのThe Cathedral and the Bazzaarを読むことを強くお勧めします。エリックは実際にはちょっとしたことですが、このエッセイはフリーソフトウェアプロジェクトを実行したい人にとっては貴重です。

Answer 5

ほとんどのオープンソースプロジェクトの歴史を読んでいれば、彼らは多くの初期作業をしている人から始めます。チームがあれば、それは小さく、実際にチームを率いるのは1人です。

1つの例を選択します。 Pythonコミュニティでは、Guido van Rossumを「善意の独裁者（BDFL）」と呼んでいます。彼の言葉は最終的なものです（多かれ少なかれ）。多くの場合、人々は彼に同意しません - しかし、Pythonコミュニティのために - 彼は彼の判断に黙認しているようです。

すべてのオープンソースプロジェクトには、意思決定が確実に行われ、一貫性のある方法で作成されることを保証する（単数の）リードプログラマーがいると思います。

昔、フレッドブルックス（The Mythical Man Month）は、「チーフプログラマーチーム」を記述していました。同じ概念。誰かが技術的な内容を担当しています。それを強調します。今日、私たちは "建築家"あるいはそのような言葉を呼んでいます。

Answer 6

私はこのプロジェクトのあなたとあなたのチームメイトの動機と目標を考えています。彼らは以下のとおりです。

a））は素晴らしい製品

または

Bを作成ソフトウェアで遊んで、そして

どちらの答えも同様に有効である、いくつか新しいことを学ぶ、と私は推測していますそれは、どちらか一方に傾いているミックスです。

それ以上の場合は、方法論などの提案を見てください。おそらくあなたのすばらしいアイデアの周りに会社を形成することを検討することさえできます。そのようなものを作ることは仕事を必要とするので、あなたはおそらく仕事でそれを十分に得るでしょう。

ほとんどの場合（b）素晴らしい製品を作るのにもっと時間を費やすことになりますが、すぐにそこに行かず、複数の書き直しを苦労して自分自身を許すことができます。そして、あなたはそれを見て一緒に働くたびに、新しいスキルを学び、あなたの長期的なキャリアには非常に適しています。

まず、皆さんが皆さんがなぜそこにいるのか、お互いに明確であることをお勧めします。次に、あなたがやろうとしていることを元に戻って調べて、早めにリリースし、頻繁にリリースします。あなたのプロジェクトが3つのコンポーネントで構成され、1つのコンポーネントが完成している場合は、それを別のコンポーネントとしてリリースし、ユーザーコミュニティを構築してください。これらのユーザーは、コードを手助けするだけでなく、完全な製品のための堅実なユーザーコアを形成し、後ではなく早く進んでいく方法を評価できるようになります。

幸運。