منبع داخلی در شرکت شتاب بیشتری می گیرد

تعداد فزاینده‌ای از شرکت‌های آینده‌نگر در خرده‌فروشی، بانکداری و رسانه‌ها، فرهنگ منبع درونی را پذیرفته‌اند. در اینجا دلیل است.

که در اصل توسط Tim O’Reilly ابداع شد، منبع داخلی یک اصل مهندسی است که هدف آن آوردن روش های منبع باز در داخل چهار دیوار یک سازمان برای ساختن نرم افزار اختصاصی است. گشودگی مورد بحث در بین تیم‌های درون یک سازمان گسترش می‌یابد، به‌جای اینکه شامل مشارکت‌کنندگان متعدد از سازمان‌های مختلف شود.

این مجموعه‌ای از تکنیک‌ها و ابزارهای رایج مورد استفاده در جوامع منبع باز را به همراه دارد که به گروه‌های بزرگی از مشارکت‌کنندگان اجازه می‌دهد تا روی کدهایی که لزوماً مسئولیت اصلی آنها نیست، با هم کار کنند. این معمولاً شامل استفاده از مخازن کد مشترک، درخواست‌های کششی، نظرات و مستندات گسترده می‌شود.

این روشی است که به طور فزاینده‌ای در بین شرکت‌های سنتی‌تری که به دنبال مدرن‌سازی شیوه‌های توسعه نرم‌افزار خود هستند و شروع به مشاهده کد خود به‌عنوان دارایی‌های مشترک و قابل استفاده مجدد می‌کنند، به‌جای مالکیت معنوی که باید تحت قفل و کلید نگه داشته شوند، محبوبیت بیشتری پیدا می‌کند. توسط تیم مسئول آن رویکرد منبع داخلی همچنین مسدودکننده‌های بالادستی را با توانمندسازی توسعه‌دهندگان برای ایجاد تغییرات از طریق درخواست‌های کششی، به روشی ایمن و شفاف حذف می‌کند.

استفاده از منبع داخلی نیازمند تغییر فرهنگ قابل توجهی برای سازمان‌های خاص است، اما می‌تواند به افزایش کیفیت، قابلیت اطمینان و امنیت کد شما کمک کند، در حالی که همکاری بیشتر و سرعت توسعه‌دهنده را با شکستن سیلوهای قدیمی تقویت می‌کند. چیزی که در طول همه گیری اهمیت بیشتری پیدا کرد.

Danese Cooper، بنیانگذار InnerSource، «اگر یک چیز وجود داشته باشد که منبع داخلی ثابت کرده است، این است که همکاری گسترده مبتنی بر همتا در بین تیم‌های ناهمزمان می‌تواند به همان اندازه مؤثر باشد که تیم‌های به شدت تحت کنترل در یک اتاق و منطقه زمانی یکسان هستند». بنیاد عوام، به InfoWorld گفت. همین ویژگی‌ها برای هدایت کار در طول همه‌گیری کووید-۱۹ کلیدی بودند و به اثبات اثربخشی و تشویق اتخاذ رویکرد منبع درونی کمک کردند.

InfoWorld با سه شرکتی صحبت کرد که روش‌های منبع داخلی را اتخاذ کردند تا ببیند چرا منبع داخلی برای آنها مناسب است و به توسعه‌دهندگانشان چه کمکی کرده است.

بلومبرگ: توانمندسازی مهندسان برای تغییری که می خواهند ببینند

یک صنعت که در آن منبع داخلی ریشه‌دار خدمات مالی است، که در آن سیلوهای سازمانی و رویکرد محافظه‌کارانه و اغلب مخفیانه برای عدم اشتراک‌گذاری کد، مدت‌ها متداول بوده است.

گیل یهودا، رئیس منبع باز در US Bank، در کنفرانس استراتژی منبع باز در لندن در اکتبر ۲۰۲۱، گفت: «منبع داخلی برای ما در سازمان های سنتی تر، تغییری نسبت به دنیای قدیمی شنا در مسیر شماست. “مفهوم محافظت از کد با به اشتراک گذاری نکردن آن یک روکش نازک است، به دلیل وابستگی های عمیقی که همه ما به آنها متکی هستیم. سالم‌تر است که آنها را به‌عنوان مجموعه‌ای از دارایی‌های مشترک و مشترک ببینیم که همه می‌توانیم از آن بهره ببریم.»

در همان پانل آن روز، آرتور مالتسون، مهندس برجسته در Capital One بود که گفت: «امروز در Capital One اشتراک‌گذاری کد و مشارکت‌های متقابل تجاری در پلتفرم‌ها وجود دارد. همانطور که مهندسان بالغ می شوند، کد به وسیله ای برای رسیدن به هدف برای حل یک مشکل تجاری تبدیل می شود و این به بهترین وجه با منبع درونی و بازتر بودن به دست می آید. مشکلات با افراد بیشتر بهتر حل می شوند. ما باید از داشتن فرهنگ مالکیت بیش از حد در میان مهندسان عبور کنیم.”

