Mục lục
- Mục lục
- Quyền lợi và độc tính của người dùng
- Chất lượng đóng góp thấp
- Thiếu cộng đồng
- Thiếu bồi thường
- Thiếu dụng cụ
- Tổng kết
GitHub đã xuất bản một bài viết gây tò mò về việc tránh tình trạng kiệt sức đối với những người bảo trì nguồn mở. Đây là một chủ đề quan trọng cần được thảo luận rộng rãi hơn và tôi đánh giá cao việc GitHub đã xuất bản nó.
Bài viết có cái nhìn tổng quan về các nguyên nhân có thể dẫn đến kiệt sức và đưa ra một số gợi ý về cách tránh nó. Tuy nhiên, tôi cảm thấy mục tiêu chính của bài viết là thuyết phục những người bảo trì tiếp tục làm những gì họ đang làm càng lâu càng tốt, nghĩa là tiếp tục làm việc miễn phí. Bài báo đề cập ngắn gọn đến việc tài trợ nhưng đối với hầu hết những người bảo trì, việc dựa vào tài trợ hoặc quyên góp là không thực tế.
Tôi nghĩ giải pháp lành mạnh nhất để tránh tình trạng kiệt sức của người bảo trì là loại bỏ hoàn toàn nguồn mở, ít nhất đó là giải pháp hiệu quả với tôi. Thật không may, bản thân tôi đã phải đạt đến trạng thái kiệt sức để hiểu điều đó, và sau đó tôi phải mất một thời gian dài để hồi phục (hoặc thay thế tình trạng kiệt sức của người bảo trì bằng tình trạng kiệt sức ở các lĩnh vực khác của cuộc sống).
Trước đây tôi đã nói về lý do tại sao nguồn mở lại hấp dẫn tôi và một chút về lý do tại sao tôi đóng góp ít hơn và cuối cùng từ bỏ nguồn mở.
Trong bài viết này, tôi muốn nói nhiều hơn về những lý do đã khiến tôi kiệt sức vì người bảo trì và từ bỏ nguồn mở sau khoảng mười năm đóng góp thường xuyên và xuất bản nhiều dự án.
Vậy lý do là gì?
Quyền lợi và độc tính của người dùng
Bằng cách nào đó mọi người mong đợi bạn giải quyết vấn đề của họ hoặc triển khai các tính năng họ cần. Họ sẽ phàn nàn rằng lỗi bạn đưa ra trong phiên bản trước đã làm hỏng bản dựng của họ hoặc họ cần tính năng khó hiểu này cho dự án hiện tại của họ tại nơi làm việc và rằng nếu bạn không nhanh chóng bổ sung nó, sếp của họ sẽ nổi điên vì thời hạn. đã ở trên mũi rồi.
Mọi người dường như nhớ rằng bạn đang thực hiện những dự án này vào thời gian rảnh rỗi, sau một ngày dài làm việc toàn thời gian và không có bất kỳ khoản thù lao nào. Họ yêu cầu bạn làm bất cứ thứ gì, theo quan điểm của họ, bị hỏng hoặc bị thiếu, và sau đó họ tức giận khi bạn không làm hoặc làm không đủ nhanh.
Họ nhớ rằng bạn có thể là người duy nhất làm việc trong dự án, rằng bạn không phải là thành viên của một nhóm lớn được trả tiền để làm việc toàn thời gian nhằm duy trì dự án và giải quyết các vấn đề của người dùng.
Bằng cách nào đó, nguồn mở đã trở thành từ đồng nghĩa với lao động tự do, không chỉ mã miễn phí, và nó có hại cho cả cộng đồng mà chủ yếu là có hại cho những người duy trì các dự án nguồn mở.
Và sau đó, có tất cả những bình luận độc hại ( chỉ xem một vài ví dụ ) cho bạn biết rằng phần mềm của bạn là rác rưởi và bạn nên tự sát bỏ lập trình, tất cả những điều bổ ích (“Tôi gặp vấn đề tương tự”), tất cả các ping (“có cập nhật nào về điều này không?”) và các nhận xét spam khác không mang lại bất kỳ giá trị nào…
Chất lượng đóng góp thấp
Tôi thường cảm thấy việc quản lý các đóng góp mất nhiều thời gian hơn việc tự mình triển khai các tính năng tương tự.
Chất lượng mã tổng thể của yêu cầu kéo đối với các dự án nguồn mở thường rất thấp và mỗi yêu cầu kéo đòi hỏi nhiều thời gian và nỗ lực tinh thần để xem xét, đòi hỏi nhiều nhận xét và nhiều lần lặp lại để đưa nó đến chất lượng có thể chấp nhận được.
Thường phải mất vài tháng để hợp nhất một yêu cầu kéo, nhiều yêu cầu bị bỏ rơi hoặc tác giả của chúng cảm thấy thất vọng và tức giận. Thông thường, ai đó gửi một yêu cầu kéo và không bao giờ quay lại yêu cầu đó nữa, vì vậy bạn lãng phí thời gian và sức lực để xem lại mã của họ mà chẳng được gì (tôi gọi những yêu cầu kéo đó là hit và run pull request ).
Mọi người thường gửi các tính năng họ muốn nhưng không phải lúc nào nó cũng phù hợp với tầm nhìn của dự án hoặc nằm ngoài phạm vi dự định của dự án. Họ cũng tin rằng việc chấp nhận tác phẩm của họ là miễn phí đối với bạn, mà không nghĩ rằng trước tiên bạn cần xem lại yêu cầu kéo (có thể nhiều lần) và sau đó duy trì tính năng này sau khi nó được hợp nhất (có thể là mãi mãi).
Và thời điểm đen tối nhất đối với một nhà bảo trì nguồn mở là tháng 10, khi trong Hacktoberfest, mọi người trên khắp thế giới đã gửi thư rác cho những nhà bảo trì nguồn mở với những hành động hoàn toàn vô nghĩa chỉ để nhận được một chiếc áo phông miễn phí.
Thiếu cộng đồng
Hầu hết các dự án của tôi không bao giờ trở nên phổ biến bất chấp mọi nỗ lực của tôi để làm cho chúng hữu ích và tiếp thị chúng. Nếu không có ai sử dụng dự án của bạn, tại sao phải sửa lỗi, viết tài liệu, tạo một trang web đẹp, v.v.?
Dự án cuối cùng của tôi, chủ đề màu Squirrelsong là một ví dụ điển hình ở đây. Tôi đã đầu tư rất nhiều thời gian để tạo chủ đề này và tôi nghĩ nó đủ tốt hơn và khác biệt hơn nhiều chủ đề hiện có, tuy nhiên, có vẻ như tôi là người dùng duy nhất.
Dự án nguồn mở phổ biến nhất của tôi, React Styleguidist, có hơn 10 nghìn sao trên GitHub, tuy nhiên, tôi không thể quản lý để xây dựng một cộng đồng xung quanh nó và làm cho nó trở nên tự cung tự cấp. Dự án quá lớn để một người có thể xây dựng nó cũng như quản lý các vấn đề và lấy yêu cầu.
Tôi đã có một số đóng góp tích cực trong nhiều năm trong nhiều dự án khác nhau, nhưng hầu hết chúng đều đòi hỏi sự cộng tác rất nhiều từ phía tôi. Một số người quan tâm đến việc duy trì một số dự án của tôi, nhưng một lần nữa, họ cần rất nhiều sự hướng dẫn từ phía tôi, vì vậy tôi chưa bao giờ cảm thấy điều đó giúp tôi tiết kiệm thời gian và công sức.
Cần có đủ người tích cực làm việc trong dự án để giải quyết các vấn đề, xem xét các yêu cầu kéo và làm việc trên các tính năng mới, vì vậy ngay cả khi một số người trong số họ bị xe buýt đâm không thể làm việc trên một dự án ngay bây giờ, nó sẽ tiếp tục. Tuy nhiên, trên thực tế, nếu tôi không làm mọi việc, các dự án sẽ dừng hoàn toàn và các vấn đề sẽ bắt đầu chồng chất.
Thiếu bồi thường
Duy trì một dự án nguồn mở là một công việc khó khăn và đòi hỏi khắt khe, giống như bất kỳ công việc nào khác. Sự khác biệt là chúng tôi thường được trả tiền để làm các công việc khác chứ không phải cho nguồn mở. Rất ít nhà phát triển có thể kiếm sống (hoặc ít nhất là bất kỳ khoản tiền đáng kể nào) bằng nguồn mở, đối với phần lớn chúng ta, điều đó chẳng là gì ngoài sự thất vọng.
Số tiền nhiều nhất tôi nhận được cho công việc nguồn mở của mình là cho React Styleguidist thông qua Open Collective. Và thỉnh thoảng chỉ mua một gói nhãn dán là đủ. Ngân sách hàng tháng hiện tại của dự án là 8 USD.
Tôi đã thử các nhà tài trợ GitHub nhưng không có kết quả, ngoại trừ khoản đóng góp một lần trị giá 550 USD từ chính GitHub đã bị hủy bỏ một cách bí ẩn cùng ngày.
Tôi có nút Mua cho tôi một ly cà phê trên readme của mọi dự án nhưng tôi không nghĩ mình từng nhận được một tách cà phê nào từ đó. (Tuy nhiên, tôi đã nhận được một số cà phê từ Unsplash, điều này cũng không thấm vào đâu so với hơn 1,5 triệu lượt tải xuống ảnh của tôi ở đó.)
Thiếu dụng cụ
Có hai vấn đề với công cụ mà những người bảo trì nguồn mở phải giải quyết.
Đầu tiên, sự phức tạp của công cụ liên quan đến việc phát triển một dự án nguồn mở điển hình:
- Publishing mã JavaScript (không thể nói về các ngôn ngữ khác - hầu hết công việc của tôi là JavaScript và TypeScript) theo cách mà nhiều người có thể sử dụng được là một việc rất phức tạp và ngày càng trở nên tồi tệ hơn.
- Việc nâng cấp phần phụ thuộc thường mất nhiều thời gian và nếu bạn có nhiều dự án, nó có thể trở thành một cuộc phiêu lưu kéo dài cả năm (tôi thậm chí còn tạo ra một công cụ để trợ giúp việc đó).
- Nói chung, số lượng cấu hình (TypeScript, linters, bộ đóng gói, bản phát hành, phần phụ thuộc, thử nghiệm, tiếp tục tích hợp, tạo nhật ký thay đổi, v.v., v.v., v.v.) nhanh chóng vượt quá tầm kiểm soát.
Thứ hai, GitHub có thể làm được nhiều hơn thế (còn hơn là không làm gì) để bảo vệ người dùng khỏi những kẻ độc hại. Ví dụ: GitHub có thể:
- Phát hiện các nhận xét độc hại và tự động xóa chúng hoặc đánh dấu chúng để xem xét thủ công.
- Xóa các nhận xét spam và chuyển đổi các nhận xét cộng thành phản ứng thích.
- Giáo dục người dùng đăng những bình luận như vậy bằng cách dạy họ những hành vi tốt hơn hoặc cấm họ nếu họ không muốn thay đổi.
- Làm rõ trạng thái dự án: làm rõ dự án được hỗ trợ bởi công ty hay được ai đó duy trì trong thời gian rảnh.
Tôi đã phải bỏ qua mọi hoạt động trong nhiều dự án trên GitHub chỉ để tránh mọi người lúc nào cũng nhắc đến tôi.
Tổng kết
Cần phải thay đổi điều gì đó để nguồn mở trở nên lành mạnh nhưng hiện tại tôi không muốn trở thành một phần của nó. Tôi không muốn giúp các tập đoàn kiếm được hàng triệu đô la nhờ mã miễn phí và nhận được những bình luận thô lỗ thay vì bất kỳ hình thức công nhận nào.
Điều tồi tệ nhất là nó đang trở nên tồi tệ hơn chứ không phải tốt hơn.
Bây giờ tôi coi các dự án nguồn mở của mình là các dự án cá nhân có mã nguồn mở. Thật thuận tiện khi giữ mã trên GitHub và sử dụng npm để chia sẻ mã giữa một số dự án. Tôi chỉ thêm các tính năng mà bản thân tôi cần và khi tôi cần chúng. Tôi không nhận được thông báo về bất kỳ hoạt động nào trong các dự án này. Tôi hiếm khi xem xét vấn đề hoặc đưa ra yêu cầu và gần như không bao giờ trả lời chúng.
Có lẽ, tôi nên vô hiệu hóa hoàn toàn các vấn đề hoặc thêm ghi chú giải thích rằng chúng có thể sẽ bị bỏ qua và chúng có thể thành công hơn bằng cách giả mạo mã. Tôi đoán, tôi vẫn muốn các dự án có một nơi để người dùng báo cáo lỗi để những người dùng khác có thể đề xuất cách giải quyết.
Tham khảo