การต่อต้านโอเพนซอร์ส: มาปกป้องโอเพนซอร์สในเวลางานกันเถอะ
(ossresistance.com)- Open Source Resistance คือแถลงการณ์ปฏิบัติการโดยตรง (manifesto) ที่ชวนให้บำรุงรักษาซอฟต์แวร์โอเพนซอร์สที่บริษัทพึ่งพาอยู่ อย่างเงียบ ๆ และเป็นมืออาชีพภายในเวลางาน
- แม้ทุกบริษัทจะไม่สามารถดำเนินธุรกิจได้หากไม่มีโอเพนซอร์ส แต่กลับมีโครงสร้างที่ทำให้เมนเทนเนอร์ต้อง อ้อนวอนขออนุญาต ปุ่มบริจาค หรือเวลาบ่ายวันศุกร์ ซึ่งแนวคิดนี้ปฏิเสธโครงสร้างดังกล่าว
- ก่อนหน้านี้ก็มีทางเลือกอย่าง Open Source Pledge (ขอให้จ่ายปีละ US$2,000 ต่อผู้พัฒนา 1 คน) หรือ Open Source Friday (ร่วมสนับสนุนอย่างน้อย 2 ชั่วโมงทุกวันศุกร์) อยู่แล้ว แต่แนวคิดนี้ย้ำการลงมือทำที่ตรงไปตรงมามากกว่า
- ต่อข้อโต้แย้งว่าเป็น “การขโมยเวลา” ก็สามารถตอบได้ว่าบริษัทได้รับเงินอุดหนุน OSS ฟรีมาโดยตลอดอยู่แล้ว และการบำรุงรักษา OSS ที่ตนพึ่งพาก็คือ งานโครงสร้างพื้นฐานร่วม
- ต้องตรวจสอบ ข้อกำหนดการโอนสิทธิ์ IP ในสัญญาจ้างให้แน่ชัด และควรเจรจาข้อยกเว้นสำหรับโอเพนซอร์สเป็นลายลักษณ์อักษร
แถลงการณ์: อย่าขออนุญาตเพื่อซ่อมงานที่จำเป็นอยู่แล้ว
- Open Source Resistance คือข้อเสนอเชิงปฏิบัติการโดยตรงที่บอกว่า การบำรุงรักษา ซอฟต์แวร์โอเพนซอร์ส (OSS) ที่บริษัทพึ่งพาไม่ควรถูกผลักให้เป็นงานอดิเรกยามค่ำคืนหรือวันหยุดสุดสัปดาห์ แต่ควรถูกทำ ในเวลางาน อย่างเงียบ ๆ และเป็นมืออาชีพ
- ซอฟต์แวร์โอเพนซอร์สไม่ใช่ “งานอดิเรก” ในเวลาว่าง และแม้บริษัทจะดึงคุณค่าจากโอเพนซอร์สในทุกชั่วโมง แต่สิ่งที่มอบให้เมนเทนเนอร์กลับมีเพียง บ่ายวันศุกร์สักครั้ง ปุ่มบริจาคสักปุ่ม หรือคำขอบคุณในที่ประชุมใหญ่
- เมนเทนเนอร์ควรทำงานกับโค้ด OSS ที่บริษัทใช้อยู่แล้วจากภายในองค์กร ในเวลางานได้โดยไม่ต้องมีเอกสาร โปรแกรมภายใน หรือการอนุมัติจากผู้จัดการ
- นี่ไม่ใช่แนวคิดใหม่ แต่คือการ พูดออกมาตรง ๆ ถึงวิธีที่โอเพนซอร์สส่วนใหญ่ดำเนินมาโดยตลอด
- เมนเทนเนอร์คือผู้ที่คอยประคับประคองอินเทอร์เน็ตโดยไม่ต้องรอการอนุมัติจากการประชุม สปรินต์ หรือผู้จัดการผลิตภัณฑ์
หลักการปฏิบัติสำคัญ
-
ปกป้องตัวเอง
- ตรวจสอบสัญญาจ้างงาน, เก็บข้อมูลลับไว้ภายในบริษัท และทำให้แน่ใจว่าคุณถือสิทธิ์ในทรัพย์สินทางปัญญาของโอเพนซอร์สที่คุณเผยแพร่
-
ลงมือทำงาน
- ทำ PR review, อัปเดต dependency และแก้บั๊กในส่วนที่เป็น OSS อยู่แล้ว
-
อย่าหุนหันพลันแล่น
- อย่าใช้เวลางาน 100% ไปกับ OSS แล้วพอถูกไล่ออกค่อยไปโทษคนอื่น; หัวใจสำคัญคือ ความสมดุล
ทางเลือกที่มีอยู่แล้ว
- Open Source Pledge: ขอให้บริษัทจ่ายเงินให้เมนเทนเนอร์ (ปีละ US$2,000 ต่อผู้พัฒนา 1 คน)
- Open Source Friday: ขอให้บริษัทบริจาคเวลา (อย่างน้อย 2 ชั่วโมงทุกวันศุกร์)
- ยังมี แนวทางแบบสุภาพ ที่เริ่มจากการโน้มน้าวนายจ้างก่อน ซึ่งล้วนเป็นแนวทางเชิงบวกและควรค่าแก่การสนับสนุน
- Open Source Resistance คือขั้นถัดไปของกระแสนี้ โดยประกาศว่าการบำรุงรักษา dependency chain นั้น เป็นส่วนหนึ่งของงานอยู่แล้ว แม้ผู้จัดการจะไม่ได้ตั้งชื่อให้ก็ตาม
- แม้คุณจะควบคุมการจัดสรรงบประมาณของบริษัทไม่ได้ แต่คุณยังควบคุมได้ว่า จะใช้เวลางานของตัวเองอย่างไร
ข้อโต้แย้งที่คาดว่าจะเจอและคำตอบ
-
"นี่คือการขโมยเวลา / ขโมยผู้ถือหุ้น"
- บริษัทต่าง ๆ ดึงคุณค่าจากเมนเทนเนอร์โอเพนซอร์สอยู่ทุกวัน และผู้ถือหุ้นก็ได้รับ เงินอุดหนุนโอเพนซอร์สฟรี มานานหลายทศวรรษแล้ว
- หากนายจ้างพึ่งพา OSS การบำรุงรักษามันก็เป็น งานโครงสร้างพื้นฐานเพื่อประโยชน์ส่วนรวม ไม่ใช่การขโมย
-
"ต้องขออนุญาตก่อน"
- การขออนุญาตคือการคงไว้ซึ่ง ความไม่สมดุลของอำนาจ
- การดูแลโครงสร้างพื้นฐานที่นายจ้างใช้อยู่แล้วไม่ควรต้องการพรจากผู้จัดการ
-
"ก็เหมือน quiet quitting"
- quiet quitting คือการลดปริมาณงาน แต่สิ่งนี้คือการ ผลิตโครงสร้างพื้นฐาน OSS ที่สร้างอินเทอร์เน็ตขึ้นมา
- ปัญหาไม่ได้อยู่ที่ตัวงาน แต่อยู่ที่บริษัท ปฏิเสธ จะนับสิ่งนี้เป็นงาน
-
"แม้นายจ้างที่ดีก็ยังได้รับผลกระทบ"
- นายจ้างที่ดีสามารถหลีกเลี่ยงปัญหานี้ได้ด้วยการอนุญาตให้บำรุงรักษาโอเพนซอร์สในเวลางาน สนับสนุนเงินทุนให้เมนเทนเนอร์ หรือ เข้าร่วม Open Source Pledge
ประสบการณ์ของ Mike McQuaid
- ผู้ร่วมก่อตั้ง Open Source Friday และ GitHub Sponsors รวมถึงเป็นผู้นำโครงการ Homebrew (เป็นเมนเทนเนอร์ตั้งแต่ปี 2009)
- ไม่เคยมีงานที่ไหนที่จ่ายเงินให้การทำงานบนโครงการโอเพนซอร์สอย่าง Homebrew เป็น หน้าที่หลัก
- ถึงอย่างนั้น เขาก็ทำสิ่งนี้กับนายจ้างทุกแห่ง โดยเจรจาสัญญา IP ให้ถูกต้องตามกฎหมาย และยังคงทำตามภาระงานที่รับไว้
- หลังมีลูก งานโอเพนซอร์ส มากกว่า 90% ถูกทำในเวลางาน
- เช่นเดียวกับที่เขาเขียนใน Open Source Maintainers Owe You Nothing เขามองว่าไม่มีใครมีสิทธิ์เรียกร้องเวลาเวลากลางคืน วันหยุดสุดสัปดาห์ หรือเวลาครอบครัวแบบไม่ได้รับค่าตอบแทนจากผู้ดูแล เพียงเพราะโมเดลธุรกิจของบริษัทใดบริษัทหนึ่งพึ่งพาโค้ดของเขา
ข้อควรระวังและคำชี้แจงทางกฎหมาย
-
ไม่ใช่คำแนะนำทางกฎหมาย
- เนื้อหานี้ระบุชัดว่า ไม่ใช่คำแนะนำทางกฎหมาย และไม่ใช่คำแนะนำเกี่ยวกับสัญญา นายจ้าง สถานะการเข้าเมือง ภาระผูกพันด้านไลเซนส์ หรือสถานการณ์เฉพาะบุคคล
- หากมีความเสี่ยงสูง ควรปรึกษาผู้มีคุณสมบัติเหมาะสมก่อนลงมือ
- เช่นเดียวกับ ไลเซนส์โอเพนซอร์สส่วนใหญ่ ไม่มีการรับประกันใด ๆ และให้มาแบบ “ตามสภาพ”
-
สัญญา นโยบาย และกรรมสิทธิ์
- สัญญาจ้าง คู่มือนโยบาย และข้อกำหนดการโอนสิ่งประดิษฐ์อาจอ้างสิทธิ์เหนือผลงานที่สร้างขึ้นระหว่างการจ้างงาน ผลงานที่ทำบนอุปกรณ์ของนายจ้าง หรือผลงานที่อยู่ในขอบเขตหน้าที่งาน
- บางรัฐจำกัดการอ้างสิทธิ์ลักษณะนี้กับงานที่ทำในเวลาส่วนตัวและด้วยอุปกรณ์ส่วนตัว แต่รายละเอียดมีความสำคัญมาก
- ก่อนลงมือ ควรอ่าน สัญญาจ้างงาน และตรวจสอบให้แน่ใจว่านายจ้างไม่ได้เป็นเจ้าของ IP ของโอเพนซอร์สที่คุณตั้งใจจะเผยแพร่
- หากอุปกรณ์ เครือข่าย หรือบัญชีมีผลต่อความเสี่ยงเรื่องกรรมสิทธิ์ ก็ควรใช้อุปกรณ์ของตัวเอง
-
การเจรจาสัญญา IP
- การโอนสิทธิ์ IP มักต่อรองได้ และแนะนำว่าเมื่อได้รับข้อเสนองาน ให้ขอข้อยกเว้นสำหรับโอเพนซอร์สเป็น ลายลักษณ์อักษร ก่อนเซ็น
- ควรอ่าน ข้อตกลง IP ของพนักงาน ก่อน เพื่อรู้ว่าควรคัดค้านส่วนใด
- Mike McQuaid ระบุว่าเขาเจรจาเปลี่ยนแปลงจากสัญญามาตรฐานกับนายจ้างแทบทุกแห่ง และส่วนใหญ่ได้รับแรงต้านน้อยกว่าที่คาดมาก
- คุณสามารถแสดง Balanced Employee IP Agreement ของ GitHub ให้กับนายจ้างที่อาจจ้างคุณดูได้
- สัญญานี้ถูกทำเป็นโอเพนซอร์สภายใต้ CC0 มีบริษัทมหาชนขนาดใหญ่ใช้งานจริง และออกแบบให้นายจ้างถือครองสิ่งที่ตนจ่ายเงินไป ขณะที่พนักงานยังคงถือครองงานโอเพนซอร์สที่ไม่แข่งขันกับธุรกิจได้
-
การรักษาความลับและความปลอดภัย
- ห้ามเปิดเผยรีโพสิตอรีส่วนตัว ข้อมูลรับรอง อินซิเดนต์ ข้อมูลลูกค้า โรดแมป ช่องโหว่ที่ยังไม่เปิดเผย หรือการสนทนาภายใน
- ห้ามหลบเลี่ยงมาตรการความปลอดภัย หรือใช้สิทธิ์เข้าถึงที่ไม่ได้รับอนุญาต
- การลงมือโดยตรงไม่ใช่ข้ออ้างในการเปิดเผยข้อมูลลับของบริษัท แต่คือการ คงให้งานสาธารณะเป็นงานสาธารณะ และแยกมันออกจากความลับทางการค้าอย่างชัดเจน
-
ความเงียบไม่ได้แปลว่าประมาท
- เมื่อมีนโยบาย สัญญา ภาระผูกพันต่อลูกค้า หรือกฎความปลอดภัยที่เปลี่ยนระดับความเสี่ยง คุณต้องใช้ วิจารณญาณของตนเอง
- คุณอาจต้องทำงานบนอุปกรณ์ บัญชี และเครือข่ายของตัวเอง
- นี่ไม่ใช่การ “ขโมย” จากบริษัท แต่คือการทำให้เกิด ความสมดุล ระหว่างสิ่งที่บริษัทเอาไปจากโอเพนซอร์สกับสิ่งที่คุณสามารถตอบแทนได้
- คุณอาจได้คะแนนประเมินผลงานต่ำกว่าเพื่อนร่วมงาน แต่การรักษาระดับ B อย่างยั่งยืนก็ยังดีต่อสุขภาพมากกว่าการ เผาชีวิตเพื่อไล่ล่าระดับ A ในบริษัทที่พร้อมจะไล่คุณออกได้ในวันพรุ่งนี้
-
ขอบเขตการใช้งาน
- ข้ออ้างนี้จะอ่อนลงมากเมื่อเวลางานถูกคิดค่าบริการให้ลูกค้าเฉพาะราย ทุนสนับสนุน หน่วยงานรัฐ โครงการด้านกลาโหม หรือสภาพแวดล้อมที่มีการกำกับดูแล
- มันยังอ่อนลงมากสำหรับ วิศวกรระดับจูเนียร์หรือวิศวกรที่สถานะไม่มั่นคง ซึ่งไม่มีอำนาจต่อรองพอจะรับผลเสียได้
- แต่จะแข็งแรงที่สุดสำหรับ เมนเทนเนอร์ระดับซีเนียร์ ที่แก้ไข dependency สาธารณะที่นายจ้างใช้อยู่แล้ว
- รูปแบบที่สะอาดที่สุดไม่ใช่ “ทำอะไรก็ได้ที่อยากทำในเวลางาน” แต่คือ ปฏิบัติต่อการบำรุงรักษาโอเพนซอร์สให้เป็นส่วนหนึ่งของงานวิศวกรรม
- ควรบำรุงรักษาโครงการที่คุณดูแลอยู่แล้ว ปรับปรุงเครื่องมือร่วมที่แตะกับงานของคุณ และหลีกเลี่ยงงานที่ไม่เกี่ยวข้อง โค้ดปิด หรือสิ่งที่ทำให้พลาดภาระผูกพันจริง
แหล่งที่มาและโครงการ
- สร้างโดย Mike McQuaid และเปิดเผยซอร์สไว้บน GitHub
2 ความคิดเห็น
โดยรวมแล้ว,,, ดูเหมือนว่าคำว่า เรซิสแตนซ์ จะเหมาะสมครับ
ความคิดเห็นจาก Hacker News
โดยทั่วไปแล้วหลายบริษัทให้สิทธิแบบครอบคลุมในการมีส่วนร่วมกับโครงการโอเพนซอร์สบางตัว
วิธีพูดสำคัญมาก ไม่ใช่ “ขอทำงานการกุศลให้ตัวเองรู้สึกดีได้ไหม?” แต่ควรพูดว่า “ขอรับ รีวิวที่เข้มงวดฟรี จากผู้เชี่ยวชาญในสาขานี้ และส่งการแก้ไขกลับไปยังโครงการโอเพนซอร์สต้นน้ำเพื่อลดต้นทุนการบำรุงรักษาในอนาคตของบริษัทได้ไหม?”
ซึ่งจริง ๆ แล้วนั่นคือแก่นของเรื่อง และเมื่อพูดแบบนั้นก็ไม่เคยมีนายจ้างคนไหนปฏิเสธ เพราะมันสอดคล้องกับผลประโยชน์ของบริษัทเต็ม ๆ แค่ต้องช่วยให้เขาเห็นภาพนั้น
ฉันเขียนใหม่ไปมากแต่ยังคงความเข้ากันได้ของ API เอาไว้เป็นส่วนใหญ่ และเน้น I/O แบบไม่บล็อกที่สามารถใช้ semantics ของ backpressure ได้หากต้องการ มันทำให้เกิดสิ่งที่น่าสนใจได้ เพราะสามารถผสม state store กับ I/O แบบบล็อก/ไม่บล็อกได้โดยยังรักษาประสิทธิภาพได้พอสมควร และเป็นโปรเจ็กต์ที่ฉันภูมิใจมากเป็นพิเศษเพราะรีดประสิทธิภาพจากหลายจุดที่มองไม่ค่อยเห็น
ฉันพยายามผลักดันให้ปล่อยบน GitHub หรือส่ง PR ไปยังโปรเจ็กต์ Kafka Streams ต้นน้ำ แต่ก่อนจะไปถึงจุดนั้นก็มีการปลดพนักงาน และหลังจากนั้นก็ไม่มี ผู้ผลักดัน งานนี้อีก มันเลยถูกขังไว้เป็นโค้ดปิดกรรมสิทธิ์
จนถึงตอนนี้ก็ยังคิดว่าจะสร้างมันใหม่ตั้งแต่ต้นแล้วปล่อยเป็นโอเพนซอร์สเสรีดีไหม เวลาผ่านมาพอสมควรแล้ว น่าจะไม่มีปัญหาถ้าจะเขียนใหม่แล้วปล่อยออกมา และก็ไม่มีเรื่องสิทธิบัตรอะไรด้วย แถมยังมีอย่างที่อยากเปลี่ยน เช่น เอา dependency ของ Vert.x ออก ถ้าวันหนึ่งได้หยุดพักสักอาทิตย์ อาจจะลองทำดู
บางบริษัทติดขัดได้เพียงแค่เพราะกระบวนการตรวจสอบทางกฎหมาย
ครั้งหนึ่งฉันเคยขออนุญาตว่าส่งแพตช์ไปยังโปรเจ็กต์หนึ่งได้ไหม แล้วก็มีอีเมลเธรดที่น่าสนใจตามมา สุดท้ายคำถามมีอยู่อย่างเดียว: ถ้าแพตช์นั้นเขียนขึ้นเพื่อแก้บั๊กในผลิตภัณฑ์ที่ส่งมอบ ระหว่างเวลาที่คิดเงินลูกค้า ต้องคอมไพล์ไลบรารีที่ถูกแพตช์ใหม่และส่งมอบพร้อมซอร์สโค้ด และในสัญญาระบุว่างานทั้งหมดและทรัพย์สินทางปัญญาที่เกี่ยวกับผลิตภัณฑ์จะโอนไปยังลูกค้า เรามีสิทธิปล่อยแพตช์นั้นเป็น public domain หรือไม่?
ฝ่ายกฎหมายไม่อยากตอบ
จะเข้าหาเรื่องนี้ได้อย่างไรยังขึ้นกับดวงเรื่องนายจ้างมากด้วย
สำหรับคำพูดที่ว่า “และต้องแน่ใจว่าคุณเป็นเจ้าของทรัพย์สินทางปัญญาของโอเพนซอร์สที่เผยแพร่” ในเขตอำนาจที่ฉันเคยทำงานมา โค้ดที่เขียนและเผยแพร่ในเวลางานเป็นของนายจ้าง ไม่ใช่ของฉัน
ฉันตัดสินใจเองไม่ได้ว่าจะมีส่วนร่วมในเวลางานหรือไม่ และหากจะทำงานกับโค้ดโอเพนซอร์สก็ต้องมีข้อตกลงอย่างเป็นทางการ ทุกครั้งที่ขอ ต้องผ่านฝ่ายกฎหมายและใช้เวลาหลายเดือน สุดท้ายก็เลยล้มเลิก หรือระหว่างนั้นก็มีคนอื่นส่ง PR ไปแล้ว ทำให้ไม่ขออีกต่อไป
สำหรับนักพัฒนาที่มีประสบการณ์นี่เป็นเรื่องชัดเจนอยู่แล้ว แต่กับนักพัฒนาจูเนียร์ในบางบริษัท มันเป็นปัญหาจริง บริษัทอาจทำอะไรเจ๋ง ๆ อยู่ในโปรเจ็กต์ภายใน แล้วเขาก็คิดว่าน่าจะเอาไป contribute ให้โปรเจ็กต์โอเพนซอร์สสักตัวได้ โดยไม่ทันคิดว่าตนกำลังใช้ความรู้จากโค้ดปิดเพื่อส่งโค้ดที่เหมือนกันอย่างมีนัยสำคัญ หรือบางทีก็คัดลอกวางเลย
นายจ้างส่วนใหญ่ที่ไม่ได้เน้นด้านไอทีคงไม่เข้าใจด้วยซ้ำว่า โอเพนซอร์ส คืออะไรและทำงานอย่างไร เพราะอย่างนั้น การต้องไปขออนุญาตจากคนจำนวนมากอาจสิ้นหวังมาก
เว็บไซต์ที่ลิงก์มาน่าจะโฟกัสกับการอธิบายประโยชน์ของโอเพนซอร์สให้นายจ้างเข้าใจก่อน และผลักดัน แนวทางกฎหมายสำหรับนายจ้าง
เป็นความคิดที่ดีมาก และถึงขั้นยอดเยี่ยมด้วยซ้ำ แต่ไม่แน่ใจว่าการวางตำแหน่งให้เป็น การต่อต้าน จะดีหรือเปล่า
เป้าหมายของงานโดยทั่วไปคือการบรรลุวัตถุประสงค์บางอย่าง และผู้เชี่ยวชาญอย่างนักพัฒนาควรเป็นคนตัดสินใจว่าจะบรรลุเป้าหมายนั้นอย่างไร ถ้าในการตัดสินใจนั้นมีซอฟต์แวร์โอเพนซอร์สรวมอยู่ด้วย การดูแลรักษามันก็ควรเป็นส่วนหนึ่งของการตัดสินใจนั้นด้วย
มันไม่ใช่เรื่องหัวรุนแรงอะไร แค่เป็นการทำงานของตัวเองพร้อมรักษาเสถียรภาพและความสามารถในการบำรุงรักษาของสิ่งที่งานนั้นพึ่งพา
ฟีเจอร์ไร้ประโยชน์เพื่อเล่นเกมตัวชี้วัด, enshittification, dark pattern, และการรวมของตามกระแสที่แทบเป็นมัลแวร์ กลับมาก่อนการลงทุนในอินฟราหรือไลบรารีพื้นฐาน
ในเชิงหลักการฉันเห็นด้วยเต็มที่ แต่ในทางปฏิบัติมันทำได้ยาก ฉันไม่ใช่ทนาย แต่โดยทั่วไปเข้าใจว่านายจ้างเป็นเจ้าของทรัพย์สินทางปัญญา จึงต้องมีการอนุญาตอย่างชัดแจ้งหากจะปล่อยเป็นโอเพนซอร์ส
และกระบวนการขออนุญาตนั้นก็มักยาก ต้องผ่านขั้นตอนและฝ่ายกฎหมายไม่รู้จบ
“ในสหรัฐฯ สหราชอาณาจักร และอีกหลายเขตอำนาจศาล หากลูกจ้างสร้างงานขึ้นเป็นส่วนหนึ่งของหน้าที่ นายจ้างจะถือเป็นผู้ประพันธ์ตามกฎหมายหรือเป็นเจ้าของลิขสิทธิ์รายแรก”
https://en.wikipedia.org/wiki/Work_for_hire
ถึงอย่างนั้นฉันก็ยังคิดว่างานโอเพนซอร์ส ทั้งการบำรุงรักษาและการพัฒนา ควรทำโดย ผู้เชี่ยวชาญที่ได้รับค่าจ้าง ไม่ใช่อาสาสมัครที่ต้องคอยขอรับบริจาค คำถามสำคัญคือจะทำให้สิ่งนี้เกิดขึ้นได้อย่างไร และจะทำให้บริษัทต่าง ๆ ยอมรับการมีส่วนร่วมกับโอเพนซอร์สเป็นแนวปฏิบัติมาตรฐานแทนที่จะเป็นข้อยกเว้นที่ต้องเจรจาเป็นรายกรณีได้อย่างไร
ในโลกจริงก็แค่ทำไปเลย ไม่มีซับรูทีนในคอมพิวเตอร์ที่คอยกัน
git pushไว้ นายจ้างเองก็เขียนสารพัดอย่างลงในสัญญาจ้าง พยายามปัดความรับผิดชอบจากทุกทิศทางให้มากที่สุดเท่าที่จะทำได้ ถ้าเขาจะเขียนอะไรก็ได้ตามใจ แล้วทำไมเราจะทำไปเลยไม่ได้? ไม่มีอะไรสำคัญหรอกในความเป็นจริง แทบไม่มีโครงการโอเพนซอร์สไหนที่ถูกท้าทายเรื่องทรัพย์สินทางปัญญาด้วยเหตุผลเชิงเทคนิคแบบนี้เลย แทบจะเป็นศูนย์
ถ้าไม่เกี่ยวข้องกับงาน ก็ขึ้นอยู่กับแต่ละรัฐ หลายรัฐมีข้อจำกัดว่านายจ้างจะอ้างว่าเป็นทรัพย์สินทางปัญญาของตนได้ไกลแค่ไหน สัญญาทั่วไปมักเขียนถ้อยคำกว้างเพื่ออ้างสิทธิทุกอย่าง แต่กฎหมายมักบอกว่าบริษัทไม่อาจยึดงานที่ทำในเวลาส่วนตัวและไม่เกี่ยวข้องกับนายจ้างได้
ถ้าทำในเวลางานหรือใช้แล็ปท็อปบริษัท ก็เปิดช่องให้บริษัทอ้างสิทธิได้ บริษัทส่วนใหญ่คงไม่สนใจ แต่ถ้าอยากให้เรื่องสะอาดเมื่อมีข้อพิพาท ก็ไม่ควรประมาท
ทำใน เวลาส่วนตัว ใช้ อุปกรณ์ส่วนตัว และอย่าให้ซ้ำซ้อนกับงานที่ถูกจ้างมาทำหรือสิ่งที่ได้พบเจอในบริษัท
การส่งการแก้ไขกลับขึ้นต้นน้ำเป็นวิธีที่ดีที่สุดในการรับประกันการบำรุงรักษา ซึ่งทั้งหมดนี้เลยดูตลกมาก เช่นเดียวกับความไม่แน่นอนทางกฎหมายของการรักษา proprietary fork ภายใน
ฉันทำงานอยู่ในบริษัทค่อนข้างใหญ่ นโยบาย โอเพนซอร์ส ของบริษัทเราสรุปคร่าว ๆ ได้ว่า “ถามผู้จัดการก่อน อย่าทำในนามบริษัท และอย่าเปิดเผยข้อมูลลับ”
ไม่เคยมีปัญหาอะไร และโดยรวมก็รู้สึกว่าสมเหตุสมผลดี
ฉันคิดว่าการมีส่วนร่วมกับโครงการโอเพนซอร์สของบุคคลที่สามในเวลางาน เช่น การแก้บั๊ก เป็นเรื่องที่ไม่มีปัญหา แต่ไม่แน่ใจว่าควรจัดการกับ โอเพนซอร์สของตัวเอง อย่างไร
เช่น สมมติว่าคุณมีไลบรารีเล็ก ๆ ที่สร้างเองเป็นการส่วนตัว บริษัทนำมันไปใช้ แล้วคุณพบบั๊กระหว่างเวลางาน ถ้าคุณไป contribute ในเวลางานก็ดูจะเป็นพื้นที่สีเทา
มีใครเคยต่อรองเรื่องนี้ตอนสัมภาษณ์งานไหม? อยากรู้ว่าทำอย่างไรกัน
ตอนทำงานในบริษัทยักษ์ใหญ่ โดยทั่วไปคำขอทำงานอย่างอื่นนอกเหนือจากเขียนโค้ดลงใน codebase ของบริษัทโดยตรง แม้จะให้เหตุผลแล้ว ผู้จัดการสายตรงก็มักตอบว่า “ไปทำเอาในเวลาส่วนตัว”
ในสภาพแวดล้อมที่ขับเคลื่อนด้วยกำไร มีแต่สิ่งที่ให้คุณค่าทันทีเท่านั้นที่ถูกมองว่าน่าทำ ทัศนคตินี้ค่อนข้าง 寄生 และถูกผลักลงมาจากด้านบนด้วยแรงกดดันเรื่องประสิทธิภาพและการแข่งขันด้านตัวชี้วัด
ฉันเคย fork อะไรสักอย่างเพื่อแก้ปัญหางาน แล้วก็ส่งผลลัพธ์นั้นกลับขึ้นต้นน้ำเป็น PR อย่างแน่นอน
นี่เป็นหนึ่งในข้อดีของการใช้งานและเข้าถึงโอเพนซอร์สได้ และเป็นเหตุผลว่าทำไม git ถึงแทบเป็นตัวเลือกชั้นหนึ่งใน
package.jsonและcargo.tomlเพราะคุณสามารถชี้ไปที่ fork โดยตรงได้จนกว่าการเปลี่ยนแปลงจะถูก merge กลับขึ้นต้นน้ำพอคุณเป็นซีเนียร์ แล้วถึงช่วง “มีคำถามอะไรอยากถามเราไหม?” ในกระบวนการสัมภาษณ์ ฉันจะถามว่า “บริษัทนี้มีจุดยืนอย่างไรต่อการที่ฉันจะใช้เวลาบางส่วนไปมีส่วนร่วมกับ โครงการโอเพนซอร์ส ที่บริษัทพึ่งพาอยู่?”
แล้วค่อยตัดสินใจจากคำตอบว่าจะไปต่อหรือไม่