در بلومبرگ، منبع داخلی به آرامی طی ۱۰ سال گذشته به یک امر عادی تبدیل شده است، و از ریشه در تیم ابزارهای توسعه‌دهنده داخلی گسترش یافته و اکنون به یک روش پذیرفته شده کار برای تجارت متقابل دارایی و سایر برنامه های کاربردی کلیدی.

«اکنون بیش از هر زمان دیگری، مهندسان در سراسر شرکت این اختیار را دارند که تغییری را که می‌خواهند در پایگاه کد تیم دیگری مشاهده کنند، چه یک رفع اشکال ساده باشد که مشتری را خوشحال می‌کند، چه ویژگی مهمی که بهره‌وری را بهبود می‌بخشد. جو پاترائو، سرپرست تیم در بلومبرگ، در طول ارائه قبلی گفت: در میان گروه بزرگی از مهندسان. امسال.

امروزه، همه مهندسان در بلومبرگ از GitHub Enterprise برای مشاهده و همکاری در کد با همکاران، از جمله دستورالعمل‌های مشارکت و آزمایش واضح استفاده می‌کنند. بکی پلامر، رهبر تیم مهندسی نرم‌افزار در بلومبرگ، به InfoWorld گفت: «ما از درخواست‌های کشش و بررسی کد برای ایجاد تغییرات استفاده می‌کنیم، و استاندارد انتظارات از [درخواست کشش] از تیمی به تیم دیگر متفاوت است». برای مثال، آستانه درخواست کشش برای یک ابزار داخلی ممکن است کمتر از یک برنامه تجاری بسیار تنظیم شده باشد.

قبل از اینکه این روش‌های منبع داخلی وارد بلومبرگ شوند، یک مهندس باید با مدیر محصول مربوطه تماس می‌گرفت تا یک ویژگی یا یکپارچه‌سازی را درخواست کند، سرعت توسعه‌دهنده را کاهش دهد و مانع همکاری بین تیمی شود. پلامر گفت: «در طول سال‌ها، ما آموخته‌ایم که این یک تجربه یادگیری فوق‌العاده است و همچنین ارزش ارائه می‌دهد و تحویل محصول را تسریع می‌کند.

بی بی سی: استفاده مجدد از کد برای سرعت بخشیدن به تحویل ویژگی

شرکت پخش بریتانیا، پخش‌کننده ملی بریتانیا، در چهار سال گذشته فرهنگ منبع درونی را به‌طور ارگانیک توسعه داده است. این تیم‌های داخلی را به هم نزدیک‌تر کرده است، همکاری بهتری را در میان بخش‌ها فعال می‌کند، و چرخه‌های توسعه نرم‌افزار کارآمدتری را هدایت می‌کند.

در تیم برنامه های تلویزیونی به طور خاص، که بر برنامه های بسیار محبوب iPlayer و Sounds تمرکز دارد، منبع باز قبلاً به خوبی درک شده بود، زیرا آن تیم قبلاً لایه برنامه تلویزیونی در سال ۲۰۱۲. اما این عمل در بقیه سازمان کمتر رایج بود.

تام سادلر، سرپرست تیم مهندسی نرم‌افزار iPlayer بی‌بی‌سی،

“ما قبلاً مصرف‌کنندگان بزرگ منبع باز بودیم، و زمانی که نرم‌افزار خودمان را مانند لایه برنامه تلویزیونی منبع باز می‌گذاشتیم، واقعاً فرهنگ منبع درونی را به وجود آورد.” به InfoWorld گفت: برنامه های صدا. “این به دلیل ضرورت در بین ۱۰ تیمی که روی توسعه برنامه تلویزیونی کار می کردند، متولد شد، جایی که توانایی همکاری در بین آن تیم ها بسیار مهم بود.”

به عنوان مثال، راه اندازی Sounds on TV – یک برنامه رادیویی برای تلویزیون های هوشمند که توسط بی بی سی در مارس ۲۰۲۰ راه اندازی شد – به لطف فرهنگ منبع درونی در آن تیم ها با استفاده مجدد از کدهای موجود، توانست سریعتر از حد انتظار به بازار راه یابد. برنامه تلویزیونی iPlayer که قبلاً راه اندازی شده بود، به جای شروع از ابتدا.

با استفاده از درخواست کشش مداوم و فرایندهای تحویل مستمر در بین تیم‌ها، این رویکرد منبع داخلی برای توسعه نرم‌افزار شروع به گسترش کرد. Sadler گفت: “به جای اینکه به تیمی نیاز داشته باشیم که کاری برای ما انجام دهد، ما به کار با آنها روی آوردیم.”

