المُقدمة

حظيَت مقالتي السابقة، "«واتساب» وتدجين المستخدمين"، باهتمام أكبر ممّا كنت أتوقع. أثارت لدي بعض ردود القرّاء العديد من الأفكار١، ولا سيما فيما يتعلَّق بالإجراءات التي يمكننا أن نتَّخِذها. أنصح بقراءة تلك المقالة أولًا؛ فهي توضِّح معنى "تدجين المُستخدِم" ولماذا يُعَدّ مشكلة. أشارت المقالة إلى ثلاثة تدابير مضادّة: «البرمجيّات الحُرّة ومفتوحة المصدر»، والبساطة، والمنصات المفتوحة.

المشكلات العسيرة، بطبيعتها، تفتقر إلى حلول يسيرة. فلا يكفي مجرد اختيار (أو إنشاء) منصة تتجنَّب "تدجين المستخدم" إذا كانت هذه المنصة قابلة للتحوُّل. إنّ ثمن الحرية هو اليقظة الدائمة؛ فبالإضافة إلى اختيار المنصة المناسبة، علينا أن نضمن أنها تحترم مُستخدِميها حاليًا وفي المستقبل. إنّ إبقاء المنصة حُرّة ومفتوحة المصدر أسهل وأقل تعقيدًا٢ من إبقائها "مفتوحة".

فكيف نضمن ألّا تتحوَّل المنصة المفتوحة اليوم إلى منصة مغلقة غدًا؟

كيف تتحوَّل المنصات المفتوحة إلى منصات مغلقة

هناك ثلاث طرق تصبح فيها المنصات مغلقة:

  1. الهجرة القسرية إلى منصة أخرى
  2. هيمنة تطبيق واحد، ممّا يؤدي إلى طمس الفروقات بين المواصفات والتطبيقات
  3. اعتماد التطبيقات المهيمنة ميزات وسلوكيات كثيرة خارج إطار المعايير المعتمدة

غالبًا ما تتداخَل هذه الأساليب الثلاثة، إذ تؤدي عادةً إلى أحاديّة المنصة (Monoculture)، أي سيطرة بائع واحد على كل التطبيقات والخوادم.

الهجرة القسرية

المنصة المُقيَّدة جزء فرعي من منصة مفتوحة أكبر حجمًا، يمكن للمقيَّدة أن تتطوَّر بوتيرتها الخاصة، دون الاكتراث بالتوافق أو قابلية التشغيل البيني (Interoperability).

عندما يتحكَّم بائع واحد بجميع أجزاء الخدمة (مثلًا: التطبيق والخادم معًا)، تصبح لديه القدرة على إنشاء منصة مُقيَّدة. فالتحكم بالتطبيق والعميل في نفس الآن يتيح للبائع أن يُحدِّث كليهما دون أن يقلق بشأن كسر التوافق مع التطبيقات أو الخوادم الأخرى في الشبكة الأوسع. بل ويمكنه أن يُحدِّث التطبيق ليوجِّه المستخدمين إلى خادم يَستخدِم بروتوكولًا مغلقًا ومختلفًا تمامًا. هذا بالضبط ما حدث لعدد كبير من مستخدمي بروتوكول «إكس إم بي بي» (XMPP) في أوائل القرن الواحد والعشرين.

دراسة حالة: تقييد بروتوكول «إكس إم بي بي»

«إكس إم بي بي» (المعروف سابقًا بـ«جابِر») بروتوكول مفتوح واتّحاديّ للمراسلة الفورية، يسمح لأي شخص بإعداد خادم خاص به والتحدُّث مع مستخدمين على خوادم أخرى تستخدم نفس البروتوكول، ممّا يمنع أي منظمة واحدة من أن تمتلك المنصة بالكامل. بين عامَي ٢٠٠٥ و٢٠١٤، دَعمَت العديد من منصات الدردشة المملوكة استخدام هذا البروتوكول. مثل «غوغل توك»، و«سكايب»، و«إيه أو إل للمراسلة الفورية» (AIM)، و«ماِسنجر» (المعروف سابقًا بـ«فيسبوك شات»). حتى إنّ بعض هذه المنصات أتاح الاتّحادية (Federation) ما بين الخوادم.

