التفكير في 18 عامًا في Google

2023-11-22 04:29 بالتوقيت العالمي التفكير في 18 عامًا في Google

انضممت إلى شركة Google في أكتوبر 2005، وقدمت استقالتي بعد مرور 18 عامًا. الأسبوع الماضي كان آخر أسبوع لي في جوجل.

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

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

فناء تشارلي في جوجل، 2011. تم التلاعب بالصورة لإزالة أفراد.

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

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

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

قضيت آخر تسع سنوات من عمري في Flutter. ومن أعز ذكرياتي عن الوقت الذي أمضيته في Google تلك الأيام الأولى من هذا الجهد. كان Flutter واحدًا من آخر المشاريع التي خرجت من Google القديم، وهو جزء من مجموعة من التجارب الطموحة التي بدأها Larry Page قبل وقت قصير من إنشاء Alphabet. لقد عملنا بشكل أساسي كشركة ناشئة، اكتشاف ما كنا نبنيه أكثر من تصميمه. تم إنشاء فريق Flutter بشكل كبير بناءً على ثقافة شركة Google الناشئة؛ على سبيل المثال، أعطينا الأولوية للشفافية الداخلية، والتوازن بين العمل والحياة، واتخاذ القرارات المستندة إلى البيانات (بمساعدة كبيرة من Tao Dong وفريق UXR الخاص به). لقد كنا منفتحين بشكل جذري منذ البداية، مما سهّل علينا بناء مشروع سليم مفتوح المصدر حول هذا الجهد أيضًا. كان Flutter أيضًا محظوظًا جدًا لأنه يتمتع بقيادة ممتازة على مر السنين، مثل آدم بارث كقائد تقني مؤسس، وتيم سنيث كرئيس للوزراء، وتود فولكيرت كمدير هندسي.

كما أننا لم نتبع أفضل الممارسات الهندسية في السنوات القليلة الأولى. على سبيل المثال، لم نكتب أي اختبارات ولم يكن لدينا سوى القليل من الوثائق الثمينة. هذه السبورة البيضاء هي ما تم اعتماده كمستند تصميم لطبقات Widget وRenderObject وdart:ui الأساسية. وقد سمح لنا ذلك بالتحرك بسرعة في البداية، لكننا دفعنا ثمن ذلك لاحقًا.

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

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

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

لا يزال هناك أشخاص رائعون في Google. لقد حظيت بشرف العمل مع أشخاص رائعين في فريق Flutter مثل JaYoung Lee، وKate Lovett، وKevin Chisholm، وZoey Fan، وDan Field، وعشرات آخرين (آسف يا رفاق، أعلم أنني يجب أن أذكركم جميعًا ولكن هناك كثيرة جدًا!). في السنوات الأخيرة، بدأت تقديم النصائح المهنية لأي شخص في Google، ومن خلال ذلك التقيت بالعديد من الأشخاص الرائعين من جميع أنحاء الشركة. من المؤكد أن الأوان لم يفت بعد لشفاء Google. سيتطلب الأمر بعض التغيير في قمة الشركة، ونقل مركز السلطة من مكتب المدير المالي إلى شخص لديه رؤية واضحة طويلة المدى لكيفية استخدام موارد Google الواسعة لتقديم قيمة للمستخدمين. ما زلت أعتقد أن هناك الكثير مما يجب تحقيقه من بيان مهمة Google (لتنظيم المعلومات في العالم وجعلها في متناول الجميع ومفيدة عالميًا). إن الشخص الذي يريد قيادة Google خلال العشرين عامًا القادمة، من خلال تعظيم الخير للإنسانية وتجاهل التقلبات قصيرة المدى في أسعار الأسهم، يمكنه توجيه مهارات Google وشغفها إلى إنجازات عظيمة حقًا.

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

تنبيهات: 1 2

11-08-2023 19:05 بالتوقيت العالمي طيف الانفتاح

“المصدر المفتوح” هو نطاق واسع، ذو محاور مختلفة. فيما يلي محاولة لوصف طرق مختلفة للنظر في الانفتاح لمساعدة قادة المشروع في تحديد الشكل الذي يريدون أن يبدو عليه مشروعهم. لقد كتبت هذا في الأصل لزملائي في Google، لكن المفاهيم تنطبق على نطاق واسع واعتقدت أنها قد تكون مفيدة للآخرين.

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

إمكانية التشغيل البيني (0-6)

أحد جوانب الانفتاح هو كيفية تفاعل منتج الفرد مع الآخرين.

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

0. الملكية مع التشويش

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

أمثلة: تنسيق ملف Kindle، ومعظم تنسيقات الموسيقى المتدفقة.

1. الملكية

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

مثال: نظام الملفات NTFS.

2. المعايير المفتوحة المرخصة

يمكن للمرء أن يكون لديه مواصفات مفتوحة تمامًا، ولكنه يتطلب الدفع (أو اتفاقيات أخرى) قبل أن يمكن قراءة المعيار أو استخدامه، على سبيل المثال عن طريق استخدام ترخيص براءات الاختراع.

