رحلة Oh My Zsh: من إعداد شخصي إلى مشروع مفتوح المصدر عملاق

رحلة غير متوقعة لمشروع مفتوح المصدر عملاق

لم تكن هذه أولى مغامراتي في عالم البرمجيات مفتوحة المصدر، ولن تكون الأخيرة. كان صيف عام 2009، ووجدت نفسي أساعد زميلاً في العمل على تصحيح خطأ ما في طرفيته (terminal). بينما كنت أحاول كتابة بضعة أوامر، لاحظت أن موجه الأوامر (prompt) لا يستجيب للاختصارات التي اعتاد عليها عقلي. شعرت بالإحباط وصحت قائلاً: “متى ستتحول أخيراً إلى Zsh؟!” (نعم، كنت من ذلك النوع من الزملاء المزعجين الذي يشير باستمرار إلى أن X أفضل من Y متى سنحت الفرصة. بالنظر إلى الوراء، لا أعرف كيف تحملوني… ولكن بيني وبينك، كان لدي وجهة نظر صحيحة).

في تلك المرحلة، كنت مستخدماً يومياً لـ Zsh لأكثر من ثلاث سنوات بقليل. شارك بعض أصدقائي في مجتمع #caboose بعض إعدادات ملفات .zshrc الخاصة بهم ضمن قناتنا على IRC. بعد بضع سنوات، نما ملف .zshrc الخاص بي ليصبح عش فئران متشابكاً. بصراحة، لم أكن أعرف ما يفعله حوالي 30% من تلك الإعدادات. لكنني وثقت بأصدقائي بما يكفي لأستمر في استخدامها.

ما كنت أعرفه هو أن لدي بعض تفاصيل فرع git وحالته، وتمييز الألوان لبعض الأدوات (مثل grep)، وإكمال مسارات الملفات تلقائياً عبر اتصالات SSH، ومجموعة من الاختصارات لـ Rake و Capistrano. كان العمل على جهاز بملف Bash افتراضي يبدو عتيقاً بشكل ملحوظ؛ لقد أصبحت معتمداً على هذه الاختصارات.

ولادة Oh My Zsh: من الفوضى إلى التعاون

كان بعض زملائي سعداء بنسخ ولصق ملف .zshrc الذي شاركته والبدء في استخدامه. لكن آخرين رفضوا لأنهم كانوا يعلمون أنني لا أعرف ما تفعله بعض أجزائه. وهذا منطقي تماماً. بعد بضع محاولات لتحويلهم دون جدوى، اخترت نهجاً مختلفاً. أولاً، أعدت تنظيم إعدادات .zshrc الخاصة بي، وتضمن ذلك تقسيمها إلى مجموعة من الملفات الأصغر. كان تفكيري هنا أن هذا سيساعدني (أ) على فهم أفضل لكيفية عمل كل هذه الأجزاء، بينما (ب) يساعد في تثقيف زملائي عندما يقرأون الكود.

استباقاً لسؤالهم التالي: “كيف أجعل هذا يعمل على جهازي؟”، قمت بصياغة أول تعليمات الإعداد. والأهم من ذلك، قمت بتجميع كل هذه الملفات في مستودع git جديد ومميز. تصورت أنه إذا رفعته على Github، فسيتمكن زملائي من التعاون معي في تحسينه. ورغم أنها لم تكن قفزة هائلة، إلا أنها كانت خطوة أفضل من دعوة الناس لنسخ ولصق ملف نصي من Pastie. في 28 أغسطس 2009، ولد مشروع Oh My Zsh.

…ولكن، انتظر دقيقة! أين السمات (themes)؟ أين الإضافات (plugins)؟ نصوص التثبيت (installation scripts)؟ الشعار (logo)؟ قد يكون هذا مفاجئاً لمعظم مستخدمي Oh My Zsh، لكن لم تكن أي من هذه الميزات ضمن اعتباراتي. كان هدفي من المشروع ليس بناء إطار عمل لصيانة إعدادات Zsh، بل مشاركة إعداداتي الخاصة مع زملائي حتى يستخدموا Zsh.

في غضون يوم واحد من مشاركته مع جميع زملائي، انتقل الجميع من Bash إلى Zsh. انتصار! …أو هكذا ظننت.

تطور غير متوقع: السمات، المثبتات، والتحديثات التلقائية

السمات: استجابة لحاجة المستخدمين