لكن، للأسف، كان مستخدمو هذه المنصات المملوكة مقيَّدِين. لم يكن كثير من مستخدمي «غوغل توك» يتحدثون مع مستخدمي «سكايب»، ولا كان مستخدمو «سكايب» يتحدثون عادةً مع مستخدمي «إيه أو إل»، فبقي المستخدمون في منصاتهم الفرعية الخاصة. وكانت النتيجة أنّ جميع المستخدمين حصروا تواصلهم في استخدام برمجيّات مزوِّدهم وحده؛ إذ كان مزوِّد واحد يهيمن على كامل مسار الرسائل، من تطبيق المُرسِل، مرورًا بالخادم، ووصولًا إلى تطبيق المُستقبِل. لطالما تعامَل المستخدمون مع تطبيق واحد لـ«إكس إم بي بي» يقدّمه مزوِّد واحد.

وفي نهاية المطاف، أقدمَت كل المنصات المذكورة على حصر مستخدميها بتهجيرهم بعيدًا عن «إكس إم بي بي». ولم يكن هذا ليحدث لو كان هناك العديد من التطبيقات والمزوِّدين الذين يتفاعلون مع بعضهم البعض. تخيَّل أنّ "باسم" يستخدم "تطبيق باسم" و"خادم باسم" ليتحدَّث مع "أسيل"، وأنّ "أسيل" تستخدم "تطبيق أسيل" و"خادم أسيل". في هذه الحالة، سيتعيَّن على "تطبيق باسم" و"خادم باسم" و"تطبيق أسيل" و"خادم أسيل" أن تبقى جميعها متوافِقة وتستخدم البروتوكول نفسه، ما يجعل الهجرة القسرية أمرًا غير محتمل، لأنه سيؤدي إلى كسر التوافق.

قارن هذا الوضع مع البريد الإلكتروني؛ فبالرغم من هيمنة «جي ميل» (Gmail)، ما يزال مزوِّدو البريد الإلكتروني الآخرون يحظون بشعبية. يحتاج مستخدمو «جي ميل» إلى إمكانية التواصل مع مُستخدِمين لديهم بريد إلكتروني مختلف، والعكس صحيح. ولذلك يُعَدّ البريد الإلكتروني أقل تقييدًا من منصات «إكس إم بي بي» المملوكة المذكورة أعلاه. ونتيجة لذلك، لم تتمكَّن «غوغل» من أن تسيطر على منصة البريد الإلكتروني بنفس السهولة؛ فهي لا تستطيع أن تَنقُل مستخدمي «جي ميل» ببساطة إلى منصة غير بريدية وغير متوافقة مع بقية منظومة البريد الإلكتروني كي تُدجِّن مستخدميها إلى حدّ أكبر.

ما يزال «إكس إم بي بي» قائمًا، لكن شعبيته الحالية لا تمثِّل إلّا جزءًا صغيرًا ممّا كانت عليه في السابق.

قوة تنفيذ المعايير

المعايير هي شكل من أشكال الاتفاقات التي وُضِعَت لتضمَن التوافق بين التطبيقات المختلفة. ويجب أن تُعقَد مثل هذه الاتفاقات برضا التطبيقات المعنية نفسها. وعندما يزداد نفوذ تطبيق واحد، يزداد أيضًا تأثيره في عملية اتخاذ القرارات المتعلِّقة بالمعايير المُشترَكة. ويمكن أن تؤدي الهيمنة المفرطة إلى أحاديّة المنصة، فيصبح التطبيق المهيمن هو التطبيق الوحيد الذي يلتزِم بالمواصفات.

وإذا كان لديه نفوذ، يمكن للتطبيق المهيمن أن يصبح تطبيقًا مرجعيًّا. وعادةً ما تكون لهذا النوع من التطبيقات فائدة واسعة، إذ تشكِّل مصدرًا موثوقًا لاختبار التطبيقات الأخرى مقارنةً بها. لكن قد تنشأ المشكلات عندما يرتبط تطوير المواصفات بتطوير التطبيق المرجعي، فهذا يحوْل دون مشاركة التطبيقات الأخرى في عملية اتخاذ القرار.

دراسة حالة: «ماتريكس» و«إليمِنت»

