گیت هاب در طول ۱۰ سال به یکی از تأثیرگذارترین پلتفرم‌های اکوسیستم برنامه‌نویسی تبدیل شد و امسال در ازای ۷.۵ میلیارد دلار به مایکروسافت پیوست.۱۰ سال پیش، تام پرستون ورنر، کریس وانستراث و پی‌جی هایت گروهی را برای انجام یک پروژه‌‌ی تقریباً تفریحی شکل دادند. هدف آنها، انجام این پروژه به‌صورت پاره‌وقت و در روزهای تعطیل بود. این گروه هیچ‌گاه تصمیم نداشت پروژه‌ی تفریحی خود را به کسب‌وکار دائمی تبدیل کند. پس از مدت کوتاهی، پتانسیل‌های این پروژه برای گروه روشن شد. ایده‌ی آنها واقعا ارزشی بیش از یک پروژه‌ی آخر هفته‌ای داشت. در نهایت این ایده،‌ شیوه‌ی برنامه‌نویسی و همکاری توسعه‌دهندگان را در جهان تغییر داد. ایده‌ی آنها، گیت‌هاب بود.
گیت‌هاب در مدت ۱۰ سال فعالیت خود، شیوه‌ی برنامه‌نویسی مردم را تغییر داد. این سرویس نه‌ تنها کدنویسی را آسان‌تر کرده، بلکه سبک تفکر برنامه‌نویس‌ها را نیز در مورد برنامه‌نویسی تغییر داده است.
GitHub با شناسایی و درک مشکل میلیون‌ها نفر در سرتاسر جهان،‌ توانست به رشدی خارق‌العاده دست پیدا کند. همکاری در کدنویسی، مشکلی بود که برای سال‌ها چالش اصلی تیم‌های برنامه‌نویسی محسوب می‌شد. راهکار گیت‌هاب در این زمینه، ساده، کاربردی و مفید بود. محصول آنها دقیقاً همان چیزی بود که مردم نیاز داشتند.

تیم گیت‌هاب، با استفاده از ابزار خارق‌العاده‌ی گیت، محصولی به‌صورت نرم‌افزار به‌عنوان سرویس یا SaaS عرضه کرد. آنها با استفاده از این سرویس متن‌باز و پیاده‌سازی عالی ایده‌ی خود، از این پروژه و اکوسیستم متن‌باز، به‌راحتی کسب درآمد کردند. این موفقیت‌های سریع باعث شد تا مایکروسافت (که زمانی دشمن اصلی اکوسیستم متن‌باز بود) به خرید شرکت علاقه‌مند شود.
در این مطلب زومیت، به بررسی تاریخچه‌ی فعالیت این سرویس پرطرفدار می‌پردازیم. برای درک بهتر پیشرفت گیت‌هاب، بهتر است نگاهی به اکوسیستم توسعه‌ی نرم‌افزار در سال ۲۰۰۸ داشته باشیم.

۲۰۰۷ تا ۲۰۱۱: کدنویسی تیمی و نرم‌افزارهای اجتماعی

اگرچه استیو جابز و بیل گیتس به‌عنوان بزرگترین تأثیرگذاران در دنیای کامپیوترهای شخصی شناخته می‌شوند. پرداختن به این تاریخچه‌ی جذاب، بدون توجه به کارهای مهم بزرگانی همچون لینوس توروالدز، دور از انصاف است. توروالدز، مهندس نرم‌افزار فنلاندی بود که سیستم‌عامل محبوب لینوکس، محصول نوآوری‌های او است.
لینوکس در سال ۱۹۹۱ عرضه شد و دوقطبی ویندوز / مک را به چالش کشید. این سیستم‌عامل متن‌باز، با سرعت بالا بین گیک‌‌های دنیای فناوری محبوب شد. افرادی که می‌خواستند کنترل بیشتری روی سیستم‌عامل خود داشته باشند.

عرضه‌ی یک سیستم‌عامل، برای بسیاری از افراد، بزرگترین کار زندگی خواهد بود اما توروالدز، با اکثر مردم فرق داشت. او پس از چند سال از توسعه‌ی لینوکس،‌ سرویس جدیدی برای کنترل نسخه‌های نرم‌افزارها با نام Git معرفی کرد. کنترل نسخه در پروژه‌های نرم‌افزاری تیمی بسیار مهم است. این فرآیند، تغییرات نسخه‌های مختلف را در فایل‌های کامپیوتری ذخیره می‌کند.کنترل نسخه‌ی نرم‌افزار، شبیه به نقاط و موقعیت‌های Restore است که کامپیوترها ذخیره می‌کنند. این فرآیند، به افراد حاضر در تیم برنامه‌نویسی امکان می‌دهد تا بدون دخالت در کدهای یکدیگر، نسخه‌های خود را روی برنامه توسعه دهند. دو اصطلاح عمومی در این فرآیند، فورک کردن (Forking) و شاخه‌های مستقل (Branching) هستند.
وقتی یکی از اعضا تغییرات لازم را در شاخه‌ی مخصوص خود انجام می‌دهد، می‌توان این شاخه را به کد اصلی بازگردانده و با آن ادغام کرد. این فرآیند با اصطلاح commit در گیت استفاده می‌شود. همان‌طور که گفته شد،‌ کار کردن روی شاخه‌های مستقل، هیچ تغییری در پروژه‌ی اصلی ایجاد نمی‌کند.
پیش از عرضه‌ی گیت، برنامه‌نویسان برای همکاری‌های گروهی انتخاب‌های محدودی داشتند. یکی از این انتخاب‌ها با نام Subversion یک ابزار متن باز برای کنترل نسخه بود. این ابزار در آن زمان و حتی اکنون،‌ بین برنامه‌نویسان مشهور است. البته کمبودهای ساب‌ورژن مختص آن نبود. در واقع همه‌ی ابزارهای این حوزه، کمبودهایی داشتند که ناشی از ذات برنامه‌نویسی گروهی و تیمی بود.
در ابزارهای پیش از گیت، کسب اجازه از مدیر پروژه برای فورک کردن کد و کار روی نسخه‌ی مستقل، برخی اوقات زمانی بیش از نوشتن خود کد، طلب می‌کرد. این دشواری‌ها مشکلات متعددی را تیم‌های متن‌باز ایجاد می‌کرد و اکثر تلاش‌ها، بی‌فایده بود.

