วิธีสร้างโครงการโอเพ่นซอร์ส

เทศกาลไอทีจะจัดขึ้นที่เซนต์ปีเตอร์สเบิร์กในสัปดาห์นี้ เทคเทรน. หนึ่งในวิทยากรคือ Richard Stallman เอ็มบ็อกซ์ ยังได้มีส่วนร่วมในเทศกาลนี้ด้วย และแน่นอนว่าเราไม่สามารถเพิกเฉยต่อหัวข้อซอฟต์แวร์เสรีได้ นั่นเป็นสาเหตุว่าทำไมหนึ่งในรายงานของเราจึงถูกเรียกว่า “จากงานฝีมือของนักเรียนไปจนถึงโครงการโอเพ่นซอร์ส ประสบการณ์กล่องจดหมาย”. โดยจะอุทิศให้กับประวัติความเป็นมาของการพัฒนา Embox ในฐานะโปรเจ็กต์โอเพ่นซอร์ส ในบทความนี้ ฉันต้องการพูดคุยเกี่ยวกับแนวคิดหลักที่ในความคิดของฉันมีอิทธิพลต่อการพัฒนาโครงการโอเพ่นซอร์ส บทความก็เหมือนกับรายงานที่อิงจากประสบการณ์ส่วนตัว

มาเริ่มกันด้วยสิ่งง่ายๆ ด้วยคำจำกัดความของคำว่า opensource แน่นอนว่าโครงการโอเพ่นซอร์สคือโครงการที่มีใบอนุญาตอย่างใดอย่างหนึ่งที่อนุญาตให้เข้าถึงซอร์สโค้ดของโครงการได้ นอกจากนี้ โปรเจ็กต์แบบเปิดหมายความว่านักพัฒนาบุคคลที่สามสามารถทำการเปลี่ยนแปลงได้ นั่นคือ หากบริษัทหรือนักพัฒนาบางรายเผยแพร่โค้ดของผลิตภัณฑ์ของตนบางส่วนหรือทั้งหมด ก็ยังไม่ได้ทำให้ผลิตภัณฑ์นี้เป็นโครงการโอเพ่นซอร์ส และสุดท้าย กิจกรรมโครงการใดๆ จะต้องนำไปสู่ผลลัพธ์บางอย่าง และความเปิดกว้างของโครงการก็บอกเป็นนัยว่าผลลัพธ์นี้ไม่เพียงแต่นักพัฒนาเองก็ใช้เท่านั้น

เราจะไม่พูดถึงปัญหาของใบอนุญาตแบบเปิด นี่เป็นหัวข้อที่ใหญ่และซับซ้อนเกินไปซึ่งต้องมีการตรวจสอบเชิงลึก มีการเขียนบทความและเนื้อหาที่ดีมากมายในหัวข้อนี้ แต่เนื่องจากตัวฉันเองไม่ใช่ผู้เชี่ยวชาญด้านลิขสิทธิ์ ฉันจะบอกเพียงว่าใบอนุญาตจะต้องเป็นไปตามเป้าหมายของโครงการเท่านั้น ตัวอย่างเช่น สำหรับ Embbox การเลือก BSD แทนที่จะเป็นใบอนุญาต GPL ไม่ใช่เรื่องบังเอิญ

ความจริงที่ว่าโครงการโอเพ่นซอร์สควรจัดให้มีความสามารถในการเปลี่ยนแปลงและมีอิทธิพลต่อการพัฒนาโครงการโอเพ่นซอร์ส แสดงว่าโครงการนั้นมีการกระจาย การจัดการ การรักษาความสมบูรณ์และประสิทธิภาพนั้นยากกว่ามากเมื่อเทียบกับโครงการที่มีการจัดการแบบรวมศูนย์ คำถามที่สมเหตุสมผลเกิดขึ้น: เหตุใดจึงต้องเปิดโครงการเลย? คำตอบอยู่ในขอบเขตของความเป็นไปได้เชิงพาณิชย์สำหรับโครงการบางประเภทประโยชน์ของแนวทางนี้มีมากกว่าต้นทุน นั่นคือไม่เหมาะกับทุกโครงการและโดยทั่วไปแล้วแนวทางแบบเปิดกว้างก็เป็นที่ยอมรับได้ ตัวอย่างเช่น เป็นเรื่องยากที่จะจินตนาการถึงการพัฒนาระบบควบคุมสำหรับโรงไฟฟ้าหรือเครื่องบินโดยใช้หลักการเปิด ไม่ แน่นอนว่าระบบดังกล่าวควรมีโมดูลตามโครงการที่เปิดอยู่ เนื่องจากจะให้ข้อดีหลายประการ แต่ต้องมีคนรับผิดชอบในผลิตภัณฑ์ขั้นสุดท้าย แม้ว่าระบบจะขึ้นอยู่กับโค้ดของโปรเจ็กต์ที่เปิดอยู่โดยสมบูรณ์ นักพัฒนาได้รวมทุกอย่างไว้ในระบบเดียวและสร้างบิลด์และการตั้งค่าเฉพาะแล้ว โดยพื้นฐานแล้วก็ต้องปิดมัน รหัสอาจเปิดเผยต่อสาธารณะ

