الطريق الآخر إلى الأمام

سبتمبر 2001

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

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

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

تبين أن هذه خطة جيدة. الآن، بصفتها Yahoo Store، هذه البرمجيات هي أشهر أداة لبناء المتاجر عبر الإنترنت، مع حوالي 14000 مستخدم.

عندما بدأنا Viaweb، بالكاد فهم أحد ما قصدناه عندما قلنا إن البرنامج يعمل على الخادم. لم يبدأ الناس في فهم الأمر إلا بعد إطلاق Hotmail بعد عام. الآن يعرف الجميع أن هذا نهج صالح. يوجد الآن اسم لما كنا عليه: مزود خدمة التطبيقات، أو ASP.

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

الشيء التالي؟

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

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

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

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

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

الفوز للمستخدمين

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

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

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

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

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

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

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

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

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

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

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

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

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

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

مدينة الكود

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

في Viaweb، شملت البرمجيات تطبيقات كبيرة جدًا تحدث المستخدمون معها مباشرة، وبرامج استخدمتها تلك البرامج، وبرامج كانت تعمل باستمرار في الخلفية بحثًا عن المشاكل، وبرامج حاولت إعادة تشغيل الأشياء إذا تعطلت، وبرامج كانت تعمل بشكل دوري لتجميع الإحصائيات أو بناء فهارس للبحث، وبرامج قمنا بتشغيلها صراحةً لتنظيف الموارد أو نقل أو استعادة البيانات، وبرامج تظاهرت بأنها مستخدمون (لقياس الأداء أو كشف الأخطاء)، وبرامج لتشخيص مشاكل الشبكة، وبرامج للقيام بالنسخ الاحتياطي، وواجهات لخدمات خارجية، وبرامج قادت مجموعة رائعة من الأقراص التي تعرض إحصائيات الخادم في الوقت الفعلي (كانت ذات شعبية لدى الزوار، ولكنها لا غنى عنها بالنسبة لنا أيضًا)، وتعديلات (بما في ذلك إصلاحات الأخطاء) على البرمجيات مفتوحة المصدر، والكثير من ملفات التكوين والإعدادات. كتب Trevor Blackwell برنامجًا مذهلاً لنقل المتاجر إلى خوادم جديدة في جميع أنحاء البلاد، دون إيقافها، بعد أن استحوذت علينا Yahoo. قامت البرامج بإعلامنا، وإرسال الفاكسات والبريد الإلكتروني للمستخدمين، وإجراء معاملات مع معالجي بطاقات الائتمان، والتحدث مع بعضها البعض عبر المقابس، والأنابيب، وطلبات HTTP، و SSH، وحزم UDP، والذاكرة المشتركة، والملفات. حتى أن بعض Viaweb تضمنت غياب البرامج، حيث أن أحد مفاتيح أمان Unix هو عدم تشغيل الأدوات غير الضرورية التي قد يستخدمها الأشخاص لاختراق خوادمنا.

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

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

نظرًا لأن البرمجيات في تطبيق الويب ستكون مجموعة من البرامج بدلاً من ملف ثنائي واحد، يمكن كتابتها بأي عدد من اللغات المختلفة. عندما تكتب برمجيات سطح المكتب، فأنت مجبر عمليًا على كتابة التطبيق بنفس لغة نظام التشغيل الأساسي - مما يعني C و C++. وبالتالي، أصبحت هذه اللغات (خاصة بين غير التقنيين مثل المديرين ورجال الأعمال) تعتبر لغات لتطوير البرمجيات "الجادّة". ولكن هذا كان مجرد أثر للطريقة التي كان يجب تقديم برمجيات سطح المكتب بها. بالنسبة للبرمجيات القائمة على الخادم، يمكنك استخدام أي لغة تريدها. [3] اليوم يستخدم الكثير من أفضل المخترقين لغات بعيدة كل البعد عن C و C++: Perl و Python، وحتى Lisp.

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

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

الإصدارات

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

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

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

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

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

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

مع برمجيات الويب، لا يتعين عليك أبدًا إصدار البرمجيات قبل أن تعمل، ويمكنك إصدارها بمجرد أن تعمل.

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

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

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

بحلول الوقت الذي تم فيه الاستحواذ علينا، كنا قد فعلنا ذلك ثلاث مرات، لذلك كنا في الإصدار 4. الإصدار 4.1 إذا كنت أتذكر بشكل صحيح. بعد أن أصبحت Viaweb Yahoo Store، لم تعد هناك حاجة ماسة للدعاية، لذلك على الرغم من استمرار تطور البرمجيات، تم إسقاط فكرة أرقام الإصدارات بالكامل بهدوء.

الأخطاء

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

يتم استخدام برمجيات الويب على مدار الساعة، لذلك يتم وضع كل ما تفعله فورًا تحت الاختبار. تظهر الأخطاء بسرعة.

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

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

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

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

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

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

الدعم

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

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

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

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

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

المعنويات

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

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

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

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

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

بروكس في العكس

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