عرضه‌ی گیت در سال ۲۰۰۵ همزمان با رنسانس دنیای متن‌باز بود. در آن زمان استفاده از لینوکس به اوج محبوبیت خود رسیده بود و اولین نسخه‌های اپلیکیشن‌های وب ۲ در حال انتشار بودند. بسیاری از شرکت‌ها، پروژه‌های خود را روی سرورهای متن‌باز منتقل می‌کردند. در آن زمان اگرچه گیت مشکل اصلی کدنویسی گروهی را با عرضه‌ی قابلیت فورک مطرح کرد، اما یک چالش بزرگ هنوز بر قوت خود باقی بود. برنامه‌نویس‌ها در پیدا کردن پروژه‌های متن‌باز مشکل داشتند. در واقع برنامه‌نویس‌های بسیار زیاد روی پروژه‌های بسیار متعدد و جذاب کار می‌کردند اما گویی کسی از دیگری خبر نداشت.
پی‌جی و کریس پیش از صحبت در مورد پروژه‌ی خود، در وبسایت CNET مشغول به کار بودند. آنها از طرفداران پلتفرم برنامه‌نویسی Ruby on Rails بودند و در زمان کار در این وب‌سایت، بهبودهای متنوعی را به کد اصلی ریلز اضافه کردند. در این میان،‌ پیدا کردن کسی که کدهای آنها را بررسی کند، مشکل اصلی بود.
در آن زمان، ریلز نیز مانند بسیاری از پروژه‌های متن‌باز توسط گروه کوچکی اداره می‌شد که اضافه کردن و اعمال تغییرات جدید را به‌صورت دستی و سلیقه‌ای انجام می‌دادند. این برنامه‌نویس‌ها اصطلاحا دروازه‌بان پروژه بودند. پی‌جی و کریس تلاش‌های زیادی کردند تا دروازه‌بان‌های ریلز به کد آنها نگاه کرده و در صورت صلاحدید، آن را به پلتفرم اصلی اضافه کنند.
حتی در صورت موافقت یکی از این دروازه‌بان‌ها، باز هم اضافه کردن کد جدید چالش‌های خاص خود را داشت. در واقع، همکاری در چنین پروژه‌هایی به‌جای معلومات برنامه‌نویسی، به آشنایی با تیم اصلی نیاز داشت.

گیت با هدف برطرف کردن برخی از این مشکلات به‌وجود آمد. این محصول توروالدز نیز مانند سیستم‌عاملش عالی و کاربردی بود. گیت به برنامه‌نویس‌ها اجازه می‌داد تا بدون درخواست رسمی، نسخه‌ای از کد اصلی پروژه‌ی متن‌باز را برای ویرایش دریافت کنند. به بیان دیگر، گیت اولین قدم‌ها در مسیر دموکراتیک شدن اکوسیستم برنامه‌نویسی را (خصوصا در جامعه‌ی متن‌باز) برداشت.
البته گیت هم با تمام نقاط قوت، از کمبود ابزارهای همکاری تیمی رنج می‌برد. به‌علاوه، اشتراک کد بین دو برنامه‌نویس هنوز هم دشوار بود. تصور کنید تیم برنامه‌نویسی باید دائما بسته‌های کامل کد را برای یکدیگر ارسال می‌کردند. همین مورد ساده، نیاز شدید به گیت‌هاب در آن زمان را نشان می‌دهد.
علاوه بر مورد بالا، گیت کمبود مهم دیگری هم داشت. این سرویس رابط کاربری نداشت و اساسا بر پایه‌ی خط فرمان عمل می‌کرد. این روش کار برای مدیران سیستم و کاربران حرفه‌ای خوب و مفید بود؛ اما کاربران دیگر از شرایط راضی نبودند. به‌هرحال پس از مدت کوتاهی اولین رابط‌های گرافیکی نیز برای گیت عرضه شدند.

با تمام این کمبودها، ورنر که برنامه‌نویس روبی در منطقه‌ی Bay Area بود، ایده‌ی جالبی در مورد گیت پیدا کرد. ورنر در حال کار روی پروژه‌ای به‌نام Grit بود. این ابزار، به برنامه‌‌نویس‌ها امکان می‌داد تا با استفاده از روشی شی‌گرا و با بهره از روبی آن ریلز، به منابع کد پروژه‌های متن‌باز در گیت دسترسی داشته باشند. ورنر و وانستراث برای اولین بار یکدیگر را در یک باشگاه ورزشی ملاقات کردند. آنها در همان دیدار در مورد این پروژه با هم بحث و تبدل نظر کردند.پرستون ورنر در این فکر بود که سرویسی برای ذخیره‌ی تمام کتاب‌‌خانه‌های برنامه‌نویسی توسعه دهد. برنامه‌نویس‌ها در این سرویس قابلیت همکاری در پروژه‌ها و یادگیری در مورد گیت را داشتند.پرستون ورنر همان‌جا نام Git Hub را برای ایده‌اش انتخاب کرد.
کار روی اولین نسخه‌ی از گیت‌هاب در یکم اکتبر سال ۲۰۰۷ شروع شد. در ساعت ۱۰:۲۴ جمعه، ۱۹ اکتبر، وانستراث اولین کامیت را در گیت‌هاب ایجاد کرد و دنیای برنامه‌نویسی را تغییر داد.
وقتی پرستون ورنر و وانستراث در سال ۲۰۰۷ کار روی پروژه‌ی گیت‌هاب را شروع کردند، به‌هیچ وجه هدفی برای تجاری کردن آن یا ایجاد کسب‌وکار با آن را نداشتند. آنها برای همکاری به این ابزار نیاز داشتند و به همین دلیل آن را توسعه دادند. نکته‌ی مهم در مورد راه‌حل این دو نفر آن است که تقریبا همه‌ی برنامه‌نویس‌ها صرف‌نظر از زبان و پلتفرم، مشکل مشابهی را تجربه کرده‌اند. در نتیجه‌ی این نیاز همگانی، پتانسیل بالای پروژه‌ی آنها بسیار زود روشن شد.