ยังมีประโยชน์มากมายสำหรับระบบเหล่านี้จากการสร้างหรือมีส่วนร่วมในโครงการโอเพ่นซอร์ส ดังที่ฉันได้กล่าวไปแล้ว รหัสของระบบปลายทางอาจยังคงเปิดเผยต่อสาธารณะ เพราะเหตุใดจึงเห็นได้ชัดว่าไม่น่าจะมีใครมีเครื่องบินลำเดียวกันเพื่อทดสอบระบบ นี่เป็นเรื่องจริง แต่อาจมีบางคนที่ต้องการตรวจสอบบางส่วนของโค้ด หรือตัวอย่างเช่น บางคนอาจค้นพบว่าไลบรารีที่ใช้งานไม่ได้รับการกำหนดค่าอย่างถูกต้อง

ประโยชน์ที่มากยิ่งขึ้นจะปรากฏขึ้นหากบริษัทจัดสรรส่วนพื้นฐานของระบบบางส่วนให้เป็นโครงการแยกต่างหาก ตัวอย่างเช่น ห้องสมุดที่รองรับโปรโตคอลการแลกเปลี่ยนข้อมูลบางประเภท ในกรณีนี้ แม้ว่าโปรโตคอลจะเฉพาะเจาะจงสำหรับสาขาวิชาที่กำหนด คุณก็สามารถแบ่งปันค่าใช้จ่ายในการบำรุงรักษาระบบส่วนนี้กับบริษัทอื่นๆ จากสาขานี้ได้ นอกจากนี้ ผู้เชี่ยวชาญที่สามารถศึกษาระบบชิ้นนี้ในสาธารณสมบัติต้องใช้เวลาน้อยกว่ามากในการใช้งานอย่างมีประสิทธิภาพ และสุดท้าย การแบ่งส่วนออกเป็นเอนทิตีอิสระที่นักพัฒนาบุคคลที่สามใช้ช่วยให้เราปรับปรุงส่วนนี้ได้ดีขึ้น เนื่องจากเราจำเป็นต้องนำเสนอ API ที่มีประสิทธิภาพ สร้างเอกสารประกอบ และฉันไม่ได้พูดถึงการปรับปรุงความครอบคลุมของการทดสอบด้วยซ้ำ

บริษัทสามารถรับผลประโยชน์เชิงพาณิชย์ได้โดยไม่ต้องสร้างโครงการโอเพ่นซอร์ส ผู้เชี่ยวชาญจะเข้าร่วมในโครงการของบุคคลที่สามที่ใช้ในบริษัทก็เพียงพอแล้ว ท้ายที่สุดแล้ว ผลประโยชน์ทั้งหมดยังคงอยู่: พนักงานรู้จักโครงการดีขึ้น ดังนั้นพวกเขาจึงใช้งานโครงการได้อย่างมีประสิทธิภาพมากขึ้น บริษัทสามารถมีอิทธิพลต่อทิศทางการพัฒนาโครงการได้ และการใช้โค้ดสำเร็จรูปที่แก้ไขจุดบกพร่องจะช่วยลดต้นทุนของบริษัทได้อย่างเห็นได้ชัด

ประโยชน์ของการสร้างโครงการโอเพ่นซอร์สไม่ได้สิ้นสุดเพียงแค่นั้น มาดูองค์ประกอบที่สำคัญของธุรกิจเช่นการตลาดกัน สำหรับเขา นี่เป็นแซนด์บ็อกซ์ที่ดีมากที่ช่วยให้เขาประเมินความต้องการของตลาดได้อย่างมีประสิทธิภาพ