أحد الأمثلة على هذه الظاهرة هو «ماتريكس». «ماتريكس» هو منصة مفتوحة اتحادية للمراسلة الفورية، شبيهة بـ«إكس إم بي بي». لدى «ماتريكس» مواصفات عديدة وعدد كبير من الميزات، مثل السجل المحفوظ على الخادم، والردود، والنص المنسَّق، والتفاعلات، وإصدارات الغرف، والتشفير التام بين الطرفين (E2EE)، والأفاتارات (الصور الرمزية)، وأسماء المستخدمين المعروضة، ومؤشرات حالة الكتابة، ومؤشرات قراءة الرسائل، والتحقُّق من هوية الأجهزة. تطول هذا القائمة وتزداد كل شهر٣. التطبيق الوحيد الذي يوفِّر جميع الميزات المطلوبة هو «إليمِنت». وإضافة إلى أنّه التطبيق الأكثر شيوعًا، يُعَدّ «إليمِنت» تطبيقًا مرجعيًّا؛ إذ تطوِّره الشركة نفسها التي تبني الخوادم المهيمنة وتضع معظم المواصفات. هذا الترابط الوثيق بين «إليمِنت» ومواصفات «ماتريكس» يتيح لـ«إليمِنت» أن يضيف ميزات بوتيرة أسرع من بقية التطبيقات؛ فيضطر مستخدمي «ماتريكس» إلى الدخول إلى «إليمِنت» في مرحلة ما لتنفيذ إجراء لا يتوفر في أي تطبيق آخر. وعلى صعيد الخادم، يُعَدّ «ساينابس» الخادم الوحيد الذي يطبِّق قدرًا كافيًا من المواصفات ليكون صالحًا للاستخدام، بينما يحتل «ديندرايت» المرتبة الثانية. وكلاهما تُطوِّره الشركة ذاتها التي تُطوِّر «إليمِنت».

وبما أنّه لا توجد تطبيقات أو خوادم خارجية يمكنها أن تحل محل النسخ الرسمية، فإن السيطرة على كل أجزاء المنصّة تكاد تؤول إلى جهة واحدة. إنّ ازدياد تعقيد المواصفات التي تتطلبها التطبيقات والخوادم قد يعمِّق أيضًا من هيمنة هذه التطبيقات، كما ذَكرتُ من قبل. اقترب «ماتريكس» من أن يصبح منصة مُقيَّدة، إذ يمكن لكل من التطبيق والخادم الرسميَين أن يتطورا بمعزل عن البيئة الرقمية الأوسع.

لا أعتقد أنّ «ماتريكس» سيتحوَّل إلى منصة مغلقة بالكامل في أي وقت قريب؛ إذ توحي مقالة "الخصوصية مقابل الحرية" بأنه ما زال يميل إلى جانب الانفتاح. كما أنّ تطبيقات مثل «غوموكس» و«فلَفي شات» يبدون قادرَين على مجاراة تطورُّ «إليمِنت» إلى حدّ يؤهّلهم لأداء الغرض بدلًا عنه في بعض الحالات. مع هذا، أشعر أنّ حالة «إليمِنت» الآن إشكالية وتشبه حالة المنصات المغلقة لا المفتوحة، عندما نقارنها بـ«إكس إم بي بي» و«آي آر سي» (IRC) والبريد الإلكتروني.

كثرة الميزات غير المعيارية

المنصات أكبر من مجرد بروتوكولاتها. فالتطبيقات المختلفة تتمتَّع بسلوكيات خاصة بها لتُميِّز نفسها عن غيرها. وتنشأ المشكلة عندما تتكاثر الميزات الفريدة وغير المعيارية في التطبيقات المهيمنة، إلى حدٍّ تُشكِّل فيه منظومة مغلقة تطغى على المنصة المفتوحة.

دراسة حالة: مزوّدو البريد الإلكتروني

بعدما قرؤوا مقالتي السابقة، تواصل معي بعض الأشخاص ليسألوني عن رأيي بخصوص بعض مزوِّدي البريد الإلكتروني. لا تتوفر مساحة كبيرة للتميُّز في خدمات البريد الإلكتروني التقليدية، خصوصًا عندما يقتصر دور التطبيقات على استضافة خادم بريدي بسيط. وغالبًا ما يضيف مزوِّدو البريد ميزات كثيرة علاوة على الالتزام بمعايير البريد الإلكتروني، بهدف تمييز أنفسهم عن الآخرين.