در هفته‌های بعد، ورنر و وانستراث در روزهای آخر هفته به بهبود پروژه‌ی خود می‌پرداختند. ورنر بخش‌های طراحی را بر عهده داشت و وانستراث ایده‌های مورد نظر او را پیاده‌سازی می‌کرد. سرانجام در ژانویه‌ی سال ۲۰۰۸ پس از ماه‌ها کار بی‌وقفه و جلسات و تبادل نظرهای دونفره، گیت‌هاب به‌صورت عمومی عرضه شد. این سرویس ابتدا به‌صورت آزمایشی و خصوصی ارائه شد. وانستراث و ورنر در ایمیل‌هایی به دوستانشان در سیلیکون ولی، از آنها در خواست کردند که از سرویس جدید استفاده کنند. پاسخ و نظرات افراد به این پروژه‌ی جدید، بسیار سریع، مثبت و امیدوارکننده بود. یک ماه بعد، GitHub به‌صورت رسمی به‌عنوان یک شرکت ثبت شد. نام شرکت ابتدا Logical Awesome بود که به گیت‌هاب تغییر کرد.
اگرچه آن دو نفر ایده‌ی جدی برای تبدیل کردن پروژه‌شان به کسب‌وکار سودآور نداشتند؛ اما پتانسیل تجاری آن به‌حدی بود که کشش لازم را برای طرح درآمدزایی ایجاد کرد. در آوریل سال ۲۰۰۸، سه ماه پس از عرضه‌ی نسخه‌ی بتا و همزمان با انتشار رسمی سایت اصلی، جفری گروزنباخ بنیان‌گذار وبسایت آموزشی PeepCode پیامی برای کریس ارسال کرد. جفری در این پیام گفته بود که کدهای خود را به گیت‌هاب منتقل کرده است.

گروزنباخ فردی بود که با وجدان خود، روند درآمدزایی را به گیت‌هاب نشان داد. او به کریس گفت از این که به‌صورت رایگان از گیت‌هاب برای پروژه‌های شرکتی استفاده می‌کند، احساس خوبی ندارد. پیام‌های این‌چنینی در ماه‌‌های بعدی هم ارسال شدند که نشان‌دهنده‌ی ارزش بالای این سرویس بودند. کاربران فعال گیت‌هاب با وجود رایگان بودن سرویس ترجیح می‌دادند وجهی را به صاحبان سایت پرداخت کنند.یکی از بزرگترین دلایل رشد گیت‌هاب، سادگی مدل کسب‌وکار آنها بود. اگر بخواهید کد خود را برای دسترسی عموم در این سرویس نگهداری کنید، استفاده از آن برای همیشه رایگان است. اگر پروژه‌ی شما خصوصی است، باید وجهی را پرداخت کنید. این دو نوع استفاده از گیت‌هاب کاملا مشخص و روشن هستند و مدل درآمدی ساده‌ای را ایجاد می‌کنند. این مدل، نسخه‌ی رایگان سرویس را بدون کم و کاست به کاربران عرضه می‌کند که محبوبیت آن را دوچندان کرده است.
شرکت گیت‌هاب به‌سادگی می‌توانست سرویس‌های خود را به عضویت یا پرداخت حق ماهانه محدود کند. این روش، درآمد خوبی هم متوجه آنها می‌کرد اما به‌هرحال اجرا نشد. نکته‌ی مهم دیگر این مدل کسب‌وکار، سهولت در جابه‌جایی از مدل رایگان به مدل پولی سرویس است. 
درواقع، مدل درآمدی گیت‌هاب تنها مدل کسب درآمد از یک پروژه‌ی توسعه‌ی نرم‌افزار متن‌باز بود. اگر آنها از ابتدا همه‌ی منابع کد را به‌صورت پولی عرضه می‌کردند، هرگز چنین استقبالی از گیت‌هاب نمی‌شد. قطعا همان استقبال‌های اولیه از رایگان بودن سرویس‌ها، به محبوبیت امروز این شرکت منجر شده است.

نکته‌ی مهم دیگر در روند قیمت‌گذاری سرویس‌های گیت‌هاب، مبتنی بر وب بودن آن‌ها بود. درواقع، میزبانی کدها در اینترنت ایده‌ی بسیار عالی بود اما بالاخره باید هزینه‌ی پهنای باند، پرداخت می‌شد. در اینجا، حرکت روزنباخ به‌عنوان اولین پرداخت‌کننده‌ی وجه به گیت‌هاب، شروع روندی از طرف دیگر شرکت‌ها برای پرداخت‌های بعدی بود. این پرداخت‌ها، بنیان‌گذاران را بر آن داشت تا سرویس خود را به‌عنوان کسب‌وکاری سودده بررسی کنند
پی‌جی هایت به‌عنوان هم‌بنیان‌گذار سوم در ژانویه‌ی سال ۲۰۰۸ به گیت‌هاب پیوست. تنها چند ماه بعد، در دهم آوریل سال ۲۰۰۸، گیت‌هاب به‌صورت رسمی رونمایی شد.
تا سال ۲۰۰۹، رشد گیت‌هاب و استقبال از آن بسیار زیاد بود. ورنر در فوریه‌ی سال ۲۰۰۹ در کنفرانس مخصوص توسعه‌دهندگان در یاهو سخنرانی کرد. او از ۴۶ هزار مخزن کد عمومی در گیت‌هاب گفت که ۱۷ هزار عدد از آنها فقط در ماه ژانویه به سرویس پیوسته بودند. تا سخنرانی بعدی ورنر در یاهو یعنی آوریل آن سال، تعداد کاربران به ۱۰۰ هزار و تعداد پروژه‌های عمومی به بیش از ۹۰ هزار عدد رسیده بود. رشدی ۹۵ درصدی تنها در ۵ ماه.

