بزرگنمايي:

آریا جوان - گیت هاب در طول 10 سال به یکی از تأثیرگذارترین پلتفرم‌های اکوسیستم برنامه‌نویسی تبدیل شد و امسال در ازای 7.5 میلیارد دلار به مایکروسافت پیوست.

10 سال پیش، تام پرستون ورنر، کریس وانستراث و پی‌جی هایت گروهی را برای انجام یک پروژه‌‌ی تقریبا تفریحی شکل دادند. هدف آنها، انجام این پروژه به‌صورت پاره‌وقت و در روزهای تعطیل بود. این گروه هیچ‌گاه تصمیم نداشت پروژه‌ی تفریحی خود را به کسب‌وکار دائمی تبدیل کند. پس از مدت کوتاهی، پتانسیل‌های این پروژه برای گروه روشن شد. ایده‌ی آنها واقعا ارزشی بیش از یک پروژه‌ی آخر هفته‌ای داشت. در نهایت این ایده،‌ شیوه‌ی برنامه‌نویسی و همکاری توسعه‌دهندگان را در جهان تغییر داد. ایده‌ی آنها، گیت هاب بود. گیت‌هاب در مدت 10 سال فعالیت خود، شیوه‌ی برنامه‌نویسی مردم را تغییر داد. این سرویس نه‌تنها کدنویسی را آسان‌تر کرده، بلکه سبک تفکر برنامه‌نویس‌ها را نیز در مورد برنامه‌نویسی تغییر داده است. Github با شناسایی و درک مشکل میلیون‌ها نفر در سرتاسر جهان،‌ توانست به رشدی خارق‌العاده دست پیدا کند. همکاری در کدنویسی، مشکلی بود که برای سال‌ها چالش اصلی تیم‌های برنامه‌نویسی محسوب می‌شد. راهکار گیت‌هاب در این زمینه، ساده، کاربردی و مفید بود. محصول آنها دقیقا همان چیزی بود که مردم نیاز داشتند.
مقاله‌های مرتبط:
آموزش مقدماتی کار با گیت و گیت‌هاب
تیم گیت‌هاب، با استفاده از ابزار خارق‌العاده‌ی گیت، محصولی به‌صورت نرم‌افزار به‌عنوان سرویس یا SaaS عرضه کرد. آنها با استفاده از این سرویس متن‌باز و پیاده‌سازی عالی ایده‌ی خود، از این پروژه و اکوسیستم متن‌باز، به‌راحتی کسب درآمد کردند. این موفقیت‌های سریع باعث شد تا مایکروسافت (که زمانی دشمن اصلی اکوسیستم متن‌باز بود) به خرید شرکت علاقه‌مند شود. در این مطلب زومیت، به بررسی تاریخچه‌ی فعالیت این سرویس پرطرفدار می‌پردازیم. برای درک بهتر پیشرفت گیت‌هاب، بهتر است نگاهی به اکوسیستم توسعه‌ی نرم‌افزار در سال 2008 داشته باشیم. 2007 تا 2011: کدنویسی تیمی و نرم‌افزارهای اجتماعی
اگرچه استیو جابز و بیل گیتس به‌عنوان بزرگترین تأثیرگذاران در دنیای کامپیوترهای شخصی شناخته می‌شوند. پرداختن به این تاریخچه‌ی جذاب، بدون توجه به کارهای مهم بزرگانی همچون لینوس توروالدز، دور از انصاف است. توروالدز، مهندس نرم‌افزار فنلاندی بود که سیستم‌عامل محبوب لینوکس، محصول نوآوری‌های او است. لینوکس در سال 1991 عرضه شد و دوقطبی ویندوز / مک را به چالش کشید. این سیستم‌عامل متن‌باز، با سرعت بالا بین گیک‌‌های دنیای فناوری محبوب شد. افرادی که می‌خواستند کنترل بیشتری روی سیستم‌عامل خود داشته باشند.
عرضه‌ی یک سیستم‌عامل، برای بسیاری از افراد، بزرگترین کار زندگی خواهد بود اما توروالدز، با اکثر مردم فرق داشت. او پس از چند سال از توسعه‌ی لینوکس،‌ سرویس جدیدی برای کنترل نسخه‌های نرم‌افزارها با نام Git معرفی کرد. کنترل نسخه در پروژه‌های نرم‌افزاری تیمی بسیار مهم است. این فرآیند، تغییرات نسخه‌های مختلف را در فایل‌های کامپیوتری ذخیره می‌کند. گیت،‌بهترین راهکار کنترل نسخه در برنامه‌نویسی،‌ توسط توروالدز توسعه یافت
کنترل نسخه‌ی نرم‌افزار، شبیه به نقاط و موقعیت‌های Restore است که کامپیوترها ذخیره می‌کنند. این فرآیند، به افراد حاضر در تیم برنامه‌نویسی امکان می‌دهد تا بدون دخالت در کدهای یکدیگر، نسخه‌های خود را روی برنامه توسعه دهند. دو اصطلاح عمومی در این فرآیند، فورک کردن (Forking) و شاخه‌های مستقل (Branching) هستند. وقتی یکی از اعضا تغییرات لازم را در شاخه‌ی مخصوص خود انجام می‌دهد، می‌توان این شاخه را به کد اصلی بازگردانده و با آن ادغام کرد. این فرآیند با اصطلاح commit در گیت استفاده می‌شود. همان‌طور که گفته شد،‌ کار کردن روی شاخه‌های مستقل، هیچ تغییری در پروژه‌ی اصلی ایجاد نمی‌کند. پیش از عرضه‌ی گیت، برنامه‌نویسان برای همکاری‌های گروهی انتخاب‌های محدودی داشتند. یکی از این انتخاب‌ها با نام Subversion یک ابزار متن باز برای کنترل نسخه بود. این ابزار در آن زمان و حتی اکنون،‌بین برنامه‌نویسان مشهور است. البته کمبودهای ساب‌ورژن مختص آن نبود. در واقع همه‌ی ابزارهای این حوزه، کمبودهایی داشتند که ناشی از ذات برنامه‌نویسی گروهی و تیمی بود. در ابزارهای پیش از گیت، کسب اجازه از مدیر پروژه برای فورک کردن کد و کار روی نسخه‌ی مستقل، برخی اوقات زمانی بیش از نوشتن خود کد، طلب می‌کرد. این دشواری‌ها مشکلات متعددی را تیم‌های متن‌باز ایجاد می‌کرد و اکثر تلاش‌ها، بی‌فایده بود.
عرضه‌ی گیت در سال 2005 همزمان با رنسانس دنیای متن‌باز بود. در آن زمان استفاده از لینوکس به اوج محبوبیت خود رسیده بود و اولین نسخه‌های اپلیکیشن‌های وب 2 در حال انتشار بودند. بسیاری از شرکت‌ها، پروژه‌های خود را روی سرورهای متن‌باز منتقل می‌کردند. در آن زمان اگرچه گیت مشکل اصلی کدنویسی گروهی را با عرضه‌ی قابلیت فورک مطرح کرد، اما یک چالش بزرگ هنوز بر قوت خود باقی بود. برنامه‌نویس‌ها در پیدا کردن پروژه‌های متن‌باز مشکل داشتند. در واقع برنامه‌نویس‌های بسیار زیاد روی پروژه‌های بسیار متعدد و جذاب کار می‌کردند اما گویی کسی از دیگری خبر نداشت. پی‌جی و کریس پیش از صحبت در مورد پروژه‌ی خود، در وبسایت CNET مشغول به کار بودند. آنها از طرفداران پلتفرم برنامه‌نویسی Ruby on Rails بودند و در زمان کار در این وبسایت، بهبودهای متنوعی را به کد اصلی ریلز اضافه کردند. در این میان،‌ پیدا کردن کسی که کدهای آنها را بررسی کند، مشکل اصلی بود. مشکلات ارتباط و دموکراسی در جامعه‌ی برنامه‌نویسی هنوز وجود داشت
در آن زمان، ریلز نیز مانند بسیاری از پروژه‌های متن‌باز توسط گروه کوچکی اداره می‌شد که اضافه کردن و اعمال تغییرات جدید را به‌صورت دستی و سلیقه‌ای انجام می‌دادند. این برنامه‌نویس‌ها اصطلاحا دروازه‌بان پروژه بودند. پی‌جی و کریس تلاش‌های زیادی کردند تا دروازه‌بان‌های ریلز به کد آنها نگاه کرده و در صورت صلاحدید، آن را به پلتفرم اصلی اضافه کنند. حتی در صورت موافقت یکی از این دروازه‌بان‌ها، باز هم اضافه کردن کد جدید چالش‌های خاص خود را داشت. در واقع، همکاری در چنین پروژه‌هایی به‌جای معلومات برنامه‌نویسی، به آشنایی با تیم اصلی نیاز داشت.
گیت با هدف برطرف کردن برخی از این مشکلات به‌وجود آمد. این محصول توروالدز نیز مانند سیستم‌عاملش عالی و کاربردی بود. گیت به برنامه‌نویس‌ها اجازه می‌داد تا بدون درخواست رسمی، نسخه‌ای از کد اصلی پروژه‌ی متن‌باز را برای ویرایش دریافت کنند. به بیان دیگر، گیت اولین قدم‌ها در مسیر دموکراتیک شدن اکوسیستم برنامه‌نویسی را (خصوصا در جامعه‌ی متن‌باز) برداشت. البته گیت هم با تمام نقاط قوت، از کمبود ابزارهای همکاری تیمی رنج می‌برد. به‌علاوه، اشتراک کد بین دو برنامه‌نویس هنوز هم دشوار بود. تصور کنید تیم برنامه‌نویسی باید دائما بسته‌های کامل کد را برای یکدیگر ارسال می‌کردند. همین مورد ساده، نیاز شدید به گیت‌هاب در آن زمان را نشان می‌دهد. علاوه بر مورد بالا، گیت کمبود مهم دیگری هم داشت. این سرویس رابط کاربری نداشت و اساسا بر پایه‌ی خط فرمان عمل می‌کرد. این روش کار برای مدیران سیستم و کاربران حرفه‌ای خوب و مفید بود؛ اما کاربران دیگر از شرایط راضی نبودند. به‌هرحال پس از مدت کوتاهی اولین رابط‌های گرافیکی نیز برای گیت عرضه شدند. ورنر در مورد روزهای ابتدایی عرضه‌ی گیت می‌گوید: افراد در رویدادهای دورهمی روبی، در مورد گیت صحبت می‌کردند. آنها مجذوب امکانات این سرویس جدید بودند. البته هنوز کمبودهایی وجود داشت. گیت قرار بود به‌عنوان ابزاری برای کدنویسی به‌صورت غیرمتمرکز استفاده شود اما راهکاری برای حفاظت از کدهای خصوصی وجود نداشت. تنها راهکار، ساختن حساب‌های کاربری مجزا روی ماشین‌های یونیکس برای این منظور بود.
با تمام این کمبودها، ورنر که برنامه‌نویس روبی در منطقه‌ی Bay Area بود، ایده‌ی جالبی در مورد گیت پیدا کرد. ورنر در حال کار روی پروژه‌ای به‌نام Grit بود. این ابزار، به برنامه‌‌نویس‌ها امکان می‌داد تا با استفاده از روشی شئ‌محور و با بهره از روبی آن ریلز، به منابع کد پروژه‌های متن‌باز در گیت دسترسی داشته باشند. ورنر و وانستراث برای اولین بار یکدیگر را در یک باشگاه ورزشی ملاقات کردند. آنها در همان دیدار در مورد این پروژه با هم بحث و تبدل نظر کردند. گیت‌هاب یکی از بزرگترین مشکلات دنیای نرم‌افزار را هدف قرار داد
پرستون ورنر در این فکر بود که سرویسی برای ذخیره‌ی تمام کتاب‌‌خانه‌های برنامه‌نویسی توسعه دهد. برنامه‌نویس‌ها در این سرویس قابلیت همکاری در پروژه‌ها و یادگیری در مورد گیت را داشتند.پرستون ورنر همان‌جا نام Git hub را برای ایده‌اش انتخاب کرد. کار روی اولین نسخه از گیت هاب در یکم اکتبر سال 2007 شروع شد. در ساعت 10:24 جمعه، 19 اکتبر، وانستراث اولین کامیت را در گیت‌هاب ایجاد کرد و دنیای برنامه‌نویسی را تغییر داد. وقتی پرستون ورنر و وانستراث در سال 2007 کار روی پروژه‌ی گیت‌هاب را شروع کردند، به‌هیچ وجه هدفی برای تجاری کردن آن یا ایجاد کسب‌وکار با آن را نداشتند. آنها برای همکاری به این ابزار نیاز داشتند و به همین دلیل آن را توسعه دادند. نکته‌ی مهم در مورد راه‌حل این دو نفر آن است که تقریبا همه‌ی برنامه‌نویس‌ها صرف‌نظر از زبان و پلتفرم، مشکل مشابهی را تجربه کرده‌اند. در نتیجه‌ی این نیاز همگانی، پتانسیل بالای پروژه‌ی آنها بسیار زود روشن شد.
در هفته‌های بعد، ورنر و وانستراث در روزهای آخر هفته به بهبود پروژه‌ی خود می‌پرداختند. ورنر بخش‌های طراحی را بر عهده داشت و وانستراث ایده‌های مورد نظر او را پیاده‌سازی می‌کرد. ورنر در مورد آن ماه‌های اولیه می‌گوید: تا سه ماه پس از عرضه‌ی اولین نسخه، کریس و من زمان‌ زیادی را به برنامه‌ریزی و برنامه‌نویسی گیت هاب اختصاص می‌دادیم. من با استفاده از پروژه‌ی Grit، رابط کاربری را توسعه می‌دادم و کریس هم اپلیکیشن ریلز را پیش می‌برد. ما هر هفته شنبه‌ها جلسه داشتیم و تصمیمات طراحی و درآمدزایی را در آن جلسات نهایی می‌کردیم. سرانجام در ژانویه‌ی سال 2008 پس از ماه‌ها کار بی‌وقفه و جلسات و تبادل نظرهای دونفره، گیت‌هاب به‌صورت عمومی عرضه شد. این سرویس ابتدا به‌صورت آزمایشی و خصوصی ارائه شد. وانستراث و ورنر در ایمیل‌هایی به دوستانشان در سیلیکون ولی، از آنها در خواست کردند که از سرویس جدید استفاده کنند. پاسخ و نظرات افراد به این پروژه‌ی جدید، بسیار سریع، مثبت و امیدوارکننده بود. یک ماه بعد، GitHub به‌صورت رسمی به‌عنوان یک شرکت ثبت شد. نام شرکت ابتدا Logical Awesome بود که به گیت‌هاب تغییر کرد. اگرچه آن دو نفر ایده‌ی جدی برای تبدیل کردن پروژه‌شان به کسب‌وکار سودآور نداشتند؛ اما پتانسیل تجاری آن به‌حدی بود که کشش لازم را برای طرح درآمدزایی ایجاد کرد. در آوریل سال 2008، سه ماه پس از عرضه‌ی نسخه‌ی بتا و همزمان با انتشار رسمی سایت اصلی، جفری گروزنباخ بنیان‌گذار وبسایت آموزشی PeepCode پیامی برای کریس ارسال کرد. جفری در این پیام گفته بود که کدهای خود را به گیت‌هاب منتقل کرده است.
گروزنباخ فردی بود که با وجدان خود، روند درآمدزایی را به گیت‌هاب نشان داد. او به کریس گفت از این که به‌صورت رایگان از گیت‌هاب برای پروژه‌های شرکتی استفاده می‌کند، احساس خوبی ندارد. پیام‌های این‌چنینی در ماه‌‌های بعدی هم ارسال شدند که نشان‌دهنده‌ی ارزش بالای این سرویس بودند. کاربران فعال گیت‌هاب با وجود رایگان بودن سرویس ترجیح می‌دادند وجهی را به صاحبان سایت پرداخت کنند. بنیان‌گذاران ابتدا هیچ برنامه‌ای برای درآمدزایی از GitHub نداشتند
یکی از بزرگترین دلایل رشد گیت‌های، سادگی مدل کسب‌وکار آنها بود. اگر بخواهید کد خود را برای دسترسی عموم در این سرویس نگهداری کنید، استفاده از آن برای همیشه رایگان است. اگر پروژه‌ی شما خصوصی است، باید وجهی را پرداخت کنید. این دو نوع استفاده از گیت‌هاب کاملا مشخص و روشن هستند و مدل درآمدی ساده‌ای را ایجاد می‌کنند. این مدل، نسخه‌ی رایگان سرویس را بدون کم و کاست به کاربران عرضه می‌کند که محبوبیت آن را دوچندان کرده است. شرکت گیت‌هاب به‌سادگی می‌توانست سرویس‌های خود را به عضویت یا پرداخت حق ماهانه محدود کند. این روش، درآمد خوبی هم متوجه آنها می‌کرد اما به‌هرحال اجرا نشد. نکته‌ی مهم دیگر این مدل کسب‌وکار، سهولت در جابه‌جایی از مدل رایگان به مدل پولی سرویس است. درواقع، مدل درآمدی گیت‌هاب تنها مدل کسب درآمد از یک پروژه‌ی توسعه‌ی نرم‌افزار متن‌باز بود. اگر آنها از ابتدا همه‌ی منابع کد را به‌صورت پولی عرضه می‌کردند، هرگز چنین استقبالی از گیت‌هاب نمی‌شد. قطعا همان استقبال‌های اولیه از رایگان بودن سرویس‌ها، به محبوبیت امروز این شرکت منجر شده است.
نکته‌ی مهم دیگر در روند قیمت‌گذاری سرویس‌های گیت‌هاب، ماهیت آن بر مبنای وب بود. درواقع، میزبانی کدها در اینترنت ایده‌ی بسیار عالی بود اما بالاخره باید هزینه‌ی پهنای باند، پرداخت می‌شد. در اینجا، حرکت روزنباخ به‌عنوان اولین پرداخت‌کننده‌ی وجه به گیت‌هاب، شروع روندی از طرف دیگر شرکت‌ها برای پرداخت‌های بعدی بود. این پرداخت‌ها، بنیان‌گذاران را بر آن داشت تا سرویس خود را به‌عنوان کسب‌وکاری سودده بررسی کنند. وانستراث در مورد اولین ایده‌ها برای درآمدزایی از پروژه می‌گوید: در این موقعیت، با این نتیجه رسیدیم که گیت‌هاب علاوه بر تأمین هزینه‌های خود، قابلیت‌های دیگری هم خواهد داشت. می‌توانیم آن را به یک کسب‌وکار واقعی تبدیل کنیم. ما تصمیم گرفتیم که کتابخانه‌های عمومی را برای همیشه رایگان عرضه کنیم اما برای منابع خصوصی و شرکتی، مبلغی را به‌عنوان هزینه در نظر بگیریم. به بیان دیگر، ما از افرادی پول می‌گرفتیم که به پرداخت، تمایل داشتند. یپی‌جی هایت به‌عنوان هم‌بنیان‌گذار سوم در ژانویه‌ی سال 2008 به گیت‌هاب پیوست. تنها چند ماه بعد، در دهم آوریل سال 2008، گیت‌هاب به‌صورت رسمی رونمایی شد. تا سال 2009، رشد گیت‌هاب و استقبال از آن بسیار زیاد بود. ورنر در فوریه‌ی سال 2009 در کنفرانس مخصوص توسعه‌دهندگان در یاهو سخنرانی کرد. او از 46 هزار مخزن کد عمومی در گیت‌هاب گفت که 17 هزار عدد از آنها فقط در ماه ژانویه به سرویس پیوسته بودند. تا سخنرانی بعدی ورنر در یاهو یعنی آوریل آن سال، تعداد کاربران به 100 هزار و تعداد پروژه‌های عمومی به بیش از 90 هزار عدد رسیده بود. رشدی 95 درصدی تنها در 5 ماه.
نکته‌‌ی مهم در مورد رشد اولیه‌ی گیت‌هاب این است که این شرکت، در ماه‌های اولیه و تنها با تبلیغ‌های دهان به دهان، توانسته بود در کمتر از یک سال به 100 هزار کاربر برسد. گیت‌هاب به‌عنوان یک محصول از همان ابتدا اعتیادآور بود. دلیل آن نیز مشکل همگانی بود که گیت‌هاب حل می‌کرد. البته در آن زمان ابزارهای دیگر همکاری بر پایه‌ی گیت نیز وجود داشتند اما گیت‌هاب، بازار خود را با ساختن سرویسی بر پایه‌ی یک فناوری جذاب رو به رشد ساخته بود. مدل کسب‌وکاری دوگانه‌ی گیت‌هاب و محبوبیت در جامعه‌ی برنامه‌نویسان، رشد این شرکت را در سال‌های بعد تضمین می‌کرد. گیت‌هاب، حل چالش همکاری را در اولویت خود قرار داده بود و دسترسی به پروژه‌ها، فاکتور رشد آن بود. این سرویس، سرعت کار را با اهدای مجوز به همه‌ی کاربران برای فورک کردن پروژه‌ها، افزایش داد. درواقع، حل این مشکل تکینیکی در برنامه‌نویسی باعث شد تا فرهنگ همکاری نیز در جامعه‌ی برنامه‌نویس‌ها دچار انقلابی بزرگ شود. نیاز شدید بازار و محصول عالی، المان‌های اصلی موفقیت گیت‌هاب بودند
البته نیاز بازار و اعتیاد به محصول، تنها فاکتورهای رشد گیت‌هاب نبودند. درواقع، ماهیت اجتماعی این سرویس نیز در رشد آن بی‌تأثیر نبود. پیش از گیت‌هاب، برنامه‌نویس‌ها برای نشان دادن تخصص خود تنها به جلسات پرسش و پاسخ عمومی محدود بودند. با این سرویس، آنها کدهای خود را برای عموم و کارفرمایان احتمالی عرضه می‌کردند، به‌علاوه، شرکت در پروژه‌های بزرگ نیز ابزاری برای افزایش محبوبیت و تخصص میان برنامه‌نویس‌ها شد. این ماهیت اجتماعی، علاوه بر برنامه‌نویس‌ها به شرکت‌ها هم امکان داد تا متخصصان نرم‌افزاری خود را بهتر پیدا کنند. آنها با جستجو در مخازن عمومی کد، افراد بااستعداد را برای استخدام کشف می‌کردند. در 29 ژوئن سال 2010، گیت هاب قابلیتی با نام Organizations Feature اضافه کرد. این بخش به شرکت‌ها امکان می‌داد تا پروژه‌های گروهی را از یک پیش‌خوان واحد کنترل کنند. این قابلیت، پاسخی به نیازهای شرکت‌ها بود که در پیوستن به گیت‌هاب مردد بودند. به‌علاوه، برنامه‌های بلندپروازانه‌ی این پلتفرم همکاری نیز در این بخش جدید نمایان شد.
بنیان‌گذاران این سرویس تا سال 2010 مطمئن شده بودند که تنها راه درآمدزایی و آینده‌ی روشن برای این سرویس، عرضه‌ی آن برای شرکت‌ها و مشتریان تجاری است. یک سال بعد، نسخه‌ی نهایی این بخش با نان Enterprise عرضه شد. تا پایان سال 2011، گیت‌هاب بزرگانی همچون SourceForge، Google Code و Microsoft Codeplex را پشت سر گذاشته بود. آنها تا آن سال میزبان 2 میلیون مخزن کد بودند. در این میان عرضه‌ی قابلیت Enterprise نیز گیت‌هاب را هم برای برنامه‌نویسان شخصی و هم شرکت‌های بزرگ دنیای فناوری، به نیازی حتمی تبدیل کرده بود. این روند یعنی جذب و حفظ مشتریان درآمدزا، تمرکز اصلی Github در خلال سال‌های 2012 تا 2015 بود. نکته‌ی جالب توجه دیگر در مورد گیت‌هاب، رشد سریع آنها بدون جذب سرمایه‌ی خارجی بود. البته از سال 2012 اولین سرمایه‌گذار یعنی اندرسن هورویتز وارد شرکت شد. 2012 تا 2015: از رشد سریع تا گسترش جهانی
گیت‌هاب در سال 2012 به سرویسی بسیار مشهور تبدیل شده بود. این سرویس نه‌تنها بدون هیچ‌گونه جذب سرمایه یا تبلیغات،‌ به پایگاهی عظیم از مشتریان دست یافته بود، بلکه تعداد پروژه‌های خصوصی و شرکتی میزبانی شده در آن نیز روز به روز افزایش می‌یافت.
نیاز گیت‌هاب در آن سال‌ها، نفوذ بیشتر به فضای تجاری برای کسب درآمد بیشتر بود. اولین اقدام آنها، استخدام برایان دال بود که به‌عنوان معاون بازاریابی و استراتژی از فوریه ی سال 2012، مشغول به کار شد. قدم بعدی، جذب سرمایه‌ی 100 میلیون دلاری به‌عنوان مرحله‌ی اول جذب سرمایه بود که توسط شرکت اندرسن انجام شد. پرستون ورنر در مورد آن سال‌ها و استراتژی شرکت می‌گوید: ما یک برنامه‌ی مخصوص با نام GitHub Everywhere داشتیم. می‌خواستیم هر کس در صنعت نرم‌افزار، از گیت‌هاب استفاده کند. اشخاص، تیم های کوچک، دانشجویان و همچنین شرکت‌های معتبر و بزرگ، همگی هدف ما بودند. مرحله‌ی اول جذب سرمایه به گیت‌هاب فرصت داد تا مسیرش در رسیدن به هدف فوق را با سرعت بیشتری طی کند. آنها تا آن زمان 1.7 میلیون کاربر و 3 میلیون مخزن کد داشتند. به‌علاوه، درآمد گیت‌هاب از سال تأسیس به‌صورت سالانه 300 درصد رشد داشت. این رشد طبیعی آنها را به سمت جذب شرکت‌های بزرگ فهرست فورچن 500 سوق داد تا درآمدهای هنگفت سال‌های بعد را از طریق این شرکت‌ها تأمین کنند. در چند سال اول فعالیت، هیچ نیازی به جذب سرمایه وجود نداشت
بسیاری از کارشناسان و کارآفرینان، از جذب سرمایه‌ی گیت‌هاب استقبال کردند اما برخی دیگر، نگاهی انتقادی به سرازیر شدن پول به این سرویس داشتند. یک گروه کوچک اما تأثیرگذار از جامعه‌ی متن‌باز، جذب سرمایه‌ی خارجی توسط پروژه‌ی گیت‌هاب را نوعی خیانت به پایه‌ها و اصول متن‌بازی می‌دانست که این شرکت روی آنها بنا شده بود. درواقع، کشمکش‌ها پایه‌های متن‌باز گیت‌هاب و برنامه‌های آتی آن برای تبدیل شدن به ابزاری تجاری، نیاز به تعادلی دقیق در مسیر توسعه‌ی شرکت داشت.
انجام یکی از بزرگترین جذب سرمایه‌های تاریخ، آزادی عمل بیشتری را به گیت‌هاب می‌داد. البته این سرمایه، فشار بیشتری را نیز به شرکت وارد می‌کرد. شرکتی که پیش از آن نیز با هویت دوگانه‌ی خود دست به گریبان بود. گیت‌هاب تا سال 2012 رشدی عالی داشت و با جذب سریع کاربران، موفقیت‌های اولیه را بسیار زود کسب کرده بود. البته پس از مدتی مشخص شد که کار کردن با همان سرمایه‌های اولیه‌ی شخصی یا اصطلاحا مدیریت به‌صورت بوت‌استرپ، سقف مشخصی را برای رشد شرکت ایجاد می‌کند. در واقع برای حفظ سرعت پیشرفت و دسترسی به بازارهای بزرگتر، قطعا نیاز به سرمایه وجود داشت. جذب سرمایه‌ی 100 میلیون دلاری از اندرسن به آنها قدرت داد تا تیم مهندسی بزرگ‌تری برای تولید محصولات جدید تشکیل دهند. پس از ورود اولین سرمایه‌گذار، انتقادهای جامعه‌ی متن‌باز شروع شد
نکته‌ی جالب توجه این است که عدم جذب سرمایه در سال‌های اولیه، به‌خاطر تقابل سرمایه با اصول گیت‌هاب و اکوسیستم متن باز نبود. در واقع، آنها نیازی به سرمایه‌گذار خطرپذیر نداشتند اما از لحاظ اصولی و اخلاقی نیز اشکالی در این حرکت نمی‌دیدند. زمانی که این شرکت به جذب سرمایه اقدام کرد، پایگاه قوی مشتریان خود را ایجاد کرده بود. به‌علاوه، آنها از همان روز اول یک کسب‌وکار سودده بودند. این موارد به گیت‌هاب امکان می‌داد که نه‌تنها محصول خود، بلکه فرهنگ جامعه‌ی برنامه‌نویسی را نیز شکل دهد. پرستون ورنر در مورد جذب سرمایه برای شرکت می‌گوید: ما هنوز هم اعتقاد داریم جذب سرمایه‌ی زیاد و زودهنگام، برای شرکت‌ها مضر است. اثرات خارجی زیاد، برای شرکت خطرناک خواهد بود. ما اکنون 4 سال و نیم عمر داریم و به اندازه‌ی کافی، شخصیت خود را تثبیت کرده‌ایم. ما هیچ‌گاه با جذب سرمایه مخالف نبودیم بلکه ارائه‌ی محصول برای مقاصد اشتباه را نقد می‌کردیم.
به‌هرحال گیت‌هاب پس از جذب تعداد زیادی برنامه‌نویس و تیم‌های توسعه، رشد کافی را پیش از جذب سرمایه انجام داده بود. آنها مسیر و هدف خود را نیز به‌روشنی مشخص کرده بودند. هدف بعدی، نفوذ به بازارهای جدید و افزایش درآمدهای بالقوه بود. در این میان، مهم‌ترین المان در فرآیند جذب سرمایه‌ی گیت‌هاب، زبان ورنر در اعلام این تصمیم بود: شرکت ما برای سال‌ها، سودده بوده است و نیازی به پول ندارد. پس چرا این چالش را بپذیریم؟ چون ما می‌خواهیم بهتر باشیم. می‌خواهیم بهترین محصولات را بسازیم. می‌خواهیم مشکلات بزرگتر را حل کنیم. می‌خواهیم زندگی را برای مردم آسان‌تر کنیم. تجربه و منابع اندرسن به ما کمک می‌کند که به این اهداف برسیم. تمرکز اصلی صحبت‌های ورنر، حل مشکلات بود. با توجه به این صحبت‌ها، می‌توان سوء برداشت‌ها در مورد گیت‌هاب به‌عنوان یک محصول یا شرکت را برطرف کرد. گیت‌هاب برای ساده‌تر کردن کدنویسی برای برنامه‌نویس‌ها طراحی نشده است. در واقع این سرویس، برای ساده‌کردن کدنویسی برای همه توسعه یافت. گیت‌هاب در طول سال‌های فعالیت خود بسیاری از مشکلات بزرگ برنامه‌نویسی را حل کرده است. وانستراث و تیمش می‌توانستند از همان ابتدا تنها به مشکلات کوچک و جزئی توجه کنند. اما آنها چالش‌های بزرگ و اساسی این اکوسیستم را هدف قرار دادند و در نهایت، محصولی با پتانسیل رشد بالا، حول آن توسعه یافت. حل مشکلات جامعه‌ی برنامه‌نویسی،‌ هدف همیشگی گیت‌هاب بوده است
جذبه‌ی گیت‌هاب به‌سرعت از جامعه‌ی متن‌باز و عاشقان هک و برنامه‌نویسی فراتر رفت. جذب شرکت‌ها و سازمان‌های بزرگ، بسیار سریع انجام شد. تا سال 2013، اکثر شرکت‌های بزرگ سیلیکون ولی از گیت‌هاب استفاده می‌کردند. ادوبی، دراپ‌باکس، فیسبوک، گوگل، و توییتر، همگی مخازن کد اختصاصی خود را در گیت‌هاب داشتند. برخی شرکت‌ها مانند موزیلا، صدها مخزن کد در این سرویس داشتند و به‌تعریفی، همه‌چیز را در گیت‌هاب ذخیره می‌کردند. شرکت‌های دیگر مانند فیسبوک، مخازن کمتر اما با مشارکت بیشتر داشتند. 102 مخزن فیسبوک، 15 هزار فورک داشتند.
رشد سریع و محبوبیت گیت‌هاب باز هم ادامه داشت. تا سال 2015، آنها 2.8 میلیون کاربر و 4.6 میلیون مخزن کد داشتند. به‌هرحال با این که ریشه‌های شرکت در فرهنگ برنامه‌نویسی بود، چشم‌انداز آنها فراتر از این اکوسیستم ترسیم شد. مرحله‌ی بعدی رشد این شرکت، تبدیل شدن به بزرگترین هاب نرم‌افزارهای متن‌باز و در نهایت، ساخت پلتفرمی بود که به «فیسبوک توسعه‌دهندگان» تبدیل شد. نفوذ گیت‌هاب به سیلیکون ولی ختم نشد و آنها راه خود را به پایتخت آمریکا نیز باز کردند. در 9 می سال 2013، کاخ سفید «سیاست‌های رسمی ایالات متحده در برابر داده‌های آزاد» را در گیت‌هاب منتشر کرد. این اولین مرتبه‌ای بود که یک سیاست رسمی فدرال به‌این صورت منتشر می‌شد. اگرچه فایل‌های منتشر شده در مقایسه با پروژه‌های ذخیره شده در گیت‌هاب، استفاده‌ی آن‌چنانی نداشتند، اما نماد محمی محسوب می‌شدند. درواقع، میزبانی اسناد سیاست‌های دولتی در سرورهای یک شرکت خصوصی، حرکت جدیدی بود. به‌علاوه با این کار، امکان فورک کردن و تغییر این اسناد نیز برای عموم آزاد بود. بن بالتر، مدیر محصول گیت‌هاب در مورد آن اتفاق تاریخی گفت: این اقدام، اولین مرتبه‌ای بود که یک دولت، قانون را به‌صورت یک سند زنده و قابل همکاری منتشر می‌کرد. باید منتظر تغییر و تحولات جذاب در این سند باشیم که توسط جامعه ایجاد می‌شوند. امیدواریم که این حرکت، شروعی بر یک روند دائمی در این زمینه باشد.
به‌هرحال، این خبر به‌نوعی تبلیغات و روابط عمومی رایگان را برای گیت‌هاب انجام داد. به‌علاوه، با این کار کاربردهای جدیدی نیز برای گیت‌هاب روشن شد. کاربردهایی که برای سالیان دراز توسط فعالان حرکت آزادی داده، گوشزد می‌کردند. هرچند برخی از آن کاربردها هیچ‌گاه اجرایی نشدند. 2015 تا کنون: توسعه‌ی جهانی، گیت‌هاب به ایالت واشنگتن می‌رود
تا سال 2015، بسیاری از برنامه‌نویس‌ها از گیت‌هاب برای کنترل نسخه‌ی برنامه‌های خود استفاده می‌کردند. البته این سرویس، کاربردهایی فراتر نیز داشت. گیت‌هاب به پلتفرمی تبدیل شده بود که برنامه‌نویس‌ها در آنجا از یکدیگر نکات کاربردی یاد می‌گرفتند. به‌علاوه، این سروس به شبکه‌ی اجتماعی و محلی برای تبادل نظرهای حرفه‌ای نیز تبدیل شده بود. کاربرد مهم مهم دیگر، استفاده از این پلتفرم به محلی برای نمایش نمونه‌ کارها و رزومه‌ی برنامه‌نویسی بود. گیت‌هاب به محلی برای ذخیره‌ی کدهای مهم جهان تبدیل شده بود. از پروژه‌های برنامه‌نویسی شخصی تا پروژه‌های بزرگترین شرکت‌های فناوری جهان، در این سرویس حضور داشتند.
مانند هر شرکت بزرگ دیگر، گیت‌هاب نیز با بزرگ‌تر شدن، هدف مهمی برای مجرمان سایبری شد. در 28 مارس سال 2015، گیت‌هاب بزرگترین حمله‌ی سایبری تاریخ خود را تجربه کرد. گفته شد که این حمله‌ی DDoS،‌ از طرف چین برنامه‌ریزی شده است. البته این حمله، تلاش یک رقیب آسیایی برای به زانو در آوردن یک شرکت آمریکایی نبود. هدف اصلی، دو پروژه‌ی مهم در گیت‌هاب بودند. پروژه‌ی اول، GreatFire بود که به کاربران اینترنت در چین امکان می‌داد تا محدودیت‌های دولتی را دور بزنند. هدف بعدی، صفحه‌ی گیت‌هاب وبسایتی چینی و کپی نیویورک تایمز بود. این صفحه نیز به کاربران چینی امکان می‌داد تا با گذر از برنامه‌های نظارتی، به این رسانه دسترسی داشته باشند. اگرچه این حملات به سرعت خنثی شد، اما خطرات نگهداری آن حجم از کد و برنامه در یک مکان را به همه نشان داد. اولین دفتر بین‌المللی گیت‌هاب در توکیو ژاپن تأسیس شد
4 ماه پس از حمله‌ی دی‌داس چینی، مرحله‌ی دوم یا B جذب سرمایه برای گیت‌هاب به مبلغ 250 میلیون دلار و توسط Sequoia Capital انجام شد. این جذب سرمایه، ارزش گیت‌هاب را به بیشاز 2 میلیارد دلار رساند. وانستراث در مورد استفاده از این سرمایه‌های جدید، هدف آنها را سرمایه‌گذاری در بخش‌های دیگر، توسعه‌ی محصولات جدید و تلاش برای حضور بین‌المللی عنوان کرد. اولین دفتر بین‌المللی گیت‌هاب در توکیو تأسیس شد. انتخاب ژاپن به‌عنوان اولین مقصد خارجی توسط GitHub، استراتژی مهمی داشت. نه‌تنها ژاپن از لحاظ تولید ناخالص ملی، سومین اقتصاد جهان محسوب می‌شود، بلکه این کشور به نووری‌های فناورانه نیز مشهور است. این ویژگی‌ها، ژاپن را به بهترین مقصد برای شرکتی تبدیل کرد که قصد میزبانی از همه‌ی کدهای جهان را داشت. شرکت‌های بزرگ ژاپنی همچون هیتاچی و سایبرایجنت نیز جزو اولین مشتری‌های گیت‌هاب بودند.
توسعه‌ی گیت‌هاب باز هم ادامه پیدا کرد. آنها تا جولای سال 2015 بیش از 9 میلیون کاربر و 21 میلیون مخزن کد داشتند. در آن زمان، این سرویس به بزرگترین مخزن کد در جهان تبدیل شده بود. اگرچه رشد کاربران با سرعت خوبی ادامه داشت، ورود به بازارهای تجاری و جلب نظر شرکت‌ها، نقش اصلی را در حفظ درآمد دائمی GitHub ایفا می‌کرد. بیش از نیمی از شرکت‌های بزرگ و مشهور آمریکایی از گیت‌هاب استفاده می‌کردند. این وضعیت،‌ نمادی از چشم‌انداز پرستون ورنر با عنوان GitHub Everywhere بود. مقاله‌های مرتبط:
گیت هاب در برابر گیت لب؛ مقایسه دو سرویس رایج مدیریت مخزن گیت گیت لب به اندازه گیت هاب متن باز نیستo
البته گیت‌هاب با وجود رشد زیاد و جذب 10 هزار کاربر جدید در هر روز، از طرف رقبای قدرتمندی تهدید می‌شد. GitLab و Bitbucket بزرگترین رقبای این سرویس بودند که سرعت رشد کاربران گیت‌هاب را تحت تأثیر قرار می‌دادند. البته درآمد گیت‌هاب باوجود ظهور این رقبا باز هم به‌سرعت افزایش پیدا می‌کرد. درآمد این سرویس در سپتامبر سال 2015 حدود 90 و در سال بعد حدود 140 میلیون دلار گزارش شد. درآمد گیت‌هاب در دوره‌ی 23 ماهه از سپتامبر 2014 تا آگوست 2016، در بخش پروژه‌های شخصی رکود نسبی داشت. البته درآمد از بخش‌های Organization دوبرابر و از بخش Enterprise نیز حدود سه برابر شد. در سپتامبر 2014،‌ این بخش حدود 35 درصد از درآمد شرکت را تأمین می‌کرد که تا آگوست 2016 به بیش از نیمی از درآمد رسید.
تا سال 2017، وابستگی افزایش و حفظ درآمد به بخش‌های شرکتی و تجاری کاملا روشن شد. در آن زمان شایعه‌ی یک عرضه‌ی عمومی سهام (IPO) قوت گرفت. البته شایعات دیگر در مورد خرید یا ادغام با شرکت‌های دیگر نیز وجود داشتند. در نهایت در 4 ژوئن سال 2018، خبر بزرگ دنیای فناوری منتشر شد. مایکروسافت، گیت‌هاب را به قیمت 7.5 میلیارد دلار خرید. تنها در عرض چند ساعت، سرویس‌هایی مانند هکر نیوز، ردیت و تک‌درت مملو از نظرات و پست‌های کاربران عصبانی شد. آنها خرید گیت‌هاب را نوعی خیانت می‌دانستند. بسیاری از کاربران، برنامه‌هایی جامع برای ترک گیت‌هاب طراحی کردند. بسیاری از آنها فرآیند کوچ از گیت‌هاب به سرویس‌های رقیبت مثل گیت‌لب را شروع کرده بودند. فروش شرکت به مایکروسافت، شوک بزرگی به کاربران وارد کرد
کاربران با شنیدن این خبر، جوک‌هایی را از روی عصبانیت در مورد امنیت کدهایشان منتشر می‌کردند. به‌هرحال نگرانی بین اکثر کاربران وجود داشت. بسیاری از آنها این حرکت را شبیه خرید سان مایکروسیستمز توسط اوراکل و در اختیار گرفتن MySQL می‌دانستند. به‌هرحال در کنار تمام نگرانی‌ها و انتقادات، احساس عمومیِ، تیره و تار شدن آینده‌ی گیت‌هاب بود. البته، اکثر مردم متوجه این نکته نمی‌شدند که خرید گیت‌هاب در حال حاضر، تأثیری روی کلیت آن به‌عنوان یک محصول نخواهد داشت. گیت‌هاب برای مدت یک دهه به استارندارد صنعت برای توسعه‌ی نرم‌افزار به‌صورت گروهی تبدیل شد. قطعا گیت‌لب و بیت‌باکت تعدادی از کاربران ناراضی گیت‌هاب (به خاطر فروش به مایکروسافت) را جذب خواهند کرد اما موقعیت این سرویس و کاربرد آن نزد جامعه‌ی برنامه‌نویسی، ضامن موفقیت و رشد آتی آن خواهد بود.
به‌علاوه، تجربه‌ی مایکروسافت به‌عنوان یک سرویس‌دهنده‌ی تجاری، گیت‌هاب را به یک دارایی استراتژیک برای این غول دنیای فناوری تبدیل خواهد کرد. برای مایکروسافت، خرید گیت‌هاب به‌عنوان تصاحب یک محصول نیست. بلکه هدف اصلی، جذب اکوسیستمی است که با این سرویس همراه هستند. اکثر بحث و تبادل نظرهای آنلاین پیرامون هوشمندانه بودن یا نبودن خرید گیت‌هاب توسط مایکروسافت شکل می‌گیرد. سوال اصلی این است که ایا مایکروسافت از GitHub استفاده‌ی صحیحی خواهد داشت؟ خریدهای قبلی این غول فناوری یعنی لینکدین و ماین‌کرافت نشان می‌دهد آنها به این زودی‌ها ساختار GitHub را تغییر نخواهند داد. مقاصد بعدی GitHub
مقاله‌های مرتبط:
ارزش‌گذاری استارتاپ و درس‌هایی از خرید گیت‌هاب توسط مایکروسافت مایکروسافت تصاحب گیت هاب با پرداخت 7.5 میلیارد دلار را تایید کرد
اکنون که مایکروسافت به صاحب قدرتمند بزرگرین مخزن کد جهان تبدیل شده است، مسیر آینده‌ی گیت‌هاب به تصمیم‌گیری‌های این شرکت در زمینه‌ی رشد بلندمدت وابسته می‌شود. در این میان، برخی تصمیم‌گیری‌ها در مورد ادامه‌ی مسیر این سرویس، احتمال بیشتری دارد: 1- یکپارچگی با Visual Studio
کارشناسان معتقدند یکپارچه شدن گیت‌هاب با ویژوال استودیو، حرکت حتمی مایکروسافت خواهد بود. این مجموعه ابزار قدرتمند مایکروسافت برای توسعه‌دهندگان، پتانسیل بالایی را به گیت‌هاب می‌افزاید. این حرکت، در مسیر استراتژی‌های بزرگ‌تر مایکروسافت مبنی بر تغییر مسیر از فروش ویندوز به خدمات تحت ابر خواهد بود. 2- ابزارهای بیشتر برای توسعه‌دهدنگان
در حال حاضر هنوز هم برنامه‌نویس‌ها با مشکلات متعدد در نوشتن و توسعه‌ی کدهای خود روبرو هستند. ابزارهای متنوع برای بهبود تجربه‌ی کدنویسی، هماهنگی بیشتر با سرویس آژور یا روش‌هایی برای کشف بهتر خطاها، امکاناتی هستند که پتانسیل اضافه شدن به گیت‌هاب را دارند. در این میان ترکیب گیت‌هاب و مایکروسافت با تمرکز بر خدمات ابری، به توسعه‌ی این ابزارها کمک می‌کند.
3- خدمات و محصولات جانبی
GitHub در حال حاضر علاوه بر مهندسان نر‌م‌افزار، برای متخصصان دیگر از جمله مدیران محصول نیز کاربردی است. این سرویس در خدمات آتی خود می‌تواند قابلیت‌ها و کاربردهایی را مخصوص این متخصصان عرضه کند. به‌عنوان مثال ابزارهای مدیریت یکپارچه‌ی پروژه، یکی از این حرکت‌های احتمالی خواهد بود. این هدف، احتمال بالایی برای وقوع دارد؛ چرا که مایکروسافت نیز به‌روشنی به‌دنبال اجرای هرچه بیشتر اپلیکیشن‌های شرکتی و ابزارهای همکاری تیمی است. درس‌هایی از تاریخچه‌ی گیت‌هاب برای کارآفرینان
گیت‌هاب در نهایت به مقصد ردموند رسید و اکنون، عضوی از خانواده‌ی بزرگ مایکروسافت است. صرف‌نظر از آینده‌ی این سرویس محبوب، تاریخچه‌ی آن درس‌های بزرگی برای علاقه‌مندان به فعالیت در دنیای فناوری دارد. 1- مشکل بزرگی را برای حل کردن پیدا کنید
آسان‌تر کردن استفاده از گیت، یکی از اهداف GitHub بود؛ اما کار هیچ‌گاه به اینجا ختم نشد. مأموریت اصلی گیت‌هاب، تقویت همکاری و کدنویسی آسان‌تر بود. هر برنامه‌نویسی در جهان با مشکلاتی روبرو بود که گیت‌هاب قصد حل کردن آنها را داشت. این واقعیت، بازاری با پتانسیل بالا در اختیار این سرویس قرار داد.
اگر شما هم به فکر محصول یا خدمات هستید، پیش از انجام هر کاری این سوالات را از خود بپرسید: آیا محصول شما، مشکل اختصاصی گروه کوچکی از جامعه را حل می‌کند؟ یا مشکل مرسومی از جامعه‌ای بزرگ‌تر با آن حل می‌شود؟ تولید محصول احتصاصی امتیاز رقابتی خوبی است اما هدف قرار دادن مشکلات بزرگ و جامع، پتانسیل بازار را افزایش می‌دهد. آیا خود شما در کارهای روزمره از محصولتان استفاده خواهید کرد؟ بسیاری از شرکت‌ها فرهنگ استفاده از محصول خود را تشویق می‌کنند اما تعداد کمی از آنها این استراتژی را به عمل می‌رسانند. اگر خودتان از محضول استفاده نمی‌کنید، دلیل آن را پیدا کنید. آیا مشکل از محصول است یا چالش حل شده توسط آن ارتباطی با خود شما ندارد؟ هر دوی این سناریوها به نوبه‌ی خود خطرناک هستند. استفاده نکردن از محصول خود،‌ این سوال را ایجاد می‌کند که آیا محصول نهایی اصلا کاربردی هست یا خیر؟ اگر خود شما، مشکل حل شده توسط محصول را تجربه نکرده‌اید، چگونه می‌توانید به بهترین شرکت برای ارائه‌ی راه‌حل تبدیل شوید؟ 2- حل مشکلات بزرگ را برنامه‌ی همیشگی خود بکنید
یکی از فاکتورهای موفقیت ادامه‌دار گیت‌هاب، نه‌تنها تمرکز روی حل مشکلات بزرگ،‌ بلکه تلاش دائمی برای رفع چالش‌های همیشگی و دردناک اکوسیستم استارتاپی محسوب می‌شد. این تلاش همیشگی، پتانسیل دست‌یابی به پایگاه بزرگ مشتریان را در مدل کسب‌وکار آنها ایجاد کرد. پیشنهاد می‌شود شما هم در مورد محصول و خدمات خود این تصورات را داشته باشید: قابلیت‌های جدید محصول یا خدمات شما، چه مشکلاتی را حل خواهند کرد؟ چرا این ویژگی در حال حاضر در محصول وجود ندارد؟ آیا بلندپروازانه یا سخت است؟ چگونه با چالش‌های توسعه‌ی این قابلیت روبرو می‌شوید؟ چه عاملی موجب دردناک شدن و مهم شدن این مشکل شده است؟ آیا مشکل موجود ناشی از کمبودهای انسانی یا فنی است؟
3- توسعه‌ی سریع و بهینه‌ی فرهنگ سازمانی
گیت‌هاب در روزهای ابتدایی خود به اهمیت فرهنگ سازمانی پی برد. این شرکت با قدرت فرهنگ خود را توسعه داد. فرهنگ سازمانی نه بر اساس محصول بلکه بر اساس تصمیم‌ها و عملکرد مدیران در تصویب قوانین شکل می‌گیرد. در مورد فرهنگ سازمانی شرکت خود به این سوال‌ها پاسخ دهید: فرهنگ سازمانی شما، چگونه نمایان‌گر ارز‌ش‌های سازمان خواهد بود؟ گیت‌هاب از همان روزهای ابتدایی با برنامه‌های متنوع و حتی طراحی دکوراسیون دفتر، فرهنگ همکاری و عدم وجود سلسله‌مراتب سنتی را به روشنی نشان داد. کارمندان در چه زمینه‌هایی فرهنگ شرکت را تشکیل می‌دهند؟ به‌بیان دیگر، چه مقدار از فرهنگ سازمانی به‌خاطر قوانین دیکته شده و چه مقدار متأثر از استخدام‌ها خواهد بود؟ رقبا، شرکت و محصول شما را چگونه می‌بینند؟ چه‌مقدار از این تصور وابسته به فرهنگ سازمانی است؟ در پایان یادآور می‌شویم که گیت‌هاب با دو رویکرد به موفقیت سریع رسید. حل مشکل عمومی و بزرگ جامعه‌ی هدف و ساخت محصولی که نیاز به استفاده از آن، همیشگی باشد. شاید مایکروسافت به‌عنوان یکی از مخالفان سنتی جامعه‌ی متن‌باز، خانه‌ی خوبی برای GitHub نباشد اما تلاش‌های این غول دنیای فناوری برای عرضه‌ی هرچه بیشتر و بهتر خدمات تجاری و تمرکز بر محصولات شرکتی، می‌تواند برای آینده‌ی گیت‌هاب مسیری روشن ایجاد کند. در پایان باز هم به سوال اصلی می‌رسیم: مایکروسافت با این اسباب‌بازی جذاب و گران‌قیمت خود چه کاری انجام خواهد داد؟