جاء أول طلب ميزة في اليوم التالي: “كيف يمكنني تخصيص موجه الأوامر (prompt) الخاص بي؟” سألني اثنان من الزملاء كيف يمكنهم تخصيص موجه الأوامر الخاص بهم. أرادوا تغيير الألوان والمعلومات المعروضة. ما هذا بحق الجحيم؟! ألم يكن موجه الأوامر الخاص بي مقنعاً بما فيه الكفاية لهم؟ يا لهم من مدققين! 😉

أشرت إلى ملف prompt.zsh وقلت لهم يمكنهم تعديله. سرعان ما أصبح هذا مشكلة حيث أصبح لديهم الآن نسختهم الخاصة من هذا الملف. ونتيجة لذلك، أضاف هذا بعض التعقيد إذا أردنا جميعاً مشاركة بعض اختصاراتنا وميزاتنا، حيث كان علينا التعامل مع التعارضات. هممم…

لذا، بعد يوم واحد من الإعلان الأول عن Oh My Zsh على مدونتي، بدأت في تقديم المفهوم الأولي للسمات (themes). هكذا قدمنا سمة robbyrussell “الشهيرة” للعالم. في هذه الأثناء، تلقيت أول طلب سحب (pull-request) خارجي من Geoff Garside لإضافة بعض الأسماء المستعارة (aliases) لـ TextMate. (لاحظ كيف ذهب ذلك مباشرة إلى ملف aliases.zsh الشامل).

بعد يوم واحد، تم إرسال سمة أخرى. رائع، من الأفضل أن أضيف رابطاً في ملف README لرؤية بعض لقطات الشاشة على الويكي. في غضون شهر، كان لدينا عشرات السمات المساهم بها في المشروع. بدأ هذا يصبح جانباً شائعاً جداً في Oh My Zsh، وكان علينا البدء في كبح قبول السمات بمجرد تجاوزنا 100 سمة (نحن حالياً عند حوالي 140 ونادراً ما نقبل سمات جديدة).

تبسيط الإعداد باستخدام المثبت (Installer)

خطر ببالي أن الإعداد الأولي كان يتطلب من الأشخاص تشغيل مجموعة من الأوامر. بدلاً من مطالبة الأشخاص بإعادة كتابة و/أو نسخ ولصق مجموعة من الأوامر، شعرت أنه سيكون أكثر كفاءة للطرفين (حيث سيقلل ذلك من الأسئلة التي قد يطرحها زملائي عندما يواجهون مشكلة و/أو يتخطون خطوة). وهكذا ولد المثبت (installer).

# The initial installer script (view on github) - This is a placeholder for the actual script if it were provided.

كانت أفكاري الأولية هي توفير بعض الخطوات على المستخدمين عن طريق أتمتة المثبت. إذا قام الجميع بتشغيل نفس الأوامر، فيمكننا تقليل الأخطاء البشرية (تخطي أمر، أخطاء إملائية، وما إلى ذلك). أردت أيضاً أن أضع في اعتباري أن الأشخاص قد ينتقلون إما من Bash أو من إعداد Zsh موجود ومجمع. لمساعدتهم في العودة المحتملة إلى الصدفة السابقة (previous shell)، قمنا بعمل نسخة احتياطية من ملف الإعداد الأصلي الخاص بهم. أخيراً، كنا نقوم بتبديل صدفة الأوامر الافتراضية (default shell) الخاصة بهم إلى Zsh. “مرحى! تم تثبيت Oh My Zsh.”

أوه، صحيح. كيف سيتمكن الأشخاص من البقاء على اطلاع دائم بالتغييرات الجديدة في المشروع؟ في اليوم التالي، أضفت نصاً برمجياً للترقية (upgrade script) ينتقل إلى دليل Oh My Zsh، يجلب التحديثات من مستودع git، ويعيدك إلى دليل العمل السابق الخاص بك. لم يكن الأمر علماً صاروخياً.

بعد حوالي ثلاثة أسابيع، أصبح من الواضح أن زملائي لم يكونوا يواكبون يدوياً جميع التحديثات الجديدة للمشروع. بدلاً من تذكيرهم بذلك من وقت لآخر، أضفت وظيفة تطلب من المستخدم بشكل دوري التحقق من وجود تحديثات. حتى هذه النقطة، كان هذا يبدو كأكثر جزء معقد من الكود في المشروع. أتمنى لو كنت أتذكر من أعطاني الفكرة الرائعة لاستخدام قيمة epoch هنا.

# The initial auto-updater (view on github) - Placeholder for actual script.