تمت كتابة Viaweb بواسطة ثلاثة أشخاص فقط. [7] كنت دائمًا تحت ضغط لتوظيف المزيد، لأننا أردنا أن يتم الاستحواذ علينا، وكنا نعلم أن المشترين سيواجهون صعوبة في دفع سعر مرتفع لشركة بها ثلاثة مبرمجين فقط. (الحل: وظفنا المزيد، لكننا أنشأنا مشاريع جديدة لهم.)

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

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

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

مراقبة المستخدمين

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

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

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

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

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

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

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

المال

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

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

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

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

عندما يستطيعون، تحب الشركات القيام بشيء يسمى التمييز في الأسعار، مما يعني فرض رسوم على كل عميل بقدر ما يستطيعون تحمله. [8] البرمجيات مناسبة بشكل خاص للتمييز في الأسعار، لأن التكلفة الهامشية قريبة من الصفر. هذا هو السبب في أن بعض البرمجيات تكلف أكثر للتشغيل على أجهزة Suns مقارنة بأجهزة Intel: الشركة التي تستخدم Suns ليست مهتمة بتوفير المال ويمكن فرض رسوم عليها بأمان. القرصنة هي فعليًا أدنى مستوى من التمييز في الأسعار. أعتقد أن شركات البرمجيات تفهم ذلك وتتغاضى عمدًا عن بعض أنواع القرصنة. [9] مع البرمجيات القائمة على الخادم، سيتعين عليهم إيجاد حل آخر.

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

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

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

العملاء

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

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

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

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

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

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

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

ابن الخادم

تشغيل البرمجيات على الخادم ليس شيئًا جديدًا. في الواقع، إنه النموذج القديم: جميع تطبيقات الكمبيوتر المركزي قائمة على الخادم. إذا كانت البرمجيات القائمة على الخادم فكرة جيدة جدًا، فلماذا خسرت في المرة الأخيرة؟ لماذا تفوقت أجهزة الكمبيوتر المكتبية على أجهزة الكمبيوتر المركزي؟

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

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

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

ألهم وصول أجهزة الكمبيوتر المكتبية الكثير من البرمجيات الجديدة، لأن كتابة التطبيقات لها بدت هدفًا يمكن تحقيقه للشركات الناشئة اليرقية. كان التطوير رخيصًا، وسيكون العملاء أفرادًا يمكنك الوصول إليهم من خلال متاجر الكمبيوتر أو حتى عن طريق البريد. كان التطبيق الذي دفع أجهزة الكمبيوتر المكتبية إلى التيار الرئيسي هو VisiCalc، أول جدول بيانات. كتبه رجلان يعملان في علية، ومع ذلك فعل أشياء لم تستطع برمجيات الكمبيوتر المركزي القيام بها. [11] كان VisiCalc تقدمًا كبيرًا، في وقته، لدرجة أن الناس اشتروا أجهزة Apple II فقط لتشغيله. وكانت هذه بداية اتجاه: فازت أجهزة الكمبيوتر المكتبية لأن الشركات الناشئة كتبت برمجيات لها.

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

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

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

إذا أرادت شركة إنشاء منصة تبني عليها الشركات الناشئة، فيجب عليها جعلها شيئًا يرغب المخترقون أنفسهم في استخدامه. هذا يعني أنها يجب أن تكون غير مكلفة ومصممة جيدًا. كان Mac شائعًا بين المخترقين عندما ظهر لأول مرة، وكثير منهم كتبوا برمجيات له. [13] ترى هذا أقل مع Windows، لأن المخترقين لا يستخدمونه. الأشخاص الذين يجيدون كتابة البرمجيات يميلون الآن إلى تشغيل Linux أو FreeBSD.

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

Microsoft

عندما ظهرت أجهزة الكمبيوتر المكتبية، كانت IBM هي العملاق الذي كان الجميع يخافه. من الصعب تخيل ذلك الآن، لكنني أتذكر الشعور جيدًا. الآن العملاق المخيف هو Microsoft، ولا أعتقد أنهم عميان عن التهديد الذي يواجههم كما كانت IBM. بعد كل شيء، بنت Microsoft أعمالها عمدًا في النقطة العمياء لـ IBM.

ذكرت سابقًا أن والدتي لا تحتاج حقًا إلى جهاز كمبيوتر مكتبي. معظم المستخدمين ربما لا يحتاجون. هذه مشكلة لـ Microsoft، وهم يعرفون ذلك. إذا تم تشغيل التطبيقات على خوادم بعيدة، فلا يحتاج أحد إلى Windows. ماذا ستفعل Microsoft؟ هل سيتمكنون من استخدام سيطرتهم على سطح المكتب لمنع، أو تقييد، هذا الجيل الجديد من البرمجيات؟

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

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

في عالم تطبيقات الويب، لا يوجد مكان تلقائي لـ Microsoft. قد ينجحون في جعل مكان لأنفسهم، لكنني لا أعتقد أنهم سيهيمنون على هذا العالم الجديد كما فعلوا في عالم تطبيقات سطح المكتب.

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

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

شركات ناشئة ولكن أكثر

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

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

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

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

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

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

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

جيد بما فيه الكفاية فقط

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

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

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

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

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

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