نکته‌‌ی مهم در مورد رشد اولیه‌ی گیت‌هاب این است که این شرکت، در ماه‌های اولیه و تنها با تبلیغ‌های دهان به دهان، توانسته بود در کمتر از یک سال به ۱۰۰ هزار کاربر برسد. گیت‌هاب به‌عنوان یک محصول از همان ابتدا اعتیادآور بود. دلیل آن نیز مشکل همگانی بود که گیت‌هاب حل می‌کرد. البته در آن زمان ابزارهای دیگر همکاری بر پایه‌ی گیت نیز وجود داشتند اما گیت‌هاب، بازار خود را با ساختن سرویسی بر پایه‌ی یک فناوری جذاب رو به رشد ساخته بود.
مدل کسب‌وکاری دوگانه‌ی گیت‌هاب و محبوبیت در جامعه‌ی برنامه‌نویسان، رشد این شرکت را در سال‌های بعد تضمین می‌کرد. گیت‌هاب، حل چالش همکاری را در اولویت خود قرار داده بود و دسترسی به پروژه‌ها، فاکتور رشد آن بود. این سرویس، سرعت کار را با اهدای مجوز به همه‌ی کاربران برای فورک کردن پروژه‌ها، افزایش داد. درواقع، حل این مشکل تکنیکی در برنامه‌نویسی باعث شد تا فرهنگ همکاری نیز در جامعه‌ی برنامه‌نویس‌ها دچار انقلابی بزرگ شود.
البته نیاز بازار و اعتیاد به محصول، تنها فاکتورهای رشد گیت‌هاب نبودند. در واقع، ماهیت اجتماعی این سرویس نیز در رشد آن بی‌تأثیر نبود. پیش از گیت‌هاب، برنامه‌نویس‌ها برای نشان دادن تخصص خود تنها به جلسات پرسش و پاسخ عمومی محدود بودند. با این سرویس، آنها کدهای خود را برای عموم و کارفرمایان احتمالی عرضه می‌کردند، به‌علاوه، شرکت در پروژه‌های بزرگ نیز ابزاری برای افزایش محبوبیت و تخصص میان برنامه‌نویس‌ها شد.
این ماهیت اجتماعی، علاوه بر برنامه‌نویس‌ها به شرکت‌ها هم امکان داد تا متخصصان نرم‌افزاری خود را بهتر پیدا کنند. آنها با جستجو در مخازن عمومی کد، افراد بااستعداد را برای استخدام کشف می‌کردند.
در ۲۹ ژوئن سال ۲۰۱۰، گیت هاب قابلیتی با نام Organizations Feature اضافه کرد. این بخش به شرکت‌ها امکان می‌داد تا پروژه‌های گروهی را از یک پیش‌خوان واحد کنترل کنند. این قابلیت، پاسخی به نیازهای شرکت‌ها بود که در پیوستن به گیت‌هاب مردد بودند. به‌علاوه، برنامه‌های بلندپروازانه‌ی این پلتفرم همکاری نیز در این بخش جدید نمایان شد.

بنیان‌گذاران این سرویس تا سال ۲۰۱۰ مطمئن شده بودند که تنها راه درآمدزایی و آینده‌ی روشن برای این سرویس، عرضه‌ی آن برای شرکت‌ها و مشتریان تجاری است. یک سال بعد، نسخه‌ی نهایی این بخش با نام Enterprise عرضه شد.
تا پایان سال ۲۰۱۱، گیت‌هاب بزرگانی همچون SourceForge، Google Code و Microsoft Codeplex را پشت سر گذاشته بود. آنها تا آن سال میزبان ۲ میلیون مخزن کد بودند. در این میان عرضه‌ی قابلیت Enterprise، گیت‌هاب را هم برای برنامه‌نویسان شخصی و هم شرکت‌های بزرگ دنیای فناوری، به نیازی حتمی تبدیل کرده بود. این روند یعنی جذب و حفظ مشتریان درآمدزا، تمرکز اصلی GitHub در خلال سال‌های ۲۰۱۲ تا ۲۰۱۵ بود.
نکته‌ی جالب توجه دیگر در مورد گیت‌هاب، رشد سریع آنها بدون جذب سرمایه‌ی خارجی بود. البته از سال ۲۰۱۲ اولین سرمایه‌گذار یعنی اندرسن هورویتز وارد شرکت شد.

۲۰۱۲ تا ۲۰۱۵: از رشد سریع تا گسترش جهانی

