วิธีจัดการกับการเติบโตของโครงการโอเพ่นซอร์ส


11

ฉันมีส่วนร่วมในการช่วยสนับสนุนโครงการโอเพนซอร์ซเป็นเวลาหนึ่งหรือสองปีและโครงการได้รับความนิยมอย่างมากตั้งแต่ฉันเริ่ม โปรแกรมดังกล่าวมีการดาวน์โหลดมากกว่า 100,000 ครั้งต่อสัปดาห์และมีผู้ใช้งานมากกว่า 60% ในสาขาหลักดังนั้นเราจึงดีใจอย่างยิ่งที่ผู้ใช้เพลิดเพลินกับการใช้มันมาก

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

ป่านนี้มันเป็นเพียงแค่กลุ่ม dudes ที่แขวนอยู่บน IRC เขียนโปรแกรมนี้และช่วยเหลือผู้ใช้ ไม่มีองค์กร 501 (c) (3) หรือ LLC หรืออะไรทำนองนั้น

ตอนนี้เราไม่มีตัวติดตามบั๊กที่เป็นทางการหรือฐานข้อมูลปัญหา (เรามีฟอรัมที่มีหมวดหมู่เฉพาะสำหรับรายงานบั๊ก) ซึ่งฉันยอมรับว่าเป็นสิ่งที่เราสามารถปรับปรุงเพื่อให้นักพัฒนาจำนวนมากขึ้นบนกระดาน แต่ฉันคิดว่าคำถามที่แท้จริงของฉันคือหนึ่งจะเปลี่ยนจากโครงการส่วนบุคคลขนาดเล็กเพื่อสิ่ง ... จริงหรือไม่ หนุ่มใหญ่อย่าง GIMP, FFmpeg, Blender และอื่น ๆ จัดการกับการเปลี่ยนแปลงนี้ได้อย่างไร?

และเหนือสิ่งนี้มีวิธีเสนอค่าชดเชยกับโครงการ FOSS หรือไม่? ฉันคิดว่าการบริจาคช่วย แต่มันไปไกลแค่ไหน ... มันดูแปลกที่การทำมาหากินของซอฟต์แวร์ฟรี แต่ถ้าโปรแกรมกำลังจะดีขึ้นต่อไปฉันจะไม่เห็นว่าเราสามารถดำเนินการต่อไปได้โดยไม่ชดเชยผู้คน สำหรับการทำงานเต็มเวลา

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


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

4
หากคุณไม่รังเกียจที่จะถามฉันโครงการคืออะไร
Robert Harvey

2
ฉันลังเลที่จะตั้งชื่อโครงการบางส่วนเพราะมันน่ากลัวนิดหน่อยที่จะออกไปที่นั่นและบอกผู้คนว่า "เฮ้เราไม่แน่ใจว่าสิ่งที่เรากำลังทำอยู่และเราต้องการความช่วยเหลือ!" นอกจากนี้ฉันไม่ต้องการให้โพสต์นี้หลุดออกมาเป็นโฆษณาเพื่อขอความช่วยเหลือในโครงการ ฉันแน่ใจว่านักสืบอินเทอร์เน็ตอย่างคร่าวๆจะเปิดเผยได้ : /
Ben Torell

คำตอบ:


13

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

นี่คือคำแนะนำบางอย่าง

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

  • ดังที่ @Ross Patterson กล่าวไว้คุณต้องตั้งค่าตัวติดตามและรายชื่อผู้รับจดหมายหรือสิ่งที่คล้ายกันเพื่อหลีกเลี่ยงความวุ่นวายทั้งหมด คุณใช้อะไรในการควบคุมเวอร์ชัน หากคุณอยู่บน GitHub คุณสามารถเริ่มต้นด้วยตัวติดตามของพวกเขาหรือคุณสามารถรวมกับ Jira หรือสิ่งที่คล้ายกันหรือถ้าคุณต้องการคุณสามารถไปที่ SourceForge ตอนนี้และใช้โครงสร้างพื้นฐานฟรีของพวกเขา คุณไม่ได้บอกว่าผู้ใช้ดาวน์โหลดจากที่ใด แต่คุณต้องการให้แน่ใจว่าคุณติดตั้งในลักษณะที่เชื่อถือได้และมีการดาวน์โหลดที่ดี

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

  • ในแง่ของวิธีการหาเลี้ยงชีพสิ่งนี้จะขึ้นอยู่กับลักษณะของโครงการของคุณเป็นอย่างมาก นี่คือเหตุผลที่ฉันจะไม่ข้ามทันทีที่จะบอกว่าคุณต้องการ 501c3 (และคุณอาจไม่ได้รับ ... ดูโครงการ Yorba) เครื่องปั่นรองรับตัวเองเป็นหลักโดยการขายเอกสาร โครงการอื่น ๆ มีระบบนิเวศธุรกิจขนาดเล็กและ / หรือให้คำปรึกษาโดยรอบพวกเขาและนักพัฒนาได้รับชีวิตของพวกเขาจากที่ โครงการอื่น ๆ มีการออกใบอนุญาตแบบคู่ดังนั้นพวกเขาจึงขายรุ่นที่รองรับ (นั่นคือเหตุผลที่ MySQL ทำและทำไมมันสามารถขายให้กับ Sun และแน่นอนว่ามี RedHat) และมีการเปิดตัวชุมชนแยกต่างหาก คนอื่น ๆ เช่น WordPress มีรุ่นโฮสต์เป็นโมเดลธุรกิจ ดังนั้นจึงมีตัวเลือกทุกประเภทและคุณต้องเข้าใจว่าอะไรเหมาะสมสำหรับคุณและชุมชนของคุณ

  • เลือกคนที่จะเป็นผู้จัดการชุมชนของคุณเพื่อเริ่มต้น และอ่านหนังสือของJono Baconหลังจากคุณจบ Fogel

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

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