مثال: برنامج ترميز الفيديو H.264.

3. “الرمز هو المعيار”

لا تقوم بعض المشاريع بتوثيق بروتوكولاتها، ولكن نظرًا لتوفر كود المصدر الخاص بها، يتم تعريفها بشكل فعال من خلال تنفيذها والأخطاء وكل شيء.

الأمثلة كثيرة ولكن بما أن الناس نادرًا ما يعتزمون أن يكونوا في هذه الحالة فإن الإشارة إلى أي مشروع محدد باعتباره ضمن هذه الفئة يميل إلى أن يكون مثيرًا للجدل.

4. العامة

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

أمثلة: IntelliJ، Swift UI، بروتوكول SMB.

5. المعايير المفتوحة

إن الانفتاح النهائي الذي يمكن أن يقدمه المرء هو تقديم البروتوكولات الخاصة به إلى لجنة المعايير (أو تشكيل لجنة جديدة؛ والفرق رمزي إلى حد كبير). يكون هذا مفيدًا عندما يكون القصد هو إنشاء نظام بيئي كامل حول المنتج والبروتوكولات الخاصة بالفرد.

أمثلة: البروتوكولات الأساسية للإنترنت، والويب.

6. المعايير المنظمة

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

أمثلة: معايير شبكة الكهرباء.

ترخيص كود المصدر (0-7)

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

0. الأسرار التجارية

تعتبر بعض أكواد المصدر سرية جدًا ومهمة جدًا لمالكها بحيث تحصل على حماية قانونية تتجاوز حقوق الطبع والنشر.

مثال: الأجزاء الداخلية الأكثر حساسية لمنتجات البرمجيات الاحتكارية الخاصة.

1. الملكية

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

مثال: الكود المصدري لأجزاء واجهة المستخدم لنظام التشغيل macOS.

2. مرخصة تجارياً

يمكن للمرء ترخيص الكود الخاص به للاستخدام من قبل مستخدمين محددين، دون نشره للعامة. عادة يتم ذلك من أجل المال.

أمثلة: كيو تي (في شكله مغلق المصدر)؛ بيع مايكروسوفت حق الوصول إلى التعليمات البرمجية المصدر لنظام التشغيل Windows.

3. كود المصدر الذي يمكن رؤيته بالصدفة

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

أمثلة: كود JavaScript في مواقع الويب التي لا تستخدم أداة تصغير أو مترجم؛ كود البرنامج النصي في ملفات بيانات اللعبة.

4. مشاركة المصادر مقيدة الاستخدام

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

مثال: MongoDB.

تراخيص مفتوحة المصدر

يمكن للمرء ترخيص الكود الخاص به للاستخدام العام، ويمكن أن تختلف هذه التراخيص في شروطها.

من المهم أن نلاحظ أن هناك تراخيص مفتوحة المصدر سليمة من الناحية القانونية، وهناك “تراخيص” لا معنى لها جاءت نتيجة لاعتقاد مهندسي البرمجيات أن مهنة المحاماة أمر سهل. تحدث إلى محامٍ قبل اختيار الترخيص. انظر صفحة ترخيص OSI للحصول على نظرة عامة على الموضوع.

5. مقيد

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

أمثلة: البرامج المرخصة بـ GPL، مثل Linux أو Emacs.

6. متبادل

تطبق هذه التراخيص الشروط التقييدية على الكود المعني (عادة مكتبة) ولكن ليس على الكود الذي يستخدمه (مثل التطبيق الذي يقوم بتضمين المكتبة).

أمثلة: البرامج المرخصة بواسطة MPL، مثل Firefox.

7. متساهل

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

أمثلة: البرامج المرخصة من Apache، مثل Android أو Rust؛ البرامج المرخصة من BSD، مثل Chromium أو Flutter.

إدارة حقوق التأليف والنشر

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

عمليات التطوير (0-8)

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

تنطبق الأقسام أدناه بالتساوي على المشاريع الكبيرة كما تنطبق على المشاريع الفردية، ولكنها تركز بشكل أساسي على المشاريع التي تضم أعضاء فريق متعددين.

0. تطوير الملكية

معظم المشاريع المغلقة لا يوجد بها أي تطوير يواجه الجمهور على الإطلاق. تتم جميع عمليات التصميم والتنفيذ والاختبار داخليًا.

مثال: بحث جوجل.

1. تطوير الملكية للبرمجيات مفتوحة المصدر

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

أمثلة: سكليتي، بوستفيكس.

2. تطوير الملكية، بيتا محدودة الوصول

يمكن للفريق دعوة مجموعة مغلقة من المستخدمين غير المنتسبين لاختبار برامجهم قبل الإطلاق.

هذا نموذج شائع للبرامج التجارية.

3. تطوير الملكية، والإصدارات التجريبية العامة

يمكن لفريق التطوير الخاص التماس التعليقات من المجتمع العام من خلال توفير برنامج ما قبل الإصدار لأي مستخدم لاختباره.

