Làm thế nào để xử lý sự tăng trưởng của một dự án nguồn mở?


11

Tôi đã tham gia giúp đỡ trong việc hỗ trợ cho một dự án nguồn mở trong một hoặc hai năm nay và dự án đã trở nên phổ biến kể từ khi tôi bắt đầu. Chương trình này có hơn 100.000 lượt tải xuống mỗi tuần và được sử dụng bởi hơn 60% số người trong lĩnh vực chính của nó, vì vậy chúng tôi rõ ràng rất vui khi mọi người thích sử dụng nó rất nhiều.

Tuy nhiên, vấn đề là cơ sở phát triển và hỗ trợ đã không phát triển nhanh như vậy và chúng ta bắt đầu gặp phải những cơn đau ngày càng tăng. Một số ít các nhà phát triển (đặc biệt là nhà phát triển chính) đang bị kéo dài khá mỏng và các tình nguyện viên hỗ trợ công nghệ bắt đầu bị đốt cháy.

Cho đến nay, nó gần như chỉ là một loạt các anh chàng lang thang trên IRC, viết chương trình này và giúp đỡ người dùng. Không có tổ chức 501 (c) (3) hoặc LLC hoặc bất cứ thứ gì tương tự.

Ngay bây giờ, chúng tôi không có trình theo dõi lỗi hoặc cơ sở dữ liệu vấn đề rất chính thức (chúng tôi có một diễn đàn với chuyên mục dành cho báo cáo lỗi), điều mà tôi thừa nhận là điều chúng tôi có thể cải thiện để có thêm nhà phát triển. Nhưng tôi cho rằng câu hỏi thực sự của tôi là, làm thế nào để người ta chuyển từ dự án cá nhân nhỏ thành một ... điều thực sự ? Làm thế nào mà các ông lớn như GIMP, FFmpeg, Blender, v.v ... đã xử lý quá trình chuyển đổi này?

Và trên hết, có cách nào để cung cấp bồi thường với dự án FOSS không? Tôi cho rằng sự đóng góp giúp đỡ, nhưng điều đó chỉ đi xa ... có vẻ lạ khi kiếm sống bằng phần mềm miễn phí, nhưng nếu chương trình sẽ tiếp tục tốt hơn, tôi không thấy làm thế nào chúng ta có thể tiếp tục mà không đền bù cho mọi người cho công việc toàn thời gian.

Về cơ bản, chúng ta đang có một số cơn đau ngày càng tăng và cảm thấy "quá lớn cho những rắc rối của chúng ta." Chúng ta có thể làm gì để quản lý quá trình chuyển đổi này và không bị đốt cháy khi làm quá nhiều việc cùng một lúc?


7
Điều đầu tiên trước tiên là có một trình theo dõi lỗi thích hợp và chạy, không có nguồn mở nào tồn tại mà không có trừ khi nhóm nòng cốt rất giỏi. Cũng đảm bảo hướng của các tính năng rõ ràng và không làm bạn khó chịu.
ratchet freak

4
Nếu bạn không phiền tôi hỏi, dự án là gì?
Robert Harvey

2
Tôi ngần ngại đặt tên cho dự án, một phần vì nó hơi đáng sợ khi ra ngoài đó và nói với mọi người "Này, chúng tôi không thực sự chắc chắn những gì chúng tôi đang làm, và chúng tôi cần sự giúp đỡ!" Ngoài ra, tôi không muốn bài đăng này xuất hiện dưới dạng quảng cáo để được giúp đỡ với dự án. Mặc dù vậy, tôi chắc chắn rằng một số điều tra trên mạng sẽ tiết lộ điều đó. : /
Ben Torell

Câu trả lời:


13

Giai đoạn dự án của bạn đang thực sự thú vị và rất quan trọng, nó rất dễ bị sập và cháy (nhưng) đó cũng là nơi bạn có thể đưa ra một số quyết định quan trọng, nếu mọi thứ hoạt động, sẽ giúp đảm bảo khả năng tồn tại lâu dài.