في رأيي، كانت هذه أيضاً نقطة تحول للمشروع. بينما كان عدد قليل من الأشخاص يستخدمونه، فإن هذه الوظيفة ستسمح لجميع المستخدمين تقريباً بالبقاء على اطلاع دائم بتغييرات المشروع، والأهم من ذلك، البقاء منخرطين. عندما يقومون بتشغيل المحدث، سيرون قائمة بالملفات التي تم تغييرها، وهذا سيقدم لهم، بمهارة، ميزات جديدة… على سبيل المثال، “أتساءل كيف تبدو تلك السمة…”

للأسف، لم يكن الجميع من المعجبين. على الرغم من وجود عدد قليل من المعارضين الصريحين على مر السنين، فقد تمسكت بقراري بإبقاء هذا إعداداً افتراضياً. في عام 2012، أجرينا تغييراً لتقليل تكرار مطالبات التحديث التلقائي بنسبة 50%. لقد سمح لنا التحديث التلقائي بشحن ميزات جديدة، وتحسينات في الأداء، وإصلاحات للأخطاء دون الاعتماد على قيام الجميع بذلك يدوياً. أنا مقتنع بأن هذه الميزة ساعدت في إبقاء المجتمع منخرطاً.

لمسة جمالية: الشعار والإضافات (Plugins)

بينما كان المشروع يجذب الكثير من السمات، شعرت حقاً أن المشروع يمكن أن يستفيد من العلامة التجارية (branding). كان حلي؟ فن Ascii art. ليس لدي أي فكرة عما دفع رسالة git commit تلك. كانت عملية تفكيري هنا… بالتأكيد، تحصل على مجموعة من الاختصارات والسمات المفيدة عندما تبدأ في استخدام Oh My Zsh، لكنني شعرت حقاً أن الانطباع الأول بعد تشغيل المثبت كان فرصة لإسعاد المستخدمين الجدد. “رشات الحلوى على الكعكة”… كما كانت. (ليس لدي أي ذكرى لماذا كتبت رسالة commit تلك في ذلك الوقت. المرجع مفقود بالنسبة لي).

ما يعرضه نص التحديث حالياً.

لطالما طلب مني الناس طباعة قمصان بفن ascii art هذا لبعض الوقت. (من المحتمل أن نفعل ذلك هذا الصيف).

نظام الإضافات (Plugins)

بعد عشرة أشهر من إطلاق المشروع كمفتوح المصدر، بدأ المستخدمون في طلب القدرة على عدم تحميل كل شيء. على سبيل المثال، قد لا يحتاج مطور Python إلى الأسماء المستعارة (aliases) المتعلقة بـ Rake و Capistrano ليتم تحميلها كما يفعل مطور Ruby. لذلك، قمنا بتطبيق نظام إضافات (plugin system) أساسي يسمح للأشخاص بتحديد ما يتم تحميله عند التهيئة عن طريق تغيير قيمة في ملف .zshrc.

عندما تم إصدار هذه الميزة، تم تجميع خمس إضافات. في غضون بضعة أشهر، بدأت أتلقى طلبات سحب (pull requests) لأفكار إضافات جديدة. في غضون عام، كنت قد قبلت أكثر من 40 إضافة. في غضون عامين؟ أكثر من 70 إضافة. حالياً، لدينا إضافات لـ adb, ant, apache2-macports, archlinux, autoenv, autojump, autopep8, aws, battery, bbedit, bgnotify, boot2docker, bower, branch, brew, brew-cask, bundler, bwana, cabal, cake, cakephp3, capistrano, cask, catimg, celery, chruby, chucknorris, cloudapp, codeclimate, coffee, colemak, colored-man-pages, colorize, command-not-found, common-aliases, compleat, composer, copydir, copyfile, cp, cpanm, debian, dircycle, dirhistory, dirpersist, django, dnf, docker, docker-compose, emacs, ember-cli, emoji, emoji-clock, emotty, encode64, extract, fabric, fancy-ctrl-z, fasd, fastfile, fbterm, fedora, forklift, frontend-search, gas, gem, git, git-extras, git-flow, git-flow-avh, git-hubflow, git-prompt, git-remote-branch, gitfast, github, gitignore, glassfish, gnu-utils, go, golang, gpg-agent, gradle, grails, grunt, gulp, heroku, history, history-substring-search, httpie, iwhois, jake-node, jhbuild, jira, jruby, jsontools, jump, kate, kitchen, knife, knife_ssh, laravel, laravel4, laravel5, last-working-dir, lein, lighthouse, lol, macports, man, marked2, mercurial, meteor, mix, mix-fast, mosh, mvn, mysql-macports, n98-magerun, nanoc, nmap, node, npm, nvm, nyan, osx, pass, paver, pep8, per-directory-history, perl, phing, pip, pj, pod, postgres, pow, powder, powify, profiles, pyenv, pylint, python, rails, rake, rake-fast, rand-quote, rbenv, rbfu, rebar, redis-cli, repo, rsync, ruby, rvm, safe-paste, sbt, scala, scd, screen, scw, sfffe, singlechar, spring, sprunge, ssh-agent, stack, sublime, sudo, supervisor, suse, svn, svn-fast-info, symfony, symfony2, systemadmin, systemd, taskwarrior, terminalapp, terminitor, terraform, textastic, textmate, thefuck, themes, thor, tmux, tmux-cssh, tmuxinator, torrent, tugboat, ubuntu, urltools, vagrant, vault, vi-mode, vim-interaction, virtualenv, virtualenvwrapper, vundle, wakeonlan, wd, web-search, wp-cli, xcode, yii, yii2, yum, z, zeus, zsh-navigation-tools, zsh_reload. في المجموع… 214 إضافة.

