سه سال و نیم قبل، سی تی او آژر – کلاود مایکروسافت – گفته بود که «یک چهارم ماشین های آژر لینوکس هستند». بعد توی سال ۲۰۱۷ مایکروسافت گفت که ۴۰٪ ماشین های مجازی ساخته شده روی آژر، لینوکس هستند. در ۲۰۱۸ اعلام شد که این عدد تقریبا نصف ماشین ها است و حالا ساشا لوین که توسعه دهنده کرنل لینوکس در مایکروسافت است، در درخواست خودش برای عضویت مایکروسافت در لیست سکیوریتی کرنل لینوکس، نوشته که «استفاده از لینوکس در کلاود ما از ویندوز بیشتر شده».

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

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

منبع

اخبار اوپن سورس از مایکروسافت زیاد به گوش می‌رسه و حالا هم کد ماشین حساب ویندوز رو روی گیت هاب گذاشته، اونم با مجوز MIT که حتی از مجوزهای بازی که تبلیغشون می کنیم هم بازتره. با اینم جوز شما حق دارین این سورس رو بردارین،‌ تغییر بدین، ببندین و فایل اجرایی نهایی رو به اسم «ماشین حساب ملی» منتشر کنین و از نظر لایسنسی هیچ خلافی هم نکرده باشین.

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

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

این احتمالا هم تجربه خیلی خوبی از بازمتن کردن یک برنامه مایکروسافت است و هم فرصتی خیلی خوب برای کسانی که می‌خوان سورس یک برنامه حرفه‌ای رو بخونن یا حتی بهش کامیت کنن و اینطوری اسمشون رو در تاریخ ویندوز و مایکروسافت ثبت کنن یا حتی احتمالا با درخشش طولانی مدت‌تر، فرصت کاری به دست بیارن.

منبع اصلی

آلمانی ها یه جشن به اسم اکتبرفست دارن که تو تبلیغات این شکلی است:

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

بعد از ثبت نام در سایت هکتبرفست در طول ماه اکتبر ۵ تا پول ریکوئست به پروژه‌های دیگران در گیت‌هاب بفرستین و یکی از دریافت کننده‌های ۵۰هزار تی‌شرت ایونت بشین؛ به همراه استیکرها و از همه مهمتر، سابقه ۵ تا پول ریکوئست

معلومه که اولین سوال‌های خیلی‌ها اینه که «نمی شه به خودمون/دوستمون پول ریکوئست بدیم؟» جواب اینه که احتمالا با کمی تقلب می شه ولی خب چه کاریه. مساله اصلی هکتبرفست اینه که آدم‌ها رو درگیر پروژه‌های دیگران بکنه و یاد بگیریم مشارکت کنیم و کارهای مثبت بکنیم.

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

اگر تازه کار هستین جاهایی مثل این و این می تونن جاهای خوبی برای پیدا کردن اولین مشارکت های شما باشن.

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

آپدیت:
اینجاها هم برای پیدا کردن اولین باگ ها خوبن:
– فهرستی از باگ های خوب برای تازه کارها
– سرچ گیت هاب برای باگ های مناسب تازه کارها بر اساس زبان

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

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

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

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

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

الان مدتی است که از zsh استفاده می‌کنم. خوبی اصلی زد اس اش برای من اینه که تا حد خیلی زیادی همون bash است با چند فیچر بهتر. مثلا توی تکمیل کردن دستورات با tab بسیار بهتر عمل می کنه می شه توش چیزها رو خلاصه‌تر نوشت. هیستوری توش راحتتر پیدا می شه و حتی می‌شه با تب، سوییچ ها رو دید. چیزی که بارها برای من توی بش پیش می‌امد این بود که دستور رو نصفه می‌نوشتم، می‌اومدم بیرون و سوییچ رو نگاه می‌کردم و بر می‌گشتم به دستور اما حالا به راحتی با زدن tab سوییچ‌ها دیده می‌شن.

این شل امکان تنظیمات زیادی داره ولی تقریبا بهترینشون برای شروع در پروژه ای به اسم oh my zsh جمع شده. برای اضافه کردن زیشل به سیستم و انتخاب اون به عنوان شل خودتون باید اول zsh رو نصب کنین، مثلا با یکی از دستورات زیر:

sudo apt install zsh #debian, Ubuntu, Ming
sudo yum install zsh #fedora, centos, redhat
sudo zypper install zsh #openSuse

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

sudo usermod -s /usr/bin/zsh jadi

تنظیمات عالی «اوه مای زیشل» رو هم می‌تونین با این یک دستور نصب کنین:

sh -c "$(wget https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh -O -)"

و به قابلیت‌های جالبی مثل اینکه در یک دایرکتوری گیت برنچ دیده بشه یا یک فلش سبز یا قرمز به شما بگه دستور قبلی درست اجرا شده یا نه دست پیدا کنین.

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

اشاره: متن پیش رو برگردان پستی است که Tom Preston-Werner در وبلاگش با عنوان Open Source (Almost) Everything منتشر کرده و به جهت اهمیت مطلبی که در آن بیان کرده، نظیر ترس کسب‌وکارها از منبع باز کردن محصولات‌شان، مرور آن ضروری می‌نماید. او در این نوشته توضیح می‌دهد که چرا و چگونه بر ترس متن‌باز کردن نرم‌افزارهای‌شان غلبه کرده و به سمت ایجاد کسب‌وکاری بر مبنای نرم‌افزارهای متن‌باز حرکت کردند. این متن را امیرپوریا مهری ترجمه کرده و من در جادی.نت بازنشرش می‌کنم. شاید من در مورد جزییات یا حتی استفاده از عباراتی مثل «بازمتن» در مقابل «آزاد» نظرات متفاوتی داشته باشم ولی در کل خوندن این مطلب بسیار راهگشا است.

در اواخر سال ۲۰۰۷، من و کریس (Chris Wanstrath) شروع به کار بر روی گیت‌هاب کردیم، کار به دو قسمت تقسیم شد: کریس بر روی توسعه‌ی برنامه‌های Rails متمرکز بود و من روی Grit کار می‌کردم که نخستین Git‌ نوشته شده بر پایه‌ی Ruby بود. پس از شش ماه توسعه، Grit به اندازه‌ی کافی آماده بود تا قدرت‌بخش گیت‌هاب شود و سایت را به انتشار عمومی دربیاوریم. در همین حال ما با سوال جالبی مواجه شدیم:

بهتر است Grit را متن‌باز کنیم و یا این که کدهای آن را به صورت اختصاصی نگه داریم؟

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

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

چرا متن‌باز کردن (تقریبا) همه‌چیز این‌قدر هیجان‌انگیز است؟

اگر آن را به شیوه‌ی درست انجام دهید، کدهای متن‌باز تبلیغ بزرگی برای خود و شرکت‌تان خواهد بود. در گیت‌هاب دوست داریم درباره‌ی کتابخانه‌ها و سیستم‌هایی که کدهای آن را زده‌ایم و هنوز متن‌بسته‌اند، ولی تصمیم داریم آنها را متن‌باز کرده، به‌طور عمومی بحث کنیم. این شگرد چندین مزیت در خود دارد. از جمله کمک می‌کند تا تععین کنیم چه چیزی را باید متن‌باز کرده و اهمیت آن برای ما چقدر است تا در اولویت کاری انتشار قرار دهیم. ما اخیرا Hubot، چت‌بات‌مان را منبع باز کردیم؛ تا شمار زیادی را خوشحال کنیم. در عرض دو روز ۵۰۰ نفر در گیت‌هاب به بررسی آن پرداختند و ۴۰۹ رای مثبت در وب‌سایت Hacker News نصیب این برنامه شد. این کار نزد مردم به حسن‌نیت گیت‌هاب ترجمه می‌شود و موجب افزایش شمار طرافداران دو‌آتشته برای ما شد.

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

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

اگر به دنبال استخدام هستید، بهترین مصاحبه‌ی فنی ممکن، این است که اصلا صورت نگیرد؛ چرا که داوطلب پیش از این در یکی از پرو‌ژه‌های منبع باز شما دست برده است. هنگامی که برتری فنی در چنین مسیری تثبیت شود؛ تمام آنچه باقی می‌ماند، بررسی این است که آیا فرد به فرهنگ شرکت‌تان می‌خورد یا نه و سپس مرحله‌ی متقاعد کردن او تا برای‌تان کار کند. اگر آنها درباره‌ی کدهای متن‌باز-ای که نوشته‌اند مشتاق باشند؛ و شما از شمار شرکت‌هایی باشید که به کدهای تمیز اهمیت می‌دهد (که باید باشید) این فرایند (استخدام) باید ساده باشد. ما Vicent Martí را پس از این‌که کارهای درخشان او را روی کتابخانه ی libgit2 دیدیم، استخدام کردیم. پروژه‌ای که در گیت‌هاب رهبری‌اش می‌کنیم تا قابلیت‌های اصلی Git‌ را بر روی کتابخانه‌ی مستقل C ببریم. مصاحبه ی فنی نیاز نبود. Vicent مهارت‌های اش را از طریق کدهای متن‌باز-اش به اثبات رسانیده بود.

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

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

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

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

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