إنّ الغالبية العظمى من حسابات البريد الإلكتروني تأتي من بضعة مزوِّدين مهيمنين ومدعومين من شركات كبرى، مثل «جي ميل»، و«بريد ياهو!»، و«بريد ياندكس»، و«ميل.آر يو»، و«آي كلاود»، وغيرها. يُعرَف مزوِّدون مثل «جي ميل» بأنّهم يضعون «فلاتر» متقدِّمة لمكافحة البريد العشوائي، لكنها تنحاز لصالح المزوّدين الرئيسيِّين على حساب المزوِّدين الأقل انتشارًا. كثيرًا ما تُصنَّف رسائل أولئك الذين يستضيفون خوادم بريدهم الخاصة، أو يستخدمون تطبيقات من مزوّدين غير بارزين، على أنها رسائل عشوائية، إلى أن يكتسبوا «سمعة» مرسِل جيدة٤. إضافة هذا «الفلتر» المعقَّد لمكافحة البريد العشوائي تُعزِّز احتكار القلّة في سوق البريد الإلكتروني بوضع حاجز دخول أمام المُستخدِمين الجدد. يقع التمييز أيضًا ضدّ المرسِلين ذوي النشاط المنخفض. قالت «ميغادو»:

"لقد رأينا نصيبنا من «فلاتر» البريد العشوائي الرديئة وخوادم أكثر رداءة. وفي بعض الأحيان كانت خوادم المُستلِمين ترفض رسائل سليمة عمدًا لمجرّد أنّ حجم إرسالنا منخفض. والمفارقة هنا، هذا هو السلوك المنشود من المُرسِل المثالي تحديدًا. ولتحسين "قابلية الاستلام"، فإنهم بالطبع يقدِّمون خدمة استضافة البريد الإلكتروني مقابل سعر باهظ."

— من مقالة "إذًا، كيف هي قابليّة استلام البريد؟"، تحت العنوان الفرعي "قابليّة استلام البريد في «ميغادو»".

من الأمثلة الأخرى، يُقدِّم مزوِّدو البريد الإلكتروني مثل «Hey.com» و«بروتون ميل» و«توتانوتا» العديد من الميِّزات التي لا تتوافق مع بروتوكولات IMAP/POP3. يستخدم «بروتون ميل» و«توتانوتا» تطبيقاتهما الخاصة غير المعيارية للتشفير التام بين الأطراف، بدلًا من التركيز على تحسين تجربة الاستخدام لـPGP التقليدي، بينما يقدِّم «Hey.com» خدمة تنظيم البريد على مستوى الخادم. ولا تعمل هذه الخدمات إلّا عبر تطبيقاتها الرسمية على الويب والحواسيب والهواتف٥. تتحكم هذه الشركات الثلاث بالتطبيق والخادم، ممّا يمنحها القدرة على فرض الاحتكار. وبالطبع، هناك حدّ لمستوى الاحتكار الذي يمكن أن يحقِّقه المزوِّدون، فكما أوضَحتُ في دراسة حالة «إكس إم بي بي»، لا يزال عليها أن تدعم بروتوكول «إس إم تي بي» (SMTP) للحفاظ على التوافق مع البيئة الأوسع للبريد الإلكتروني.

الحلول

دعونا من التشاؤم، فلنركِّز على الخطوات التي يمكن للمُستخدِمين والمزوِّدين أن يتَّخِذوها لإبقاء المنصات مفتوحة.

دور المُستخدِم

بصفتك مُستخدِمًا، فكِّر في استخدام تطبيقات وخوادم طُوِّرَت على يد مجموعات مختلفة من الأشخاص، لتُصعِّب تقييد المنصة. اختر تطبيقات تعاني أقل قدرٍ من التكاثر الزائد للميزات خارج الالتزام بالمواصفات. ما يُميِّز التطبيق ليست الميزات، بل كيف تُطبَّق تلك الميزات. من الواضح أنّ وجود بعض الميزات الفريدة أمر جميل، لكن تنشأ المشاكل عندما يتجاوز عدد هذه الميزات الفريدة حدًا معينًا. إنّ الالتزام بهذين النهجَين يشجِّع التطبيقات على الامتثال للمعايير والموثوقية والتوافق بدلًا من "الابتكار" المفرِط. اختر التكنولوجيا المُمِلَّة بدلًا من الميزات اللامعة والجديدة.

حاول أن تتجنَّب الخيارات السائدة، جرِّب مزوِّدًا أو تطبيقًا أقل انتشارًا. كل تطبيق له نقطة بدء، وتعدُّد البدائل يحوْل دون احتكار القلّة.

وعندما تختار التطبيق والمزوِّد، فكِّر في مصالح المزوِّد. مَن يَخدِم؟ المُستخدِم أم المُستثمِر؟ وهل تجاوز مرحلة الاستدامة المالية؟