Đây là một vài gợi ý.

  • Đọc cuốn sách tuyệt vời của Karl Fogel Sản xuất phần mềm nguồn mở . Ông bao gồm hầu hết các vấn đề lớn trước mắt. Mặc dù tôi không đồng ý với mọi điều anh ta nói, đó chỉ là ý kiến. Anh ấy hoàn toàn hiểu thế giới nguồn mở.

  • Như @Ross Patterson đã nói, bạn hoàn toàn phải thiết lập trình theo dõi và danh sách gửi thư hoặc một cái gì đó tương tự để tránh sự hỗn loạn hoàn toàn. Bạn đang sử dụng gì để kiểm soát phiên bản? Nếu bạn đang ở trên github, bạn có thể bắt đầu với trình theo dõi của họ hoặc bạn có thể tích hợp với Jira hoặc một cái gì đó tương tự hoặc nếu bạn muốn, bạn có thể truy cập SourceForge ngay bây giờ và sử dụng cơ sở hạ tầng miễn phí của họ. Bạn không nói mọi người đang tải xuống từ đâu nhưng bạn muốn chắc chắn rằng bạn đã thiết lập nó một cách đáng tin cậy và có số lượt tải xuống tốt.

  • Không có lý do gì mà bạn không thể kiếm sống bằng phần mềm miễn phí nếu đó là điều bạn muốn, rất nhiều người làm điều đó, nhưng nó có rất nhiều hình thức khác nhau. Bạn cần quyết định cách bạn muốn làm điều đó trước khi đưa ra quyết định lớn của tổ chức. Ví dụ: bạn có thể và có thể nên thành lập một công ty để giữ nhãn hiệu và bản quyền cũng sẽ cung cấp một số bảo vệ pháp lý nếu cần thiết. Tuy nhiên sau đó bạn sẽ cần một chủ tịch hoặc thủ quỹ. Loại tổ chức nào (phi lợi nhuận hoặc vì lợi nhuận, LLC, hợp tác, hợp tác) thực sự phụ thuộc vào mục tiêu của bạn và nên được thảo luận với một luật sư giỏi. Nếu bạn được chấp nhận bởi Bảo vệ Tự do Phần mềm, họ sẽ giúp bạn tìm ra điều đó và cũng giúp giải quyết các vấn đề về kế toán và thuế, v.v. Ngoài ra còn có một vài vườn ươm FOSS khác nhưPhần mềm vì lợi ích công cộng . Ngoài ra, tôi nghĩ Outercurve là một khả năng.

  • Về cách bạn kiếm sống, điều này sẽ phụ thuộc rất nhiều vào bản chất của dự án của bạn. Đây cũng là lý do tại sao tôi sẽ không ngay lập tức nói rằng bạn cần 501c3 (và bạn có thể không nhận được ... xem dự án Yorba). Blender hỗ trợ chính nó bằng cách bán tài liệu. Các dự án khác có hệ sinh thái kinh doanh nhỏ và / hoặc tư vấn xung quanh họ và các nhà phát triển kiếm sống từ đó. Các dự án khác không có mô hình cấp phép kép để họ bán các phiên bản được hỗ trợ (đó là lý do tại sao MySQL đã làm và tại sao nó có thể được bán cho Sun và tất nhiên là có RedHat) và có một bản phát hành riêng. Những người khác như WordPress có phiên bản được lưu trữ như một mô hình kinh doanh. Vì vậy, có tất cả các loại tùy chọn và bạn cần tìm ra điều gì có ý nghĩa đối với bạn và cộng đồng của bạn.

  • Chọn ai đó ngay bây giờ để làm người quản lý cộng đồng của bạn để bắt đầu. Và đọc cuốn sách của Jono Bacon sau khi bạn hoàn thành Fogel's.

  • Quyết định ngay bây giờ trên một bản đồ đường có ý nghĩa cho nhóm cốt lõi của bạn; hãy thực tế và đừng bị bắt nạt bởi những người không đóng góp. Bản đồ đường không chỉ có nghĩa là các kế hoạch và tính năng kỹ thuật, đó là về nơi bạn muốn đến như một dự án.

  • Đừng ngại nói chuyện với các dự án khác mà bạn ngưỡng mộ hoặc trong cùng một không gian cho vấn đề đó. Tìm hiểu những gì đã làm việc và không làm việc cho họ. Chỉ cần gửi một email. Ngoài ra, bạn có thể đi đến một số sự kiện chung nguồn mở và chỉ nói chuyện với các dự án khác. Trên toàn bộ foss mọi người là khá hữu ích.

Chúc may mắn, đó là một điều thú vị ở giai đoạn này.


