この記事は、高可用アーキテクチャグループの集まりでの講演に基づいて整理されたものです。子供の頃から口下手で、公開講演のたびに緊張を感じ、自分の考えを完全に表現できないので、演壇で流暢に語れる人が羨ましいです。だから、自分の考えを記事に整理して表現することにしました。
個人的にオープンソースに関しては新参者で、16年初頭にgo-commons-poolというオープンソースプロジェクトをリリースしました。これはgolangの汎用オブジェクトプールで、現在約200スターを獲得しています。起業に関しても新参者で、15年初頭から技術パートナーとしてチームコミュニケーション協力ツールの開発を始めました。1年間、開発をしながら製品の仕事を少し、運営の仕事も少し兼務してきました。起業とオープンソースの両者には多くの共通点があると感じたので、いくつかの気づきを共有したいと思います。前の方々はドライな内容を多く話しましたが、私のプロジェクトは技術的に比較的シンプルなので、Timのアドバイスに従って、もう少しスープを混ぜましょう。：）
起業であれオープンソースであれ、最初に直面する問題は何をするかです。何をするかというアイデアはどこから来るのでしょうか？以下の2つのルート以外にありません：
- 観察 周りの人を観察し、自分の生活と仕事を観察し、みんなの習慣を観察し、どこにまだ改善の余地があるか、どこに痛点があるかを見る。例えば、私のこのpoolのアイデアは、誰かがグループで質問したことで、検索してみると、golangには確かに汎用で使いやすいオブジェクトプールがないことがわかりました。また、タクシーがこんなに難しい、道端で長時間待っても来ないと気づいた人がいて、Uberが生まれました。複数のデバイスでファイルを同期したい人がいて、Dropboxが生まれました。仕事でいつも繰り返し作業をしていると気づいた人がいて、様々なフレームワークが生まれました。
- 参考 他の先進的な地域や分野を見て、参考にできるものがあるか、先進地域や分野の成果を後進地域や新しい分野に移植する。ずっとホットなCopy To China起業はこのパターンで、先進地域の発展軌跡を通じて後進地域の未来トレンドを予測します。あの高可用グループでindigoが共有した、日本の経済社会の発展を通じて中国のトレンドを予測するのも同じ理屈です。私がこのpoolを作ったのも、実はjavaコミュニティの状況を分析し、golangが今後サーバーサイドで大有為になると考え、接続プールなどの用途に堅牢なオブジェクトプールがきっと必要だと判断したからです。
何をするか考えたら、次はどうするかです。このステップは、起業とオープンソースでは大きな差があるように見えますが、両者には共通点があります。実際、やることの重要なポイントは、「事」への資源投入を評価し、配置することです。資源にはお金と時間が含まれます。前に考えたことが大きすぎて、実際の資源とマッチしない場合、結果は起業が失敗するか、オープンソースプロジェクトがリポジトリを作成し、readmeを書いて、それから何も起きないことになります。ここでは、事の複雑さの評価能力と資源のコントロール能力が試されます。
プロジェクトが完成したら？次はどうやってユーザーに知らせるかです。いわゆる「お勧め」という流行りの言葉です。PingCAPの黄東旭も先ほど彼らのマーケティング方法とチャネルに言及しました。このステップの核心は、ユーザーの注意が一般的にどこにあるかを知り、最小のコストでユーザーにリーチする方法です。オープンソースプロジェクトは、様々なオープンソースコミュニティや技術者コミュニティ、自分のソーシャルネットワーク、技術会議など様々な方法でリーチします。
初期のユーザーリーチが完了し、ユーザーがプロジェクトを知り、一部の人がスターをつけたかもしれません。これらの人は潜在ユーザーです。また一部の人がforkした場合、使用するか二次開発をする準備をしている可能性があります。では、現在のユーザーをどのように維持し、より多くのユーザーを引き付けるのでしょうか？これがこの段階で考えるべきことです。以下を含みますが、これらに限定されません：
- ドキュメントを完備し、ユーザーに使い方を教える。ユーザーを「弱い」と軽視しない。
- ユーザーのフィードバックに対応し、issueを処理する。起業製品の場合はカスタマーサービスシステムが必要です。
徐々にユーザーが増え、コミュニティが形成され、独自のブランドができます。このステップは、私が作ったような小さなツールでは達成できませんが、PingCAPのTiDBや謝孟軍のbeegoのようなフレームワークは、すでに独自のコミュニティとブランドを形成しています。
このプロセスの重要なポイントをまとめます：
- アイデアが抽象化されていない。実際、すべてのツールと製品は抽象化を行っており、ユーザーニーズの抽象化です。例のあの古典的な例のように、ユーザーに何が必要かと聞くと、ユーザーは間違いなくもっと速い馬が必要だと言い、自動車だとは言いません。自動車はユーザーの移動ニーズの抽象化です。しかし、このような抽象化をどのように行うのでしょうか？私は3つの境界をまとめました。
- DRY原則、自分を繰り返さない。最も一般的なのはコード規範で使用され、みんなに無闇にコピペせず、ある程度の抽象化をするよう勧めます。しかし実際には、すべての言語の高度な機能、オブジェクト指向、モジュール化、コード生成ツール、様々なフレームワークは、この問題を解決しています。つまり、多くの繰り返し作業をしていることに気づいたら、そこからツールを抽象化できる可能性があります。
- 車輪を再発明しない この原則は議論があるようですが、私は「発明」と「作る」の違いを理解していない議論だと思います。車輪を繰り返し発明してはいけませんが、新しい車輪を作ったり、既存の車輪を改良したりすることはできます。この原則は、他人がすでに完了した仕事を繰り返さず、門前の小僧の車を作らず、先人の基礎の上で改良を行うことです。車輪を発明した人は偉大で、難しく、歴史的地位は火を発明した人と匹敵すると思います。車輪ができてから、人間が使用する道具と動物が使用する道具に本質的な違いが生まれました。
- 前に、自分を繰り返さないこと、他人を繰り返さないことを達成しました。3番目の境界は「他人に自分を繰り返させない」ことです。あなたのツール、フレームワーク、抽象化を共有し、オープンソース製品やSaaSサービスとして、他人がすでに完了した仕事を繰り返さないようにします。
- 開発速度が遅く、競合製品が登場し、機能が競合製品より弱い。
- プロモーションがうまくいかず、みんなが知らず、後発者に追い抜かれた。
- 作ったものに実際のニーズがない 例えばpool、goではchannelでシミュレートすれば簡単で、複雑なpoolを使う必要がないと考える人がいます。多くのCopy To Chinaプロジェクトのように、中国の環境に適合しないことがわかります。
- オープンソース後にメンテナンスせず、情熱を失い、ユーザーフィードバックに対応せず、最終的にすべてが流出した。多くのゾンビオープンソースプロジェクトがこのようになっています。
だから、起業したいエンジニアは、まずオープンソースから始め、オープンソースを起業のリハーサルとして使うべきだと思います。構想、開発、プロモーションの全プロセスを体験し、起業プロセスの重要なポイントを体験し、自分の長所と短所を評価できます。結局、自分はエンジニアで、開発時間は自分でコントロールでき、対象ユーザーもエンジニアで、解決する問題は自分が精通している分野で、伝播するコミュニティも自分が精通しているコミュニティです。このような天時地利人和の状況でプロジェクトを行っても困難に遭遇するなら、自分が精通していない分野、精通していないユーザー、精通していないコミュニティに移ったら、困難がどれほど大きいか想像できます。
また、技術者起業について一言。王安石の詩がとても良いと思います。「春江水暖鴨先知」。私たち一線でコードを書くエンジニアは水の中の鴨で、川の水の変化は間違いなく最初に感じ取れます。この点で優位性があります。もしあなたが昇進してコードを書かなくなり、岸に上がったら、川の水の変化を感じ取れなくなるかもしれません。
転載をご希望の場合は、出典を明記してください：デベロッパーリレーションズ »
