ภูมิปัญญาของการใช้รหัสโอเพนซอร์ซในผลิตภัณฑ์ซอฟต์แวร์เชิงพาณิชย์

ฉันกำลังมองหาที่ใช้โค้ดบางส่วนที่มาเปิดใน app เว็บของฉัน ASP.NET (เฉพาะDapper ) การจัดการไม่ได้เป็นแฟนเพราะโอเพ่นซอร์สถูกมองว่าเป็นความเสี่ยงที่กัดเรามาก่อน เห็นได้ชัดว่าผู้พัฒนาก่อนหน้านี้ต้องแก้ไขสิ่งต่าง ๆ หลังจากที่ส่วนประกอบโอเพ่นซอร์สล้มเหลว

ข้อดีดูเหมือนจะเป็น:

• มันทำสิ่งต่าง ๆ มากมายสำหรับฉันที่อาจเกี่ยวข้องกับรหัส boilerplate จำนวนมากหรือโซลูชันที่ Microsoft แนะนำ แต่ช้าลง (Entity Framework)

จุดด้อย:

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

ฉันทามติที่นี่คืออะไร? มันไม่ฉลาดที่จะใช้รหัสโอเพนซอร์สในโครงการของฉันที่ฉันไม่รู้จัก / เข้าใจรวมถึงฉันใช้โค้ดของตัวเอง?

มันเป็นทางเลือกที่คุณจะต้องทำตามสถานการณ์ที่เฉพาะเจาะจง คุณสามารถลดความเสี่ยงโดย:

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

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

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

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

แม้แต่ไลนัสก็ยอมรับว่าเขาพยายามหาวิธีแก้ปัญหา SCM ที่ตรงตามเกณฑ์ทั้งหมดของเขาก่อนที่จะพัฒนา Git อย่างน้อยเขาก็สามารถอธิบายได้ว่าทำไมการแก้ปัญหาที่มีอยู่ไม่ดีพอ

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

หมายเหตุ: ฉันไม่ใช่พนักงานของ Microsoft ความเห็นส่วนตัวอย่างสมบูรณ์ ความคิดมากมายมาจาก 5-7 ปีที่ผ่านมาในการใช้ทั้งโอเพนซอร์สและผู้ขายรายใหญ่ในฐานะนักพัฒนา

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

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

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

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

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

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

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

นอกจากนี้ยังมี LGPL ซึ่งเป็นกรณีชายแดนที่น่าสนใจซึ่งคุณสามารถใช้สิ่งเหล่านี้ได้ในขณะที่ไม่เปิดรหัสของคุณเองหากคุณ จำกัด การเข้าถึงขอบเขตแบบไบนารี (เช่นเข้าถึงไลบรารีเป็นไลบรารีแบบไดนามิกเท่านั้น) การใช้ห้องสมุด LGPL ทำได้มากคุณต้องระวังให้มากขึ้น

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

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

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

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

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

สันนิษฐานว่าประเด็นการออกใบอนุญาตจะไม่มีปัญหาที่นี่: ต้องดูอย่างรวดเร็วที่ Dapper ผมสังเกตเห็นว่ามีเพียง2,255 สายของดีเอกสารอ่านรหัส นั่นคือ

• ใหญ่พอที่คุณจะลงทุนได้หลายวันหรือหลายสัปดาห์เพื่อสร้างรหัสของคุณภาพที่เทียบเท่ากันได้
• มีขนาดเล็กพอที่คุณสามารถเข้าใจสิ่งที่มันทำและแก้ไขข้อบกพร่องใด ๆ ในรหัสนั้นหากปรากฏในการผลิต

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

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

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

สิ่งหนึ่งที่ควรคำนึงถึงที่นี่: ในกรณีของคุณคุณพูดถึงว่ามีทางเลือกที่ยอมรับกันอย่างกว้างขวางจากผู้จำหน่ายรายใหญ่ที่มีอยู่ (MS Entity Framework ซึ่งคุณไม่ต้องจ่ายค่าธรรมเนียมใบอนุญาตเพิ่มเติม!) คุณไม่ต้องการใช้เนื่องจากข้อควรพิจารณาด้านประสิทธิภาพ ฉันแนะนำอย่างจริงจังว่าอย่าปล่อยให้การแสดงเป็นจุดเดียวหรือหลักที่ควรพิจารณา คำถามที่คุณควรถามที่นี่มี Dapper ฟังก์ชั่นทั้งหมดที่คุณต้องการในขณะนี้และสำหรับอายุการใช้งานที่คาดหวังของซอฟต์แวร์ของคุณหรือไม่ หรือคุณสามารถคาดการณ์ได้ว่าคุณจะถึงขีด จำกัด ของ Dapper อย่างรวดเร็วและคุณจะต้องเพิ่มฟังก์ชันการทำงานที่ขาดหายไปจำนวนมากสิ่งที่คุณอาจจะไม่ต้องทำถ้าคุณตัดสินใจใช้ EF ในตอนแรก หากเป็นกรณีหลังฉันจะแนะนำไม่ให้ใช้ Dapper ถามตัวคุณเองด้วย: EF ไม่เร็วพอสำหรับการสมัครของคุณหรือไม่