لماذا لا؟

كان E. B. White مسليًا عندما علم من صديق مزارع أن العديد من الأسوار الكهربائية لا يمر بها تيار. يبدو أن الأبقار تبتعد عنها، وبعد ذلك لا تحتاج إلى التيار. "انهضوا، أيها الأبقار!" كتب، "خذوا حريتكم بينما ينام الطغاة!".

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

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

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

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

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

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

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

قد لا تصدق ذلك، لكنني أعدك، Microsoft تخاف منك. قد لا يفعل المديرون المتوسطون المطمئنون ذلك، لكن Bill يفعل ذلك، لأنه كان أنت مرة واحدة، في عام 1975، آخر مرة ظهر فيها طريقة جديدة لتقديم البرمجيات.

ملاحظات

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

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

[3] في عام 1995، عندما بدأنا Viaweb، كان من المفترض أن تكون تطبيقات Java هي التكنولوجيا التي سيستخدمها الجميع لتطوير تطبيقات قائمة على الخادم. بدت التطبيقات لنا فكرة قديمة. تنزيل البرامج للتشغيل على العميل؟ أبسط من الذهاب بالكامل وتشغيل البرامج على الخادم. لقد أضعنا القليل من الوقت في التطبيقات، ولكن لا حصر لها من الشركات الناشئة الأخرى يجب أن تكون قد انجذبت إلى هذا المستنقع. قليلون يمكن أن يكونوا قد نجوا على قيد الحياة، أو لم يكن بإمكان Microsoft الإفلات من إسقاط Java في أحدث إصدار من Explorer.

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

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

[6] داخل Viaweb، أجرينا ذات مرة مسابقة لوصف أسوأ شيء في برمجياتنا. تعادل شخصان من دعم العملاء للمركز الأول بإدخالات ما زلت أرتجف عند تذكرها. قمنا بإصلاح كلتا المشكلتين على الفور.

[7] كتب روبرت موريس نظام الطلبات، الذي استخدمه المتسوقون لتقديم الطلبات. كتب تريفور بلاكويل مولد الصور والمدير، الذي استخدمه التجار لاسترداد الطلبات وعرض الإحصائيات وتكوين أسماء النطاقات وما إلى ذلك. كتبت المحرر، الذي استخدمه التجار لبناء مواقعهم. تم كتابة نظام الطلبات ومولد الصور بلغة C و C++، والمدير في الغالب بلغة Perl، والمحرر بلغة Lisp.

[8] التمييز في الأسعار منتشر للغاية (كم مرة سمعت بائع تجزئة يدعي أن قوته الشرائية تعني أسعارًا أقل لك؟) لدرجة أنني فوجئت بالعثور على أنه غير قانوني في الولايات المتحدة بموجب قانون روبنسون-باتمان لعام 1936. لا يبدو أن هذا القانون يُنفذ بقوة.

[9] في No Logo، تقول نعومي كلاين إن العلامات التجارية للملابس التي يفضلها "شباب الحضر" لا تحاول جاهدة منع السرقة من المتاجر لأنهم في سوقهم المستهدف هم قادة الموضة.

[10] تتساءل الشركات غالبًا عما يجب تفويضه وما لا يجب. أحد الإجابات الممكنة: تفويض أي وظيفة لا تتعرض مباشرة للضغط التنافسي، لأن تفويضها سيعرضها للضغط التنافسي.

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

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

[13] إذا كان Mac رائعًا جدًا، فلماذا خسر؟ التكلفة، مرة أخرى. ركزت Microsoft على أعمال البرمجيات، وأطلقت سربًا من موردي المكونات الرخيصة على أجهزة Apple. لم يساعد أيضًا أن الشركات تولت زمام الأمور خلال فترة حرجة.

[14] أحد الأشياء التي ستساعد تطبيقات الويب، وتساعد في منع الجيل القادم من البرمجيات من أن تطغى عليها Microsoft، سيكون متصفحًا جيدًا مفتوح المصدر. Mozilla مفتوح المصدر ولكنه يبدو أنه عانى من كونه برمجيات شركات لفترة طويلة. سيكون المتصفح الصغير والسريع الذي تتم صيانته بنشاط شيئًا رائعًا بحد ذاته، ومن المحتمل أن يشجع الشركات أيضًا على بناء أجهزة ويب صغيرة.

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

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

[15] يكتب Trevor Blackwell، الذي ربما يعرف أكثر عن هذا من تجربته الشخصية أكثر من أي شخص آخر:

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

[16] في النسخة الأصلية من هذه المقالة، نصحت بتجنب Javascript. كانت هذه خطة جيدة في عام 2001، لكن Javascript يعمل الآن.

شكر لسارة هيرلين، وتريفور بلاكويل، وروبرت موريس، وإريك ريموند، وكين أندرسون، ودان غيفين لقراءة مسودات هذه الورقة؛ لدان بريكلين وبوب فرانكستون للحصول على معلومات حول VisiCalc؛ ومرة أخرى لكين أندرسون لدعوتي للتحدث في BBN.

ستجد هذه المقالة و 14 مقالة أخرى في Hackers & Painters.