گیت هاب، سرویسی که طی ۱۰ سال دنیای برنامه نویسی را تغییر داد

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

گیت‌هاب در مدت ۱۰ سال فعالیت خود، شیوه‌ی برنامه‌نویسی مردم را تغییر داد. این سرویس نه‌ تنها کدنویسی را آسان‌تر کرده، بلکه سبک تفکر برنامه‌نویس‌ها را نیز در مورد برنامه‌نویسی تغییر داده است.

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

در این مطلب زومیت، به بررسی تاریخچه‌ی فعالیت این سرویس پرطرفدار می‌پردازیم. برای درک بهتر پیشرفت گیت‌هاب، بهتر است نگاهی به اکوسیستم توسعه‌ی نرم‌افزار در سال ۲۰۰۸ داشته باشیم.

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

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

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

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

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

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

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

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

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

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

البته گیت هم با تمام نقاط قوت، از کمبود ابزارهای همکاری تیمی رنج می‌برد. به‌علاوه، اشتراک کد بین دو برنامه‌نویس هنوز هم دشوار بود. تصور کنید تیم برنامه‌نویسی باید دائما بسته‌های کامل کد را برای یکدیگر ارسال می‌کردند. همین مورد ساده، نیاز شدید به گیت‌هاب در آن زمان را نشان می‌دهد.

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

ورنر در مورد روزهای ابتدایی عرضه‌ی گیت می‌گوید:

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

با تمام این کمبودها، ورنر که برنامه‌نویس روبی در منطقه‌ی Bay Area بود، ایده‌ی جالبی در مورد گیت پیدا کرد. ورنر در حال کار روی پروژه‌ای به‌نام Grit بود. این ابزار، به برنامه‌‌نویس‌ها امکان می‌داد تا با استفاده از روشی شی‌گرا و با بهره از روبی آن ریلز، به منابع کد پروژه‌های متن‌باز در گیت دسترسی داشته باشند. ورنر و وانستراث برای اولین بار یکدیگر را در یک باشگاه ورزشی ملاقات کردند. آنها در همان دیدار در مورد این پروژه با هم بحث و تبدل نظر کردند.

کار روی اولین نسخه‌ی از گیت‌هاب در یکم اکتبر سال ۲۰۰۷ شروع شد. در ساعت ۱۰:۲۴ جمعه، ۱۹ اکتبر، وانستراث اولین کامیت را در گیت‌هاب ایجاد کرد و دنیای برنامه‌نویسی را تغییر داد.

وقتی پرستون ورنر و وانستراث در سال ۲۰۰۷ کار روی پروژه‌ی گیت‌هاب را شروع کردند، به‌هیچ وجه هدفی برای تجاری کردن آن یا ایجاد کسب‌وکار با آن را نداشتند. آنها برای همکاری به این ابزار نیاز داشتند و به همین دلیل آن را توسعه دادند. نکته‌ی مهم در مورد راه‌حل این دو نفر آن است که تقریبا همه‌ی برنامه‌نویس‌ها صرف‌نظر از زبان و پلتفرم، مشکل مشابهی را تجربه کرده‌اند. در نتیجه‌ی این نیاز همگانی، پتانسیل بالای پروژه‌ی آنها بسیار زود روشن شد.

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

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

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

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

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

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

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

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

وانستراث در مورد اولین ایده‌ها برای درآمدزایی از پروژه می‌گوید:

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

پی‌جی هایت به‌عنوان هم‌بنیان‌گذار سوم در ژانویه‌ی سال ۲۰۰۸ به گیت‌هاب پیوست. تنها چند ماه بعد، در دهم آوریل سال ۲۰۰۸، گیت‌هاب به‌صورت رسمی رونمایی شد.

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

نکته‌‌ی مهم در مورد رشد اولیه‌ی گیت‌هاب این است که این شرکت، در ماه‌های اولیه و تنها با تبلیغ‌های دهان به دهان، توانسته بود در کمتر از یک سال به ۱۰۰ هزار کاربر برسد. گیت‌هاب به‌عنوان یک محصول از همان ابتدا اعتیادآور بود. دلیل آن نیز مشکل همگانی بود که گیت‌هاب حل می‌کرد. البته در آن زمان ابزارهای دیگر همکاری بر پایه‌ی گیت نیز وجود داشتند اما گیت‌هاب، بازار خود را با ساختن سرویسی بر پایه‌ی یک فناوری جذاب رو به رشد ساخته بود.

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

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

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

بنیان‌گذاران این سرویس تا سال ۲۰۱۰ مطمئن شده بودند که تنها راه درآمدزایی و آینده‌ی روشن برای این سرویس، عرضه‌ی آن برای شرکت‌ها و مشتریان تجاری است. یک سال بعد، نسخه‌ی نهایی این بخش با نام Enterprise عرضه شد.

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

نکته‌ی جالب توجه دیگر در مورد گیت‌هاب، رشد سریع آنها بدون جذب سرمایه‌ی خارجی بود. البته از سال ۲۰۱۲ اولین سرمایه‌گذار یعنی اندرسن هورویتز وارد شرکت شد.

گیت‌هاب در سال ۲۰۱۲ به سرویسی بسیار مشهور تبدیل شده بود. این سرویس نه‌تنها بدون هیچ‌گونه جذب سرمایه یا تبلیغات،‌ به پایگاهی عظیم از مشتریان دست یافته بود، بلکه تعداد پروژه‌های خصوصی و شرکتی میزبانی شده در آن نیز روز به روز افزایش می‌یافت.

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