และแน่นอนว่า เราต้องไม่ลืมว่าโครงการโอเพ่นซอร์สเป็นวิธีที่มีประสิทธิภาพในการประกาศตัวเองว่าเป็นผู้ให้บริการความเชี่ยวชาญพิเศษใดๆ ในบางกรณี นี่เป็นวิธีเดียวที่จะเข้าสู่ตลาดได้ ตัวอย่างเช่น Embox เริ่มต้นจากโปรเจ็กต์เพื่อสร้าง RTOS คงไม่ต้องอธิบายว่าคู่แข่งมีเยอะ หากไม่มีการสร้างชุมชน เราก็จะไม่มีทรัพยากรเพียงพอที่จะนำโปรเจ็กต์ไปยังผู้ใช้ปลายทาง กล่าวคือ เพื่อให้นักพัฒนาบุคคลที่สามเริ่มใช้โปรเจ็กต์ได้

ชุมชนเป็นกุญแจสำคัญในโครงการโอเพ่นซอร์ส ช่วยให้คุณลดต้นทุนการจัดการโครงการ พัฒนา และสนับสนุนโครงการได้อย่างมาก เราสามารถพูดได้ว่าหากไม่มีชุมชน ก็ไม่มีโครงการโอเพ่นซอร์สเลย

มีการเขียนเนื้อหามากมายเกี่ยวกับวิธีสร้างและจัดการชุมชนโครงการโอเพ่นซอร์ส เพื่อไม่ให้เล่าข้อเท็จจริงที่ทราบอยู่แล้ว ฉันจะพยายามเน้นไปที่ประสบการณ์ของ Embox เช่น กระบวนการสร้างชุมชนเป็นประเด็นที่น่าสนใจมาก นั่นคือหลายคนบอกวิธีจัดการชุมชนที่มีอยู่ แต่บางครั้งช่วงเวลาของการสร้างก็ถูกมองข้ามไปเมื่อพิจารณาถึงสิ่งนี้

กฎหลักในการสร้างชุมชนโครงการโอเพ่นซอร์สคือไม่มีกฎเกณฑ์ ฉันหมายความว่าไม่มีกฎเกณฑ์สากล เช่นเดียวกับไม่มีกระสุนเงิน ถ้าเพียงเพราะโครงการมีความแตกต่างกันมาก ไม่น่าเป็นไปได้ที่คุณสามารถใช้กฎเดียวกันนี้เมื่อสร้างชุมชนสำหรับไลบรารีการบันทึก js และไดรเวอร์ที่มีความเชี่ยวชาญสูงบางตัว ยิ่งไปกว่านั้น ในขั้นตอนต่าง ๆ ของการพัฒนาโครงการ (และชุมชน) กฎเกณฑ์ก็เปลี่ยนไป

Embbox เริ่มต้นจากโครงการนักเรียนเนื่องจากมีสิทธิ์เข้าถึงนักเรียนจากแผนกการเขียนโปรแกรมระบบ อันที่จริงเรากำลังเข้าสู่ชุมชนอื่น เราอาจทำให้ผู้เข้าร่วมในชุมชนนี้ นักศึกษา สนใจแนวปฏิบัติทางอุตสาหกรรมที่ดีในงานพิเศษ งานทางวิทยาศาสตร์ในสาขาการเขียนโปรแกรมระบบ หลักสูตร และอนุปริญญา นั่นคือเราปฏิบัติตามกฎพื้นฐานข้อหนึ่งในการจัดตั้งชุมชน: สมาชิกในชุมชนจะต้องได้รับบางสิ่งบางอย่าง และราคานี้จะต้องสอดคล้องกับการมีส่วนร่วมของผู้เข้าร่วม

ขั้นตอนต่อไปสำหรับ Embbox คือการค้นหาผู้ใช้บุคคลที่สาม สิ่งสำคัญมากคือต้องเข้าใจว่าผู้ใช้มีส่วนร่วมอย่างเต็มที่ในชุมชนโอเพ่นซอร์ส มักจะมีผู้ใช้มากกว่านักพัฒนา และเพื่อที่จะต้องการเป็นผู้มีส่วนร่วมในโครงการ ก่อนอื่นพวกเขาจึงเริ่มใช้มันไม่ทางใดก็ทางหนึ่ง