گیت‌هاب در سال ۲۰۱۲ به سرویسی بسیار مشهور تبدیل شده بود. این سرویس نه‌تنها بدون هیچ‌گونه جذب سرمایه یا تبلیغات،‌ به پایگاهی عظیم از مشتریان دست یافته بود، بلکه تعداد پروژه‌های خصوصی و شرکتی میزبانی شده در آن نیز روز به روز افزایش می‌یافت.
نیاز گیت‌هاب در آن سال‌ها، نفوذ بیشتر به فضای تجاری برای کسب درآمد بیشتر بود. اولین اقدام آنها، استخدام برایان دال بود که به‌عنوان معاون بازاریابی و استراتژی از فوریه‌ی سال ۲۰۱۲، مشغول به کار شد. قدم بعدی، جذب سرمایه‌ی ۱۰۰ میلیون دلاری به‌عنوان مرحله‌ی اول جذب سرمایه بود که توسط شرکت اندرسن انجام شد.مرحله‌ی اول جذب سرمایه به گیت‌هاب فرصت داد تا مسیرش در رسیدن به هدف فوق را با سرعت بیشتری طی کند. آن‌ها تا آن زمان ۱.۷ میلیون کاربر و ۳ میلیون مخزن کد داشتند. به‌علاوه، درآمد گیت‌هاب از سال تأسیس به‌صورت سالانه ۳۰۰ درصد رشد داشت. این رشد طبیعی آن‌ها را به سمت جذب شرکت‌های بزرگ فهرست فورچن ۵۰۰ سوق داد تا درآمدهای هنگفت سال‌های بعد را از طریق این شرکت‌ها تأمین کنند.بسیاری از کارشناسان و کارآفرینان، از جذب سرمایه‌ی گیت‌هاب استقبال کردند اما برخی دیگر، نگاهی انتقادی به سرازیر شدن پول به این سرویس داشتند. یک گروه کوچک اما تأثیرگذار از جامعه‌ی متن‌باز، جذب سرمایه‌ی خارجی توسط پروژه‌ی گیت‌هاب را نوعی خیانت به پایه‌ها و اصول متن‌بازی می‌دانست که این شرکت روی آنها بنا شده بود. درواقع، کشمکش‌ پایه‌های متن‌باز گیت‌هاب و برنامه‌های آتی آن برای تبدیل شدن به ابزاری تجاری، نیاز به تعادلی دقیق در مسیر توسعه‌ی شرکت داشت.
انجام یکی از بزرگترین جذب سرمایه‌های تاریخ، آزادی عمل بیشتری را به گیت‌هاب می‌داد. البته این سرمایه، فشار بیشتری را نیز به شرکت وارد می‌کرد. شرکتی که پیش از آن نیز با هویت دوگانه‌ی خود دست به گریبان بود.
گیت‌هاب تا سال ۲۰۱۲ رشدی عالی داشت و با جذب سریع کاربران، موفقیت‌های اولیه را بسیار زود کسب کرده بود. البته پس از مدتی مشخص شد که کار کردن با همان سرمایه‌های اولیه‌ی شخصی یا اصطلاحا مدیریت به‌صورت بوت‌استرپ، سقف مشخصی را برای رشد شرکت ایجاد می‌کند. در واقع برای حفظ سرعت پیشرفت و دسترسی به بازارهای بزرگتر، قطعا نیاز به سرمایه وجود داشت. جذب سرمایه‌ی ۱۰۰ میلیون دلاری از اندرسن به آنها قدرت داد تا تیم مهندسی بزرگ‌تری برای تولید محصولات جدید تشکیل دهند.
نکته‌ی جالب توجه این است که عدم جذب سرمایه در سال‌های اولیه، به‌خاطر تقابل سرمایه با اصول گیت‌هاب و اکوسیستم متن باز نبود. در واقع، آنها نیازی به سرمایه‌گذار خطرپذیر نداشتند اما از لحاظ اصولی و اخلاقی نیز اشکالی در این حرکت نمی‌دیدند. زمانی که این شرکت به جذب سرمایه اقدام کرد، پایگاه قوی مشتریان خود را ایجاد کرده بود. به‌علاوه، آن‌ها از همان روز اول یک کسب‌وکار سودده بودند. این موارد به گیت‌هاب امکان می‌داد که نه‌تنها محصول خود، بلکه فرهنگ جامعه‌ی برنامه‌نویسی را نیز شکل دهد.به‌هرحال گیت‌هاب پس از جذب تعداد زیادی برنامه‌نویس و تیم‌های توسعه، رشد کافی را پیش از جذب سرمایه انجام داده بود. آنها مسیر و هدف خود را نیز به‌روشنی مشخص کرده بودند. هدف بعدی، نفوذ به بازارهای جدید و افزایش درآمدهای بالقوه بود. در این میان، مهم‌ترین المان در فرآیند جذب سرمایه‌ی گیت‌هاب، زبان ورنر در اعلام این تصمیم بودتمرکز اصلی صحبت‌های ورنر، حل مشکلات بود. با توجه به این صحبت‌ها، می‌توان سوءبرداشت‌ها در مورد گیت‌هاب به‌عنوان یک محصول یا شرکت را برطرف کرد. گیت‌هاب برای ساده‌تر کردن کدنویسی برای برنامه‌نویس‌ها طراحی نشده است. در واقع این سرویس، برای ساده‌کردن کدنویسی برای همه توسعه یافت.
گیت‌هاب در طول سال‌های فعالیت خود بسیاری از مشکلات بزرگ برنامه‌نویسی را حل کرده است. وانستراث و تیمش می‌توانستند از همان ابتدا تنها به مشکلات کوچک و جزئی توجه کنند. اما آنها چالش‌های بزرگ و اساسی این اکوسیستم را هدف قرار دادند و در نهایت، محصولی با پتانسیل رشد بالا، حول آن توسعه یافت.
جذبه‌ی گیت‌هاب به‌سرعت از جامعه‌ی متن‌باز و عاشقان هک و برنامه‌نویسی فراتر رفت. جذب شرکت‌ها و سازمان‌های بزرگ، بسیار سریع انجام شد. تا سال ۲۰۱۳، اکثر شرکت‌های بزرگ سیلیکون ولی از گیت‌هاب استفاده می‌کردند. ادوبی، دراپ‌باکس، فیسبوک، گوگل، و توییتر، همگی مخازن کد اختصاصی خود را در گیت‌هاب داشتند. برخی شرکت‌ها مانند موزیلا، صدها مخزن کد در این سرویس داشتند و به‌عبارتی همه‌چیز را در گیت‌هاب ذخیره می‌کردند. شرکت‌های دیگر مانند فیسبوک، مخازن کمتر اما با مشارکت بیشتر داشتند. ۱۰۲ مخزن فیسبوک، ۱۵ هزار فورک داشتند.رشد سریع و محبوبیت گیت‌هاب باز هم ادامه داشت. تا سال ۲۰۱۵، آنها ۲.۸ میلیون کاربر و ۴.۶ میلیون مخزن کد داشتند. به‌هرحال با این که ریشه‌های شرکت در فرهنگ برنامه‌نویسی بود، چشم‌انداز آن‌ها فراتر از این اکوسیستم ترسیم شد. مرحله‌ی بعدی رشد این شرکت، تبدیل شدن به بزرگترین هاب نرم‌افزارهای متن‌باز و در نهایت، ساخت پلتفرمی بود که به «فیسبوک توسعه‌دهندگان» تبدیل شد.
نفوذ گیت‌هاب به سیلیکون ولی ختم نشد و آنها راه خود را به پایتخت آمریکا نیز باز کردند. در ۹ می سال ۲۰۱۳، کاخ سفید «سیاست‌های رسمی ایالات متحده در برابر داده‌های آزاد» را در گیت‌هاب منتشر کرد. این اولین مرتبه‌ای بود که یک سیاست رسمی فدرال به‌این صورت منتشر می‌شد. اگرچه فایل‌های منتشر شده در مقایسه با پروژه‌های ذخیره شده در گیت‌هاب، استفاده‌ی آن‌چنانی نداشتند، اما نماد مهمی محسوب می‌شدند. درواقع، میزبانی اسناد سیاست‌های دولتی در سرورهای یک شرکت خصوصی، حرکت جدیدی بود. به‌علاوه با این کار، امکان فورک کردن و تغییر این اسناد نیز برای عموم آزاد بود.
به‌هرحال، این خبر به‌نوعی تبلیغات و روابط عمومی رایگان را برای گیت‌هاب انجام داد. به‌علاوه، با این کار کاربردهای جدیدی نیز برای گیت‌هاب روشن شد. کاربردهایی که برای سالیان دراز توسط فعالان حرکت آزادی داده، گوشزد می‌کردند. هرچند برخی از آن کاربردها هیچ‌گاه اجرایی نشدند.