لا أدّعي أنّ ما يفعله المُستخدِمون العاديّون "خاطئ" إنْ اختاروا غير ذلك؛ فإنّه لأمر ساذج أن نتوقَّع من الناس أن يغيِّروا سلوكهم من أجل الصالح العام. أوجِّه هذه النصائح إلى المُستخدِمين الذين يملِكون معرفة تقنية والمستعِدّون للتأمُّل قبل اختيار المنصة، كما أخاطب بها أيضًا كل من يمتدّ إليهم تأثير تلك الشريحة من المُستخدِمين.

دور المزوِّد

بدلًا من الإفراط في التركيز على التوسُّع، سَهِّل تثبيت البرمجيّات وأتِح الاتحادية بينها. إذا تجاوز مستخدمو تطبيقك عددًا معينًا، أوقف تسجيل الحسابات، وشجِّع الناس على تجربة مُزوِّدين آخرين. تَتْبَع هذا النهج العديد من النُسَخ البرمجيّة داخل «الفيديفرس». لا أنفي أهمية التوسُّع؛ وإنَّما أرى أنّ تقليل الحواجز أمام المزوِّدين الجدد يوفّر بديلاً فعّالًا للتوسُّع٦.

اطَّلِع على الحقوق المتروكة (Copyleft Licensing)، فتُعَدّ هذه الحقوق من أقوى الأدوات التي نملكها لحماية حرية المُستخدمِ، إذ أنّها تمنَع إنشاء أعمال ثانوية تسعى لتقييد حرية المُستخدِم. بهذه الطريقة، يَصعُب على التطبيقات البديلة أن تُخفي تعديلاتِها لتُقيِّد مستخدميها. ويُعَدّ ترخيص «GNU AGPLv3» فعالًا بشكل خاص لأنه يفرض توزيع كود الخادم للخدمات الشبكية؛ ولو كان هناك انتشار واسع للبرمجيات المرخَّصة تحت «AGPLv3» لكان التخفيف من تقييد مستخدمي «إكس إم بي بي» بالإمكان في أوائل القرن الواحد والعشرين.

تُعَدّ التطبيقات المرجعية جيدة إذا لم تتخطى حدًّا معيَّنًا في هيمنتها. تأكَّد من أنّ التطبيقات الأخرى قادرة على مجاراة التطوُّر. وإذا لزم الأمر، أبطئ وتيرة تطوير المواصفات، واسمح لمطوِّري التطبيقات الأخرى بالمشاركة في عملية اتخاذ القرار، وقدِّم لهم العون لتحسين تطبيقاتهم. نهج «تحرَّك بسرعة وحَطِّم كلّ شيء» ليس بالخيار الأمثل.

على سبيل المثال، يمكن لـ«إليمِنت» و«مؤسسة ماتريكس.أورغ» أن يُقلِّصا معظم مخاوفي إذا قاموا بهذه الممارسات:

  • وضع حدّ لعدد الحسابات الجديدة على خادم «ماتريكس.أورغ» الرئيسي، لتوجيه المستخدمين إلى خوادم بديلة يديرها أشخاص مختلفون.
  • توَخِّي الحذر عند طرح ميزات جديدة، إلى أن تُحقِّق التطبيقات والخوادم تكافؤًا مع «إليمِنت» و«ساينابس» و«ديندرايت».
  • التقليل من متطلبات العتاد والبرمجيّات لاستضافة الخادم حتى يسهل على مزوِّدين جدد الانضمام، وهذا قيد التنفيذ بالفعل بفضل تطوير «ديندرايت».

العيوب

العيب الأبرز هنا هو وتيرة التطوير. فالحفاظ على التوافق والالتزام بالمواصفات يُبطِّئ وتيرةَ إضافة الميزات الجديدة. وكما يجادل «موكسي»، ربما لم يكن «سيجنال» ليتمكَّن من إدخال هذا العدد من الميزات لو كان منصةً مفتوحة؛ فالتطوير المقيَّد بالمواصفات —بحكم التعريف— مقيَّد. يظلّ المُستخدِمون محكومين بما تتفِّق عليه التطبيقات الأكثر انتشارًا من حدٍّ أدنى للميزات.