از نظر نحوه پردازش و تایید تغییرات در بی بی سی، به قضاوت داخلی در مورد اینکه چه چیزی یک تغییر عمده یا جزئی را تشکیل می دهد، برمی گردد. برای تغییرات جزئی، عنصری از اعتماد سازمانی وجود دارد که وارد می‌شود. برای تغییرات مهم‌تر، بی‌بی‌سی فرآیند درخواست تغییر مشابه با پروژه‌های منبع باز بزرگ مانند زبان برنامه‌نویسی Rust را دنبال می‌کند، که در آن هر کسی که مستقیماً تحت تأثیر آن تغییر قرار می‌گیرد، این فرصت را دارد که قبل از ادغام تغییر، نظر بدهد و جایگزین‌هایی را پیشنهاد کند.

این فرهنگ در طول همه‌گیری بسیار سودمند بود، جایی که همکاری ناهمزمان زمانی که تیم‌های توسعه‌دهنده از راه دور می‌رفتند حیاتی بود. Sadler گفت: “داشتن ذهنیت درخواست کشش، مکالمات در Slack و Teams، و نصب مکانیسم هایی برای تصمیم گیری بین تیمی قطعا به ما در طول همه گیری کمک کرد.”

Asos: نباید هیچ شگفتی در روابط عمومی وجود داشته باشد

خره‌فروش آنلاین پوشاک Asos زمانی که چهار سال پیش به ایجاد منبع داخلی در حدود ۷۰ تیم مهندسی خود رسید، از مزیت میراث بسیار کمی برخوردار بود. دیو گرین، مدیر معماری و مهندسی Asos، به InfoWorld گفت: «این تیم‌ها توسعه‌دهنده، چابک هستند و برنامه‌های کاربردی خود را با سطح خوبی از استقلال دارند، بنابراین ما فرصتی برای تسریع در تحویل تیم‌های متقابل دیدیم.

با تسریع ذهنیت منبع درونی در بین تیم‌ها، Asos توانست برخی از سیلوهای سازمانی را خراب کند، استفاده مجدد از کد را تشویق کند، و توجه بیشتری به کد برای افزایش کیفیت داشته باشد. ما می خواهیم دیوارها را خراب کنیم تا همه بتوانند دیگران را ببینند. تونی گورمن، مهندس اصلی Asos، گفت: شفافیت و ارتباطات خوب به ما امکان می‌دهد تا جوامعی را در Asos ایجاد کنیم.

او گفت: «ایده این است که کد را بهتر کنیم و قابلیت‌های بیشتری را فعال کنیم و به این احترام بگذاریم که کد متعلق به شخصی است – هرکسی به نوعی در مورد کد ارزشمند است – بنابراین انجام کارها به وضوح و شفاف کلید اصلی است.

>

اما این بدان معنا نیست که همه چیز روان بود. “این یک سفر است. وقتی می‌دانید که دیگران آن را خواهند دید و مشارکت می‌کنند، کد را متفاوت از زمانی که فقط داخلی است، می‌نویسید. گرین گفت: اسناد و اتوماسیون کلیدی هستند.

به گفته گرین و گورمن، در آن روزهای اولیه اشتباهات زیادی انجام نشد، اما یک مورد وجود داشت که یک مهندس ناامید تصمیم گرفت قبل از رفتن به تعطیلات بدون دنبال کردن روند مناسب، ویژگی جدیدی را ارائه کند. گورمن گفت: «این منجر به گفتگوی قوی شد.

این سفر منجر به ظهور چیزی شبیه به یک شعار در سراسر Asos شد: “هیچ شگفتی در مورد یک PR [درخواست کشش] نباید وجود داشته باشد.” با استفاده از GitHub و Microsoft Azure Repos، در کنار ابزارهای همکاری مانند Slack و Microsoft Teams، مهندسان Asos می‌توانند با خیال راحت در یک منبع داخلی کار کنند، جایی که همکاری بین تیمی به یک امر عادی تبدیل شده است.

اکنون Asos شاهد توسعه پروژه‌های داخلی به روش‌هایی است که ممکن است ارزش بازگرداندن منبع باز به جامعه را داشته باشند. گورمن گفت: «میل به بازپرداخت وجود دارد.

از کجا با منبع داخلی شروع کنیم

بسیاری از مهندسانی که InfoWorld با آنها صحبت کرده است به PayPal به عنوان استاندارد طلایی برای دریافت اشاره کردند. با منبع داخلی شروع شد.

منابع مفید دیگر برای شروع کار با منبع داخلی عبارتند از کتابهای الکترونیکی شروع به کار با InnerSource و اقتباس InnerSource.

برای داشتن یک انجمن فعال در اطراف منبع داخلی، به InnerSource Commons، کامل با وبلاگ‌ها، یک ویکی، نگاه نکنید. یک مخزن Git، یک مجموعه ویدیویی مسیر یادگیری در YouTube، داستان های کاربر، و آزمایش شده و آزمایش شده الگوها.