هذا نموذج شائع للبرامج التجارية.

4. الحضور العام، والتنمية الخاصة

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

إن قنوات الاتصال الخاصة بهذا الفريق كلها أو معظمها داخلية. عادةً ما يكون الوصول الالتزامي تلقائيًا للفريق، وغير متاح لأي شخص آخر.

أمثلة: العديد من مشاريع Google الصغيرة مفتوحة المصدر، والعديد من المشاريع الشخصية على GitHub، تندرج ضمن هذه الفئة.

5. تنمية الزمرة العامة

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

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

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

الأمثلة كثيرة ولكن بما أن الناس نادرًا ما يعتزمون أن يكونوا في هذه الحالة فإن الإشارة إلى أي مشروع محدد باعتباره ضمن هذه الفئة يميل إلى أن يكون مثيرًا للجدل.

6. التنمية العامة، والحوكمة الخاصة

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

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

مثال: الرفرفة.

7. التطوير العام من خلال فريق أساسي غير منتخب ولكنه مستقل

يمكن أن يكون المشروع مفتوحًا تمامًا في تطويره، مع فريق أساسي معين ذاتيًا لا يستجيب لأي شخص سوى نفسه. يُستخدم أحيانًا مصطلح “الديكتاتور الخير مدى الحياة” (BDFL) لوصف هذا النموذج عندما يكون الفريق الأساسي شخصًا واحدًا (عادةً مؤسس المشروع).

يمكن أن يكون له ميزة الرؤية القوية التي لا تتأثر بالاتجاهات العابرة، ولكن يمكن أن يكون له أيضًا عيب المشروع عدم الاستجابة للتحولات المهمة في البيئة.

أمثلة: لينكس.

8. تنمية عامة مستقلة وخاضعة للمساءلة

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

وهذا له كل مزايا وعيوب الديمقراطية.

أمثلة: بايثون، كوبيرنيتيس.

2023-01-27 23:58 بالتوقيت العالمي تحديد الأخطاء التي سيتم إصلاحها

البرنامج لديه عدد لا حصر له من الأخطاء. كيف يمكننا معرفة أي منها يجب إصلاحه؟

أقترح أنه من المنطقي تحسين سعادة الأشخاص لكل وحدة زمنية لإصلاح الأخطاء، مما يزيد من مقدار جهدنا لتحسين المنتج لمستخدمينا.

وبعبارة رياضية، نريد إصلاح الأخطاء ذات أعلى N.ΔH / T، حيث:

• ن هو عدد الأشخاص الذين يؤثر عليهم الخطأ
• “ح هي زيادة السعادة لكل مستخدم متأثر بالخلل
• ت هو تقدير لمقدار الوقت الذي سنستغرقه لإصلاح الخطأ

(من الصعب جدًا تقدير هذه المقاييس. لا تقلق كثيرًا بشأن الدقة هنا.)

الأخطاء التي تتحسن ت للأخطاء المستقبلية

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

تعتبر الأخطاء التي تؤثر على عدد أكبر من الأشخاص أكثر قيمة (تعظيم ن)

سنجعل المزيد من الناس أكثر سعادة إذا أصلحنا خطأ يعاني منه عدد أكبر من الأشخاص.

هناك شيء واحد يجب توخي الحذر بشأنه وهو التفكير في عدد الأشخاص الذين نتجاهلهم في مقاييسنا. على سبيل المثال، إذا كان لدينا خطأ يمنع منتجنا من العمل على Windows، فلن يكون لدينا أي مستخدمين لنظام Windows، وبالتالي لن يؤثر الخطأ على أحد. ومع ذلك، فإن إصلاح الخلل سيمكن الملايين من المطورين من استخدام منتجنا، وهذا هو العدد المهم.

تعتبر الأخطاء ذات التأثير الأكبر على المطورين أكثر قيمة (تعظيم “ح)

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

تعتبر الأخطاء التي يسهل إصلاحها أكثر قيمة (تقليل ت)

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

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

خطوات إعادة الإنتاج تجعل الخطأ أكثر قيمة

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

مرة أخرى، سنجعل المزيد من المستخدمين أكثر سعادة إذا قمنا بإصلاح المزيد من الأخطاء التي تؤثر على كل منها X الناس مما لو قمنا بإصلاح عدد أقل من الأخطاء (ولكنها أكثر خطورة) التي تؤثر على كل منها X الناس.

الاستثناءات

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

تحديد موعد المضي قدمًا

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

الاختيار بين المهام ذات الجدارة المتساوية

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

إن الإدراك الأساسي لحل هذه المعضلة هو أمر مثير للقلق ومثير للقلق إلى حد ما: لا يهم. يمكننا أن نفعل أي شيء نشعر به.

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

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

هذا لا يعني أن أيًا من هذه الأخطاء أو الميزات غير مهم. هذا يعني فقط أنهما متساويان في الأهمية، وقد فاز أحدهم باليانصيب وتم إصلاحه.

اقرأ أكثر