۲۰۱۵ تا کنون: توسعه‌ی جهانی، گیت‌هاب به واشنگتن دی‌.سی. می‌رود

تا سال ۲۰۱۵، بسیاری از برنامه‌نویس‌ها از گیت‌هاب برای کنترل نسخه‌ی برنامه‌های خود استفاده می‌کردند. البته این سرویس، کاربردهایی فراتر نیز داشت. گیت‌هاب به پلتفرمی تبدیل شده بود که برنامه‌نویس‌ها در آنجا از یکدیگر نکات کاربردی یاد می‌گرفتند. به‌علاوه، این سرویس به شبکه‌ی اجتماعی و محلی برای تبادل نظرهای حرفه‌ای نیز تبدیل شده بود. کاربرد مهم دیگر، استفاده از این پلتفرم به عنوان محلی برای نمایش نمونه‌ کارها و رزومه‌ی برنامه‌نویسی بود.
گیت‌هاب به محلی برای ذخیره‌ی کدهای مهم جهان تبدیل شده بود. از پروژه‌های برنامه‌نویسی 
شخصی تا پروژه‌های بزرگترین شرکت‌های فناوری جهان، در این سرویس حضور داشتند.مانند هر شرکت بزرگ دیگر، گیت‌هاب نیز با بزرگ‌تر شدن، هدف مهمی برای مجرمان سایبری شد. در ۲۸ مارس سال ۲۰۱۵، گیت‌هاب بزرگترین حمله‌ی سایبری تاریخ خود را تجربه کرد. گفته شد که این حمله‌ی DDoS،‌ از طرف چین برنامه‌ریزی شده است. البته این حمله، تلاش یک رقیب آسیایی برای به زانو در آوردن یک شرکت آمریکایی نبود. هدف اصلی، دو پروژه‌ی مهم در گیت‌هاب بودند.
پروژه‌ی اول، GreatFire بود که به کاربران اینترنت در چین امکان می‌داد تا محدودیت‌های دولتی را دور بزنند. هدف بعدی، صفحه‌ی گیت‌هاب وب‌سایتی چینی و کپی نیویورک تایمز بود. این صفحه نیز به کاربران چینی امکان می‌داد تا با گذر از برنامه‌های نظارتی، به این رسانه دسترسی داشته باشند. اگرچه این حملات به سرعت خنثی شد، اما خطرات نگهداری آن حجم از کد و برنامه در یک مکان را به همه نشان داد.

۴ ماه پس از حمله‌ی دی‌داس چینی، مرحله‌ی دوم یا B جذب سرمایه برای گیت‌هاب به مبلغ ۲۵۰ میلیون دلار و توسط Sequoia Capital انجام شد. این جذب سرمایه، ارزش گیت‌هاب را به بیش از ۲ میلیارد دلار رساند. وانستراث در مورد استفاده از این سرمایه‌های جدید، هدف آنها را سرمایه‌گذاری در بخش‌های دیگر، توسعه‌ی محصولات جدید و تلاش برای حضور بین‌المللی عنوان کرد.
اولین دفتر بین‌المللی گیت‌هاب در توکیو تأسیس شد. انتخاب ژاپن به‌عنوان اولین مقصد خارجی توسط GitHub، استراتژی مهمی داشت. نه‌تنها ژاپن از لحاظ تولید ناخالص ملی، سومین اقتصاد جهان محسوب می‌شود، بلکه این کشور به نوآوری‌های فناورانه نیز مشهور است. این ویژگی‌ها، ژاپن را به بهترین مقصد برای شرکتی تبدیل کرد که قصد میزبانی از همه‌ی کدهای جهان را داشت. شرکت‌های بزرگ ژاپنی همچون هیتاچی و سایبرایجنت نیز جزو اولین مشتری‌های گیت‌هاب بودند.

