โอเพนซอร์สคือการโยนโค้ดลงบน GitHub มาทำความเข้าใจว่ามันคืออะไร และไม่ใช่อะไร?
พูดง่ายที่สุด การเขียนโปรแกรมโอเพนซอร์สคือการเขียนโค้ดที่ทุกคนสามารถนำไปใช้และดัดแปลงได้อย่างอิสระ แต่คุณคงเคยได้ยินเรื่องตลกเกี่ยวกับภาษา Go ที่ว่า Go “ง่ายจนมองครั้งเดียวก็เข้าใจกฎ แต่ต้องใช้ชั่วชีวิตเพื่อเรียนรู้การนำไปใช้” จริงๆ แล้วการเขียนโค้ดโอเพนซอร์สก็เช่นกัน การโยนโค้ดไม่กี่บรรทัดลงบน GitHub, Bitbucket, SourceForge หรือบล็อกหรือเว็บไซต์ของคุณเองไม่ใช่เรื่องยาก แต่ถ้าต้องการให้มีประสิทธิภาพ ยังต้องอาศัยความพยายามและวิสัยทัศน์ระยะยาวจากบุคคล
ความเข้าใจผิดเกี่ยวกับการเขียนโปรแกรมโอเพนซอร์ส
ก่อนอื่นผมต้องชี้แจงให้ชัดเจน: การวางโค้ดของคุณใน repository สาธารณะบน GitHub ไม่ได้หมายความว่าคุณได้เปิดเผยโค้ดของคุณแล้ว ในเกือบทั่วโลก โดยไม่ต้องให้ผู้สร้างทำอะไร ตราบใดที่ผลงานเกิดขึ้น ลิขสิทธิ์ก็เกิดขึ้นตามมา ก่อนที่ผู้สร้างจะให้สิทธิ์ มีเพียงผู้เขียนเท่านั้นที่สามารถใช้สิทธิ์ที่เกี่ยวข้องกับลิขสิทธิ์ได้ โค้ดที่ไม่ได้รับอนุญาตจากผู้สร้าง ไม่ว่าจะมีกี่คนใช้งาน ล้วนเป็นระเบิดเวลา มีเพียงคนโง่เท่านั้นที่จะไปใช้มัน
ผู้สร้างบางคนใจดี คิดว่า “ชัดเจนว่าโค้ดของผมให้ทุกคนใช้ฟรี” และเขาก็ไม่อยากฟ้องคนที่ใช้โค้ดของเขา แต่นั่นไม่ได้หมายความว่าโค้ดเหล่านี้สามารถใช้ได้อย่างสบายใจ ไม่ว่าในสายตาคุณผู้สร้างจะใจดีแค่ไหน พวกเขาล้วน มีอำนาจ ฟ้องทุกคนที่ใช้ ดัดแปลงโค้ด หรือฝังโค้ดโดยไม่ได้รับอนุญาตอย่างชัดเจน
ชัดเจนว่า คุณไม่ควรเผยแพร่ซอร์สโค้ดของคุณบนอินเทอร์เน็ตโดยไม่ระบุสัญญาอนุญาตโอเพนซอร์ส แล้วหวังว่าคนอื่นจะใช้และมีส่วนร่วมกับมัน ผมแนะนำว่าคุณควรหลีกเลี่ยงการใช้โค้ดแบบนี้ด้วย แม้แต่โค้ดที่สงสัยว่าไม่ได้รับอนุญาตก็ไม่ควรใช้ หากคุณพัฒนาฟังก์ชันและรูทีนที่คล้ายกับโค้ดที่สงสัยว่าไม่ได้รับอนุญาตก่อนหน้านี้ ผู้เขียนซอร์สโค้ดสามารถฟ้องคุณในข้อหาละเมิดลิขสิทธิ์
ยกตัวอย่างเช่น Jill Schmill เขียน AwesomeLib แล้ววางบน GitHub โดยไม่ระบุสัญญาอนุญาตอย่างชัดเจน แม้ Jill Schmill จะไม่ฟ้องใคร แต่ตราบใดที่เธอขายลิขสิทธิ์ทั้งหมดของ AwesomeLib ให้ EvilCorp EvilCorp ก็จะฟ้องคนที่ใช้โค้ดนี้โดยผิดกฎหมาย พฤติกรรมแบบนี้เหมือนกับการฝังอันตรายด้านความปลอดภัยคอมพิวเตอร์ สักวันหนึ่งจะถูกใช้ประโยชน์
โค้ดที่ไม่มีสัญญาอนุญาตอันตราย จำไว้ให้ดี
เลือกสัญญาอนุญาตโอเพนซอร์สที่เหมาะสม
สมมติว่าคุณกำลังจะเขียนโปรแกรมใหม่ และตั้งใจจะให้คนใช้ในรูปแบบโอเพนซอร์ส สิ่งที่คุณต้องทำคือเลือกสัญญาอนุญาตที่ตรงกับความต้องการของคุณมากที่สุด ตามที่โฆษณาบอก คุณสามารถเริ่มจาก choosealicense.com ที่ GitHub สนับสนุน เว็บไซต์นี้ออกแบบเหมือนแบบสอบถามง่ายๆ สะดวกและรวดเร็วมาก คลิกไม่กี่ครั้งก็หาสัญญาอนุญาตที่เหมาะสมได้
คำเตือน: อย่าหยิ่งผยองเกินไปเมื่อเลือกสัญญาอนุญาต หากคุณเลือกสัญญาอนุญาต ApacheหรือGPLv3ที่ใช้กันอย่างแพร่หลาย คนง่ายที่จะเข้าใจว่าพวกเขาและคุณมีสิทธิ์อะไรบ้าง คุณไม่ต้องจ้างทนายความมาตรวจสอบช่องโหว่ สัญญาอนุญาตที่คุณเลือกยิ่งมีคนใช้น้อย ยิ่งมีปัญหามากขึ้น
ที่สำคัญที่สุด: อย่าพยายามสร้างสัญญาอนุญาตของคุณเอง! การสร้างสัญญาอนุญาตของคุณเองจะนำความสับสนและปัญหามาสู่ทุกคน อย่าทำแบบนั้น หากในสัญญาอนุญาตที่มีอยู่จริงๆ หาข้อกำหนดที่คุณต้องการไม่ได้ คุณสามารถแนบความต้องการของคุณเพิ่มเติมในสัญญาอนุญาตที่มีอยู่ และเน้นย้ำ เตือนผู้ใช้ให้สังเกต
ผมรู้ว่าบางคนจะออกมาพูดว่า: “ผมขี้เกียจยุ่งกับสัญญาอนุญาต ผมโยนโค้ดลงสู่สาธารณสมบัติแล้ว” แต่ปัญหาคือ ผลทางกฎหมายของสาธารณสมบัติไม่ได้รับการยอมรับทั่วโลก ในประเทศต่างๆ ผลและรูปแบบของสาธารณสมบัติแตกต่างกัน ในบางประเทศที่รัฐบาลควบคุม คุณไม่สามารถโยนซอร์สโค้ดของคุณลงสู่สาธารณสมบัติได้ด้วยซ้ำ โชคดีที่Unlicenseสามารถเติมเต็มช่องโหว่เหล่านี้ได้ ภาษาของมันกระชับ ใช้คำไม่กี่คำอธิบายชัดเจนว่า “โยนลงสู่สาธารณสมบัติ” แต่ผลทางกฎหมายได้รับการยอมรับทั่วโลก
วิธีนำสัญญาอนุญาตเข้ามา
หลังจากกำหนดสัญญาอนุญาตที่จะใช้แล้ว คุณต้องระบุให้ชัดเจนและไม่คลุมเครือ หากคุณเผยแพร่บน GitHub, GitLab หรือ BitBucket คุณต้องสร้างโฟลเดอร์หลายโฟลเดอร์ ในโฟลเดอร์ราก คุณควรสร้างสัญญาอนุญาตเป็นไฟล์ข้อความธรรมดาชื่อ LICENSE.txt
หลังจากสร้างไฟล์ LICENSE.txt แล้วยังมีเรื่องอื่นต้องทำ คุณต้องเพิ่มบล็อกคอมเมนต์ในส่วนหัวของไฟล์สำคัญทุกไฟล์เพื่อประกาศสัญญาอนุญาต หากคุณใช้สัญญาอนุญาตที่มีอยู่แล้ว ขั้นตอนนี้ง่ายมากสำหรับคุณ บล็อกคอมเมนต์แบบ # ชื่อโปรเจกต์ (c)2018 ชื่อผู้เขียน สัญญาอนุญาต GPLv3 ดูรายละเอียดที่ https://www.gnu.org/licenses/gpl-3.0.en.html มีผลทางกฎหมายแรงกว่าการชี้นำสัญญาอนุญาตแบบคลุมเครือมาก
หากคุณจะเผยแพร่บนเว็บไซต์ของคุณเอง ขั้นตอนก็คล้ายกัน สร้างไฟล์ LICENSE.txt ก่อน ใส่สัญญาอนุญาต แล้วระบุที่มาของสัญญาอนุญาต
ความแตกต่างของโค้ดโอเพนซอร์ส
ความแตกต่างหลักระหว่างโค้ดโอเพนซอร์สและโค้ดกรรมสิทธิ์คือโค้ดโอเพนซอร์สเขียนขึ้นเพื่อให้คนอื่นดู ผมเป็นผู้ดูแลระบบอายุ 40 กว่า ได้เขียนโค้ดมามากมาย ในตอนแรกผมเขียนโค้ดเพื่องาน เพื่อแก้ปัญหาของบริษัท ดังนั้นโค้ดส่วนใหญ่เป็นโค้ดกรรมสิทธิ์ จุดประสงค์ของโค้ดแบบนี้ง่ายมาก ขอแค่ทำงานได้ในสถานการณ์เฉพาะผ่านวิธีเฉพาะก็พอ
โค้ดโอเพนซอร์สต่างออกไปอย่างสิ้นเชิง เมื่อเขียนโค้ดโอเพนซอร์ส คุณรู้ว่ามันอาจถูกใช้ในสภาพแวดล้อมที่หลากหลาย บางทีสภาพแวดล้อมของ use case ของคุณจำกัดมาก แต่คุณยังหวังว่ามันจะทำงานได้ดีในสภาพแวดล้อมต่างๆ เมื่อคนต่างๆ ใช้โค้ดเหล่านี้จะเกิด use case หลายประเภท คุณจะเห็นความขัดแย้งหลายอย่าง และแนวคิดที่คุณไม่เคยคิดถึง แม้โค้ดไม่จำเป็นต้องตอบสนองทุกคน แต่อย่างน้อยควรจัดการปัญหาที่พวกเขาเจออย่างเหมาะสม แม้แก้ไม่ได้ ก็ควรแปลงกลับเป็นตรรกะทั่วไป ไม่สร้างปัญหาให้ผู้ใช้ (เช่น “ข้อผิดพลาดการหารด้วยศูนย์ที่บรรทัด 583” ไม่ควรเป็นผลลัพธ์ตอบสนองต่อการให้ argument บรรทัดคำสั่งผิดพลาด)
ซอร์สโค้ดของคุณอาจทำให้คุณบ้าได้ โดยเฉพาะหลังจากแก้ไขฟังก์ชันหรือ subroutine ที่ผิดพลาดซ้ำแล้วซ้ำเล่า จนในที่สุดได้ผลลัพธ์ที่คุณหวัง ตอนนั้นคุณจะไม่ได้ถอนหายใจแล้วไปทำงานถัดไป คุณจะทำความสะอาดกระบวนการ เพราะคุณไม่อยากให้ใครเห็นร่องรอยการลองผิดลองถูกซ้ำแล้วซ้ำเล่าของคุณ เช่น คุณจะเปลี่ยน $variable, $lol ทั้งหมดเป็น $iterationcounter และ $modelname ที่มีความหมาย นั่นหมายความว่าคุณต้องคอมเมนต์อย่างจริงจังและเป็นมืออาชีพ (แม้สำหรับความรู้พื้นหลังที่คุณอยู่มันไม่ยากที่จะเข้าใจ) เพราะคุณหวังว่าจะมีคนมากขึ้นใช้โค้ดของคุณ
กระบวนการนี้หลีกเลี่ยงไม่ได้ที่จะเจ็บปวดและท้อแท้ หลังจากทั้งหมดนี้ไม่ใช่สิ่งที่คุณทำประจำ จะรู้สึกไม่คุ้นเคย แต่มันจะทำให้คุณเป็นโปรแกรมเมอร์ที่ดีขึ้น และทำให้โค้ดของคุณยกระดับ แม้โปรเจกต์ของคุณจะมีคุณเพียงคนเดียวที่มีส่วนร่วม การทำความสะอาดโค้ดก็จะประหยัดงานของคุณในภายหลังได้มาก เชื่อผมสิ หนึ่งปีให้หลังเมื่อคุณดูโค้ดแอปของคุณอีกครั้ง คุณจะดีใจที่เขียน $modelname และมีคอมเมนต์ชัดเจน ไม่ใช่ลำดับตัวเลขที่ไม่รู้จัก หรือแม้แต่ $lol ก็ไม่ใช่
คุณไม่ได้เขียนเพื่อคุณคนเดียว
แก่นแท้ของโอเพนซอร์สไม่ใช่โค้ด แต่เป็นชุมชน โปรเจกต์ที่มีชุมชนใหญ่กว่ามีอายุยืนยาวกว่า และคนยอมรับได้ง่ายกว่า ดังนั้นไม่เพียงต้องเข้าร่วมชุมชน แต่ยังต้องมีส่วนร่วมในการพัฒนาชุมชนมากขึ้น ให้โปรเจกต์ของคุณเป็นประโยชน์ต่อชุมชน
แบทแมนทำงานหนักลำพังอย่างลับๆ เพื่อบรรลุเป้าหมาย คุณไม่ต้องทำแบบนั้น คุณสามารถล็อกอิน Twitter, Reddit หรือส่งอีเมลให้คนที่เกี่ยวข้องกับโปรเจกต์ของคุณ ประกาศข่าวว่าคุณกำลังเตรียมโปรเจกต์ใหม่ พูดคุยเกี่ยวกับจุดประสงค์การออกแบบและแผนของคุณอย่างละเอียด ให้ทุกคนช่วยกัน เก็บรวบรวมข้อมูล input และ use case ที่คล้ายกันจากทุกคน นำข้อมูลเหล่านี้มารวมไว้ ใช้ในโค้ดของคุณ คุณไม่ต้องยอมรับข้อเสนอและคำขอทั้งหมด แต่คุณต้องมีความเข้าใจโดยรวม จะได้หลีกเลี่ยงกับดักบางอย่างเมื่อปรับปรุงในภายหลัง
หลังจากประกาศครั้งแรกแล้วกระบวนการยังไม่สมบูรณ์ หากคุณหวังว่าทุกคนจะยอมรับและใช้ผลงานของคุณ คุณต้องออกแบบโดยมีจุดประสงค์นี้ สาธารณชนอาจช่วยคุณได้ คุณไม่ต้องมองการเปิดเผยเป็นศัตรู ดังนั้นอย่าทำงานแบบปิดกั้น เมื่อคุณเขียนเพื่อทุกคน ก็สร้างโปรเจกต์ที่แท้จริงและเปิดเผย จินตนาการว่าคุณกำลังทำให้สำเร็จทีละขั้นตอนอย่างจริงจังภายใต้ความช่วยเหลือและการกำกับดูแลของชุมชน
วิธีสร้างโปรเจกต์
คุณสามารถลงทะเบียนบัญชีฟรีบน GitHub, GitLab หรือ BitBucket เพื่อจัดการโปรเจกต์ของคุณ หลังจากลงทะเบียนแล้ว สร้าง repository สร้างไฟล์ README กำหนดสัญญาอนุญาต และเขียนโค้ดทีละขั้นตอน วิธีนี้จะช่วยให้คุณสร้างนิสัยที่ดี ทำให้เมื่อคุณทำงานกับทีมจริงในภายหลัง สามารถทำงานไปสู่เป้าหมายอย่างมีจุดประสงค์และมั่นคง ยิ่งคุณทำนานเท่าไหร่ ยิ่งมีความสนใจมากขึ้น โดยปกติจะมีผู้ใช้สนใจโปรเจกต์ของคุณก่อน
ผู้ใช้จะเริ่มถามคำถาม บางครั้งจะทำให้คุณมีความสุข บางครั้งจะทำให้คุณรำคาญ คุณควรตอบด้วยความเป็นมิตรและสุภาพ แม้พวกเขาหลายคนเข้าใจผิดเกี่ยวกับโปรเจกต์มาก หรือไม่รู้เลยว่าโปรเจกต์ของคุณทำอะไร คุณก็ควรปฏิบัติต่อพวกเขาอย่างสุภาพและเป็นมืออาชีพ ในมุมหนึ่ง คุณสามารถชี้นำพวกเขาให้เข้าใจสิ่งที่คุณทำ ในอีกมุมหนึ่ง พวกเขาจะค่อยๆ นำคุณเข้าสู่ชุมชนที่ใหญ่ขึ้น
หากโปรเจกต์ของคุณได้รับความนิยมจากผู้ใช้ จะมีนักพัฒนาระดับสูงปรากฏตัวและแสดงความสนใจ นี่อาจเป็นเรื่องดี หรืออาจทำให้คุณโกรธ ในตอนแรกคุณอาจทำเพียงการแก้ไขปัญหาง่ายๆ แต่สักวันหนึ่งคุณจะได้รับ pull request อาจเป็น hard coding หรือ use case พิเศษ (อาจทำให้โปรเจกต์ดูแลยากขึ้น) มันอาจเปลี่ยนขอบเขตของโปรเจกต์ของคุณ หรือแม้แต่เปลี่ยนจุดประสงค์ดั้งเดิมของโปรเจกต์ คุณต้องเรียนรู้ที่จะแยกแยะว่าอะไรมีส่วนร่วม และตัดสินใจว่าจะ merge อันไหน ปฏิเสธอันไหน
ทำไมเราต้องเปิดเผยซอร์ส?
โอเพนซอร์สฟังดูเป็นงานหนัก และมันก็เป็นจริงๆ แต่มันก็มีประโยชน์หลายอย่างสำหรับคุณ มันสามารถฝึกฝนคุณโดยไม่รู้ตัว ทำให้คุณเขียนโค้ดที่บริสุทธิ์และยั่งยืน และสอนให้คุณสื่อสารและทำงานเป็นทีม สำหรับนักพัฒนามืออาชีพที่มีความทะเยอทะยาน มันเป็นเนื้อหาประวัติที่ดีที่สุด นายจ้างในอนาคตของคุณอาจคลิกเข้าไปดู repository ของคุณ เพื่อทำความเข้าใจขอบเขตความสามารถของคุณ และนักพัฒนาจากโปรเจกต์ชุมชนอาจนำงานมาสู่คุณ
สุดท้าย การทำงานเพื่อโอเพนซอร์ส หมายถึงการพัฒนาตนเอง เพราะสิ่งที่คุณทำไม่ได้เป็นเพียงเพื่อคุณคนเดียว มันสำคัญกว่าการเลี้ยงชีพตัวเองมาก
โปรดระบุแหล่งที่มา: ความสัมพันธ์นักพัฒนา »