پرستون ورنر در مورد آن سال‌ها و استراتژی شرکت می‌گوید:

ما یک برنامه‌ی مخصوص با نام GitHub Everywhere داشتیم. می‌خواستیم هر کس در صنعت نرم‌افزار، از گیت‌هاب استفاده کند. اشخاص، تیم های کوچک، دانشجویان و همچنین شرکت‌های معتبر و بزرگ، همگی هدف ما بودند.

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

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

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

پرستون ورنر در مورد جذب سرمایه برای شرکت می‌گوید:

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

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

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

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

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

رشد سریع و محبوبیت گیت‌هاب باز هم ادامه داشت. تا سال ۲۰۱۵، آنها ۲.۸ میلیون کاربر و ۴.۶ میلیون مخزن کد داشتند. به‌هرحال با این که ریشه‌های شرکت در فرهنگ برنامه‌نویسی بود، چشم‌انداز آن‌ها فراتر از این اکوسیستم ترسیم شد. مرحله‌ی بعدی رشد این شرکت، تبدیل شدن به بزرگترین هاب نرم‌افزارهای متن‌باز و در نهایت، ساخت پلتفرمی بود که به «فیسبوک توسعه‌دهندگان» تبدیل شد.

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

بن بالتر، مدیر محصول گیت‌هاب در مورد آن اتفاق تاریخی گفت:

این اقدام، اولین مرتبه‌ای بود که یک دولت، قانون را به‌صورت یک سند زنده و قابل همکاری منتشر می‌کرد. باید منتظر تغییر و تحولات جذاب در این سند باشیم که توسط جامعه ایجاد می‌شود. امیدواریم که این حرکت، شروعی بر یک روند دائمی در این زمینه باشد.

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

تا سال ۲۰۱۵، بسیاری از برنامه‌نویس‌ها از گیت‌هاب برای کنترل نسخه‌ی برنامه‌های خود استفاده می‌کردند. البته این سرویس، کاربردهایی فراتر نیز داشت. گیت‌هاب به پلتفرمی تبدیل شده بود که برنامه‌نویس‌ها در آنجا از یکدیگر نکات کاربردی یاد می‌گرفتند. به‌علاوه، این سرویس به شبکه‌ی اجتماعی و محلی برای تبادل نظرهای حرفه‌ای نیز تبدیل شده بود. کاربرد مهم دیگر، استفاده از این پلتفرم به عنوان محلی برای نمایش نمونه‌ کارها و رزومه‌ی برنامه‌نویسی بود.

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

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

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

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

توسعه‌ی گیت‌هاب باز هم ادامه پیدا کرد. آن‌ها تا جولای سال ۲۰۱۵ بیش از ۹ میلیون کاربر و ۲۱ میلیون مخزن کد داشتند. در آن زمان، این سرویس به بزرگترین مخزن کد در جهان تبدیل شده بود. اگرچه رشد کاربران با سرعت خوبی ادامه داشت، ورود به بازارهای تجاری و جلب نظر شرکت‌ها، نقش اصلی را در حفظ درآمد دائمی GitHub ایفا می‌کرد. بیش از نیمی از شرکت‌های بزرگ و مشهور آمریکایی از گیت‌هاب استفاده می‌کردند. این وضعیت،‌ نمادی از چشم‌انداز پرستون ورنر با عنوان GitHub Everywhere بود.

درآمد گیت‌هاب در دوره‌ی ۲۳ ماهه از سپتامبر ۲۰۱۴ تا آگوست ۲۰۱۶، در بخش پروژه‌های شخصی رکود نسبی داشت. البته درآمد از بخش‌های Organization دوبرابر و از بخش Enterprise نیز حدود سه برابر شد. در سپتامبر ۲۰۱۴،‌ این بخش حدود ۳۵ درصد از درآمد شرکت را تأمین می‌کرد که تا آگوست ۲۰۱۶ به بیش از نیمی از درآمد رسید.

تا سال ۲۰۱۷، وابستگی افزایش و حفظ درآمد به بخش‌های شرکتی و تجاری کاملا روشن شد. در آن زمان شایعه‌ی یک عرضه‌ی عمومی سهام (IPO) قوت گرفت. البته شایعات دیگر در مورد خرید یا ادغام با شرکت‌های دیگر نیز وجود داشتند. در نهایت در ۴ ژوئن سال ۲۰۱۸، خبر بزرگ دنیای فناوری منتشر شد. مایکروسافت، گیت‌هاب را به قیمت ۷.۵ میلیارد دلار خرید.

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

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

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

به‌علاوه، تجربه‌ی مایکروسافت به‌عنوان یک سرویس‌دهنده‌ی تجاری، گیت‌هاب را به یک دارایی استراتژیک برای این غول دنیای فناوری تبدیل خواهد کرد. برای مایکروسافت، خرید گیت‌هاب به‌عنوان تصاحب یک محصول نیست. بلکه هدف اصلی، جذب اکوسیستمی است که با این سرویس همراه هستند.

اکثر بحث و تبادل نظرهای آنلاین پیرامون هوشمندانه بودن یا نبودن خرید گیت‌هاب توسط مایکروسافت شکل می‌گیرد. سؤال اصلی این است که ایا مایکروسافت از GitHub استفاده‌ی صحیحی خواهد داشت؟ خریدهای قبلی این غول فناوری یعنی لینکدین و ماین‌کرافت نشان می‌دهد آنها به این زودی‌ها ساختار GitHub را تغییر نخواهند داد.

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

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

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

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

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

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

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

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

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

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

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

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

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