Cảm ơn! Mã đã được lưu trữ trên Github (cũng là nơi lưu trữ các bản phát hành), nhưng chúng tôi thực sự không thích trình theo dõi vấn đề của Github ... một trong những người trong nhóm có kinh nghiệm với Mantis nên tôi nghĩ chúng tôi sẽ sử dụng cái đó. Tôi cũng nghe bạn nói về lộ trình ... ít nhất, có một lộ trình công khai sẽ rất tuyệt nếu chỉ giới thiệu người dùng đang theo dõi các tính năng cụ thể, vì vậy chúng tôi có thể cho họ biết khi các tính năng đó xuất hiện so với các tính năng khác. Tôi đã khám phá Outercurve vào tối nay và tôi cũng sẽ xem những cuốn khác. Cảm ơn sự động viên!
Ben Torell

1
@BenTorell Tôi nói với bất kỳ ai hỏi, "Mọi trình theo dõi lỗi đều bị hút, câu hỏi duy nhất là, 'Cái nào hút ít nhất đối với các quy trình của bạn?'".
Ross Patterson

Ross hoàn toàn đúng. Tôi thực sự không thích trình theo dõi của Github vì một số lý do nhưng đặc biệt là nó không có ACL thực sự. Tôi đồng ý tìm một cái phù hợp với quy trình của bạn. Rất nhiều trình theo dõi không hoạt động tốt cho các dự án do tình nguyện viên thực hiện vì họ đưa ra tất cả các giả định có ý nghĩa trong cài đặt thương mại, ngay cả trong từ vựng họ sử dụng. Tất nhiên, nói về những gì quá trình của bạn thực sự là một bài tập tốt. Đừng cố sử dụng trình theo dõi để thực hiện các thay đổi không thực tế trong quy trình của bạn. Mọi thứ thật sự khác biệt khi tất cả đều là tình nguyện viên.
Elin

3

Các chàng trai thực sự lớn thiết lập tất cả các cơ chế bạn biết về - họ chạy máy chủ trang trại lớn, họ chạy (đôi khi viết) trackers lỗi và hệ thống xây dựng, vv Họ thường có 501 (c) 3 cơ sở sở hữu bản quyền, vv Họ nhận các khoản đóng góp lớn của công ty và các công ty cho họ mượn các nhà phát triển, v.v. Bạn biết đấy, công cụ LỚN.

Những cậu bé không quá lớn nhận được rất nhiều sự giúp đỡ từ nơi khác. Các Tự do Conservancy phần mềm , ví dụ, sẽ giúp các dự án vừa-lớn có được nền tảng pháp lý của họ ngay, và tạo điều kiện đóng góp. Có rất nhiều tùy chọn để lưu trữ mã và theo dõi lỗi trong những ngày này - heck, bất kỳ ai cũng có thể có được một trang web GitHub. Và bạn sẽ thấy rằng nhiều công ty phần mềm vừa và nhỏ sẽ tặng giấy phép cho các sản phẩm độc quyền của họ để hỗ trợ các dự án Nguồn mở có tổ chức - đặc biệt là khi họ liên kết với doanh nghiệp của mình bằng cách nào đó.


3
Tôi không cố gắng trở thành nhà mô phạm và tôi chắc chắn 100% rằng bạn không có ý nói theo cách tiêu cực, nhưng nó thực sự không giúp tăng sự tham gia vào nguồn mở để đề cập đến những người liên quan như con trai. Chỉ cần một cái gì đó để suy nghĩ; Tôi biết đó là một cụm từ mọi người sử dụng.
Elin

@Elin Chỉ cần trả lời câu hỏi: "Làm thế nào mà các ông lớn như GIMP, FFmpeg, Blender, v.v ... đã xử lý quá trình chuyển đổi này?"
Ross Patterson

Ồ, và +1 trên bình luận - đôi khi chúng ta cần được nhắc nhở. Doanh nghiệp này là quá trung tâm nam giới.
Ross Patterson

Cảm ơn và vâng tôi đã không nhận thấy tài liệu tham khảo trong bài viết gốc.
Elin

Vâng, tôi chỉ sử dụng "các ông lớn" như một cụm từ ... Tôi đoán tôi đã không nghĩ về nó theo cách đó, nhưng tôi có thể hiểu ý của bạn. Cảm ơn vì lời khuyên! Ưu tiên hàng đầu của tôi ngay bây giờ là có được một trình theo dõi vấn đề thực sự mà những người đóng góp có thể kiểm tra và hy vọng chọn một vấn đề để giải quyết (ngay bây giờ tất cả những gì chúng ta có là một bảng Trello lộn xộn). Như tôi đã nói với @Elin, tôi đang nghiêng về Thần chú thay vì hệ thống vấn đề của Github. Tôi cho rằng chúng ta chỉ cần một cái gì đó vào thời điểm này.
Ben Torell
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.