นักพัฒนา 7 ใน 10 คนมีส่วนร่วมในโอเพ่นซอร์ส และนี่คือเคล็ดลับและคำแนะนำบางส่วนเกี่ยวกับวิธีเริ่มต้นใช้งาน
ไม่เป็นความลับเลยว่าการมีส่วนร่วมของ โอเพ่นซอร์ส เป็นหนึ่งในทักษะที่เป็นที่ต้องการมากที่สุดในด้านเทคโนโลยี นอกจากสวัสดิการในการจ้างงานแล้ว ยังมีข้อดีอื่นๆ อีก เช่น
- การเรียนรู้และแบ่งปันความรู้
- สร้างและปรับปรุงการมองเห็นแบรนด์ของคุณ
- การทำงานร่วมกันและการสื่อสารกับนักพัฒนารายอื่นผ่านการตรวจสอบโค้ดและการอภิปราย
- การตอบแทนคืนสู่สังคม ❤
- เชื่อมต่อกับคนที่มีความคิดเหมือนกัน ค้นหาพนักงาน/พนักงาน ผู้ร่วมก่อตั้ง ผู้ให้คำปรึกษา ผู้ให้คำปรึกษา
จากข้อมูลของ Eclipse Foundation โอเพ่นซอร์สได้เห็นการลงทุนมหาศาลในช่วงไม่กี่ปีที่ผ่านมา
ทำไมคุณควรสนใจ?
เมื่อมองย้อนกลับไปที่ "การสำรวจ" ของ StackOverflow ในปี 2559 ไม่มีการเอ่ยถึงโอเพ่นซอร์สเลย อย่างไรก็ตาม ในปี 2560 "การสำรวจ" ประมาณ 32.7%ของผู้ตอบแบบสอบถามอ้างว่ามีส่วนร่วมในโอเพ่นซอร์ส และตัวเลขนี้เพิ่มขึ้น เกือบ 10% (เป็น 43.6%) ในปี 2018 แบบสำรวจ และสิ่งที่น่าสนใจยิ่งกว่านั้นก็คือ % ของผู้มีส่วนร่วมเพิ่มขึ้น 20% ในปี 2019 (เป็น 63.3%)
ตาม "ผลการสำรวจอนาคตของโอเพ่นซอร์สในอนาคตปี 2559" โดย BlackDuck ประมาณ 67% ของการมีส่วนร่วมในโอเพ่นซอร์สได้รับการ
- แก้ไขข้อบกพร่อง
- เพิ่มคุณสมบัติใหม่
59% ของนักพัฒนามีส่วนร่วมในโอเพ่นซอร์สเพื่อสร้างความได้เปรียบในการแข่งขัน
เมื่อคำนึงถึงข้อเท็จจริง ตัวเลข และแนวโน้มข้างต้น IMO จึงคุ้มค่าที่จะพิจารณาการมีส่วนร่วมของโอเพ่นซอร์ส
เป็นการเปลี่ยนแปลงที่คุณอยากเห็นในโลกนี้ - มหาตมะ คานธี
สาเหตุที่ฉันไม่สามารถบริจาคได้ก่อนหน้านี้?
นักพัฒนาส่วนใหญ่อย่างพวกเราชอบที่จะมีส่วนร่วมในโอเพ่นซอร์ส แต่สุดท้ายกลับล้มเหลวในการทำเช่นนั้นด้วยเหตุผลหลายประการ นี่คือรายการเหตุผลสำหรับฉัน
- สถาบันการศึกษาส่วนใหญ่ไม่ยอมรับ การมีส่วนร่วมแบบโอเพ่นซอร์ส ว่าเป็นวิธีที่มีประสิทธิภาพในการเรียนรู้หรือกระตุ้นให้นักเรียนมีส่วนร่วม — IMO การสนับสนุนแบบโอเพ่นซอร์สควรเป็นส่วนหนึ่งของหลักสูตร (ในฐานะงานที่ได้รับมอบหมาย โครงการ ฯลฯ)
- ตำแหน่งทางภูมิศาสตร์ของคุณ — IMO ประเทศที่คุณอาศัยอยู่ก็มีบทบาทสำคัญในดังที่เน้นไว้ใน บทความ นี้
- ปณิธานปีใหม่และคำสัญญาวันเกิด— ฉันมีสิ่งเหล่านี้มานับไม่ถ้วน แต่มันก็ไม่เคยได้ผลเลย
- เป้าหมายที่ไม่สมจริง— ครั้งหนึ่งฉันตัดสินใจว่าจะทำคำขอดึงอย่างน้อยยี่สิบ (20) รายการไปยังที่เก็บเช่น นักเทียบท่า(เพราะฉัน ❤ นักเทียบท่า) โดยไม่คำนึงถึงข้อเท็จจริง ว่าข้าพเจ้าไม่มีความรู้พอที่จะทำเช่นนั้นได้
- งาน โครงการรอง และข้อแก้ตัวในชีวิต —หลังจากล้มเหลวในการมีส่วนร่วมทุกครั้ง ฉันจะปรึกษาตัวเองว่าฉันทำได้ดีในแนวดิ่งอื่นๆ
ไม่ว่าเงินบริจาคจะน้อยแค่ไหน แต่ถ้าคุณทำเป็นประจำ มันก็จะสร้างความแตกต่างในระยะยาว
- ประเมินความสามารถของฉันต่ำไป— บางครั้งฉันได้ตรวจสอบคำขอดึงข้อมูลและปัญหาที่มีอยู่ และได้ข้อสรุปว่า "สิ่งนี้ซับซ้อน"
- การเพิกเฉยต่อปัญหาด้านเอกสาร— ส่วนใหญ่ฉันเพิกเฉยต่อปัญหาที่เกี่ยวข้องกับเอกสารทั้งหมด
- นายจ้างของฉันไม่สนใจ — ฉันชอบงานที่ต้องมีส่วนร่วมกลับคืนสู่ชุมชนโอเพ่นซอร์ส
- การผัดวันประกันพรุ่ง — แน่นอนเป็นปัจจัยด้วยเหตุผลหลายประการ
นี่คือเหตุผลหลักบางส่วนที่ทำให้ฉันหยุดเริ่มต้นใช้งานโอเพ่นซอร์สตั้งแต่เนิ่นๆ
แรงจูงใจของฉัน
แรงจูงใจหลักในการมีส่วนร่วมกับโอเพ่นซอร์สสำหรับฉันคือการมีความรู้เพียงพอที่จะเขียนเกี่ยวกับมัน
ฉันให้ความสำคัญอย่างมากกับการแบ่งปันความรู้ และนี่คือสิ่งที่ฉันพยายามทำทั้งเป็นการส่วนตัวขณะทำงานในระดับทีมและระดับองค์กร
ปีที่แล้วฉันทำงานเสริมโปรเจ็กต์และฉันได้เรียนรู้บางอย่างเกี่ยวกับการเข้ารหัส ดังนั้นฉันจึงเขียนเกี่ยวกับเรื่องนี้ "ที่นี่" ไม่กี่เดือนข้างหน้า ฉันได้ช่วยเขียนแนวทางการเขียนโค้ดของบริษัท และใช้ความรู้นั้นเขียน “บทความ” เกี่ยวกับเรื่องนี้ด้วย
หลังจากผ่านไปสองบทความ ฉันก็อยากจะเขียนเกี่ยวกับสิ่งที่ฉันถือว่าสำคัญมากสำหรับนักพัฒนาใหม่และนักศึกษา
ชุมชนชื่นชอบ ❤ บทความนี้ และได้รับการดูประมาณ 50,000 ครั้ง เสียงปรบมือหลายพันครั้ง และความคิดเห็นแสดงความขอบคุณ
บทความใหญ่ถัดไปสำหรับฉันคือการเขียนเกี่ยวกับการมีส่วนร่วมของโอเพ่นซอร์ส (บทความนี้) และเพื่อสิ่งนั้น ฉันจำเป็นต้องเขียนการสนับสนุนโอเพ่นซอร์สสองสามอย่างก่อน
ดังนั้น หากคุณพบว่าตัวเองอยู่ในเรือลำเดียวกันกับที่ต้องการมีส่วนร่วมแต่ยังไม่ได้ทำ ให้มองหาเหตุผล แรงจูงใจ วัตถุประสงค์ แรงผลักดัน หรืออะไรก็ตาม
กลยุทธ์การสนับสนุนโอเพ่นซอร์สของฉัน
ฉันตัดสินใจว่าจะสนับสนุน "Spring Framework" ซึ่งเป็นห้องสมุดที่ฉันเคยใช้มาก่อน ฉันกำลังอ่าน หลักเกณฑ์การสนับสนุน เมื่อฉันสังเกตเห็นลิงก์เสียบางลิงก์ ฉันจึงสร้าง "คำขอดึง" เพื่อแก้ไข
คำขอดึงถูกรวมเข้าด้วยกัน และรู้สึกดีมากจนฉันตัดสินใจดำเนินการต่อ อย่างไรก็ตาม มีปัญหาเกิดขึ้น ปัญหา GitHub ส่วนใหญ่ (เช่น ข้อบกพร่อง ครั้งแรก ต้องการความช่วยเหลือ ฟีเจอร์) จะถูกเลือกโดยผู้ร่วมให้ข้อมูลรายอื่นก่อนที่ฉันจะมีโอกาสแสดงความสนใจด้วยซ้ำ
เมื่อใดก็ตามที่กระบวนการไม่ก่อให้เกิดผลลัพธ์ที่ต้องการสำหรับฉัน ฉันจะทำการเปลี่ยนแปลงและประเมินผลลัพธ์อีกครั้ง และดำเนินการเช่นนี้ต่อไปจนกว่าผลลัพธ์จะเป็นที่ต้องการ
นี่คือสิ่งที่ฉันทำ
- ฉันสมัคร (ดู) พื้นที่เก็บข้อมูล Spring — มีการแจ้งเตือนมากมาย
- ระหว่างเดินทางไปทำงาน ฉันจะดูการแจ้งเตือนทางอีเมลและแสดงความสนใจผ่านความคิดเห็นเกี่ยวกับปัญหาที่ฉันสามารถจัดการได้
จากกลยุทธ์นี้ ฉันมีปัญหามากมายที่ต้องดำเนินการ การปรับปรุงครั้งแรก คุณสมบัติ
ฉันยังคงดำเนินการในลักษณะนี้ต่อไปในประเด็นอื่นๆ สองสามรายการ เช่น การเพิ่มประสิทธิภาพ ข้อบกพร่อง และ คุณลักษณะใหม่ ซึ่งส่งผลให้มีการประชาสัมพันธ์ดังต่อไปนี้
- เพิ่มการรองรับตัวยึดตำแหน่งสำหรับแอตทริบิวต์แท็กส่วนหัว — Spring Security
- เพิ่มคุณสมบัติการกำหนดค่าสำหรับ Undertow ที่เหลือ — Spring Boot
- ตรวจสอบให้แน่ใจว่ามีการประเมินรอบคัดเลือกด้วยชื่อ bean เมื่อใช้ SpyBean - Spring Boot — ปฏิเสธ
- แปลง PluginPropertiesExtension Groovy เป็น Java — ElasticSearch
- เพิ่มการสนับสนุนสำหรับข้อมูลเมตาเซิร์ฟเวอร์การอนุญาต RFC 8414 OAuth 2.0 — Spring Security
ดังนั้น หากคุณประสบปัญหาในการหาปัญหาให้แก้ไข ให้เปลี่ยนไปใช้กลยุทธ์อื่น
เคล็ดลับและข้อเสนอแนะ
จากความรู้และประสบการณ์ของผมจนถึงตอนนี้
- คำแนะนำ ที่ต้องอ่านเกี่ยวกับ “วิธีการมีส่วนร่วม”
- เรียนรู้พื้นฐาน Git
- เลือกภาษา เช่น Java, JavaScript
- ระบุพื้นที่เก็บข้อมูลที่ยินดีมีส่วนร่วม — ใช้เครื่องมือเช่น CodeTriage, Github Explore และ this
- อ่านนโยบายพื้นที่เก็บข้อมูล เช่น แนวทางการสนับสนุน
- เรียนรู้โครงการที่คุณต้องการมีส่วนร่วม
- มีส่วนร่วมในรูปแบบของโค้ด เอกสาร ข้อบกพร่อง และคุณสมบัติใหม่
- กรองปัญหาตามป้ายกำกับ เช่น ต้องการความช่วยเหลือ จุดบกพร่อง ผู้มาครั้งแรก ฯลฯ
- คำนึงถึงเวลาของผู้อื่นโดยเฉพาะผู้ดูแลที่ช่วยเหลือคุณ
- ตรวจสอบให้แน่ใจว่าคุณมีทักษะและเวลาที่จำเป็นในการลงทุน
- ติดตามการอภิปรายในประเด็นและคำขอดึง ดูการเปลี่ยนแปลงรหัส
- อดทนและเปิดรับความคิดเห็น
ฉันเลือกปัญหา Elastic Search และ เพิกเฉย ความจริงที่ว่าฉันต้องรู้จัก Groovy บางอย่าง และวิธีการทำงานของ Elastic Search build ส่งผลให้ฉันใช้เวลาและความพยายามมากขึ้นในการทำให้ PR เข้าสู่ขั้นตอนที่เสร็จสมบูรณ์ .
เป็นความคิดที่ดีเสมอที่จะหาข้อมูลก่อนที่จะมีตัวเลือกในการแก้ไขปัญหา
แนะนำให้อ่าน
ฉันขอแนะนำให้คุณอ่าน "คู่มือโอเพ่นซอร์ส" และ "บทความ" นี้มาพร้อมกับความรู้มากมายเกี่ยวกับวิธีเริ่มต้นใช้งาน บทความ นี้เน้นเคล็ดลับดีๆ และหากคุณเป็นคนที่มองเห็นภาพได้ วิดีโอ เหล่านี้โดย Kent C. Dodds อาจเป็นประโยชน์
ขอบคุณสำหรับการอ่าน. โปรดติดตามฉันใน "สื่อ" เพื่อดูบทความเพิ่มเติมและเชื่อมต่อกับ "LinkedIn" และแพลตฟอร์มโซเชียลมีเดียอื่น ๆ ที่คุณเลือก
หากบทความนี้ช่วยคุณในการสนับสนุนครั้งแรกไม่ว่าในลักษณะใดก็ตาม คุณสามารถแบ่งปันแนวคิด คำแนะนำ ข้อเสนอแนะ และดึงคำขอของคุณเป็นความคิดเห็นได้