خب، پس چه موقع نباید نرم‌افزارم را متن‌باز کنم؟

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

• هسته‌ی برنامه‌ی اصلی مبتنی بر Rails گیت‌هاب (وقتی متن‌بسته است راحت می‌توانید آن‌را بفروشید)
• برنامه‌ی Jobs Sinatra (ساخته شد تا در گیت‌هاب دات کام ادغام شود)

این هم تعدادی نمونه از چیزهایی است که متن‌باز کردیم به همراه دلیل آن:

• Grit (Git bindings همه منظوره، مفید برای ساختن ابزارها)
• Ernie (BERT-RPC سرور همه‌منظوره)
• Resque (job processing همه‌منظوره)
• Jekyll (صفحه استاتیک‌ساز همه‌منظوره)
• Gollum (ویکی اپ همه‌منظوره)
• Hubot (چت‌بات همه‌منظوره)
• Charlock_Holmes (character encoding detection همه منظوره)
• Albino (syntax highlighting همه‌منظوره)
• Linguist (filetype detection همه‌منظوره)

توجه کنید که هر چیزی را که متن‌بسته نگه داشتیم، ارزش کسب‌وکار (business value) خاص ما بود که می‌تواند با در دست رقبای‌مان قرار گرفتن، کسب‌وکارمان را به خطر بیاندازد. هر چیزی را که متن‌باز کردیم، ابزاری همه‌منظوره است که می‌تواند توسط عموم مردم و شرکت‌ها برای ساختن همه نوع چیزی استفاده شود.

مجوز درست حسابی کدام است؟

من مجوز MIT را ترجیح می‌دهم و تقریبا تمام چیزهایی که در گیت‌هاب متن‌باز کردیم با این مجوز منتشر شدند. من این مجوز را به چندین دلیل دوست دارم:

• کوتاه است. هر کسی می‌تواند متن این مجوز را مطالعه کرده و بفهمد دقیقا چه می‌گوید بدون این‌که نیاز باشد با پرداخت حق مشاوره، وکلا را پول‌دارتر کند.
• به اندازه‌ی کافی از کدنویس حمایت می‌کند تا مطمئن باشم اگر کد به درستی کار نکرد، از من شکایت نمی‌شود.
• هر کسی پیامدهای قانونی مجوز MIT را می‌فهمد. مجوزهای عجیب-و-غریب مثل WTFPL و Beer تظاهر می‌کنند که در میان مجوزهای آزاد بهترین هستند، اما کاملا در این هدف شکست خورده‌اند. این مجوزهای حاشیه‌ای بیش از حد مبهم و غیرقابل اجرا هستند تا برای استفاده در شرکت‌ها قابل قبول باشند. در سوی دیگر، مجوز GPL‌ بیش از اندازه محدود شده و متعصبانه است تا قابل استفاده برای عموم کارها باشد. من می‌خواهم همه بتوانند از کدهایم بهره‌مند شوند، «همه». این چیزی است که از واژه‌ی «باز» و «آزاد» تداعی می‌شود.

خب، حالا می‌پرسید چگونه آغاز کنم؟

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

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

سال‌های سال است که تعداد توسعه دهندگان مستقل (فردی/بدون حقوق) لینوکس با کاهشی پایدار مواجه بوده. در ۲۰۱۲ این عدد ۱۴.۶ درصد بود، در ۲۰۱۳ برابر ۱۳.۶ درصد و در ۲۰۱۴ تعداد توسعه دهندگان مستقل به ۱۱.۸ رسید. اما حالا این عدد روی ۷.۷ درصد ایستاده. این سقوط دائمی دلایل متنوعی داره اما حتما منطقی‌ترین دلیل ساده‌ترین اونها است: توسعه‌دهندگان کرنل کم هستن و هر کسی که بتونه نشون بده کد نوشته شده توسط خودش می تونه به کرنل برسه، در پیدا کردن شغل هم مشکلی نخواهد داشت.

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

در این دوره ۹ ورژن جدید کرنل منتشر شده و عدد اصلی ورژن از ۳ به ۴ تغییر کرده که نشون دهنده هیچ چیز خاصی هم نیست و فقط نشون دهنده این است که هر کرنل جدید تغییراتی داره که دیگه تفاوت خاصی بین عدد اصلی و عدد کوچیک رو لازم نمی‌کنه.

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