منبع: اينفو ورلد ترجمه: کيومرث سلطاني اشاره: يک مجله مربوط به خودرو زماني اعلام کرده بود، كه اگر توضيح خصوصيات يك خودرو پيش از قرض دادنش به يك دوست بيش از 15 دقيقه طول بكشد،آن خودرو «داراي كاراكتر » يا شخصيت است. با توجه به اين استاندارد، هر قطعه نرم‌افزاري داراي کاراکتر است. بيشتر ويژگي‌هاي خاص برنامه‌نويسي وابستگي شديدي به Context خاصي که در آن مطرح مي‌شوند داشته و به همين دليل توصيف آن‌ها مي‌تواند با ابهام همراه باشد. به عنوان مثال، سايت‌هايي که داده‌هاي XML را عرضه مي‌كنند ممکن است به شيوه‌اي نوشته نشده باشند که به مرورگر اعلام کنند انتظار داده‌هاي XML را داشته باشد. اين باعث مي‌شود تا زماني که مقدار درستي در فيلد مخصوص نوشته نشود، کل کارايي نرم‌افزار زير سؤال برود. يک مجله مربوط به خودرو زماني اعلام کرده بود، كه اگر توضيح خصوصيات يك خودرو پيش از قرض دادنش به يك دوست بيش از 15 دقيقه طول بكشد،آن خودرو «داراي كاراكتر» يا شخصيت است. با توجه به اين استاندارد، هر قطعه نرم‌افزاري داراي کاراکتر است. بيشتر ويژگي‌هاي خاص برنامه‌نويسي وابستگي شديدي به Context خاصي که در آن مطرح مي‌شوند داشته و به همين دليل توصيف آن‌ها مي‌تواند با ابهام همراه باشد. به عنوان مثال، سايت‌هايي که داده‌هاي XML را عرضه مي‌كنند ممکن است به شيوه‌اي نوشته نشده باشند که به مرورگر اعلام کنند انتظار داده‌هاي XML را داشته باشد. اين باعث مي‌شود تا زماني که مقدار درستي در فيلد مخصوص نوشته نشود، کل کارايي نرم‌افزار زير سؤال برود. با اين حال، تعدادي اصول در برنامه‌نويسي وجود دارند که باعث مي‌شوند برنامه‌نويسان با استفاده از آن‌ها پروژه‌هاي قابل فهم‌تر و سرراست‌تر توليد كنند. اگر زماني را در رستوران‌هاي نزديک شرکت‌هاي مرتبط با فناوري گذرانده باشيد، حتماً چنين سؤال‌هايي را شنيده‌ايد: چرا فلان برنامه‌نويس از فلان ساختار منسوخ استفاده کرده است؟ مکانيزم‌هاي جلوگيري از حمله از سوي وب کجا هستند؟ آيا مي‌دانندکه مسائل تازه، با برنامه چه کاري انجام خواهند داد؟ به نظر مي‌رسد، برنامه‌نويسان که در واقع موجوداتي وابسته به تفريح و لذت هستند، دچار حالت‌هاي مشکل‌زايي مي‌شوند که نمي‌توان از آن‌ها دوري كرد. به‌طور معمول اين حالت‌ها وقتي پيش مي‌آيند که آن‌ها درگير عادت‌هايي مشکل‌زا در برنامه‌نويسي مي‌شوند.در ادامه فهرستي از رايج‌ترين دام‌هاي برنامه‌نويسي را مشاهده مي‌کنيد. هر مورد از اين فهرست بلافاصله با زوج مخالف خود همراه شده و اين اثباتي ديگر بر اين ادعا است که برنامه‌نويسي در حال تبديل به يک هنر است. هنري که نيازمند دستاني توانا و ذهني خلاق براي دست يافتن به حدي متعادل و معقول ميان ايده‌آل‌هايي پيچيده است. اشتباه 1: سريع و بي‌دقت بازي کردندر نظر نگرفتن موارد اوليه کار، راحت‌ترين روش براي از کار انداختن کد است. معمولاً اين نکته به معناي در نظر نگرفتن نحوه رفتار يک کاربر دلخواه است. آيا ورودي صفر در يک عمليات تقسيم مورد استفاده قرار مي‌گيرد؟ آيا متن Submit شده طول مناسب دارد؟ آيا فرمت تاريخ رعايت شده است؟ آيا نام کاربري در پايگاه داده تأييد شده است؟ اشتباه در کوچک‌ترين بخش‌ها مي‌تواند کارکرد کل نرم‌افزار را به خطر بياندازد. بدترين بخش ماجرا اين است که پيشرفت‌هاي انجام شده با هدف برطرف كردن اين قبيل مشكلات معمولاً درست عمل نمي‌كنند. به عنوان مثال آخرين نسخه جاوا را در نظر بگيريد. اين نسخه تلاش مي‌کند تا با اضافه کردن يک سينتکس ساده کار بررسي کردن Null-Pointer را به صورت هميشگي انجام دهد. فقط کافي است تا يک علامت سؤال به هر فراخواني متد اضافه كنيد تا به صورت خودكار Null Pointerها بررسي شوند. به اين ترتيب، ديگر به نوشتن قطعه کدي مانند زير نيازي نيست. <code> public String getPostcode(Person person) { String ans= null; if (person != null) { Name nm= person.getName(); if (nm!= null) { ans= nm.getPostcode(); } } return ans } </code> در عوض کافي است تا تنها بنويسيد: <code> public String getFirstName(Person person) { return person?.getName()?.getGivenName(); } </code> به هر ترتيب، در پايان چنين پيشرفت‌هايي در سينتکس تنها مي‌توانند سيستم را از Crash كردن نجات دهند و کارکرد درست آن را تضمين نمي‌کنند. در واقع ريشه مسئله، يعني ازدياد مقادير Null به دليل برنامه‌نويسي سريع و بي دقت از بين نمي‌رود. اشتباه 2: توجه بيش از حد به جزئياتاز يک طرف نرم‌افزارهايي با جزئيات بسيار زياد مي‌توانند به شدت کند عمل كنند. بررسي کردن چندين Null Pointer در کارايي تفاوت چنداني ايجاد نمي‌کند، اما بعضي از نرم‌افزارها به گونه‌اي نوشته مي‌شوند كه مانند افراد وسواسي هستند که بايد چندين بار بسته بودن در را بررسي كنند تا خوابشان ببرد. توجه بيش از اندازه نسبت به جزئيات مي‌تواند نرم‌افزار را دچار مشکل سازد، به خصوص زماني که اين بررسي کردن‌ها نيازمند ارتباط با يک سايت ديگر از طريق شبکه است. من پكيج‌هايي دارم که در صورت اجرا روي لپ‌تاپي بدون اتصال واي‌فاي به طرز قابل توجهي کند مي‌شوند. زيرا آن‌ها عميقاً سعي دارند به مبدأ خود متصل شده و دريابند که آيا نسخه جديدي از نرم‌افزار موجود است يا خير. در واقع چنين برنامه‌هايي پيوسته به دنبال Hotspot مي‌گردند که اصلاً در آنجا وجود ندارد.چالش در اينجا طراحي لايه‌هايي از کد است که در نخستين‌باري که ظاهر مي‌شوند، داده‌ها را بررسي مي‌كنند. اما انجام اين موضوع خيلي دشوارتر از آن چيزي است که به نظر مي‌آيد، به خصوص زماني که چندين برنامه‌نويس روي يک نرم‌افزار کار مي‌کنند.حتي در مواقعي که يک برنامه‌نويس تمام کار را انجام مي‌دهد، به يادآوردن اين‌که چه زماني پوينترها بايد بررسي شوند و اصولاً لزوم بررسي کردن آن‌ها بسيار دشوار است. اشتباه 3: ساده سازي نکردن کنترلدر بسياري از مواقع توسعه‌دهندگان با ساده‌سازي‌نکردن کنترل وظايف در نظر‌گرفته‌شده در کد، در واقع آغاز يك فاجعه را رقم مي‌زنند. مايک سوبلسکي، يکي از مؤسسان OtherInBox.com از مدافعان سرسخت اين ايده است که براي هر کاري بايد فقط يک محل در کد وجود داشته باشد. اگر اين مکان‌ها به دو برسد، احتمال دارد که کسي يکي از آن‌ها را تغيير داده، اما ديگري را تغيير ندهد. اگر اين تعداد بيش از دوتا شود، وضعيت به سمت يک فاجعه سوق پيدا مي‌كند و احتمال اين‌که يک نفر بتواند هنگام تغيير همه آن‌ها را با هم هماهنگ نگه دارد، بسيار پايين مي‌آيد. سوبلسکي مي‌گويد: «سه سال است که روي کدي کار مي‌کنم و بزرگ‌ترين افسوسم اين است که چرا آن را بيشتر ماجولار نساختم. من از تجربه‌هاي سخت و ناموفق آموختم که چرا اصل تک مسئوليتي در نوشتن نرم‌افزار اهميت دارد. در نوشتن کدهاي جديد به طور کامل به اين اصل وفادار مانده‌ام و البته نخستين‌کاري که در بازبيني کدهاي قديمي انجام مي‌دهم نيز اصلاح اين موضوع است.» همان‌طور که ممکن است حدس زده باشيد، سوبلسکي يک برنامه‌نويس Ruby on Rails است. اين فريم‌ورک سادگي و كوتاهي كد را ترويج مي‌كند و در اين راستا فرض مي‌کند که ساختار نرم‌افزار با يکي از الگوهاي شناخته‌شده هماهنگ مي‌شود. فلسفه‌اي که برنامه‌نويسان Rails بعضي اوقات از آن با اصطلاح «قرارداد، نه تنظيم» ياد مي‌کنند. نرم‌افزار فرض مي‌کند، اگر کسي يك شيء از نوع Name با دو خاصيت first و last بسازد، نرم‌افزار بايد بلافاصله يک جدول Name در پايگاه داده با دو ستون first و last نيز ايجاد كند. با تعريف نام‌ها در يک مکان، مي‌توان از مشکلات احتمالي که در اثر رعايت نکردن توالي تنظيمات در لايه‌ها ايجاد مي‌شود، جلوگيري کرد. اشتباه 4: تکيه بيش از حد به فريم ورکهابعضي مواقع ابزارهاي جادويي به گمراهي منجر مي‌شوند. با مجردسازي کارکردها، فريم‌ورک‌ها در بسياري از مواقع برنامه‌نويس را از درک اين‌که چه چيزي در کد درست کار نمي‌کند، ناکام مي‌گذارند.جي بليک ميک، يک برنامه‌نويس ساکن سياتل، يک نمونه از توسعه‌دهندگاني است که تکيه بيش از حد به ابزارهاي خودكاري مانند Ruby on Rails را دور شدن از توليد کدهاي تميز معني مي‌کند. ميک مي‌گويد: «قرارداد بنا به تعريف، چيزي است که در خارج از کد قرار دارد. به عنوان مثال، تا زماني که مکانيزم Ruby on Rails را براي تبديل يک URL به فراخواني‌هاي متد ندانيد، هيچ راهي وجود ندارد که متوجه شويد در پاسخ به يک پرسوجو(query) چه اتفاقي مي‌افتد.»ميك معتقد است: «در اين حالت خواندن کد بايد با در اختيار داشتن يک راهنما همراه شود که به شما بگويد در پشت اين دستورات دقيقاً چه اتفاقي در حال وقوع است.» ميک ادامه مي‌دهد : «قوانين با وجود اين‌که تقريباً منطقي هستند، چندان بديهي نيستند. براي کار روي برنامه‌هاي Ruby on Rails بايد اين فريم‌ورک را دقيقاً بشناسيد. با رشد برنامه، پروژه‌تان بيش از پيش به اين دانش خارجي تقريباً بديهي وابسته مي‌شود. در نهايت، مجموع اين بخش‌هاي کمي تا قسمتي بديهي به مجموعي نابديهي تبديل مي‌شود. بنابراين، چيزهاي زيادي است که براي کار روي برنامه‌هاي اين چنيني بايد ياد بگيريد و البته هنگام اشكال‌زدايي برنامه آن‌ها را به ياد آوريد.»مايک مورتون، يک برنامه‌نويس ديگر مي‌گويد: «فريم ورک‌ها در نود درصد راه بالا رفتن از کوه، با يک اتاق از امکانات کامل شما را همراهي مي‌کنند، اما اين پايان کار آن‌ها است. اگر مي‌خواهيد ده درصد آخر را انجام دهيد، بايد بتوانيد پيش‌بيني‌كرده و اکسيژن و امکانات ديگر را از ابتدا با خود بياوريد.» اشتباه 5: اطمينان به کلاينتبسياري از باگ‌هاي امنيتي وقتي اتفاق مي‌افتند که توسعه دهندگان فرض مي‌کنند دستگاه کلاينت کار درست را انجام خواهد داد. به عنوان مثال، کدي که براي اجرا در مرورگر نوشته شده مي‌تواند توسط مرورگر بازنويسي شده تا کار مشخصي را انجام دهد. اگر برنامه‌نويس برگشتن مجدد تمام داده‌ها را دوباره بررسي نكند، همه چيز مي‌تواند دچار مشکل شود. يکي از ساده‌ترين حمله‌ها بر پايه اين حقيقت ايجاد شده است که بعضي از برنامه‌نويسان داده‌هاي کلاينت را مستقيم به پايگاه داده مي‌فرستند. فرآيندي که به خوبي کار مي‌کند، البته تا زماني که کلاينت تصميم بگيرد به جاي فرستادن جواب‌هاي سالم، SQL به پايگاه داده بفرستد. اگر سايتي از کاربر نام وي را درخواست کرده و وي نام را به يک پرسوجو اضافه كند، مثلاً به جاي نام x; DROP TABLE users.. را تايپ کند، پايگاه داده به شکلي کاملاً وظيفه شناسانه فرض مي‌کند که نام x است، سپس به دستور بعدي رفته و جدول مربوط به کاربران را پاک مي‌کند. راه‌هاي فراواني براي سوء استفاده از اطمينان يک سرور وجود دارد که افراد خرابکار از آن سود مي‌برند. نظرسنجي‌هاي وبي مي‌توانند دعوت نامه‌اي براي تزريق Bias باشند. سرريزكردن بافر هنوز هم يکي از ساده‌ترين راه‌هاي خراب کردن يک نرم‌افزار است. بدتر اين‌كه ممکن است تعدادي از حفره‌هاي امنيتي با يکديگر به صورت يک زنجير ترکيب شده و يک فاجعه ايجاد كنند. يک برنامه‌نويس ممکن است بگذارد کلاينت روي يک فايل جديد بنويسد، به اين اميد که Permission يا مجوزهاي دسترسي دايرکتوري براي جلوگيري از بروز مشکل کافي است. ديگري ممکن است Permissionها را بازکرده تا چند باگ اتفاقي را اصلاح كند. هيچ کدام از اين دو به تنهايي مشکل‌زا نيستند، اما با يکديگر باعث مي‌شوند که به کاربر يک دسترسي آزاد اهدا شود. اشتباه 6: اطمينان نکردن کافي به کلاينتبعضي اوقات امنيت فراوان به صورت پارادکس گونه‌اي به ايجاد حفره‌هاي امنيتي منجر مي‌شود. چند روز بيش، به من گفته شد که راه حل مشکل بخشي از يک نرم‌افزار خاص، chmod 777کردن دايرکتوري و تمام فايل‌هاي درون آن است. امنيت فراوان مي‌تواند به هدر رفتن تلاش‌ها منجر شود و برنامه‌نويس را مجبور سازد که محدوديت‌ها را کمتر كند تا تنها بتواند فرآيند را اجرا كند. فرم‌هاي وبي يکي از بسترهاي ديگري است که اطمينان مي‌تواند به کاهش هزينه‌ها در بلندمدت منجر شود. نه تنها امنيت در سطح بانکي، سؤال‌هاي شخصي طولاني و تأييد کردن آدرس‌هاي ايميل، افراد را از سايت خود دلزده مي‌کند، بلکه اعمال امنيت فراوان بعد از ذخيره‌سازي داده‌ها نيز هزينه‌اي بيش از مزاياي آن به دنبال دارد. به همين دليل، بسياري از توسعه دهندگان وب سعي مي‌کنند تا جاي ممکن امنيت را کاهش دهند. اين کار باعث مي‌شود تا افراد دسترسي راحت‌تري به محصول ارائه شده توسط سايت داشته باشند و همچنين لزوم محافظت از داده‌هايي بيش از ميزان مورد نياز نيز از ميان مي‌رود. اشتباه 7: وابستگي بيش از حد به بسته‌هاي جادوييآيا نگران امنيت هستيد؟ فقط کمي رمزنگاري چاشني آن كنيد. مي‌خواهيد پايگاه داده شما پشتيبان داشته باشد؟ فقط دکمه Automated Replication را فشار دهيد. نگران نباشيد، فروشنده گفته است: «اين روش به‌خوبي جواب مي‌دهد.» برنامه‌نويسان کامپيوتر افراد خوشبختي هستند. دانشمندان علوم کامپيوتر به طور مرتب کتابخانه‌هاي فوق‌العاده‌اي ايجاد مي‌کنند که با گزينه‌هاي فراواني براي کمک به کدهاي ما پر شده‌اند. تنها مشکل اين است که سادگي همراه با استفاده از کد شخصي يا گروهي ديگر در پروژه خود، مي‌تواند مسائل پيچيده‌اي را به وجود آورد يا حتي بدتر دام‌هاي جديدي را وارد کد شما كند. جان ويگا، يکي از مؤلفان «24 گناه نابخشودني امنيت نرم‌افزار: رخنه‌هاي برنامه‌نويسي و شيوه اصلاح آن‌ها» اعتقاد دارد، رمزشناسي يک از مهم‌ترين منابع ضعف در اين مسئله است. تعداد بسياري زيادي از برنامه‌نويسان تصور مي‌کنند که مي‌توان يک کتابخانه Encryption را به برنامه لينک کرد، دکمه‌اي را فشار داده و از امنيتي غيرقابل نفوذ برخوردار شد. اما واقعيت اين است که بسياري از اين الگوريتم‌هاي جادويي ضعف‌هايي پنهان دارند و يافتن اين ضعف‌ها به يادگيري‌اي بيشتر از آن چيزي که در بخش Quick Start راهنماي آن‌ها گفته شده است نياز دارد. حال براي يادگيري بيشتر درباره اين الگوريتم‌ها به کسب دانش بيشتري درباره موضوع نياز داريد و اين نيازمند صرف وقت و زمان است. به همين دليل، بسياري از برنامه‌نويسان ترجيح مي‌دهند تا به اين کدها اطمينان کرده و بدون مطالعه بيشتر، از آن‌ها در پروژه‌هايشان استفاده كنند. اشتباه 8: اختراع دوباره چرخدرست کردن ماست خود، قصابي کردن دام‌هاي خود و نوشتن کتابخانه‌هاي خود فقط به اين دليل که فکر مي‌کنيد راه بهتري براي کد زني آن داريد، مي‌تواند دردسرهاي زيادي براي شما به همراه داشته باشد.ويگا مي‌گويد: «پرورش دادن رمزنگاري مخصوص به خودتان يک خوشامد‌گويي براي حمله کنندگان است.» توجه کنيد که حتي خبره‌ها هم وقتي سعي مي‌کنند ديگران را از يافتن و استفاده از ضعف‌هاي سيستم‌شان بازدارند، ممکن است اشتباه کنند. حال به چه کسي بايد اطمينان کرد: خودتان يا به اصطلاح خبره‌هايي که اشتباه نيز مي‌کنند؟پاسخ به قلمرو مديريت ريسکتان باز مي‌گردد. درباره بسياري از کتابخانه‌ها نيازي به بي نقص بودنشان نيست. بنابراين، انتخاب يکي از آن‌ها مي‌تواند بهتر از نوشتن کد به وسيله خودتان باشد. کتابخانه مورد نظر شامل روتين‌هاي نوشته و بهينه شده توسط يک گروه از متخصصان اين کار است. البته، آن‌ها نيز مرتکب اشتباه مي‌شوند، اما فرآيندهاي بزرگ‌تر مي‌تواند به حذف بسياري از اين اشتباهات منجر شود. اشتباه 9: شفافيت بيش از اندازه براي کاربربرنامهنويسان عاشق اين هستند که بتوانند به متغيرها دسترسي داشته و بخش‌هايي از نرم‌افزار را تغيير دهند. اما بيشتر کاربران حتي نمي‌توانند تصور کنند که اين کارها چگونه انجام مي‌شود.به عنوان مثال، آندروئيد را در نظر بگيريد. آخرين باري که من يک بسته نرم‌افزاري روي گوشي نرم‌افزاري خود نصب کردم، با پيغامي مواجه شدم که پنج يا شش راه دسترسي به اطلاعات من توسط نرم‌افزار را مشخص مي‌كرد. تيم آندروئيد توانسته يک مجموعه مفيد از گزينه‌ها را براي من ايجاد كند تا بتوانم مشخص كنم که آيا يک نرم‌افزار اجازه دسترسي به دوربين، دنبال کردن مکان من و ديگر گزينه‌ها را دارد يا خير. اما قراردادن مسئوليت روي دوش کاربر براي سفارشي کردن کاربردهايي که وي درک کاملي از آن‌ها ندارد مي‌تواند به فجايعي از نوع حفره‌هاي امنيتي و نقض اتفاقي حريم خصوصي منجر شود. همچنين ممکن است نرم‌افزار آن‌قدر پيچيده و گنگ شود که بازارش را از دست بدهد. نكته جالب توجه اين که با وجود اين‌که بيشتر کاربران هنگام خريد يک بسته نرم‌افزاري فهرست ويژگي‌ها را به دقت بررسي کرده و نسبت به آن حساسيت فراواني نشان مي‌دهند، اما بيشتر کاربران نمي‌توانند از تمام سطوح نرم‌افزار استفاده کنند و بسياري از ويژگي‌ها بي استفاده باقي مي‌ماند. ويژگي‌هاي اضافه معمولاً به معناي مخدوش کردن تجربه کاربر و مشکل ساختن راهبري و استفاده از نرم‌افزار مي‌شود. اشتباه 10: بهاي بيش از حد به تجربه کاربربعضي از توسعه‌دهندگان با ارائه‌کردن فقط يک راه حل براي هر نياز، مشکلات گنجاندن تعداد زيادي ويژگي را از ميان مي‌برند. جي‌ميل، به ارائه کردن انتخاب‌هاي محدودي که توسعه‌دهندگان عاشق آن هستند، معروف است. شما پوشه نداريد، اما مي‌توانيد ايميل‌هاي خود را با توجه به کلمات tag کرده يا روي آن‌ها label قرار دهيد. ويژگي‌هايي که توسعه‌دهندگان عقيده دارند از داشتن پوشه بسيار قدرتمندتر هستند. از طرف ديگر، اگر کاربران ايده را دوست نداشته باشند، راه حلي را براي دور زدن محدوديت‌هاي موجود جست‌وجو خواهند كرد و اين باعث خواهد شد تا سيستم هدف مشکلات امنيتي قرار گرفته يا رقابت‌هاي ناخواسته ايجاد شود.جست‌وجو به دنبال حد متوسطي ميان ويژگي‌هاي فراوان يا اندك چالشي بي‌پايان است که مي‌تواند بسيار پرهزينه باشد. اشتباه 11: بستن سورس کديکي از دشوارترين چالش‌هاي هر شركت مشخص‌کردن ميزاني از نرم‌افزار است که قرار است با ديگر افراد تقسيم شود. جان گيلمور، از مؤسسان Cygnus Solutions يکي از نخستين شركت‌هاي اپن‌سورس، اعتقاد دارد تصميم به توزيع نکردن سورس کد عليه يکپارچگي نرم‌افزار عمل کرده و يکي از راحت‌ترين راه‌هاي جلوگيري از خلاقيت و از آن مهم‌تر جلوگيري از پوشاندن و اصلاح باگ‌ها است. گيلمور مي‌گويد: «از نتايج عملي بازکردن کد، کمک افرادي که شما تا به حال اسمشان را هم نشنيده‌ايد به توسعه و بهبود پروژه نرم‌افزاري‌تان است. آن‌ها باگ‌ها را خواهند يافت (و براي اصلاح آن‌ها تلاش مي‌کنند)، ويژگي‌هاي جديد اضافه‌کرده و مستندسازي را بهبود مي‌بخشند. حتي اگر بهبود انجام شده توسط آن‌ها، به شيوه آماتوري صورت گرفته باشد، يک بررسي چند دقيقه‌اي از طرف تيم توسعه مي‌تواند به يافتن راه حل هماهنگ‌تري براي حل همان مشکل منجر شود.» مزايا از اين نيز فراتر مي‌روند. به‌طور معمول زماني که ديگران کد را Recompile کرده و آن را به پلتفرم‌هاي ديگر انتقال مي‌دهند، خود کد با ساختاري ماجولارتر رشد‌کرده و بهتر ساخت مي‌يابد. بازکردن کد شما را مجبور مي‌سازد که اطلاعات را دسترس پذيرتر، قابل فهم‌تر و در نتيجه بهتر كنيد. با اعمال تلاشي کوچک براي به اشتراك گذاشتن کد، نتيجه کار در خود کد اوليه نمايان خواهد شد. اشتباه 12: فرض اين‌که بازبودن درمان همه چيز استتا به حال ميليون‌ها پروژه اپن‌سورس عرضه شده و تنها نسبت اندکي از آن‌ها توانسته است توجه كاربراني بيش از انگشتان يك دست را براي کمک به نگه‌داري، بازبيني و گسترش خود جلب كنند. به معناي ديگر، جمله معروف «اگر آن را بسازيد، افراد به سراغش خواهند آمد،» هميشه نتايج خوبي را در عمل توليد نمي‌كنند. در حالي‌که بازبودن امکان مشارکت و بهبود پروژه را براي ديگران فراهم مي‌آورد، اين ويژگي به صورت تنها نمي‌تواند کار زيادي براي شما انجام دهد، بلکه بايد مشوق‌هاي ديگري نيز براي ترغيب مشارکت بيروني به وجود آيد. اشتياق و علاقه شديد مدافعان اپن‌سورس چشم بسياري از توسعه‌گران را نسبت به اين واقعيت مي‌بندد که بازبودن به تنهايي نمي‌تواند جلوي حفره‌هاي امنيتي را گرفته، crash کردن‌ها را از بين برد يا يک تکه کد ناکامل را قابل استفاده كند. افراد کارهاي ديگري براي انجام دارند و ممکن است کوه نوردي، خانواده، رستوران و شغلي که بابت آن پول دريافت مي‌کنند، اولويت بالاتري نسبت به کامل کردن کد پروژه شما داشته باشد. باز کردن يک پروژه مي‌تواند سربار قابل توجه‌اي را در زمينه ارتباطات و مستندسازي فراهم آورد. يک پروژه کد بسته نيازمند مستندسازي مشخص و تغييرناپذيري براي کاربران است. اما يک پروژه اپن‌سورس خوب بايد داراي يک مستندسازي گسترش يافته براي APIها و نقشه‌اي براي توسعه‌هاي آينده نرم‌افزار باشد. اين کار اضافي ممکن است در پروژه‌هاي بزرگ ارزش انجام را داشته باشد، اما درباره پروژه‌هاي کوچک‌تر مي‌تواند به عاملي بازدارنده تبديل شود. بارها پيش آمده، کدهايي که تنها بعضي وقت‌ها کار مي‌کنند، به داخل SourceForge انداخته شده تا شايد کسي پيدا شده و با سپري کردن زمان قابل توجهي آن‌ها را کامل كند. اين تصميمي است که مي‌تواند يک پروژه را قبل از آن‌که واقعاً شروع شده باشد، از مسير خارج كند. بازکردن پروژه همچنين مي‌تواند شما را از پشتيباني‌هاي مالي دور سازد. بسياري از شركت‌هاي اپن‌سورس سعي مي‌کنند تا تعدادي ويژگي مالکانه را در پروژه خود نگه دارند تا به اين ترتيب کنترل خود را روي پروژه حفظ كنند. اين باعث مي‌شود تا آن‌ها بتوانند از افراد براي پشتيباني تيم توسعه مرکزي نرم‌افزار پول دريافت کنند. پروژه‌هايي که تمرکز خود را روي برنامه‌نويسان داوطلب مي‌گذارند، معمولاً به اين نتيجه مي‌رسند که اين نوع از برنامه‌نويسان بسيار غيرقابل پيش‌بيني هستند. در حالي‌که رقابت کاملاً آزاد و خلاقيت مي‌تواند نتايج قابل توجه‌اي به دنبال داشته باشد، عده‌اي از افراد هم همچنان شيوه‌هاي سنتي توسعه نرم‌افزار را در اولويت مي‌دانند.
