Ở giai đoạn nào của một dự án Nguồn mở, bạn nên mời đóng góp từ cộng đồng? [đóng cửa]

Tôi đã tự hỏi về việc đóng góp cho một sản phẩm nguồn mở mới mà nhóm của tôi sẽ phát triển. Chúng tôi khuyến khích chúng tôi nhận được nhiều sự hỗ trợ từ cộng đồng rộng lớn nhất có thể, nhưng tôi cũng có thể thấy điều này hấp dẫn rất nhiều thời gian để đảm bảo rằng các bên thứ 3 nằm ngoài văn phòng của chúng tôi đang theo dõi những thứ như chất lượng mã. Ngoài ra, khi bắt đầu dự án, chúng tôi có thể có nhiều cuộc thảo luận không chính thức trong nhóm cốt lõi liên quan đến thiết kế hệ thống, gai, v.v. và việc trực tuyến này để cho phép sự tham gia của cộng đồng sẽ tốn thời gian và tôi có thể tưởng tượng có thể làm cho thảo luận kém hiệu quả.

Có một khía cạnh nhân văn hơn về vấn đề này có lẽ cần được xem xét: cho phép sự tham gia của cộng đồng vào quá trình thiết kế cũng có thể có lợi ích của nó liên quan đến quyền sở hữu dự án và luôn có cơ hội tham gia sớm vào các vấn đề cốt lõi Đội chưa để ý.

Vì vậy, câu hỏi: ở giai đoạn nào của một dự án Nguồn mở bạn nên mời đóng góp từ cộng đồng?

Ngay từ đầu! Bạn muốn cộng đồng cảm thấy rằng họ có cổ phần thực sự trong dự án của bạn, nếu không họ sẽ cảm thấy như họ đang được sử dụng như lao động tự do.

Tất cả thông tin liên lạc nên qua một danh sách gửi thư công cộng hoặc diễn đàn, một lần nữa điều này giúp tăng cường ý tưởng của cộng đồng.

Bạn có thể giảm thiểu vấn đề 'thiết kế theo ủy ban' bằng cách đưa ra một tầm nhìn rõ ràng trong các bài đăng ban đầu của bạn vào danh sách gửi thư, ví dụ:

"Vì vậy, chúng tôi đang xem xét một mô hình miền để đại diện cho Cửa hàng thú cưng của chúng tôi (theo JIRA-4). Có ai thấy bất kỳ vấn đề lớn nào với mô hình này không?"

Về mặt chấp nhận đóng góp vật lý thực tế, bạn nên bắt đầu bằng cách chấp nhận các bản vá và thực hiện đánh giá mã công khai trên chúng. Bằng cách đó, những người đóng góp có thể đã công khai xem loại tiêu chuẩn mã hóa nào họ cần tuân thủ. Hãy chắc chắn rằng các cam kết của bạn cũng có sẵn trong một danh sách gửi thư cam kết - bạn cần phải được giữ theo cùng tiêu chuẩn!

Nó cũng trả tiền để có các tiêu chuẩn dự án trên Wiki hoặc một số tài liệu như vậy.

Đọc http://www.producingoss.org để biết thêm chi tiết về cách chạy một dự án nguồn mở thành công.

Điều này đã được thảo luận rất lâu trong cuộc nói chuyện về IO IO của huyền thoại về lập trình viên tài ba , bởi Brian Fitzpatrick và Ben Collins-Sussman của Subversion. Nói tóm lại, họ kết luận rằng không nên sớm đến mức chưa có gì ở đó (ví dụ: "hãy nhìn vào dự án tuyệt vời của tôi! Vẫn chưa có nhiều ở đây nhưng có rất nhiều điều tuyệt vời đã được lên kế hoạch!") Hoặc quá muộn vì vậy tất cả các quyết định đã được đưa ra (Thật khó để có được một từ trong một dự án solo.)

Tôi đồng ý với Martijn Verburg . Bạn nên bắt đầu thu hút đóng góp ngay từ đầu. Tôi đã viết một chút về điều này trước đây.

Tóm tắt của bài viết đó là rots phần mềm. Nếu bạn muốn giữ cho nó tươi, bạn phải bảo trì. Và một dự án càng phổ biến thì càng có nhiều lỗi được tìm thấy, càng nhiều tính năng sẽ được thêm vào, và nhiệm vụ bảo trì này sẽ khiến bạn thất vọng.

Trên thực tế, đây là một vấn đề rất phổ biến. Có một cuộc nói chuyện tuyệt vời của Fat có tên là Nguồn mở là gì và tại sao tôi lại cảm thấy tội lỗi như vậy? Trong buổi nói chuyện này (mà tôi đặc biệt khuyên bạn nên xem) anh ấy kể câu chuyện về một trong những dự án OSS của anh ấy, và theo thời gian, anh ấy đã dành phần lớn thời gian rảnh của mình để thực hiện các nhiệm vụ quản lý và phân phối vé. Và anh ấy nói về việc làm thế nào là thiệt hại. Đó là điều tôi hoàn toàn có thể đồng cảm với.

Giải pháp, tất nhiên, là thêm người vào dự án sớm và thường xuyên. Thời gian của bạn là có hạn, và có giá trị. Đầu tư vào việc phát triển cơ sở đóng góp của bạn và phần còn lại của các vấn đề của bạn bắt đầu tự chăm sóc bản thân.

Như tôi nói ở cuối bài viết của mình: "Điều gì quan trọng hơn cho dự án của bạn: tính năng hay tương lai? Hãy chọn một thứ và ưu tiên những nỗ lực của bạn cho phù hợp."