غالبًا ما تكون تجربة الاستخدام أقل سلاسة في المنصّات المفتوحة متعدِّدة الميزات، خصوصًا في الخطوات الأولى لانضمام المُستخدِمين. فبدلًا من الدخول إلى التطبيق أو الموقع الرسمي مباشرة، يتعيَّن على المُستخدِم أن يختار بين عدد كبير من التطبيقات والمزوِّدين. هذا قد يُبعِد المُستخدِم الذي يريد أن يجرِّب الخدمة وحسب. يبدأ تحسين تجربة الانضمام بتوصيات بسيطة تُقدِّمها لأصدقائك الذين لا يملكون معرفة تقنية؛ فيمكنك أن تساعدهم على اتخاذ قرارٍ واعٍ.

حالات أخرى مشابهة

اللغات البرمجية التي تُشكِّلها «المعايير» لا «التطبيقاتٌ المرجعية» تتمتَّع عادةً بقابلية نقلٍ أعلى، وتملك ميزات جيدةً عديدة، ونادرًا ما تتلاشى مع الزمن. من أمثلتها: لغة «سي»، و«سي++»، و«كومون لِيسب» (Common Lisp)، و«جافا سكرِبت»، و«POSIX Shell». قارن ذلك بـ«بايثون»؛ حيث يعتمد عدد كبير من الحزم على أسلوب «سي بايثون» (CPython) في بناء الإضافات بِلُغة «سي»، لذا تجد البدائل مثل «باي باي» (PyPy) صعوبة في تحقيق التوافق مع هذا الأسلوب، فتظلّ في مرتبة أدنى عمليًا.

الاعتماد على المعايير والتوافق في تطوير المنصّات يُحقِّق الاستقرار لكنه يُخفِّض من الكفاءة؛ وتتكرَّر هذه المقايضة في مجالاتٍ أخرى خارج مجال تطوير البرمجيّات، إذ تعاني معظم أشكال الديمقراطية من البيروقراطيةَ والصراعاتِ الداخلية التي تعيق التقدُّم. يرى البعض أنّ لاكفاءة الديمقراطية ميزة وليست عيبًا. كما يقول «ناثان ميهرڤولد»:

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

ناثان ميهرڤولد، من مقالة: ميزة البيروقراطية البطيئة

ربما تكون الفائدة الأكبر من التخلي عن مبدأ "تحرَّك بسرعة وحطِّم كلّ شيئ" هي أنه لا يُعيق التطوُّر السريع للخدمات فحسب، بل يمنع تدهورها السريع أيضًا.

الشكر والتقدير

ساعدني دنفر جينجيرتش في طرح الأفكار خلال المراحل الأولى من الكتابة، وقدَّم معلومات مفيدة لجزء بروتوكول «إكس إم بي بي».

أقدم الشكر إلى بارنا زومبور وكاربوليمر على ملاحظاتهم القيِّمة حول بروتوكول الدردشة «آي آر سي» (IRC).


ملاحظات

  1. هذا التعليق على منصة «هاكر نيوز» هو الذي ألهم العديد من الأفكار المطروحة في هذه المقالة.
  2. لاحظ أن كلمة "أسهل" وعبارة "أقل تعقيدًا" غير مترادفتين رغم وجود بعض التداخل بينهما.
  3. اطّلِع على مدوّنة هذا الأسبوع في «ماتريكس»، وهي نشرة أسبوعية تتحدَّث عن آخر التطورات في بيئة «ماتريكس». تحديدًا، ننصح بمتابعة تحديثات المواصفات الفنية، حيث تُدمَج مقترحات تحسين «ماتريكس» (MSCs) الجديدة كل شهر.
  4. "التوجيهات الرسمية من «غوغل» و«أمازون ويب سيرفيسز» (AWS) تشرح هذا السلوك بتفصيل أكبر.
  5. يقدِّم «بروتون ميل» (Protonmail) برنامج الربط الخاص الذي يحوِّل واجهة برمجة تطبيقاته (API) إلى بروتوكول IMAP، مما يمكِّن المستخدمين من الوصول إلى حساباتهم عبر أي تطبيق بريد إلكتروني متوافق. هذا لا يُغيِّر من حقيقة أنه يجب على المُستخدِمين الدخول إلى تطبيقات رسمية؛ وفي هذه الحالة، التطبيق الرسمي هو برنامج الربط نفسه.
  6. امتنعتُ عن استخدام العُنوان الفرعي المُستفِز "التوسع يُعتبر ضارًا" لأنني خشيتُ أن يأخذ القُراء على موقعٍ ما (ذي لونٍ برتقالي) النكتة على محمل الجد.