البحث في الموقع

الحوسبة خفيّة الخوادم (Serverless computing) في طريقها لإحداث ثورة في طرق تطوير البرمجيّات المتعارف عليها. ستساعدك المنصّات المفتوحة المصدر التي نقدّمها هنا في التعرّف على هذا المجال. كثُر الحديث في الآونة الأخيرة عن خفاء الخوادم (Serverless)، فلنوضّح المعنى المقصود بهذا المصطلح، والمصطلحات المرتبطة به، مثل الحوسبة خفيّة الخوادم (Serverless computing) والمنصّات خفيّة الخوادم (Serverless platform). يُستخدَم مصطلح خفاء الخوادم عادةً على أنّه مرادف لتقديم الوظائف بصيغة خدمات (Functions-as-a-Service, FaaS)؛ إلّا أنّ المصطلح لا يعني غيّاب الخادم، عكس ما قد يوحي به الاسم. في الواقع، توجد خوادم عدّة لأنّ مزوّدي الخدمات السحابيّة للعموم يوفّرون خوادم تنشُر، وتشغّل ، وتدير تطبيقك. تعدّ الحوسبة خفيّة الخوادم قسمًا جديدًا يمثّل تحوّلًا في الطريقة التي يبني بها المطوّرون ويوزّعون الأنظمة البرمجية. يمكن أن يؤدّي عزلُ البنية التحتيّة للتطبيقات عن الشفرة البرمجيّة إلى تسهيل عمليّة التطوير مع الحصول على فوائد أخرى من حيث التكلفة والفاعليّة. يرى عدد من المتخصّصين أنّ الحوسبة خفيّة الخوادم وFaaS ستلعبان دورًا أساسيًّا في تحديد أبعاد الحقبة القادمة من تقنيّة المعلومات في المؤسسّات، جنبًا لجنب مع خدمات السحابة الأصيلة Cloud-native والخدمات السحابيّة الهجينة (Hybrid cloud). توفّر المنصّات خفيّة الاسم واجهات تطبيقات برمجيّة (API) تتيح للمستخدمين تشغيل دوالّ برمجيّة (تُسمّى أيضًا إجراءات (Actions)) وتُرجِع نتيجة تشغيل كلّ دالة. توفّر المنصّات خفيّة الخادم كذلك نهايات HTTPS لتمكين المطوّر من الحصول على نتائج الدالّة. يمكن استخدام هذه النهايات (Endpoints) لتكون مُدخلًا Input لدوالّ أخرى؛ وبالتالي توفير متتاليّة (أو سلسلة) من الدوالّ المترابطة. تعمل أغلب المنصّات خفيّة الاسم بحيث ينشُر المستخدم (أو يُنشئ) الدوالّ قبل تنفيذها. يتوفّر لدى المنصّة بعد ذلك كلّ ما يلزم لتنفيذ الشفرة البرمجيّة حالما يُطلب منها ذلك. يُمكن طلب تنفيذ الدالّة خفيّة الخادم يدويًّا بتنفيذ أمر، أو يمكن التسبّب في تنفيذها عبر حدث مرجعي مُعدّ لتنشيط الدالّة للإجابة على أحداث مثل إشعار Cron، وتحميل ملفّ، وأحداث أخرى كثيرة. سبع منصّات مفتوحة المصدر للتعرّف على الحوسبة خفيّة الخوادم Apache OpenWhisk: منصّة مفتوحة المصدر تمكّنك من تنفيذ شفرة برمجيّة استجابةً للأحداث مهما كان عددها. كُتبت المنصّة بلغة Scala، ويمكنها معالجة مُدخلات انطلاقًا من طلبات HTTP ثم تشغيل شفرات برمجيّة مكتوبة بلغة جافاسكريبت أو سويفت Swift. Fission: إطار عمل للحوسبة خفيّة الخوادم يمكّن المطوّرين من إنشاء دوالّ باستخدام Kubernetes. يتيح إطار العمل هذا للمبرمجين كتابة دوالّ تدوم لمدّة قصيرة بأيّة لغة برمجة، وربطها بأي حدث مثل طلبات HTTP. IronFunctions: إطار عمل للحوسبة خفيّة الخوادم يوفّر منصّة للخدمات الصغيرة (Microservices) المترابطة، عن طريق دمج الخدمات الموجودة والاستفادة من Docker. يكتُب المطوّرون الدوالّ بلغة Go. FnProject: منصّة خفيّة الخوادم مُوجَّهة أساسًا للحاويّات يمكن تشغيلها في أي مكان على السحابة أو في البنية التحتيّة الداخليّة. استخدام المنصّة سهل، كما أنّها عاليّة الأداء، و تدعم لغات البرمجة جميعًا، ويمكن توسعتها. OpenLambda: مشروع حوسبة خفيّة الخوادم مُرخص برخصة Apache، ومكتوب بلغة Go، ويعتمد على حاويّات لينكس. يهدف OpenLambda في المقام الأول إلى التمكين من استغلال المقاربات الجديدة للحوسبة خفيّة الخوادم. Kubeless: إطار عمل يعتمد على Kubernetes ويسمح للمطوّر بنشر شفرات برمجيّة قصيرة دون التفكير في البنية التحتيّة المستخدمة. يعتمد Kubeless على موارد Kubernetes لتوفير قابليّة التوسّع الذاتيّة، وتوجيه واجهات التطبيقات البرمجية، والمراقبة، والتشخيص وغيرها. OpenFaas: إطار عمل لبناء دوالّ خفيّة الخوادم باستخدام Docker وKubernates؛ يوفّر دعمًا مدمجًا للقيّاسات والإحصاءات. يُمكن تحزيم أي عمليّة Process على هيئة دالّة، ممّا يسمح باستغلال مجموعة من أحداث الويب دون الحاجة لكتابة شفرات مُكرَّرة. يعدّ Kubernates المنصّة الأكثر انتشارًا لإدارة أحمال العمل في المنصّات خفيّة الخوادم، وحاويّات التطبيقات ذات الخدمات الصغيرة. يستخدم Kubernates نموذج نشر معدًّا بدقّة لمعالجة أحمال العمل بسرعة أكبر وسهولة أكثر. يمكّن Knative Serving من بناء خدمات وتطبيقات خفيّة الخوادم ونشرها على Kubernates، مع استخدام Istio للتوسّع ودعم سيناريوهات عمل متقدّمة، مثل: النشر السريع لحاويات خفيّة الخوادم التوسع والتقلّص التلقائيّيْن (Scaling up and down) التوجيه وبرمجة الشبكات بالنسبة لعانصر Istio أخذ لقطات (Snapshots) من الشفرة المنشورة والإعدادات في نقاط زمنيّة محدّدة. يركّز Knative على المهامّ الاعتيّاديّة من بناءٍ للتطبيقات وتشغيلها على منصّات السحابة الأصليّة (Cloud-native)؛ بهدف تنسيق عمليّات البناء من الشفرة البرمجيّة إلى الحاويّة، وربط الخدمات بأحداث النظام، وتوجيه حركة البيانات وإدارتها أثناء النشر، والتوسّع التلقائي حسب حمل العمل. أمّا Istio، فهو منصّة مفتوحة للاتّصال بالخدمات الصغيرة وتأمينها (وهو في الواقع مستوى تحكّم بنسيج الخدمة Service mesh في الوسيط Envoy) صُمِّم ليتناسب مع تفاعل أشخاص مختلفين مع إطار العمل بما في ذلك المطوّرون، عمّال الصيّانة ومزوّدو الخدمات. يمكن – على سبيل المثال – نشر جافاسكريبت خفيّة الخادم باستخدام Knative Serving على منصّة Minishift محليّة باتّباع الشفرة التاليّة: ## Dockerfile FROM bucharestgold/centos7-s2i-nodejs:10.x WORKDIR /opt/app-root/src COPY package*.json ./ RUN npm install COPY . . EXPOSE 8080 3000 CMD ["npm", "start"] ## package.json { "name": "greeter", "version": "0.0.1", "private": true, "scripts": { "start": "node app.js" }, "dependencies": { "express": "~4.16.0" } } ## app.js var express = require("express"); var app = express(); var msg = (process.env.MESSAGE_PREFIX || "") + "NodeJs::Knative on OpenShift"; app.get("/", function(req, res, next) { res.status(200).send(msg); }); app.listen(8080, function() { console.log("App started in port 8080"); }); ## service.yaml apiVersion: serving.knative.dev/v1alpha1 kind: Service metadata: name: greeter spec: configuration: revisionTemplate: spec: container: image: dev.local/greeter:0.0.1-SNAPSHOT أنشئ تطبيق Node.js وانشره على منصّة Kubernates المحليّة. ستحتاج لتثبيت متطلّبات المنصّة (Knative، و Istio، و Knative Serving على Kubernetes (أو Minishift)). اربط المنصّة بخدمة Docker بالأمر التالي: (minishift docker-env) && eval(minishift oc-env) أنشئ نسخة من حاوية خفيّة الخادم باستخدام Jib عبر الأمر التالي: ./mvnw -DskipTests clean compile jib:dockerBuild انشر خدمة خفيّة الاسم مثل Minishift على عنقود Kubernates بالأمر التالي: kubectl apply -f service.yaml خاتمة يوضّح المثال أعلاه أين وكيف يمكن البدء في تطوير تطبيقات خفيّة الخادم باستخدام منصّات سحابة أصليّة مثل Kubernates، و Knative Serving وIstio. ترجمة - بتصرّف - للمقال 7 open source platforms to get started with serverless computing لصاحبه Daniel Oh.

