المحتوى عن 'مصدر مفتوح'.



مزيد من الخيارات

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المُحتوى


التصنيفات

  • التخطيط وسير العمل
  • التمويل
  • فريق العمل
  • دراسة حالات
  • نصائح وإرشادات
  • التعامل مع العملاء
  • التعهيد الخارجي
  • التجارة الإلكترونية
  • مقالات عامة

التصنيفات

  • PHP
    • Laravel
    • ووردبريس
  • جافاسكريبت
    • Node.js
    • jQuery
    • AngularJS
    • Cordova
  • HTML5
  • CSS
    • Sass
    • إطار عمل Bootstrap
  • SQL
  • سي شارب #C
    • منصة Xamarin
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • برمجة أندرويد
  • لغة Swift
  • لغة R
  • سير العمل
    • Git
  • صناعة الألعاب
    • Unity3D
  • مقالات عامّة

التصنيفات

  • تجربة المستخدم
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
    • كوريل درو
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • مقالات عامّة

التصنيفات

  • خواديم
    • الويب HTTP
    • قواعد البيانات
    • البريد الإلكتروني
    • DNS
    • Samba
  • الحوسبة السّحابية
    • Docker
  • إدارة الإعدادات والنّشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • مقالات عامة

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • استسراع النمو
  • المبيعات

التصنيفات

  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • مقالات عامة

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
  • أندرويد
  • iOS
  • macOS
  • ويندوز

التصنيفات

  • شهادات سيسكو
    • CCNA
  • شهادات مايكروسوفت
  • شهادات Amazon Web Services
  • شهادات ريدهات
    • RHCSA
  • شهادات CompTIA
  • مقالات عامة

أسئلة وأجوبة

  • الأقسام
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة البرمجة
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات
    • أسئلة الشهادات المتخصصة

التصنيفات

  • ريادة الأعمال
  • العمل الحر
  • التسويق والمبيعات
  • البرمجة
  • التصميم
  • DevOps