صحيح أن هذا لم يثير إعجاب الجميع. أتفق على أنه يمكن تحسينه بشكل كبير. في المرات القليلة التي فكرت فيها بالأمر، وجدت أن الأساليب المقترحة معقدة للغاية بالنسبة للأشخاص الذين ليسوا على دراية و/أو مرتاحين لاستخدام الطرفية (terminal). ربما نهج أكثر تطوراً للإصدار الثاني من إطار العمل (المزيد عن هذا لاحقاً).

كان هناك أيضاً جزء مني يشعر أن هذا المشروع لن يثير اهتمام الناس إلا لبضع سنوات. مع اكتساب المستخدمين المزيد من الخبرة و/أو مع تطور التكنولوجيا، سيتخلف إطار العمل عن المشاريع الجديدة اللامعة التي حلت المشاكل بشكل أفضل بكثير مما فعلنا. لم أتخيل أبداً أن Oh My Zsh سيظل يكتسب زخماً بعد سبع سنوات تقريباً.

الآن، في عام 2016، لا يزال مستودع shell الأكثر رواجاً على Github هو Oh My Zsh. (أجد الأمر مضحكاً أن الرابط يقرأ “bash“… أهلاً).

ثمانية اعتبارات لمشروعك مفتوح المصدر

بينما لدي العديد من القصص لأشاركها (وأعتزم الكتابة المزيد عن هذا الموضوع)، أردت أن أتحدث إلى أولئك الذين يناقشون فكرة إطلاق مشروع مفتوح المصدر.

1. لا تبدأ بهدف طموح للغاية

ابدأ مشروعك بهدف بسيط وقابل للتحقيق. كيف يبدو النجاح؟ في حالتي، أردت أن يستخدم شخص واحد أو اثنان من فريقي نصوصي البرمجية (scripts). نجح المشروع في أقل من 24 ساعة. كل ما حدث منذ ذلك الحين كان بمثابة “نقاط إضافية”.

2. لا تحاول حساب كل السيناريوهات

لو كنت قد علقت ببعض التفاصيل طويلة الأجل للمشروع، لما رأى Oh My Zsh النور أبداً. كل ما أضيف إلى المشروع تقريباً جاء بشكل عضوي بعد الإصدار الأولي. أحد الجوانب الجميلة للمشروع مفتوح المصدر هو أن قاعدة مستخدميك يمكن أن تساعد في تشكيله.

3. لا تحاول جعله مثالياً

القلق بشأن كيفية تفاعل الآخرين مع الكود الخاص بك لا ينبغي أن يكون أكبر همك. هل يعمل؟ كيف يشعرون عندما يتفاعلون معه يجب أن يكون اهتماماً أعلى. في حالتي، كان لدي بعض المساهمين الرائعين على مر السنين الذين ساعدوا في ترتيب وتحسين جودة الكود الذي أصدرته في الأصل. نادراً ما قال أحد أي شيء نقدي عن الكود القديم الخاص بي – ربما كان ينبغي عليهم ذلك، على الرغم من ذلك. 😉

4. لا تحاول أن تكون كل شيء للجميع

كانت هناك بضع نقاط في تاريخ المشروع حيث وصلنا إلى مفترق طرق. على وجه الخصوص، كان هناك وقت تم فيه اقتراح إعادة بناء ضخمة، والتي كنت متحمساً لها جداً حتى تمكنت من استيعاب بعض التغييرات. اقتراح لتبسيط OH-MY-ZSH.