توسعه‌ی گیت‌هاب باز هم ادامه پیدا کرد. آن‌ها تا جولای سال ۲۰۱۵ بیش از ۹ میلیون کاربر و ۲۱ میلیون مخزن کد داشتند. در آن زمان، این سرویس به بزرگترین مخزن کد در جهان تبدیل شده بود. اگرچه رشد کاربران با سرعت خوبی ادامه داشت، ورود به بازارهای تجاری و جلب نظر شرکت‌ها، نقش اصلی را در حفظ درآمد دائمی GitHub ایفا می‌کرد. بیش از نیمی از شرکت‌های بزرگ و مشهور آمریکایی از گیت‌هاب استفاده می‌کردند. این وضعیت،‌ نمادی از چشم‌انداز پرستون ورنر با عنوان GitHub Everywhere بود.البته گیت‌هاب با وجود رشد زیاد و جذب ۱۰ هزار کاربر جدید در هر روز، از طرف رقبای قدرتمندی تهدید می‌شد. GitLab و Bitbucket بزرگترین رقبای این سرویس بودند که سرعت رشد کاربران گیت‌هاب را تحت تأثیر قرار می‌دادند. البته درآمد گیت‌هاب باوجود ظهور این رقبا باز هم به‌سرعت افزایش پیدا می‌کرد. درآمد این سرویس در سپتامبر سال ۲۰۱۵ حدود ۹۰ و در سال بعد حدود ۱۴۰ میلیون دلار گزارش شد.
درآمد گیت‌هاب در دوره‌ی ۲۳ ماهه از سپتامبر ۲۰۱۴ تا آگوست ۲۰۱۶، در بخش پروژه‌های شخصی رکود نسبی داشت. البته درآمد از بخش‌های Organization دوبرابر و از بخش Enterprise نیز حدود سه برابر شد. در سپتامبر ۲۰۱۴،‌ این بخش حدود ۳۵ درصد از درآمد شرکت را تأمین می‌کرد که تا آگوست ۲۰۱۶ به بیش از نیمی از درآمد رسید.

تا سال ۲۰۱۷، وابستگی افزایش و حفظ درآمد به بخش‌های شرکتی و تجاری کاملا روشن شد. در آن زمان شایعه‌ی یک عرضه‌ی عمومی سهام (IPO) قوت گرفت. البته شایعات دیگر در مورد خرید یا ادغام با شرکت‌های دیگر نیز وجود داشتند. در نهایت در ۴ ژوئن سال ۲۰۱۸، خبر بزرگ دنیای فناوری منتشر شد. مایکروسافت، گیت‌هاب را به قیمت ۷.۵ میلیارد دلار خرید.
تنها در عرض چند ساعت، سرویس‌هایی مانند هکر نیوز، ردیت و تک‌درت مملو از نظرات و پست‌های کاربران عصبانی شد. آنها خرید گیت‌هاب را نوعی خیانت می‌دانستند. بسیاری از کاربران، برنامه‌هایی جامع برای ترک گیت‌هاب طراحی کردند. بسیاری از آنها فرآیند کوچ از گیت‌هاب به سرویس‌های رقیبی مثل گیت‌لب را شروع کرده بودند.
کاربران با شنیدن این خبر، جوک‌هایی را از روی عصبانیت در مورد امنیت کدهایشان منتشر می‌کردند. به‌هرحال نگرانی بین اکثر کاربران وجود داشت. بسیاری از آنها این حرکت را شبیه خرید سان مایکروسیستمز توسط اوراکل و در اختیار گرفتن MySQL می‌دانستند.
به‌هرحال در کنار تمام نگرانی‌ها و انتقادات، احساس عمومی، تیره و تار شدن آینده‌ی گیت‌هاب بود. البته، اکثر مردم متوجه این نکته نمی‌شدند که خرید گیت‌هاب در حال حاضر، تأثیری روی کلیت آن به‌عنوان یک محصول نخواهد داشت. گیت‌هاب برای مدت یک دهه به استاندارد صنعت برای توسعه‌ی نرم‌افزار به‌صورت گروهی تبدیل شد.
قطعا گیت‌لب و بیت‌باکت تعدادی از کاربران ناراضی گیت‌هاب (به خاطر فروش به مایکروسافت) را جذب خواهند کرد اما موقعیت این سرویس و کاربرد آن نزد جامعه‌ی برنامه‌نویسی، ضامن موفقیت و رشد آتی آن خواهد بود.
به‌علاوه، تجربه‌ی مایکروسافت به‌عنوان یک سرویس‌دهنده‌ی تجاری، گیت‌هاب را به یک دارایی استراتژیک برای این غول دنیای فناوری تبدیل خواهد کرد. برای مایکروسافت، خرید گیت‌هاب به‌عنوان تصاحب یک محصول نیست. بلکه هدف اصلی، جذب اکوسیستمی است که با این سرویس همراه هستند.
اکثر بحث و تبادل نظرهای آنلاین پیرامون هوشمندانه بودن یا نبودن خرید گیت‌هاب توسط مایکروسافت شکل می‌گیرد. سؤال اصلی این است که ایا مایکروسافت از GitHub استفاده‌ی صحیحی خواهد داشت؟ خریدهای قبلی این غول فناوری یعنی لینکدین و ماین‌کرافت نشان می‌دهد آنها به این زودی‌ها ساختار GitHub را تغییر نخواهند داد.

مقاصد بعدی GitHub

اکنون که مایکروسافت به صاحب قدرتمند بزرگرین مخزن کد جهان تبدیل شده است، مسیر آینده‌ی گیت‌هاب به تصمیم‌گیری‌های این شرکت در زمینه‌ی رشد بلندمدت وابسته می‌شود. در این میان، برخی تصمیم‌گیری‌ها در مورد ادامه‌ی مسیر این سرویس، احتمال بیشتری دارد:

۱- یکپارچگی با Visual Studio

کارشناسان معتقدند یکپارچه شدن گیت‌هاب با ویژوال استودیو، حرکت حتمی مایکروسافت خواهد بود. این مجموعه ابزار قدرتمند مایکروسافت برای توسعه‌دهندگان، پتانسیل بالایی را به گیت‌هاب می‌افزاید. این حرکت، در مسیر استراتژی‌های بزرگ‌تر مایکروسافت مبنی بر تغییر مسیر از فروش ویندوز به خدمات تحت ابر خواهد بود.

۲- ابزارهای بیشتر برای توسعه‌دهدنگان

در حال حاضر هنوز هم برنامه‌نویس‌ها با مشکلات متعدد در نوشتن و توسعه‌ی کدهای خود روبرو هستند. ابزارهای متنوع برای بهبود تجربه‌ی کدنویسی، هماهنگی بیشتر با سرویس آژور یا روش‌هایی برای کشف بهتر خطاها، امکاناتی هستند که پتانسیل اضافه شدن به گیت‌هاب را دارند. در این میان ترکیب گیت‌هاب و مایکروسافت با تمرکز بر خدمات ابری، به توسعه‌ی این ابزارها کمک می‌کند.