تمّ العثور على 3 نتائج

  1. ماذا يحدث إن أُجبرت على تطوير كل شفراتك البرمجية Codes المفضلة والسرية والمملوكة لك في مستودع Github عام؟ بالتأكيد ستُنتقَد؛ سينتقد أقرانك هذه الشفرات البرمجية، وسيضعون تعريفًا فضفاضًا “للشفرة البرمجية السليمة”يتضمن كل شيء بدءًا بالملف وتنظيم الأصناف والتوثيق والاختبارات وتجنب وضع مفاتيح واجهات التطبيقات البرمجية API في الشفرة وتقليص اعتمادك على ” أمن المعلومات عبر الغموض” وحتى الجودة الفنية التي لا يوجد معيار لها. سيفرض عليك التطوير علانية خلق شفرة جذابة وذات جودة عالية، وما يدفعك إلى ذلك هو رغبتك في إبهار الآخرين. لعل هذا شيء جيد، لكن ماذا عن عملك التجاري؟ هل انفضحت كل أسرارك، فازدادت قوة منافسيك وتظن نفسك انتهيت؟ بمعنى أنه إن كانت شفرتك مفتوحة المصدر، فلن تكون ذات ميزة تنافسية، لأن منافسيك يستطيعون أيضًا عملها، وبالتالي عليك أن تضيف ميزة تنافسية جديدة لعملك. على سبيل المثال، إن أظهرت شركة Esty خفاياها كاملة للعلن، هل يستطيع منافس أن يحل محلها؟ بالطبع لا، لأنهم قد صنعوا سوقًا، يكون فيه حضور المشترين والبائعين أصلًا أوليًّا من أصول الشركة. وهل سيتفوّق منافس على فيسبوك لأنها فتحت الآن مصادر البنية التحتية لمركز معلوماتها، ؟ بالطبع لا. قيمة هاتين الشركتين لا يمكن تملّكها بالمال، ولهذا السبب هما قيّمتان. قد تكون الميزة التنافسية التقنية ميزة دائمة في حالات نادرة، مثل جوجل (التي استمرت في الابتكار بسرعة عالية لدرجة أنه لم يسبقها أحد) أو لأي شخص يستطيع أخيرًا فك شفرة السيارات ذاتية القيادة. لكن هذه الحالات نادرة، فالمميزات التقنية متلاشية، لأن معظمها يمكن تقليده، بل عادة ما يكون التقليد أسرع وأرخص من المنتج الأصلي، وقد ثبت أن “الأسبق” ليس دائمًا “الأنجح” في السوق. لذلك، العمل علانية يدفعك إلى خلق ميزة تنافسية دائمة. ماذا عن الأسرار الشخصية بدلًا من التقنية؟ إن أعلنت عن مفردات راتب كل شخص في شركتك، لن تستطيع بعد ذلك المنافسة على الكفاءة على أساس التعويضات بمفردها. فإن لم تكن قادرًا على دفع زيادة 10 ألاف دولار في العام لنيل الموظف الكفء ذي الخبرة المناسبة، فسيدفعك هذا إلى بناء شركة حيث تريد الكفاءات العمل مع انخفاض الأجر. توجد العديد من الإرشادات التي توضح بناء بيئة مثل تلك، لكنها بوجه عام تتلخص في: الاستقلالية: أي حرية الاكتشاف، القدرة الكاملة على ابتكار حلول للمشاكل، والقدرة على برهنة هذه الحلول بالتنفيذ، مقابل تحمل مسؤولية النتائج) النمو: أي العمل على حل أحجيات ومشاكل شيقة، سواء شخصية أو مهنية، بالإضافة إلى تحقيق رحلة مهنية مُرضية، تنتقل من نجاح إلى نجاح، الهدف: أي لماذا يجب أن توجد هذه الشركة؟ لماذا تستحق بذل العناء لرؤيتها تنجح، بالإضافة إلى الثقافة، والقيم، ومتعة العمل مع الآخرين الذين تحبهم وتحترمهم. لذلك، العمل علانية يدفعك إلى خلق شركة ذات ثقافة استثنائية ومنظمة ذات تمكين وهدف. يعد كلٌّ من خلق ميزة تنافسية دائمة (بدون أسرار البرمجيات) وبناء ثقافة شركة تجذب وتستبقي الكفاءات المميزة لأسباب تتعدى الرشوة المالية مكونيْن حاسمين لخلق شركات تقنية مُعَمَّرة لا تعيق نموها ولا تمحو هويتها الشركات الناشئة ذات الفطنة والمال والمجتهدة في العملالتي ستظهر حتما في أي سوق كبيرة كفاية ليكون العمل فيها شيقًا. لذلك عند إظهار كل شيء علانية، فأنت مجبر على تقديم “الأكثر قيمة” بالإضافة إلى تقديم “ما لا يمكن تقليده” سواء كان هذا يعني إتقان صنعتك أو إخفاء سر عملك أو جذب الكفاءات. لا يزال من الممكن أن تعمل في السر، لكن ضوء الشمس ليس فقط المُطهِّر الأفضل، بل هو أفضل طريقة للتفوق في السوق. ترجمة – بتصرّف – للمقال Building in public forces true competitive advantage لصحابه Jason Cohen. حقوق الصورة البارزة محفوظة لـ Freepik
  2. يكون التجديد في نموذج العمل Business model عادةً أكثر تأثيرًا من التجديد التقني، كما أنه أكثر إزعاجا منه وأصعب في الاستنساخ. رغم ذلك لا تزال الكثير من الشركات ترتكز على التجديد التقني للمنافسة. حالة Airbnb تأمّل Airbnb. ما يجعل هذه الشركة ناجحة جدًّا ليس أفضليّة تقنية، بل نموذج أعمالها الذي يوفر لهم تكلفة قريبة من الصفر؛ ما يجعلها تتفوّق على سلاسل الفنادق التقليدية التي تحتاج إلى بناء مساحة مادية أكبر بتكلفة كبيرة. وبدلاً من تكلفة الإعداد، يمكن لشركة Airbnb إضافة غرفة أخرى إلى مخزونها دون أي تكاليف تقريباً من خلال تمكين الناس من مشاركة منازلهم القائمة. هذا هو التجديد في نموذج الأعمال. وعلاوة على ذلك، فإنه من الصعب للغاية لسلسة الفنادق التقليدية تبديل نموذج أعمالها لتتناسب مع نموذج عمل Airbnb . البرمجيات مفتوحة المصدر ينطبق الشيء نفسه على البرمجيّات مفتوحة المصدر. صحيح أن المصادر المفتوحة تُنتِج في كثير من الأحيان برامج متفوقة تقنياً، إلا أنّ قوتها الحقيقية تكمُن من تجديد نموذج الأعمال: المشاركة في الإنشاء. البرمجيات مفتوحة المصدر مثل دروبال أو لينكس هي منتجات خُلقت نتيجة المشاركة، فقد ساهم الآلاف في بناء دروبال وتعزيز مكانته، والجميع يستفيد من ذلك. يُنتِج مجتمع كبير للبرمجيّات مفتوحة المصدر أكثر بكثير من منافس بنفس الحجم، كما يتشارك في تقاسم تكاليف الإنتاج وإستراتيجية الدخول في السوق. يشوّش نموذج عمل البرمجيات مفتوحة المصدر كثيرا على شركات البرمجيات الخاصة التي توجد بها أدوار منفصلة لكل من الإنتاج والاستهلاك، بالإضافة للتكاليف المرتفعة للإنتاج والدخول في السوق. في حين يمكن للشركات الراسخة نسخ الابتكارات التقنية الأساسية للمصدر المفتوح، إلا أنه يصعُب عليها التبديل من نموذج الأعمال الاحتكاري إلى نموذج الأعمال مفتوح المصدر، لأن ذلك يُؤثر على كيفية بنائها لبرامجها، وكيفية تحقيق الدخل من البرامج، بالإضافة لكيفية بيعها وتسويقها لبرامجها، وهيكل التكاليف، وأكثر من ذلك بكثير. ستخسر شركات البرمجة الاحتكاريّة لصالح مجتمعات المصادر المفتوحة المزدهرة. لا يمكنني تصور كيف لشركات مثل HP، Oracle، SAP أن تغيّر نموذج أعمالها بينما تعيش فصلا ماليّا بعد الآخر في الأسواق العامة. يمكن لتغيير نموذج أعمال هذه الشركات أن يعرقل عائداتها وبالتأكيد سيستغرق التغيير سنوات طويلة. حالة Amazon Web Services خذ خدمات أمازون على سبيل المثال، إنها واحدة من أكثر التطورات إزعاجا في عالم تكنولوجيا المعلومات في العقد الماضي. في حين أن عروض AWS غنية وغالباً ما تكون في صدارة المنافسة، إلا أن أكبر سبب لنجاح الشركة هو نموذج أعمالها. فخدمات أمازون لا تعتمد فقط على التسعير القائم على الاستهلاك (ادفع بقدر ما تستهلك)، ولكنها أيضاً مريحة في تشغيل الأعمال ذات هامش الربح المنخفض. بعد 10 سنوات على إطلاق AWS تقريباً، هناك كميات هائلة من البيانات تتحرك في سحابتها. في حين أن Oracle، SAP وHP لا تملك حتى الآن سحابة أعمال تنافسية. رغم أنه كان بإمكان كلّ واحدة من هذه الشركات أن تعوِّض تأخرها التقني أمام أمازون، إلا أنه لم يكن بإمكانها تعديل نموذج عملها القائم فعلا. خاتمة من السهل جدًّا أن تجدّد في نموذج العمل بالنسبة للشركات الناشئة مقارنةً بالشركات الراسخة. في الواقع فإن نموذج العمل المبتكر هو أفضل سلاح لديك ضد الشركات الكبيرة. قد يعطيك الابتكار التقني ميزة تنافسية لمدة تتراوح بين 6-18 شهراً لا غير، ولكن ميزة التجدي في نموذج العمل يمكن أن تمنحك ميزة تنافسية لسنوات قادمة. تركّز كثير من الشركات الناشئة على إنشاء تقنيات مبتكرة أو الحصول عليها من شركات احتكاريّة بهدف الفوز في السوق. تأتي الشركات الناشئة عادةً بابتكارات تقنية في نقاط عدّة، إلا أنّ ما يؤدّي إلى منظمة ناجحة تدوم طويلا هو الإبداع في نموذج العمل؛ إذ أن نماذج العمل المبتكرة تميل إلى أن تكون مستعصية على الاستنساخ مقارنة بالابتكارات التقنية. ترجمة - بتصرّف - للمقال Business model innovation beats technical innovation لصاحبه Dries Buytaert. حقوق الصورة البارزة محفوظة لـ Freepik
  3. ما الذي يجعل مشروعك مفتوح المصدر؟ أن تكون الشّيفرة متوفرةً مجانًا على الإنترنت؟ أو أن تستطيع استعماله، أو تعديله وإرساله إلى صديقك؟ إذا ابتغينا الدقة، فإن الرخصة هي التي تعطيك الامتيازات لفعل كل ما سبق ذكره. فعندما "تفتح" مصدر مشروعك، فعليك أن تُضمِّن ملف رخصة يُحدِّد ما هي الشروط التي سيُسمَح للآخرين باستعمال مشروعك وفقًا لها. لحسن الحظ، هنالك خياراتٌ عديدةٌ يمكنك الاختيار بينها، فلا حاجة إلى أن تكون محاميًا لفعل ذلك؛ لكن لسوء الحظ هنالك الكثير من الرخص، مما يجعلك تحتار أيهم ستختار. تنبيه: هذه هي طريقة ترخيص مشاريعي الخاصة، لكنني لست محاميًا وهذه المقالة لا تُمثِّل نصيحة قانونية. ما هي الرخص؟ عدد الرخص التي يمكن اعتبارها "حرة" (free) أو مفتوحة المصدر (open-source) بالمئات! إذا كنت تريد قوائم طويلة، فراجع القوائم الموجودة على موقع مشروع GNU و opensoucre.org أو على ويكيبيديا، وحتى تلك القوائم الطويلة ليست شاملة لجميع الرخص. وعلى الرغم من التعداد الكبير للرخص، لكن الفروقات بينها ليست محورية؛ والسبب وراء وجود عدد كبير منها هو أنَّ كاتبيها صعيبو المراس في اختيار الكلمات وبعض التفاصيل، لكن يمكن اعتبار شروط الكثير منها متماثلة. ادخل إلى موقع tl;drLegal لمراجعة سريعة لشروط مختلف الرخص. الرخص المتساهلة و Copyleft أكبر أمر يُفرِّق بين الرخص هو Copyleft، وهو مصطلحٌ أوجده مشروع غنو (GNU) لمنع الأشخاص الذين سيعيدون توزيع البرمجيات في المستقبل من تقييد الحريات التي أعطيتَها للمشروع عند إطلاقه، وهذا يعني أنَّه على أيّ شخصٍ يريد أن يُعيد توزيع نسخةٍ مُعدَّلةٍ من الشيفرة التي كتبتَها أن ينشر تعديلاته أيضًا. تُطبِّق بعض الرخص ذاك المبدأ (مثل GPL، و LGPL، وMPL) بينما لا تُطبقه الأخرى (مثل MIT، و Apache، و BSD). قد تكون رخص "copyleft" مفيدةً جدًا لمنع إساءة استعمال مشروعك، وقد تكون في بعض الأحيان معيقةً لاستعماله من الشركات التي قد لا تقدر على استعمال شيفرات مرخصة بتلك الرخصة في برمجياتها التجارية. مجال مشروعك أحد أهم الأشياء التي يجب أخذها بعين الاعتبار عند اختيار رخصة لمشروعك هو "المجال"؛ هل هو مكتبة برمجية، أم أداة للمطورين، أم تطبيق كامل للمستخدم النهائي؟ إذا كان سيُستعمَل مع مكتباتٍ أخرى، فعليك أن تكون حذرًا في اختيارك للرخصة بسبب مشاكل في التوافقية بين الرخص (سنشرح ذلك بعد قليل). أختارُ للتطبيقات الكاملة أو المنتجات، مثل تطبيقات الأندرويد أو تطبيقات سطح المكتب أو الأدوات التي تعمل من سطر الأوامر، رخصًا من نمط copyleft مثل GPLv3 التي تطمئنني أنَّ المشروع سيبقى مفتوح المصدر دومًا. وعندما تُطلِقُ مكتبة أو إطار عمل ليستعمله المطورون في مشاريعهم، فإن اختيارك سيصبح أكثر صعوبةً. فعدم السماح لهم بتوزيع برمجياتهم التي تعتمد على مكتبتك دون التضمين الكود المصدري قد يمنع الشركات من استعمالها في مشاريعهم، مما يمنع انتشارها انتشارًا واسعًا. شخصيًا، أستعمل رخصًا متساهلة في هذه الحالة، مثل MIT أو BSD؛ وبينما تترك تلك الرخص احتمال أن تشتق الشركات مصدر المشروع الخاص بك، وتطوره ولا تعطيك التعديلات عليه، لكن ذلك غير عملي أو منطقي لكثيرٍ من الشركات؛ لأن الاختلاف من مصدر الشيفرة الأصلي سيجعلهم يتحملون عبء تكاليف الصيانة التي تتجاوز عادةً قيمة التّعديل الذي أجروه على شيفرة مشروعك. رخصة LGPL ليست خيارًا سيئًا أيضًا، إذ تسمح للآخرين باستعمال نسخة مُصرَّفة (compiled) من المكتبة مع شيفراتهم المملوكة (proprietary أو الاحتكارية)، وفي نفس الوقت ستحافظ على حقوق مصدر المكتبة. المشاكل في التوافقية تحتوي بعض الرخص بنودًا تتعارض مع غيرها من الرخص؛ مما يجعلها غير متوافقة، مما يعني أنك لا تستطيع أن تدمج بين حزمتين برمجيتين أو مكتبتين مرخصتين برخصتين فيهما بنود متعارضة. انظر إلى الحزم البرمجية التي تستعملها في مشروعك، وحاول أن تختار رخصةً لا تتعارض مع بنود تلك الحزم. هنالك مصادرٌ عدِّة تستطيع الحصول على معلومات توافقية الرخص منها، بما في ذلك ويكيبيديا. تؤثر عادةً المشاكل في التوافقية على الرخص المعقَّدة والمحدَّدة مثل GPLv3؛ فكلما ازداد طول الرخصة وتخصيصها للبنود، كما ازدادت احتمالية حدوث مشاكل في التوافقية. تحقق من مجتمعك اعتمادًا على التقنيات التي يستعملها مشروعك، قد تجد أنَّ إحدى الرخص أفضل وأنسب من الأخرى، آخذًا بعين الاعتبار سهولة دمج مشروعك وتبنيه، وخصيصًا لو كان مكتبةً. فاستعمال أكثر رخصة شائعة في مجالك ستُسهِّل الأمر على مستعمليها، لأنهم سيكونون معتادين على شروط تلك الرخصة، وسيتم تقليل احتمالية وجود تعارض في الرخص في المشاريع. على سبيل المثال، مجتمعَا JavaScript و Ruby يُحبذون الرخص الأكثر سماحيةً مثل MIT، بينما تُنشَر المشاريع المكتوبة بلغة C/C++‎ برخصة GPL. عليك أن تبحث قليلًا في المجتمع التطويري المحيط بك عندما تنشر مكتبة برمجية وفق رخصةٍ معينة، فذاك المجتمع قد يساعدك بقرارك. لكن لا تُكرِه نفسك على رخصة معينة لأن الآخرين يستعملونها، فقد لا تكون خيارًا صائبًا لمشروعك. الخلاصة هي أنه اختيارك سيكون سديدًا إن كانت تتوافق الرخصة التي اخترها مع أغلبية المكتبات في مجتمعك. بدون رخصة إحصائيات الاستخدام التي نُشِرَت من Ben Balter على مدونة Github في مطلع عام 2015 تُظهِر أنَّ حوالي 80% من المستودعات على الموقع لا تُضمِّن رخصة؛ وهذا يعني أنَّ لا يُسمَح لأي شخص قانونيًا أن يستعمل الشيفرة الخاصة بهم حتى لو كانت متوفرة على الإنترنت لأنه لا يمكن اعتبارها "مفتوحة المصدر". هذا أمرٌ كارثي! إن لم يكن هذا ما تطمح له، فخذ وقتك للتفكير برخصة مناسبة، وإلا فلن "يلمس" أي مبرمج خبير الشيفرة الخاصة بك، ويعرض سمعته للخطر بدعوى قضائية. الخلاصة هذه هي الطريقة التي أتبعها لاختيار رخصة لمشروعي. لا يوجد خيار صائب أو خيار خاطئ في اختيارك للرخصة إن كنت تعي ما تفعل. اختر واحدةً تناسب احتياجاتك، وتأكد أن تختار رخصةً واحدةً على الأقل. ما هي الرخصة التي استعملتها لآخر مشروعٍ لك؟ أخبرنا في التعليقات. ترجمة -وبتصرّف- للمقال How to pick an open source licence for your code لصاحبه Radek Pazdera.