- Phần mềm mã nguồn mở, ngay cả trước thời kỳ (D)VCS, vẫn có thể được phát hành chỉ bằng trang HTML, tệp txt, tarball qua FTP và địa chỉ liên hệ email; nó vẫn là mã nguồn mở dù không có cộng đồng công khai
- Có mailing list hay kênh IRC đã là may mắn, nhưng pull request, issue, wiki, core team và Code of Conduct không phải là điều kiện bắt buộc của mã nguồn mở
- Sourceforge cung cấp CVS/SVN và mailing list gần như miễn phí, giúp việc phát triển công khai trở nên dễ dàng hơn; sau đó git thắng trong cuộc cạnh tranh DVCS và thế giới dần hội tụ về GitHub
- Sau GitHub, việc bảo trì mã nguồn mở đã biến thành kiểu lao động không lương khi phải gánh cả issue, những pull request vượt ngoài phạm vi, lời phàn nàn, yêu cầu và cả việc quản lý nhóm chat, điều có thể dẫn đến kiệt sức và mất quyền kiểm soát
- Dự án không nhất thiết phải được phát triển công khai; bạn có thể tắt issue tracker và pull request, dùng bare git server, rồi vận hành mã nguồn mở cùng một nhóm nhỏ đáng tin cậy hoặc một mình
Gánh nặng bảo trì sau GitHub
- GitHub khiến mã nguồn mở có cảm giác như lao động không lương đối với người bảo trì
- Sau khi ở công ty phải xử lý ticket, họp với các bên liên quan, roadmap, chính trị nội bộ, xao nhãng, deadline, chỉ số, KPI, yêu cầu thay đổi, standup, one-on-one, Agile, Waterfall, thì khi về nhà, thông báo mã nguồn mở lại tiếp tục chồng chất
- issue tích lại, các pull request xuất hiện để thiết kế lại phần mềm theo hướng vượt ngoài phạm vi dự án, còn lời phàn nàn và yêu cầu thì ngày càng tăng
- Khi có nhóm chat và “cộng đồng”, người bảo trì còn phải gánh trách nhiệm quản lý những người thiếu kiên nhẫn và xử lý từng trường hợp một-một
- Kết quả là mã nguồn mở biến thành công việc thứ hai, người bảo trì bị kiệt sức và thậm chí có thể mất cả quyền kiểm soát lẫn định hướng của chính dự án mình
Vận hành đơn giản trở lại
- Một số dự án quá lớn và phức tạp nên cần quản lý theo nhóm, nhưng đó là ngoại lệ chứ không phải trường hợp phổ biến
- Nếu bạn bực bội vì người mới và bot AI liên tục kéo sự chú ý đi nơi khác, bạn có thể quay lại cách làm ngày xưa
- Có thể tắt issue tracker và pull request, hoặc vận hành bare git server chỉ để công khai mã nguồn
- Bạn có thể làm việc với một nhóm nhỏ mà mình thực sự quen và tin tưởng, hoặc hoàn toàn tự làm dự án một mình
- Không cần phải cho phép người lạ xâm nhập vào không gian của mình, và những Code of Conduct hay chính sách LLM mang tính trưng bày cũng không phải là bắt buộc
- Để là “mã nguồn mở”, không bắt buộc phải phát triển công khai
- Hãy dùng công cụ bạn muốn, làm thứ bạn thích, thậm chí thả code lúc 2 giờ sáng ngày Giáng sinh cũng được, không cần bị kéo vào một mô hình vận hành như thể pha trộn giữa lò ươm công nghệ và cơ sở giữ trẻ
1 bình luận
Ý kiến trên Lobste.rs
Chính vì suy nghĩ này mà tôi đã tạo ra https://casuallymaintained.tech/ , và tôi rất thích nó
Ví dụ nổi tiếng nhất là SQLite, dự án này từ chối các đóng góp từ bên ngoài
Nghĩ đến việc nó còn được dùng trong các ứng dụng tối quan trọng như máy bay của Airbus thì đây là một chính sách hợp lý
SQLite là mã nguồn mở nên bạn có thể sao chép bao nhiêu tùy thích và sử dụng không hạn chế, nhưng đây không phải là một dự án đóng góp công khai (open-contribution)
Để giữ SQLite ở phạm vi public domain và ngăn mã độc quyền hay mã có giấy phép bị trộn vào, họ không nhận patch từ những người chưa nộp tuyên bố hiến tặng phần đóng góp của mình cho public domain
Đây là một góc nhìn khá mới mẻ
Có lẽ tác giả đúng, và có thể chúng ta đang đòi hỏi quá nhiều ở những người bảo trì
Có khi thứ bị hỏng không phải toàn bộ mã nguồn mở, mà là sự lạm phát kỳ vọng về những gì mã nguồn mở phải cung cấp
Yếu tố xã hội của GitHub cũng có thể góp phần vào chuyện này. Càng nhiều sao và người dùng phổ thông, áp lực phải làm hài lòng những người mới ghé xem dự án càng lớn
Đặc biệt sẽ trở nên nguy hiểm khi sự quan tâm và yêu cầu từ cộng đồng không còn khớp với tầm nhìn ban đầu của người tạo ra nó
Bài liên quan: Git without a Forge: https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/git-no-forge/
Đây là một cách tiếp cận vững chắc, và tôi mong nhiều người sẽ xem nó là mặc định hơn
Xây dựng cộng đồng hay gánh thêm một loại trách nhiệm nào đó nên là hành động ngoại lệ và có chủ đích
Phần nói rằng bộ quy tắc ứng xử và chính sách LLM chỉ là làm màu có hơi lạc điệu, nhưng vì đây là chủ đề nhạy cảm nên cũng có thể hiểu được
Nhưng nếu gắn nó vào một kho lưu trữ một người, không có người dùng, không có cộng đồng và cũng không định xây dựng những thứ đó trong tương lai, thì nó đúng là làm màu
Tôi không cần một bộ quy tắc ứng xử cho chính mình trong một kho lưu trữ chỉ mình tôi dùng
Sẽ rất tuyệt nếu cuộc thảo luận này có thêm sức nặng và thực sự dẫn đến một sự đồng thuận hiệu quả
Có rất nhiều cách để tạo phần mềm và đóng góp một cách lành mạnh
Chỉ là chúng có thể không tương thích với nhau, hoặc không phù hợp với các tiêu chuẩn cao của mã nguồn mở, hoặc phải trả cái giá của sự hiển thị và nổi tiếng, hoặc dùng các cơ chế khác nhau như giấy phép, tự lưu trữ, không nhận đóng góp mã nguồn
Tôi hy vọng chúng ta có thể cùng tìm ra một con đường tốt đặt niềm vui và sự công bằng lên hàng đầu trong phần mềm cộng đồng
Trạng thái được mô tả trong bài thực ra là trạng thái tự nhiên của mọi dự án mã nguồn mở cá nhân vừa mới được một người không nổi tiếng tạo ra
Tất cả chúng ta đều có khá nhiều dự án vận hành theo kiểu đó
Vấn đề là mọi người không biết mình muốn gì từ dự án, hoặc nghĩ rằng điều hành một dự án nổi tiếng sẽ rất ngầu nhưng lại không cân nhắc kỹ cái giá phải trả
Vì thế, dù có ý thức hay không, việc theo đuổi sự chú ý bắt đầu xuất hiện
Câu nói “GitHub đã biến toàn bộ mã nguồn mở thành một công việc không lương cho người bảo trì” chỉ đúng khi bạn cho phép điều đó
Nếu bỏ đi lời hứa hẹn mơ hồ về danh tiếng, thì trong hầu hết tình huống GitHub thực ra không có nhiều đòn bẩy để ép bạn làm những việc vốn dĩ bạn không muốn làm
Chuẩn luôn
Trước đây tôi có một dự án hơi nổi một chút, và tôi đã bị căng thẳng vì phải xử lý các báo lỗi và pull request cho những tính năng tôi không hề muốn
Giá mà hồi đó tôi được đọc một bài như thế này thì tốt biết mấy
Nhân tiện, https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9 cũng đáng đọc
Với các dự án nhỏ thì tôi cực kỳ đồng ý với bài này
Ngay cả với các dự án lớn hơn, những dự án thành công nhất cũng thường không khởi đầu như một cộng đồng mở ngay từ đầu
Nhiều dự án tôi yêu thích bắt đầu được phát triển trong các tổ chức lớn, và điểm cốt lõi là phần mềm đó được thực sự sử dụng tích cực trong nội bộ
Vì thế người bảo trì vốn dĩ đã được trả lương rồi
Dù là dự án cá nhân hay đội ngũ nội bộ, phần mềm được tạo ra để giải quyết các vấn đề thường nhật của chính nhà phát triển dường như thành công hơn và ít mang tính bóc lột hơn so với phần mềm được tạo ra vì danh tiếng hay thương mại hóa