ผู้ใช้ Embox รายแรกคือภาควิชาไซเบอร์เนติกส์เชิงทฤษฎี พวกเขาแนะนำให้สร้างเฟิร์มแวร์ทางเลือกสำหรับ Lego Mindstorm และถึงแม้ว่าพวกเขาจะยังคงเป็นผู้ใช้ในพื้นที่ (เราสามารถพบปะกับพวกเขาด้วยตนเองและหารือเกี่ยวกับสิ่งที่พวกเขาต้องการ) แต่มันก็ยังคงเป็นประสบการณ์ที่ดีมาก ตัวอย่างเช่น เราได้พัฒนาการสาธิตที่สามารถแสดงให้ผู้อื่นเห็นได้ เนื่องจากหุ่นยนต์นั้นสนุกและดึงดูดความสนใจได้ เป็นผลให้เราได้รับผู้ใช้ที่เป็นบุคคลที่สามอย่างแท้จริงซึ่งเริ่มถามว่า Embbox คืออะไรและใช้งานอย่างไร

ในขั้นตอนนี้ เราต้องคิดถึงเอกสารเกี่ยวกับวิธีการสื่อสารกับผู้ใช้ ไม่ แน่นอน เราเคยคิดถึงสิ่งสำคัญเหล่านี้มาก่อน แต่มันก็ยังเร็วเกินไปและไม่ได้ให้ผลเชิงบวก ผลกระทบค่อนข้างเป็นลบ ผมขอยกตัวอย่างให้คุณฟังสักสองสามตัวอย่าง เราใช้ googlecode ซึ่ง wiki รองรับหลายภาษา เราสร้างเพจในหลายภาษา ไม่เพียงแต่ภาษาอังกฤษและรัสเซีย ซึ่งเราแทบจะสื่อสารกันไม่ได้ แต่ยังรวมถึงภาษาเยอรมันและสเปนด้วย ด้วยเหตุนี้ จึงดูไร้สาระมากเมื่อถูกถามในภาษาเหล่านี้ แต่เราไม่สามารถตอบได้เลย หรือพวกเขาแนะนำกฎเกี่ยวกับการเขียนเอกสารและการแสดงความคิดเห็น แต่เนื่องจาก API มีการเปลี่ยนแปลงค่อนข้างบ่อยและมีนัยสำคัญ ปรากฏว่าเอกสารของเราล้าสมัยและทำให้เข้าใจผิดมากกว่าที่ช่วยได้

เป็นผลให้ความพยายามทั้งหมดของเรา แม้แต่ความพยายามที่ผิด ก็นำไปสู่การปรากฏของผู้ใช้ภายนอก และแม้แต่ลูกค้าเชิงพาณิชย์ก็ปรากฏว่าต้องการให้ RTOS ของเขาเองได้รับการพัฒนาให้เขา และเราพัฒนามันขึ้นมาเพราะเรามีประสบการณ์และมีพื้นฐานมาบ้างแล้ว ที่นี่คุณต้องพูดถึงทั้งช่วงเวลาที่ดีและไม่ดี ฉันจะเริ่มต้นด้วยสิ่งที่ไม่ดี เนื่องจากนักพัฒนาจำนวนมากมีส่วนร่วมในโครงการนี้ในเชิงพาณิชย์ ชุมชนจึงค่อนข้างไม่มั่นคงและแตกแยก ซึ่งแน่นอนว่าไม่สามารถส่งผลกระทบต่อการพัฒนาโครงการได้ ปัจจัยเพิ่มเติมอีกประการหนึ่งคือทิศทางของโครงการถูกกำหนดโดยลูกค้าเชิงพาณิชย์รายหนึ่ง และเป้าหมายของเขาไม่ใช่การพัฒนาโครงการเพิ่มเติม อย่างน้อยนี่ก็ไม่ใช่เป้าหมายหลัก

ในทางกลับกัน มีด้านบวกหลายประการ เรามีผู้ใช้ที่เป็นบุคคลที่สามอย่างแท้จริง ไม่ใช่แค่ลูกค้าเท่านั้น แต่ยังรวมถึงผู้ที่ระบบนี้ตั้งใจให้ด้วย มีแรงจูงใจในการเข้าร่วมโครงการเพิ่มขึ้น ท้ายที่สุดแล้ว หากคุณสามารถสร้างรายได้จากธุรกิจที่น่าสนใจได้ มันก็ดีเสมอไป และที่สำคัญที่สุดเราได้ยินความปรารถนาอย่างหนึ่งจากลูกค้าซึ่งในเวลานั้นดูเหมือนเราจะบ้าไปแล้ว แต่ซึ่งตอนนี้เป็นแนวคิดหลักของ Embox คือการใช้โค้ดที่พัฒนาแล้วในระบบ ตอนนี้แนวคิดหลักของ Embox คือการใช้ซอฟต์แวร์ Linux ที่ไม่มี Linux นั่นคือแง่บวกหลักที่มีส่วนในการพัฒนาโครงการต่อไปคือการตระหนักว่าผู้ใช้บุคคลที่สามใช้โครงการนี้และควรแก้ไขปัญหาบางอย่างของพวกเขา

