Các dự án nguồn mở được quản lý như thế nào

Question

Tôi đang làm việc trong một nhóm nhỏ về một số dự án trong thời gian rảnh rỗi của mình. Chúng tôi đang gặp vấn đề mà chúng tôi dường như đi trong vòng kết nối và không thể phát triển sản phẩm của chúng tôi - tuy nhiên đây không phải là vấn đề trong công việc ban ngày của tôi. Việc thiếu giao tiếp mặt đối mặt dường như có tác động thực sự đến năng suất.

Bất kỳ ví dụ về phần mềm hoặc phương pháp nào được sử dụng bởi cộng đồng phát triển nguồn mở sẽ được đánh giá cao.

Answer 1

Đây là câu hỏi khó trả lời bởi vì "dự án nguồn mở" là một lựa chọn rất lớn các dự án. Tôi nghĩ rằng đặc điểm xác định là dự án có một mục tiêu thống nhất duy nhất (có lẽ, một tập hợp các mục tiêu liên quan).

Bạn có đang ở trên bất kỳ danh sách gửi thư nguồn mở nào không? Tôi đã đăng ký vào danh sách gửi thư của favorite distro và các nhà phát triển e-mail cho nhau nhiều lần trong ngày. Ngoài ra, còn có các cách giao tiếp khác như IRC/Instant Messenger.

Tôi không phải là nhà phát triển RoR, nhưng tôi khuyên bạn nên lướt qua Getting Real để lấy cảm hứng.

Answer 2

Dự đoán của tôi là các dự án riêng tư của bạn đều được chạy và được mã hóa bởi nhà phát triển. Các nhà phát triển được biết là ... tiếp tục phát triển. Sự khác biệt lớn, theo kinh nghiệm của tôi là một công ty đã có kinh nghiệm các nhà quản lý có thể xác định khi mọi thứ được làm. Tôi khuyên bạn nên đặt ai đó vào nhiệm vụ xác định mục tiêu và quyết định khi nào mọi thứ được thực hiện.

Answer 3

Không phương pháp thực sự ở đây, nhưng tôi nghĩ 2 điều rất quan trọng:

1. Có mục tiêu được xác định rõ và trách nhiệm.
2. Cho phép mỗi nhà phát triển có tiếng nói cuối cùng về cách thức phân bổ phần .

Trong các dự án mã nguồn mở, động lực thực sự và mạnh mẽ nhất là niềm vui được mã hóa sản phẩm. Liên quan đến # 2 ở trên, nếu mọi người được bảo phải làm gì, và họ không đồng ý với nó, động lực bắt đầu thiếu. Tất nhiên sẽ luôn luôn có một chút cho-và-như trong bất kỳ loại khác của mối quan hệ.

Cũng khoảng thời gian mặt, Skype là rất tốt cho việc có mặt đối mặt các cuộc họp, mà tôi khuyên bạn nên ít nhất một lần một tuần hoặc hàng tháng (tùy thuộc vào kích thước và động lực của dự án)

Answer 4

Tôi đã ở trên một số dự án mà chúng tôi có nhiều người nói chuyện nhiều hơn các nhà phát triển. Độ nghiêng của tôi là bỏ qua những người nói chuyện và lắng nghe những người lập trình. Thậm chí sau đó thường có một người chịu trách nhiệm chấp nhận các bản vá lỗi. Có thể có những vấn đề chính trị mà họ phải đi một cách nhẹ nhàng xung quanh, nhưng đối với tất cả ý định và mục đích họ nói cuối cùng.

Linus đã có một số vấn đề khá nổi tiếng với cùng một vấn đề. Lưu ý chuỗi này từ năm 2006: Talk is cheap. Show me the code.

Một điều nữa. Vì bạn nói trong phần bình luận rằng bạn có mã, chỉ cần viết lại rất nhiều, tôi khuyên bạn nên đọc số The Cathedral and the Bazzaar của Eric Raymond. Eric là một chút của một nutter thực sự, nhưng bài luận là vô giá cho bất cứ ai muốn chạy một dự án phần mềm miễn phí.

Answer 5

Nếu bạn đọc lịch sử của hầu hết các dự án mã nguồn mở, chúng bắt đầu bằng một người làm rất nhiều công việc ban đầu. Nếu có một đội, nó nhỏ, và một người thực sự dẫn dắt đội.

Để chọn một ví dụ. Trong cộng đồng Python, họ đề cập đến Guido van Rossum là nhà độc tài bền bỉ cho cuộc sống (BDFL). Lời của anh ta là (nhiều hay ít) cuối cùng. Trong nhiều trường hợp, có những người không đồng ý với anh ta - nhưng vì lợi ích của cộng đồng Python - họ dường như không chấp nhận phán xét của anh ta.

Tôi nghĩ rằng mọi dự án nguồn mở đều có một nhà lập trình dẫn đầu (số ít) đảm bảo rằng các quyết định được đưa ra và được thực hiện một cách nhất quán.

Quay lại những ngày xa xưa, Fred Brooks (Tháng người đàn ông huyền thoại) được mô tả "nhóm lập trình viên trưởng". Cùng một khái niệm. Ai đó chịu trách nhiệm về nội dung kỹ thuật. Nhấn mạnh vào một. Ngày nay chúng ta gọi là "kiến trúc sư" hoặc một số thuật ngữ như vậy.

Answer 6

Tôi muốn suy nghĩ về động lực và mục tiêu của bạn và đồng đội trong dự án này. Họ đến:

a) Tạo một sản phẩm tuyệt vời

hoặc

b) chơi xung quanh với các phần mềm, và tìm hiểu một số điều mới

Cả hai câu trả lời là giá trị ngang nhau, và tôi đoán nó sẽ là một sự pha trộn với một nghiêng về phía này hay cái kia.

Nếu có nhiều (a) thì hãy xem các đề xuất về phương pháp, v.v. Thậm chí có thể xem xét việc hình thành một công ty xung quanh ý tưởng tuyệt vời của bạn. Bởi vì làm một điều như vậy có tác dụng .. và bạn có thể có đủ điều đó trong công việc.

Nếu chủ yếu là (b) thì bạn sẽ có một thời gian khó khăn hơn để tạo ra một sản phẩm tuyệt vời, nhưng bạn có thể tha thứ cho chính mình vì không đến đó ngay lập tức và chịu nhiều lần viết lại. Và tất cả các bạn sẽ học những kỹ năng mới mỗi khi bạn nhìn vào nó và làm việc cùng nhau, rất phù hợp với nghề nghiệp lâu dài của bạn.

Trước tiên, tôi đề nghị tất cả các bạn nên rõ ràng với nhau về lý do tại sao bạn ở đó. Sau đó, hãy nhìn vào những gì bạn định làm, và phát hành sớm và phát hành thường xuyên. Nếu dự án của bạn được tạo thành từ ba thành phần và một thành phần hoàn chỉnh, sau đó phát hành nó như một thành phần riêng biệt và bắt đầu xây dựng một cộng đồng người dùng. Điều này sẽ trả hết vì những người dùng này có thể giúp bạn với mã của bạn, cộng với hình thành một cốt lõi của người dùng cho toàn bộ sản phẩm và cho phép bạn đánh giá bạn sẽ sớm như thế nào sau này.

Chúc may mắn.