في حالة مجتمع مطوري البرامج، يعد التقارب على نهج تقني أمرًا أساسيًا. قد يؤدي وجود الكثير من الآراء حول كيفية التعامل مع الأمور إلى إعاقة التطوير، لذا هناك توازن يجب إيجاده بين قدر كبير من التنوع لإثارة الإبداع والكثير من تباين الآراء التي قد تعيق التطوير.
انظر إلى دعم ActivityPub في Discourse. بدأ النقاش منذ سنوات. في البداية، تم رفضه. لكن الإصرار والمثابرة في محاولة تشكيل اقتراح جعلا فريق Discourse يقبلون المحاولة وتفويض المهمة لفريق Pavilion، وها نحن هنا مع ActivityPub Plugin يعمل ويتكامل ببطء مع الميزات التي كانت تعتبر في البداية مستحيلة أو ضارة بـ Discourse. مع نضوج المكون الإضافي واكتساب دعم ActivityPub زخمًا، يتغير شكل المجتمع أيضًا.
لكن ربما أبتعد كثيرًا عن الموضوع. عندما كتبت عن متلازمة “لم تُخترع هنا” (NIH)، كنت أفكر تحديدًا في مثل هذه المواقف حيث توجد تذكرة لميزة ما، ويقوم شخص ما بالتقاطها وتقديم طريقة غير متوقعة تمامًا لمعالجة المشكلة، لا تتناسب مع الطريقة المعتادة للقيام بالأشياء في مشروع البرمجيات. ربما يشجع هذا النهج شخصًا آخر على تجربة طريقة أخرى غير عادية تمامًا، وبدلاً من التركيز على التطوير، قد يؤدي ذلك إلى تشتيت الجهود دون الكثير من التوجيه. في مثل هذه الحالات، عادة ما يكون التوجيه أكثر أهمية من التنوع، ولكن بعد ذلك، قد يكون العكس هو الصحيح (مثل دعم ActivityPub في Discourse…).
آمل أن يوضح هذا وجهة نظري، على الرغم من أنه قد لا يفعل ذلك. لست متأكدًا مما سيفعله الذكاء الاصطناعي به. 