ในเวลานั้น Embox ได้ก้าวไปไกลกว่าขอบเขตของโครงการนักศึกษาแล้ว ปัจจัยจำกัดหลักในการพัฒนาโครงการตามแบบนักศึกษาคือแรงจูงใจของผู้เข้าร่วม นักเรียนมีส่วนร่วมในขณะที่เรียน และเมื่อสำเร็จการศึกษา ควรมีแรงจูงใจที่แตกต่างกัน หากไม่มีแรงจูงใจ นักเรียนก็เพียงแค่หยุดเข้าร่วมโครงการ หากเราคำนึงว่านักเรียนจำเป็นต้องได้รับการฝึกอบรมก่อน ปรากฎว่าพวกเขากลายเป็นผู้เชี่ยวชาญที่ดีเมื่อสำเร็จการศึกษา แต่การมีส่วนร่วมในโครงการนี้เนื่องจากไม่มีประสบการณ์จึงมีไม่มากนัก

โดยทั่วไปแล้ว เราไปยังประเด็นหลักได้อย่างราบรื่นซึ่งช่วยให้เราสามารถพูดคุยเกี่ยวกับการสร้างโครงการโอเพ่นซอร์ส - การสร้างผลิตภัณฑ์ที่จะแก้ปัญหาของผู้ใช้ ตามที่ฉันได้อธิบายไว้ข้างต้น คุณสมบัติหลักของโครงการโอเพ่นซอร์สก็คือชุมชนของโครงการ นอกจากนี้ สมาชิกชุมชนยังเป็นผู้ใช้งานเป็นหลัก แต่มันมาจากไหนเมื่อไม่มีอะไรใช้? ปรากฎว่า เช่นเดียวกับโปรเจ็กต์ที่ไม่ใช่โอเพ่นซอร์ส คุณต้องมุ่งเน้นไปที่การสร้าง MVP (ผลิตภัณฑ์ที่ใช้งานได้ขั้นต่ำ) และหากเป็นที่สนใจของผู้ใช้ ชุมชนก็จะปรากฏขึ้นรอบๆ โปรเจ็กต์ หากคุณมีส่วนร่วมในการสร้างชุมชนผ่านการประชาสัมพันธ์ชุมชนเท่านั้น การเขียนวิกิในทุกภาษาของโลก หรือแก้ไขเวิร์กโฟลว์คอมไพล์บน GitHub สิ่งนี้ไม่น่าจะมีความสำคัญในระยะแรกของโครงการ แน่นอนว่าในขั้นตอนที่เหมาะสม สิ่งเหล่านี้ไม่เพียงแต่สำคัญเท่านั้น แต่ยังเป็นสิ่งที่จำเป็นอีกด้วย

โดยสรุปผมอยากจะชี้ให้เห็นว่า ความเห็นในความคิดของฉัน สะท้อนให้เห็นถึงความคาดหวังของผู้ใช้จากโครงการโอเพ่นซอร์ส:

ฉันกำลังคิดอย่างจริงจังเกี่ยวกับการเปลี่ยนมาใช้ระบบปฏิบัติการนี้ (อย่างน้อยก็ลอง พวกเขากำลังติดตามมันและทำสิ่งเจ๋งๆ อยู่)

พีเอส เปิด เทคเทรน เราจะมีรายงานมากถึงสามรายงาน หนึ่งอันเกี่ยวกับโอเพ่นซอร์สและสองอันเกี่ยวกับการฝังตัว (และอีกอันใช้งานได้จริง) ที่บูธเราจะจัดคลาสมาสเตอร์เกี่ยวกับการเขียนโปรแกรมไมโครคอนโทรลเลอร์โดยใช้ เอ็มบ็อกซ์. ตามปกติ เราจะนำฮาร์ดแวร์มาให้คุณและตั้งโปรแกรมไว้ นอกจากนี้ยังจะมีภารกิจและกิจกรรมอื่นๆ มางานเฟสติวัลและสแตนด์ของเราก็จะสนุกแน่นอน

ที่มา: will.com