เท่าที่ฉันเห็นมันเป็นการกระทำที่สมดุล

หากคุณทำให้ตัวเองต้องพึ่งพาผู้ขายก็มั่นใจได้ว่าการสนับสนุนจะหายไปในไม่ช้า

• เนื่องจากพวกเขามีโปรแกรมเมอร์ที่ต้องจ่ายเงินดังนั้นพวกเขาจึงต้องสร้างเวอร์ชั่นใหม่และทำให้แน่ใจว่าโปรแกรมเก่านั้นเป็นไปไม่ได้ที่จะได้รับและไม่ทำงานอีกต่อไป (บนแพลตฟอร์มใหม่) ดังนั้นคนใหม่จะมีตลาด

• หากพวกเขาไม่สามารถขายพอที่จะพิสูจน์รูปแบบธุรกิจพวกเขาส่งมันออกจาก บริษัท A ไปยัง บริษัท B ถึง C ซึ่งแต่ละอย่างเปลี่ยนไปมากพออีกครั้งคุณไม่สามารถใช้รูปแบบใหม่โดยไม่ต้อง reprogramming และคุณสามารถ ' ไม่ได้รับของเก่าที่ใช้งานได้

• พวกเขาตัดสินใจว่าจะไม่สนับสนุนอีกต่อไปเพราะปัญหามากเกินไปและไม่มีเงินอยู่ เงินทั้งหมดอยู่ในแอพใหม่

ดังนั้นหากคุณต้องการสร้างบางสิ่งที่ไม่จำเป็นต้องเขียนใหม่อย่างต่อเนื่องทุกสองสามปีโอเพนซอร์สสามารถเป็นเพื่อนของคุณได้

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

ถามผู้บริหารว่าทำไมมันถึงล้มเหลวมาก่อนมีความขยันเพียงพอ

jquery มีตัวเลือกในการใช้ใบอนุญาต MIT ดังนั้นเว็บไซต์การค้าและรัฐบาลหลายแห่งก็ใช้ jquery เช่นกัน เว็บไซต์ของ Microsoft ใช้ jquery ด้วย! ดังนั้นความกังวลคือการออกใบอนุญาต หลีกเลี่ยงการใช้ GPL / LGPL ก็เพียงพอแล้ว

"นานแค่ไหนที่จะได้รับการแก้ไขข้อบกพร่องรายงาน?" หลังจากรายงานข้อผิดพลาดมันอาจได้รับการแก้ไขภายในไม่กี่นาทีชั่วโมงหรือวัน สำหรับสถานการณ์เร่งด่วนพนักงานอาจ "ดึงคอมไพล์" เพื่อรับแหล่งและรวบรวมด้วยตนเอง เขาเพียงแค่รายงานรุ่นเช่น "v1.2.3-101-gd62fdae" ต่อฝ่ายจัดการซึ่งตรวจสอบย้อนกลับได้

โอเพ่นซอร์สนั้นเกี่ยวกับข้อกฎหมายไม่ใช่คุณภาพของรหัส มีผลิตภัณฑ์โอเพนซอร์ซที่ดีและไม่ดีเหมือนกับที่มีผลิตภัณฑ์โอเพนซอร์ซที่ดีและไม่ดี ฉันเชื่อว่าภาวะที่กลืนไม่เข้าคายไม่ออกของคุณคือการใช้โครงการที่พัฒนาโดยชุมชนของอาสาสมัคร

คุณแน่ใจหรือว่าปัญหาการจัดการเป็นปัญหาทางเทคนิค

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

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

และอีกจุดหนึ่งที่ควรจดจำ - "ไม่มีใครถูกไล่ออกจากการซื้อ IBM" (เช่นฝ่ายบริหารพูดสำหรับ "ถ้าคุณใช้เงินเป็นจำนวนมากจะต้องเป็นผลิตภัณฑ์ที่ดีกว่าผลิตภัณฑ์ที่ไม่มีค่าใช้จ่าย"