(แปลจาก Working on Free Software โดย Havoc Pennington)
โปรแกรมเมอร์หลายคนอยากจะตั้งโครงการซอฟต์แวร์เสรีแต่ไม่แน่ใจว่าสิ่งต่างๆ มีกลไกการดำเนินการอย่างไร บทความนี้เป็นการรวบรวมอย่างไม่เป็นทางการของ "กฎและความเข้าใจที่ไม่มีการบัญญัติ" สำหรับผู้ที่สนใจจะอาสาช่วยงานทั้งหลาย ผมเรียนรู้สิ่งเหล่านี้จากความผิดพลาด และแม้ทุกวันนี้ก็ยังฝ่าฝืนเองอย่างหน้าตาเฉยในบางครั้ง เพราะนี่เป็นเพียงแนวทางคร่าวๆ เท่านั้น :-) ผมแน่ใจว่าคนอื่นๆ ก็อาจได้กฎที่ต่างไปจากนี้ได้เช่นกัน
หลายคนพออยากจะเขียนซอฟต์แวร์เสรี ก็ตั้งต้นขีดเขียนโค้ด ประทับ GPL แล้วปล่อยเวอร์ชัน 0.0.1 alpha ทันที แม้ว่าการทำเช่นนั้นจะสนุกและได้ความรู้ แต่ก็เป็นการสิ้นเปลืองอย่างสิ้นเชิง เหตุผลก็คือ:
มาถึงตรงนี้ ถ้าคุณมีความคิดเจ๋งๆ และคิดว่าลุยแล้วสนุก ก็จงทำเสียเถิด เราได้ทำไว้หมดแล้วแหละ :-) โครงการพวกนี้จะไปอยู่ที่ใดที่หนึ่ง และถ้าคุณมีประสบการณ์ในการแฮ็กมาพอสมควรแล้ว และมีโปรแกรมไหนที่ยังไม่มีคนทำ ก็มุ่งลงไปทำได้เลย
เมื่อคุณตั้งต้นทำโครงการใดๆ สิ่งที่สำคัญที่สุดก็คือการเขียนโค้ด คุณต้องเขียนโค้ดด้วยตัวเองมากพอที่จะทำให้โปรแกรมเริ่มใช้การได้ ซึ่งอาจหมายถึงการทำงานคนเดียวเป็นเดือนหรือเป็นปี นอกเสียจากจะมีผู้มีเมตตาจิตตัดสินใจที่จะช่วยคุณทำแทนที่จะเริ่มด้วยตนเอง :-) คุณต้องรีลีสบ่อยๆ แก้บั๊กให้รวดเร็ว และพยายามทำให้มีอะไรน่าตื่นเต้นอยู่ตลอด แต่เมื่อถึงเวลาทำงานจริง การเขียนโปรแกรมเป็นงานที่หนักหนาสาหัสจริงๆ ถ้าคุณเขียนโค้ดเอง ให้กันเวลาไว้สัก 10-20 ชั่วโมงต่อสัปดาห์เป็นอย่างต่ำ แต่แน่นอนว่าถ้าเป็นแค่การช่วยทำงานในโครงการที่มีอยู่ก่อนแล้ว คุณก็ต้องการเวลาน้อยกว่านั้น และให้กันเวลา 10-20 ชั่วโมงต่อสัปดาห์นั้นไว้สำหรับการทำงานในอนาคตด้วย ถ้าคุณไม่สามารถให้เวลาได้มากขนาดนี้ ก็อย่าคิดจะเปิดโครงการเลยจะดีกว่า หรือถ้าคุณเขียนโค้ดไม่ได้ ก็อย่าได้คิดเช่นกัน
หลายต่อหลายคนโพสต์เจตนารมณ์ที่จะเขียนโปรแกรม X หรือประกาศเวอร์ชัน 0.0.1 alpha ขึ้นมา แล้วก็ล้มเลิกเมื่อไม่ได้รับการตอบสนอง จงเผชิญหน้ากับมัน คุณจะไม่ได้รับการตอบสนองมากนักจนกว่าคุณจะมีผู้ใช้ และคุณจะไม่มีผู้ใช้จนกว่าคุณจะเขียนโค้ด ดังนั้น คุณต้องจัดการกับการตัดสินใจของคุณด้วยตัวเอง
ปรากฏการณ์เดียวกันจะเกิดตอนที่คุณร้องขอความช่วยเหลือ ที่สุดแล้ว ถ้าปัญหาเรื่องบั๊กหรือ feature ที่ไม่ต้องการหรือการขาดเอกสารขวางหน้าคุณอยู่ คุณมักจะต้องตรงเข้าไปแก้ปัญหาด้วยตัวเอง เหล่าแฮ็กเกอร์มักจะยินดีช่วยเหลือผู้มาใหม่ที่ไม่รู้จะเริ่มต้นที่ไหนก็จริง แต่ไม่ช้าก็เร็ว เขาก็คาดหวังว่าคุณจะสามารถแก้ปัญหาได้ด้วยตัวเองเหมือนกัน
เมื่อมีคำถาม จงถามใน mailing list การ mail ตรงถึงนักพัฒนาคนใดคนหนึ่งเป็นการส่วนตัวเป็นสิ่งที่ไม่ค่อยสุภาพนัก นอกจากคุณมีเหตุผลที่จะเชื่อว่าเขาเป็นพียงคนเดียวที่สามารถตอบคำถามนี้ได้ แต่ถ้าคุณถามในลิสต์ นักพัฒนาอื่นๆ ก็จะช่วยกันแบ่งเบาภาระในการตอบได้ (ในขณะที่ถ้าคุณใช้เมลส่วนตัว โดยส่วนใหญ่แล้วจะเป็นการเมลไม่ถูกคน แล้วก็จะไม่ได้คำตอบในที่สุด เพราะเขาไม่รู้เรื่องนั้น)
mailing list และเอกสารต่างๆ ถูกสร้างขึ้นมาโดยนักพัฒนาเพื่อให้การช่วยเหลือผู้ใช้จำนวนมากเป็นไปได้ จำไว้ว่าทุกคนเป็นอาสาสมัคร และถ้าคุณต้องการ การให้คำปรึกษาแบบคิดค่าใช้จ่ายก็อาจจะมีอยู่เช่นกัน
ผู้คนมักจะคาดหวังว่าจะมีใครรับผิดชอบในโครงการซอฟต์แวร์เสรี หรือไม่ก็คาดหวังว่าจะได้รับการมอบหมายงานเพื่อทำให้เสร็จตามกำหนด เปล่า.. มันไม่ได้เป็นเช่นนั้นเลย คุณไม่สามารถควบคุมว่าใครจะทำอะไรได้ และไม่มีใครมาบอกคุณให้ทำโน่นทำนี่ได้เช่นกัน ถึงแม้จะมีได้บ้างก็ในรูปของคำแนะนำ ถ้าคุณต้องการอะไร คุณต้องกระโจนลงมาทำให้มันเกิดเอง
ถ้าคุณใช้เวลาถึง 3 เดือนเพื่อเขียนโค้ดสำหรับ feature ใหม่เจ๋งๆ แต่สุดท้ายผู้ดูแลไม่ชอบไอเดียและไม่รับ patch หรือพบว่า patch ของคุณใช้กับเวอร์ชันล่าสุดไม่ได้ หรือพบว่ามีคนกำลังทำงานเดียวกันอยู่ คุณคงจะเซ็งสุดชีวิต ดังนั้น เมื่อวางแผนจะทำอะไร จงหย่อนบันทึกให้ผู้ดูแลรู้ก่อน ผู้ดูแลส่วนใหญ่จะทำหน้าสงสัย (เพราะอาจจะได้รับบันทึกที่ว่าเยอะแยะแต่ไม่เคยเห็นผลลัพธ์!) แต่ก็จะจำไว้และอาจจะให้คำแนะนำคุณด้วย
เมื่อคุณได้เข้าไปมีส่วนร่วมในโครงการมากๆ เข้า การประสานงานที่ละเอียดยิ่งขึ้นก็ย่อมเป็นไปได้ โดยผ่านทาง e-mail, CVS หรือ IRC และเมื่อการสื่อสารต่างๆ ขาดหาย CVS จะช่วยได้มากในการรวมโค้ด
คำตอบสำหรับคำถามทั้งสองก็คือ "เมื่อมีคนทำ" และถ้าคนทำนั้นคือคุณ คุณก็จะรู้คำตอบ แต่ถ้าคนทำไม่ใช่คุณ คุณก็ต้องรอดู :-) โครงการต่างๆ ไม่ได้มีผู้จัดการและไม่มีใครคอยตามงาน
คนชี้นิ้วมักจะมีกระแสความคิดอันบรรเจิดไม่หยุดหย่อนใน mailing list แต่ไม่เคยโค้ดหรือไม่รู้วิธีโค้ดเลย ถ้าคุณไม่รู้วิธีโค้ด คุณก็ไม่รู้วิธีออกแบบซอฟต์แวร์ด้วย เอวัง คุณทำได้แค่ก่อปัญหาเท่านั้นแหละ
อย่างไรก็ดี มีสิ่งที่ผู้ที่โค้ดไม่เป็นสามารถทำได้มากมาย เช่น การรายงานบั๊ก การร้องขอ feature (ตราบใดที่มันไม่มั่วซั่วและไม่ได้อยู่คนละโลกกับโค้ดเดิม) เขียนเอกสาร ช่วยตอบคำถามเรื่องการใช้งานและการติดตั้ง การตั้ง user group การดูแลเว็บไซต์ ดูแลเซิร์ฟเวอร์ ทำ package สำหรับ distribution ฯลฯ บรรดาแฮ็กเกอร์จะชื่นชมที่คุณสนใจในงานของเขาและช่วยงานเขา
อาการคันไม้คันมืออยากจะร่วมใน mailing list และวิจารณ์ทุกสิ่งที่ขวางหน้าอาจจะรุนแรง แต่อย่าได้ทำตัวชี้นิ้วเป็นอันขาด โพสต์ได้ถ้าคุณมีประสบการณ์ที่เกี่ยวข้อง หรือรู้ว่าสามารถทำให้เกิดบั๊กนั้นๆ ได้อย่างไร หรือมีความชำนาญพิเศษในเรื่องนั้นๆ หรือรู้คำตอบของคำถาม มิฉะนั้นแล้ว กรุณาอยู่เฉยๆ นอกจากนี้ การซุ่มมองประชาคมเสียหน่อยก่อนที่จะเริ่มโพสต์ก็เป็นความคิดที่ไม่เลว จะได้รู้วัฒนธรรมของเขาว่าเป็นอย่างไร
คุณต้องเป็นนักกฎหมายสักหน่อยเพื่อจะมีส่วนร่วมในซอฟต์แวร์เสรี นั่นหมายถึง คุณต้องศึกษาหาความรู้ด้วยตนเอง โดยปกติแล้ว วิธีหนึ่งที่จะเรียนรู้ได้ก็จากการเฝ้ามองสงครามน้ำลายซ้ำซากอาทิตย์ต่ออาทิตย์ในกลุ่มข่าว gnu.misc.discuss แต่วิธีที่เร็วกว่านั้นคือไปอ่านที่ เว็บไซต์ของ GNU โดยเฉพาะในส่วนการวิเคราะห์คำศัพท์ต่างๆ อย่าโพสต์ในหัวข้อกฎหมายถ้าคุณไม่ได้เข้าใจอย่างแท้จริง แต่คุณควรรู้เอาไว้ถ้าคุณกำลังจะเขียนซอฟต์แวร์และกำลังจะใส่ license
เมื่อคุณส่ง patch จะเป็นการดีที่จะใช้ license และสไตล์การโค้ด ฯลฯ แบบเดียวกับที่ผู้ดูแลแพกเกจใช้ ถ้าคุณใช้ CVS ล่ะก็ อย่า commit CVS โดยไม่บอกกล่าวแก่ผู้ดูแลก่อน
เป็นประเด็นเล็กๆ แต่ทุกคนชอบ patch แบบนี้กัน
ปฏิบัติต่อเขาด้วยความเคารพที่เขาสมควรได้รับ เพราะพวกเขาทำงานก็ด้วยความพอใจ ออกจะเลวไปสักหน่อยที่จะปฏิบัติไม่ดีกับคนที่ให้อะไรกับคุณเปล่าๆ
พวกเราหลายคนมีปัญหากับเรื่องนี้ แต่ยิ่งคุณสามารถติดหนึบกับงานชิ้นใดชิ้นหนึ่งและพยายามทำให้เสร็จได้มากเท่าไหร่ คุณก็ยิ่งจะได้สิ่งที่เป็นประโยชน์มากเท่านั้น ผมพบว่าผมต้องซอยงานเป็นชิ้นเล็กๆ เพื่อจะได้ความจดจ่อ คนอื่นๆ อาจทำได้ดีกว่าในโครงการระยะยาว จงจัดสรรความพยายามของคุณตามบุคลิกภาพ พยายามทำโครงการให้เสร็จแทนการเริ่มงานอันทะเยอทะยาน 100 ชิ้น
เป็นความคิดที่ดีที่จะติดตามเว็บไซต์ข่าวเสมอๆ เช่น LinuxToday LWN หรือ Slashdot รวมทั้งไซต์ที่เกี่ยวข้องกับโครงการที่คุณมีส่วนร่วมอยู่ (สามไซต์ที่พูดถึงเป็นเพียงไซต์ที่ผมบังเอิญอ่านเท่านั้น) หนังสือที่ดีเล่มหนึ่งเกี่ยวกับประวัติของประชาคมคือ Hackers เขียนโดย Steven Levy และเว็บไซต์ www.gnu.org ก็มีข้อมูลต่างๆ ให้อ่านมากมาย รวมทั้งการซุ่มดู mailing list ก็ทำให้ได้อะไรๆ มากมายเหมือนกัน
เป็นกฎธรรมดาเลยว่า ไม่ว่าคุณจะทำจะพูดอะไร จะมีคนคอยด่าคุณอยู่ มันคือวิถีแห่งอินเทอร์เน็ต หลายคนที่ยังไม่เคยได้รับบทเรียนนี้จะหัวเสียแล้วก็เปิดเปิงไปทันทีที่พบ โปรดอย่าทำเช่นนั้น ถ้าคุณซุ่มดู mailing list ให้ดี คุณจะเรียนรู้ในไม่ช้าว่าคนไหนมักจะมีประเด็นน่าเชื่อถือ คนไหนคอยด่าเป็นนิจสิน (ไม่ใช่ว่าทั้งสองจะเป็นคนละกลุ่มเสมอไป แฮ็กเกอร์ที่ขยันๆ บางคนก็ด่าเป็นไฟเหมือนกัน) ทำหน้าให้หนาเข้าไว้ คุณต้องใช้มัน
การแฮ็กเป็นงานอย่างแท้จริง มันคือการนั่งอยู่กับตัวเองและโขกโค้ดหรือเอกสารออกมา แต่ก็ยังมีโอกาสหลายโอกาสที่จะได้สังสรรค์ในงานประชุมสัมมนา ใน IRC หรือทาง e-mail การเขียนโค้ดก็น่าจะเป็นเรื่องสนุกทุกเวลาเช่นกัน ฉะนั้น ก็จงสนุกกับมัน นั่นแหละคือส่วนหนึ่งของประเด็น อย่าได้ถือเอาเอกสารนี้หรือกฎใดๆ เป็นจริงเป็นจังเกินไปนัก
แนวคิดของ Eric Raymond เกี่ยวกับเรื่องนี้อยู่ที่นี่ (พร้อมฉบับเล่าภาษาไทย โดย kitty) HOWTO ของเขาบรรยายถึงวิธีเข้าร่วม "วัฒนธรรมแฮ็กเกอร์" ซึ่งในความคิดของผม วัฒนธรรมดังกล่าวก็ไม่ค่อยจำเป็นต้องเข้าร่วมเท่าไรนักเวลาเข้าโครงการซอฟต์แวร์เสรี ตราบใดที่คุณทำตามครรลองของทุกสิ่งในประชาคม คุณก็ไม่จำเป็นต้องเข้าไปในสังคมแฮ็กเกอร์ (นอกจากคุณอยากจะเข้าไป) นอกจากนี้ Advogato (อีกตัวตนหนึ่งของ Raph Levien) ยังมีบทความอีกที่นี่ ท้ายที่สุด หลังจากที่คุณอ่านข้อแนะนำเหล่านี้แล้ว อย่างที่ RMS พูด ขอให้ happy hacking ครับ!
|
|