โชคดีมันเป็นสิ่งที่น่าตื่นเต้นที่ได้มาถึงจุดนี้แล้ว


ขอบคุณ! รหัสนี้โฮสต์บน Github แล้ว (ซึ่งก็เป็นที่ที่มีการวางจำหน่ายอีกด้วย) แต่เราไม่ชอบตัวติดตามปัญหาของ Github ... หนึ่งในทีมที่มีประสบการณ์กับตั๊กแตนตำข้าวดังนั้นฉันคิดว่าเราจะใช้ ที่. ฉันยังได้ยินคุณเกี่ยวกับแผนงาน ... อย่างน้อยที่สุดการมีแผนงานสาธารณะจะเป็นการดีที่จะแนะนำผู้ใช้ให้ทราบว่าใครกำลังใช้งานคุณสมบัติบางอย่างเพื่อให้เราสามารถบอกพวกเขาได้เมื่อคุณสมบัติดังกล่าวสัมพันธ์กับคุณสมบัติอื่น ๆ ฉันกำลังสำรวจ Outercurve คืนก่อนหน้านี้และฉันจะตรวจสอบคนอื่น ๆ เช่นเดียวกับหนังสือ ขอบคุณสำหรับกำลังใจ!
Ben Torell

1
@ BenTorell ฉันจะบอกทุกคนที่ถามว่า "ตัวติดตามข้อผิดพลาดทุกอันมีคำถามเดียวคือ 'อันไหนที่แย่ที่สุดในกระบวนการของคุณ?'"
Ross Patterson

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

3

ชายใหญ่จริงๆตั้งค่ากลไกทั้งหมดที่คุณรู้เกี่ยวกับ - พวกเขาทำงานเซิร์ฟเวอร์ฟาร์มขนาดใหญ่ที่พวกเขาทำงาน (บางครั้งเขียน) ติดตามข้อผิดพลาดและระบบสร้างฯลฯ พวกเขามักจะมี 501 (c) 3 ฐานรากที่เป็นเจ้าของลิขสิทธิ์ฯลฯพวกเขา รับการบริจาคจากองค์กรขนาดใหญ่และ บริษัท ต่างๆให้ยืมนักพัฒนาซอฟต์แวร์ฯลฯ คุณรู้ไหมว่าสิ่งที่ยิ่งใหญ่

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


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

@Elin เพียงตอบคำถามที่ถาม: "เด็กชายตัวใหญ่อย่าง GIMP, FFmpeg, Blender และอื่น ๆ จัดการการเปลี่ยนแปลงนี้ได้อย่างไร"
Ross Patterson

โอ้และ +1 ในความคิดเห็น - พวกเราต้องได้รับการเตือนเป็นครั้งคราว ธุรกิจนี้ไกลเกินกว่าจะให้ผู้ชายเป็นศูนย์กลาง
Ross Patterson

ขอบคุณและใช่ฉันไม่ได้สังเกตการอ้างอิงนั้นในโพสต์ดั้งเดิม
Elin

ใช่ฉันแค่ใช้คำว่า "เด็กชายตัวใหญ่" เป็นวลี ... ฉันคิดว่าฉันไม่ได้คิดอย่างนั้น แต่ฉันสามารถดูว่าคุณหมายถึงอะไร ขอบคุณสำหรับคำแนะนำ! ลำดับความสำคัญสูงสุดของฉันในตอนนี้คือการติดตามปัญหาจริงที่ผู้มีส่วนร่วมสามารถอ่านและหวังว่าจะเลือกปัญหาที่จะเกิดความเสียหาย (ตอนนี้สิ่งที่เรามีคือกระดาน Trello ยุ่ง ๆ ) ดังที่ฉันบอก @Elin ฉันกำลังโน้มตัวไปหาตั๊กแตนตำข้าวแทนระบบปัญหาของ Github ฉันคิดว่าเราต้องการบางสิ่งในตอนนี้
Ben Torell
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.