۳- خدمات و محصولات جانبی

GitHub در حال حاضر علاوه بر مهندسان نر‌م‌افزار، برای متخصصان دیگر از جمله مدیران محصول نیز کاربردی است. این سرویس در خدمات آتی خود می‌تواند قابلیت‌ها و کاربردهایی را مخصوص این متخصصان عرضه کند. به‌عنوان مثال ابزارهای مدیریت یکپارچه‌ی پروژه، یکی از این حرکت‌های احتمالی خواهد بود. این هدف، احتمال بالایی برای وقوع دارد؛ چرا که مایکروسافت نیز به‌روشنی به‌دنبال اجرای هرچه بیشتر اپلیکیشن‌های شرکتی و ابزارهای همکاری تیمی است.

درس‌هایی از تاریخچه‌ی گیت‌هاب برای کارآفرینان

گیت‌هاب در نهایت به ردموند رسید و اکنون، عضوی از خانواده‌ی بزرگ مایکروسافت است. صرف‌نظر از آینده‌ی این سرویس محبوب، تاریخچه‌ی آن درس‌های بزرگی برای علاقه‌مندان به فعالیت در دنیای فناوری دارد.

۱- مشکل بزرگی را برای حل کردن پیدا کنید

آسان‌تر کردن استفاده از گیت، یکی از اهداف GitHub بود؛ اما کار هیچ‌گاه به اینجا ختم نشد. مأموریت اصلی گیت‌هاب، تقویت همکاری و کدنویسی آسان‌تر بود. هر برنامه‌نویسی در جهان با مشکلاتی روبرو بود که گیت‌هاب قصد حل کردن آنها را داشت. این واقعیت، بازاری با پتانسیل بالا در اختیار این سرویس قرار داد.

اگر شما هم به فکر محصول یا خدمات هستید، پیش از انجام هر کاری این سوالات را از خود بپرسید:

• آیا محصول شما، مشکل اختصاصی گروه کوچکی از جامعه را حل می‌کند؟ یا مشکلی متداول از جامعه‌ای بزرگ‌تر با آن حل می‌شود؟ تولید محصول احتصاصی امتیاز رقابتی خوبی است اما هدف قرار دادن مشکلات بزرگ و جامع، پتانسیل بازار را افزایش می‌دهد.
• آیا خود شما در کارهای روزمره از محصولتان استفاده خواهید کرد؟ بسیاری از شرکت‌ها فرهنگ استفاده از محصول خود را تشویق می‌کنند اما تعداد کمی از آنها این استراتژی را به عمل می‌رسانند.
• اگر خودتان از محصول استفاده نمی‌کنید، دلیل آن را پیدا کنید. آیا مشکل از محصول است یا چالش حل شده توسط آن ارتباطی با خود شما ندارد؟ هر دوی این سناریوها به نوبه‌ی خود خطرناک هستند. استفاده نکردن از محصول خود،‌ این سؤال را ایجاد می‌کند که آیا محصول نهایی اصلا کاربردی هست یا خیر؟ اگر خود شما، مشکل حل شده توسط محصول را تجربه نکرده‌اید، چگونه می‌توانید به بهترین شرکت برای ارائه‌ی راه‌حل تبدیل شوید؟

۲- حل مشکلات بزرگ را برنامه‌ی همیشگی خود بکنید

یکی از فاکتورهای موفقیت ادامه‌دار گیت‌هاب، نه‌تنها تمرکز روی حل مشکلات بزرگ،‌ بلکه تلاش دائمی برای رفع چالش‌های همیشگی و دردناک اکوسیستم استارتاپی بود. این تلاش همیشگی، پتانسیل دست‌یابی به پایگاه بزرگ مشتریان را در مدل کسب‌وکار آن‌ها ایجاد کرد. پیشنهاد می‌شود شما هم در مورد محصول و خدمات خود این تصورات را داشته باشید:

• قابلیت‌های جدید محصول یا خدمات شما، چه مشکلاتی را حل خواهند کرد؟
• چرا این ویژگی در حال حاضر در محصول وجود ندارد؟ آیا بلندپروازانه یا سخت است؟ چگونه با چالش‌های توسعه‌ی این قابلیت روبرو می‌شوید؟
• چه عاملی موجب دردناک شدن و مهم شدن این مشکل شده است؟ آیا مشکل موجود ناشی از کمبودهای انسانی یا فنی است؟

۳- توسعه‌ی سریع و بهینه‌ی فرهنگ سازمانی

گیت‌هاب در روزهای ابتدایی خود به اهمیت فرهنگ سازمانی پی برد. این شرکت با قدرت فرهنگ خود را توسعه داد. فرهنگ سازمانی نه بر اساس محصول بلکه بر اساس تصمیم‌ها و عملکرد مدیران در تصویب قوانین شکل می‌گیرد. در مورد فرهنگ سازمانی شرکت خود به این سؤال‌ها پاسخ دهید:

• فرهنگ سازمانی شما، چگونه نمایان‌گر ارز‌ش‌های سازمان خواهد بود؟ گیت‌هاب از همان روزهای ابتدایی با برنامه‌های متنوع و حتی طراحی دکوراسیون دفتر، فرهنگ همکاری و عدم وجود سلسله‌مراتب سنتی را به روشنی نشان داد.
• کارمندان در چه زمینه‌هایی فرهنگ شرکت را تشکیل می‌دهند؟ به‌بیان دیگر، چه مقدار از فرهنگ سازمانی به‌خاطر قوانین دیکته شده و چه مقدار متأثر از استخدام‌ها خواهد بود؟
• رقبا، شرکت و محصول شما را چگونه می‌بینند؟ چه‌مقدار از این تصور وابسته به فرهنگ سازمانی است؟