حدود شش ماه پیش، من مقاله‌ای درباره وضعیت تجاری‌سازی منبع باز نوشتم که مورد توجه قرار گرفت. تقریباً بلافاصله پس از آن هکر نیوز این قطعه نثر نسبتاً مشکل ساز را در صفحه اول به نمایش گذاشت. عنوان این است: «اصلاحش کن، فورکش کن، فک کن» (سانسور متعلق به من است). من فکر می کنم این یک نمونه عالی از جایی است که OSS هم از نظر تجاری و هم به عنوان یک جنبش در حال شکست است. توجه زیادی در OSS به سیاست‌های کد رفتار (که مهم هستند) معطوف می‌شود، اما به اندازه کافی به آنچه برای ایجاد یک پروژه منبع باز موفق نیاز است، توجه نمی‌شود. این فقط کد نویسی نیست. من استدلال می کنم که کدنویسی اغلب کمتر از این مهم است.
برخورد حق
می فهمم نویسنده از کجا آمده است. او از یک نقطه ناامید می نویسد. ما کار زیادی را برای پروژه OSS خود انجام می دهیم و یک کاربر نهایی با عنوان می تواند بسیار دشوار باشد. من موافقم که برخی از افراد از این خط عبور می کنند، اما در تجربه من، این کمتر از 0.1٪ از شکایات است. بسیار نادر است که یک مصرف کننده واقعا سمی داشته باشید.
این مشکل اساسی من با آن پست است، این وظیفه را به عهده کاربران می گذارد. “خودت درستش کن”. این حق نگهدار است. اشتباه نکنید، اشکالی ندارد که یک کد نویسی انجام دهید. اما سپس آن را به عنوان چنین اعلام کنید و آن را رها کنید. نگهدارنده بودن چیزی کاملا متفاوت است.
من از کاربرانی که می‌خواهند خودشان این مشکل را برطرف کنند، حمایت می‌کنم و به آنها کمک می‌کنم، اما افرادی را که نمی‌خواهند این کار را انجام دهند، دریافت می‌کنم. من هنوز فکر می کنم اشکالی ندارد که آنها شکایت کنند که انگار پول نرم افزار را پرداخت کرده اند. بله، شنیدن شکایات ناامید کننده است. اما من یک پروژه متن باز را شروع نکردم فقط برای اینکه به من بگویند چقدر عالی هستم. من می‌خواهم کاربران احساس راحتی کافی برای تخلیه هوا داشته باشند، این به من کمک می‌کند تا نقاط درد را درک کنم. این به اصالت جامعه کمک می کند و توانایی آن در انتقاد از من به همه کمک می کند. مخصوصا من. توجه سایر اعضای جامعه را که ممکن است مشکل مشابهی داشته باشند و ممکن است انگیزه بیشتری برای رفع آن داشته باشند، جلب می کند. من را نسبت به مشکلات و نکاتی که نیاز به بهبود دارد بیشتر آگاه می کند.
یک سازمان دهنده جامعه
یک نگهدارنده OSS یک سازمان دهنده جامعه است. کمی سیاستمدار آمیخته با مدیر پروژه و دیکتاتور خیرخواه. همه به یک تبدیل شدند. مدیران و رهبران خوب معمولاً افرادی همدل و خوب هستند… بیشتر اوقات. مردم گاهی از یک مدیر یا رهبر OSS یاد می کنند و می گویند که او چه شخصیت وحشتناکی دارد. این بی معنی است. آنها اغلب این داستان‌ها را از چند حادثه از هزاران مورد استخراج می‌کردند. یک پروژه موفق با یک رهبر بیمار شروع می شود. بله، آن رهبر ممکن است گاهی اوقات روز بدی داشته باشد. یا ممکن است از زبانی استفاده کنند که از نظر سیاسی صحیح نیست. اما استثنا قاعده را ایجاد نمی کند و چنین زبانی همیشه به عنوان خصمانه ترجمه نمی شود.
“اسطوره” یک رهبر نابغه یک سوراخ اغلب فقط همین است. یک افسانه. وقتی چنین افرادی موفق می شوند، معمولاً با وجود آن اتفاق می افتد، نه به خاطر آن. با این حال، برخی از مردم ترجیح می‌دهند به جای مسئولیت‌پذیری، این روایت را پشت سر « شایسته‌سالاری» کاذب پنهان کنند. این راه را اشتباه نگیرید، من فکر نمیکنم ما نیازی به قدم زدن روی پوسته‌های تخم مرغ در اطراف همه داشته باشیم. فکر نمیکنم کمک کند و فکر نمیکنم چیزی را حل کند.
بد نیست نگهبانی را ببخشید که روز بدی داشته یا کار اشتباهی انجام داده است. اما احتمالاً نباید “جشن” گرفت. چرا اینطور است؟ چرا باید یک پروژه منبع باز نگه دارم که ممکن است برای آن پولی دریافت نکنم و همچنین از کاربران پشتیبانی کنم؟
چرا در وهله اول کد منبع باز می نویسیم؟ ما عاشق کدنویسی هستیم. اما فکر می‌کنم وقتی مردم از نرم‌افزار ما استفاده می‌کنند بیشتر دوست داریم. من هم از آشپزی لذت می برم، اما اگر مردم غذای من را نخورند… بدتر از این است که آن را روی اجاق گاز بسوزانم. یکی از شکست های من به عنوان یک نگهدارنده این است که بیش از حد به پیشینه تکنوکراتیک خود تکیه می کنم. من بیش از حد حمایت می کنم. این اغلب جامعه را خفه می کرد. اگر شای بلافاصله پاسخ دهد، چرا در انجمن به یک سوال پاسخ دهید؟
راه حل این بود که غافل نشویم. روزی یکبار جواب میدم نه سریعتر. در نتیجه، جامعه می تواند نقاط قوت خود را توسعه دهد. این نسخه ای از مدیریت خرد بود که برای نگهدارنده ها اعمال می شود. معمولاً برای کارهای کدنویسی که ما تمایل داریم خیلی از کارها را به عهده بگیریم و خیلی کم به آنها واگذار کنیم.
چرا این مهم است
آخرین باری که در مورد تصاحب منبع باز شرکتی نوشتم. این عناصر خوبی در خود دارد اما خطرات زیادی را نیز به همراه دارد. ما به جامعه برای هدایت این امر نیاز داریم. ما به نگهبانانی نیاز داریم که کار را درک کنند و متعهد به حاکمان شرکت نباشند.
مشکل بزرگ در هر پروژه ای، اعم از متن باز یا پروژه های دیگر، این است که مردم اهمیتی نمی دهند. جلب توجه جامعه چیزی است که همه ما به آن نیاز داریم. به این ترتیب شما یک پروژه را ایجاد می کنید. اگر در زمان مناسب در مکان مناسب باشید، ممکن است خوش شانس باشید. اما اگر از جامعه خود حمایت کنید، حتی اگر قایق را از دست بدهید، ممکن است موفق شوید.
همه اینها مرا به این می رساند که چرا “ناگهان” به یاد آوردم که این پست را شش ماه در انبارهایم مانده و گرد و غبار جمع کرده است.
آیا باید پروژه OSS جدیدی را شروع کنم؟
من به نوع جدیدی از AoT JVM فکر کرده ام که رویکردی کاملاً متفاوت از آنچه در حال حاضر داریم دارد. این چیزی است که من می خواهم بسازم، اما آیا باید آن را به عنوان یک پروژه OSS بسازم یا به صورت خصوصی شروع کنم؟
من می خواهم برای آن بودجه جمع آوری کنم و جذب جامعه کمک خواهد کرد. اما اگر هنوز پروژه OSS نداشته باشم، عدم قطعیت کشش آینده ممکن است نقطه فروش بهتری برای سرمایه گذاران نسبت به واقعیت کشش محدود فعلی باشد. یک پروژه JVM به دلیل ماهیت خود زمان می برد تا به ثمر بنشیند و ارزشی برای مشتریان فراهم کند، در اوایل جامعه یا کشش ایجاد نمی کند. بنابراین ممکن است این پروژه ایده آلی برای ساخت در فضای باز نباشد. من همچنین طرفدار کدنویسی با افرادی که بالای شانه من خیره شده اند نیستم. از آنجایی که انتظاراتی در مورد مهارت های کدنویسی من وجود دارد، احساس خودآگاهی می کنم.
من 100% می‌خواهم در فضای باز بسازم، اما فقط زمانی می‌توانم این کار را انجام دهم که چیزی در حال اجرا باشد که ارزش کاری را که انجام می‌دهم نشان دهد. این زمان خواهد برد. این خیلی ذهنی است. برخی از پروژه ها از ابتدا به عنوان منبع باز معنا پیدا می کنند.
آیا ما به این پروژه جدید نیاز داریم؟
مدتی قبل با یکی از دوستانم صحبت می‌کردم و درباره ایده‌ام بحث می‌کردم که او با من در مورد نیاز به یک JVM دیگر به چالش کشید. آیا مطالعه بازار انجام دادید؟ امکان ساختن چنین چیزی چیست؟
من نمی‌خواهم به جایی برسم که وقت و روحم را روی محصولی سرمایه‌گذاری کنم که در نهایت به یک طاقچه کوچک ختم شود. این ضرب المثل وجود دارد: “اگر از مردم می پرسیدم که چه می خواهند، آنها می گفتند اسب های سریع تر.” این را به هنری فورد نسبت می دهند که تا آنجا که من می دانم هرگز چنین چیزی را نگفته است. فکر نمیکنم هم درست باشه حتی در هنگام ساختن یک پروژه متن باز باید محصول محور باشیم.
ما باید به ارزش مشتری، تمایل به انطباق و نفوذ به بازار فکر کنیم، حتی زمانی که چیزی رایگان و منبع باز می سازیم. قبل از راه‌اندازی LWUIT در Sun Microsystems، زمان زیادی را با کاربران هدف بالقوه سپری کردیم. ما مصاحبه ها، جلساتی را انجام دادیم و به ادغام کمک کردیم. بازخوردی که دریافت کردیم فوق العاده بود.
از آنجایی که Codename One از همین ریشه ها می آمد، از آن ریشه ها بهره می برد. با این حال، ما با شرکت های شتاب دهنده کار کردیم تا ببینیم چگونه از نزدیک کار می کنند. ما همچنین یک بتا اولیه گسترده داشتیم. این برای کشش اولیه پروژه بسیار مهم است. زمانی که LWUIT اعلام شد، می‌توانیم کاربران اولیه را با محصولی که بیشتر با نیازهای مشتری سازگار است، خوشحال کنیم. این به کاربران اولیه و اولین مشتریانی که برای Codename One به دست آوردیم کمک زیادی کرد.
سرانجام
وقتی یک پروژه منبع باز می سازیم، اغلب در نهایت همه کارها را انجام می دهیم. محصول، DevOps، تجربه کاربر/توسعه‌دهنده، و غیره. این تجربه منحصربه‌فردی است که اکثر شرکت‌ها به شما ارائه نمی‌دهند. می دانم که تجربه من در آن رشته های دیگر باعث شده در دراز مدت مدیر و کارآفرین بهتری باشم.
این یک شغل است. هزینه ای ندارد (حداقل در ابتدا) و ساعت ها همیشه اضافه کاری است. اما هنوز یک شغل است. زیرا در غیر این صورت، از توسعه دهندگان دیگر می خواهید که به سرگرمی شما اعتماد کنند. این برای آنها بی انصافی است. حتی زمانی که رایگان است، باید پروژه را جدی بگیریم و به کاربران خود احترام بگذاریم.
نگهبانان در ازای آن چیزهای زیادی دریافت می کنند. ما مهارت های خود را بهبود می بخشیم. مردم بیشتر از کار ما استفاده می کنند و از آن حمایت می کنند و به احتمال زیاد به یک تلاش سودآور ختم می شود. پایان دادن به یک شغل منبع باز از پروژه سرگرمی ما یک نتیجه بسیار عالی برای بسیاری از پروژه های جانبی است. با صبور بودن معقول با مردم شروع می شود.