نتيجة لذلك، تم إعادة تسمية نسخة متفرعة (fork) واتفقنا على اتباع مسارات مختلفة. لم يكن الجميع سعداء بقراري هنا، لكن خلال هذه الفترة أصبح من الواضح (بالنسبة لي) أنني أردت تركيز اهتمامي على الأشخاص الذين لم يكونوا مرتاحين جداً للطرفية (terminal) و/أو git.

5. لا تتوقف عن شكر المساهمين

إذا ساعد أي شخص مشروعك، يرجى إخباره بمدى تقديرك لجهوده. لا أستطيع أن أشكر مساهمي بما فيه الكفاية. أحد أكبر انتقاداتي الذاتية المتعلقة بهذا المشروع هو أنني لم أكن متسقاً بما فيه الكفاية في التعبير عن تقديري. هناك 910 أشخاص من جميع أنحاء العالم تم قبول الكود الخاص بهم في الفرع الرئيسي (master branch) لـ Oh My Zsh وقت كتابة هذا. إنها قائمة طويلة جداً لدرجة أن Github لا يمكنه حتى سردها كلها. على وجه الخصوص، شكراً لكم. (أنتم تعرفون أنفسكم).

6. لا تنس التوثيق

على مر السنين، كان توثيق الإضافات (plugins) والوظائف (functionality) حيوياً لمساعدة المستخدمين على الاستفادة من إطار العمل. أتمنى لو كنا قد اعتمدنا هذا التقليد قبل عدة سنوات. ملف README هو الأكثر مشاهدة… لذا اجعله مهماً. في حالتي، اخترت أن أقدم للناس شخصيتي وروح الدعابة الجافة.

7. لا تنس بقية حياتك

مرة أخرى، لم أتوقع أبداً أن يتحول المشروع إلى ما هو عليه اليوم. هل أنت على دراية بالقصة الرمزية عن الضفدع في قدر الماء المغلي؟ استغرق الأمر مني 3-4 سنوات، أكثر من اللازم، لأجلب أخيراً شخصاً آخر للمساعدة في صيانة المشروع. كنت أظل أعتقد أنه يمكنني اللحاق بجميع طلبات السحب (pull requests) والمشكلات المفتوحة. ما كنت أقوله لنفسي هو أن الأشخاص الذين يعرفون كيفية تفريع المشروع (fork) يمكنهم إجراء التغييرات التي يرغبون فيها والعمل بناءً على ذلك، لذا فإن مراجعة طلبات السحب والموافقة عليها هو أمر “جميل أن يحدث” بدلاً من “يجب أن يحدث”.

في الممارسة العملية، الأمر يقع بين الاثنين. أشعر بالسوء قليلاً تجاه طلبات السحب القديمة التي لا تزال معلقة، لكنني أيضاً لا أضع Oh My Zsh ضمن أهم المشاريع القليلة على قائمتي. خارج Oh My Zsh، أدير وكالة تضم 19 شخصاً، أعزف الغيتار في فرقة روك ما بعد الروك الآلية، أجلس في مجلس إدارة منظمة غير ربحية محلية لمأوى المشردين، أسافر بالكاميرا كثيراً، أقود دراجتي النارية، أقود دراجتي الهوائية، وأحاول الحفاظ على حياة اجتماعية مع أصدقائي. يقع Oh My Zsh في مكان ما بين كل هذه الأمور. إنه ليس على رأس قائمة أولوياتي. إنه ليس في أسفلها. إنه في مكان ما بينهما. هذا ليس عذراً لعدم القدرة على مواكبة المجتمع، بل هو تذكير بأن تلك الأمور الأخرى يجب أن تهمك أيضاً، إذا كنت على وشك بدء مشروعك الخاص.

8. لا تنس أن تستمتع ببعض المرح

عندما تبدأ مشروعك، قرر ما إذا كان هذا سيكون وقت عمل جاد أم وقت لعب. ربما يمكن أن يكون في مكان ما في المنتصف. لطالما كان Oh My Zsh بالنسبة لي مشروعاً ترفيهياً. معرفة أن أحد مشاريعي المرحة كان وما زال يستمتع به الناس هو شعور رائع. قد يسميه البعض “مشروع شغف”. أنا أسميه “وقت لعب”.

هل أنت مهتم بمشروعي مفتوح المصدر الممتع؟ يمكنك معرفة المزيد على http://ohmyz.sh.