ماذا يحدث إن أُجبرت على تطوير كل شفراتك البرمجية Codes المفضلة والسرية والمملوكة لك في مستودع Github عام؟ بالتأكيد ستُنتقَد؛ سينتقد أقرانك هذه الشفرات البرمجية، وسيضعون تعريفًا فضفاضًا “للشفرة البرمجية السليمة”يتضمن كل شيء بدءًا بالملف وتنظيم الأصناف والتوثيق والاختبارات وتجنب وضع مفاتيح واجهات التطبيقات البرمجية API في الشفرة وتقليص اعتمادك على ” أمن المعلومات عبر الغموض” وحتى الجودة الفنية التي لا يوجد معيار لها. سيفرض عليك التطوير علانية خلق شفرة جذابة وذات جودة عالية، وما يدفعك إلى ذلك هو رغبتك في إبهار الآخرين. لعل هذا شيء جيد، لكن ماذا عن عملك التجاري؟ هل انفضحت كل أسرارك، فازدادت قوة منافسيك وتظن نفسك انتهيت؟ بمعنى أنه إن كانت شفرتك مفتوحة المصدر، فلن تكون ذات ميزة تنافسية، لأن منافسيك يستطيعون أيضًا عملها، وبالتالي عليك أن تضيف ميزة تنافسية جديدة لعملك. على سبيل المثال، إن أظهرت شركة Esty خفاياها كاملة للعلن، هل يستطيع منافس أن يحل محلها؟ بالطبع لا، لأنهم قد صنعوا سوقًا، يكون فيه حضور المشترين والبائعين أصلًا أوليًّا من أصول الشركة. وهل سيتفوّق منافس على فيسبوك لأنها فتحت الآن مصادر البنية التحتية لمركز معلوماتها، ؟ بالطبع لا. قيمة هاتين الشركتين لا يمكن تملّكها بالمال، ولهذا السبب هما قيّمتان. قد تكون الميزة التنافسية التقنية ميزة دائمة في حالات نادرة، مثل جوجل (التي استمرت في الابتكار بسرعة عالية لدرجة أنه لم يسبقها أحد) أو لأي شخص يستطيع أخيرًا فك شفرة السيارات ذاتية القيادة. لكن هذه الحالات نادرة، فالمميزات التقنية متلاشية، لأن معظمها يمكن تقليده، بل عادة ما يكون التقليد أسرع وأرخص من المنتج الأصلي، وقد ثبت أن “الأسبق” ليس دائمًا “الأنجح” في السوق. لذلك، العمل علانية يدفعك إلى خلق ميزة تنافسية دائمة. ماذا عن الأسرار الشخصية بدلًا من التقنية؟ إن أعلنت عن مفردات راتب كل شخص في شركتك، لن تستطيع بعد ذلك المنافسة على الكفاءة على أساس التعويضات بمفردها. فإن لم تكن قادرًا على دفع زيادة 10 ألاف دولار في العام لنيل الموظف الكفء ذي الخبرة المناسبة، فسيدفعك هذا إلى بناء شركة حيث تريد الكفاءات العمل مع انخفاض الأجر. توجد العديد من الإرشادات التي توضح بناء بيئة مثل تلك، لكنها بوجه عام تتلخص في: الاستقلالية: أي حرية الاكتشاف، القدرة الكاملة على ابتكار حلول للمشاكل، والقدرة على برهنة هذه الحلول بالتنفيذ، مقابل تحمل مسؤولية النتائج) النمو: أي العمل على حل أحجيات ومشاكل شيقة، سواء شخصية أو مهنية، بالإضافة إلى تحقيق رحلة مهنية مُرضية، تنتقل من نجاح إلى نجاح، الهدف: أي لماذا يجب أن توجد هذه الشركة؟ لماذا تستحق بذل العناء لرؤيتها تنجح، بالإضافة إلى الثقافة، والقيم، ومتعة العمل مع الآخرين الذين تحبهم وتحترمهم. لذلك، العمل علانية يدفعك إلى خلق شركة ذات ثقافة استثنائية ومنظمة ذات تمكين وهدف. يعد كلٌّ من خلق ميزة تنافسية دائمة (بدون أسرار البرمجيات) وبناء ثقافة شركة تجذب وتستبقي الكفاءات المميزة لأسباب تتعدى الرشوة المالية مكونيْن حاسمين لخلق شركات تقنية مُعَمَّرة لا تعيق نموها ولا تمحو هويتها الشركات الناشئة ذات الفطنة والمال والمجتهدة في العملالتي ستظهر حتما في أي سوق كبيرة كفاية ليكون العمل فيها شيقًا. لذلك عند إظهار كل شيء علانية، فأنت مجبر على تقديم “الأكثر قيمة” بالإضافة إلى تقديم “ما لا يمكن تقليده” سواء كان هذا يعني إتقان صنعتك أو إخفاء سر عملك أو جذب الكفاءات. لا يزال من الممكن أن تعمل في السر، لكن ضوء الشمس ليس فقط المُطهِّر الأفضل، بل هو أفضل طريقة للتفوق في السوق. ترجمة – بتصرّف – للمقال Building in public forces true competitive advantage لصحابه Jason Cohen. حقوق الصورة البارزة محفوظة لـ Freepik

يكون التجديد في نموذج العمل 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

ما الذي يجعل مشروعك مفتوح المصدر؟ أن تكون الشّيفرة متوفرةً مجانًا على الإنترنت؟ أو أن تستطيع استعماله، أو تعديله وإرساله إلى صديقك؟ إذا ابتغينا الدقة، فإن الرخصة هي التي تعطيك الامتيازات لفعل كل ما سبق ذكره. فعندما "تفتح" مصدر مشروعك، فعليك أن تُضمِّن ملف رخصة يُحدِّد ما هي الشروط التي سيُسمَح للآخرين باستعمال مشروعك وفقًا لها. لحسن الحظ، هنالك خياراتٌ عديدةٌ يمكنك الاختيار بينها، فلا حاجة إلى أن تكون محاميًا لفعل ذلك؛ لكن لسوء الحظ هنالك الكثير من الرخص، مما يجعلك تحتار أيهم ستختار. تنبيه: هذه هي طريقة ترخيص مشاريعي الخاصة، لكنني لست محاميًا وهذه المقالة لا تُمثِّل نصيحة قانونية. ما هي الرخص؟ عدد الرخص التي يمكن اعتبارها "حرة" (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.