Mã nguồn mở không đồng nghĩa với cộng đồng công khai
(blog.feld.me)- 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ẻ
2 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
Ý kiến trên Hacker News
Ngay cả trong những cộng đồng khép kín nhất, nếu gửi email lịch sự thì nhiều khi họ vẫn nhận đóng góp
Có một nhà phát triển mã nguồn mở từng tắt pull request của kho lưu trữ và nhiều tính năng khác vì quá mệt mỏi với việc bị quấy rối, và trong giai đoạn đó còn mang tiếng là người cực kỳ khó tính
Tôi không biết chuyện phía sau, chỉ nghĩ dự án vốn hoạt động theo cách đó, nên đã tìm được địa chỉ email sau một chút dò hỏi rồi gửi một bản vá không chính thức bằng email, nhẹ nhàng và lịch sự, đồng thời nói rõ là dùng hay bỏ qua đều được
Nhà phát triển đó trả lời cảm ơn, giải thích tình hình, còn xin lỗi vì đã gây bất tiện, nói rằng ngoài cách khóa mọi thứ lại thì không biết phải xử lý ra sao, rồi dĩ nhiên đã áp dụng luôn phần sửa đổi
Tôi cứ tưởng bài này sẽ nói về vấn đề phổ biến là các dự án phần mềm tự do bắt buộc thảo luận hay báo lỗi qua Discord
Có vẻ từng có chút quan tâm đến việc chuyển sang công cụ khác trong khoảng một hai tuần, nhưng giờ đã nguội rồi, và rốt cuộc ai cũng bỏ cuộc rồi quay lại Discord
Discord không phải là thứ tệ hại hoàn toàn, nhưng nó phù du và đòi hỏi một web app khổng lồ, cồng kềnh
Từ góc nhìn của một ông già nhiều kinh nghiệm, tôi thích thái độ của tác giả
Tôi đủ già để còn nhớ thời ngồi trước các bậc tiền bối ARPANET, khi chỉ có số 1, và phải gọt bằng tay khoảng một nửa trong số đó thành số 0
Trong cách phát triển phần mềm ngày xưa, dự án thường được viết hoặc duy trì bởi một hoặc hai người, và cả Internet đều biết địa chỉ email của họ để gửi báo lỗi trực tiếp
Một số dự án được thảo luận trên IRC hoặc mailing list, nhìn chung mọi người cư xử chuyên nghiệp, còn nếu không thì sẽ bị xóa khỏi mailing list hoặc đưa vào file chặn của iirc và pine
Điều cốt lõi là ở bất kỳ thời điểm nào, nhóm nhà phát triển đang hoạt động cũng rất nhỏ
Tôi chủ yếu nói đến các tiện ích nhỏ như make, Sendmail, sed, awk; ngay cả Perl trước năm 1990 trông cũng gần như chỉ có Larry Wall và tchrist
gcc là một phản ví dụ điên rồ, nơi hàng nghìn người gửi bản vá và nếu muốn được đưa upstream thì còn phải phối hợp ổn thỏa với RMS
Các công cụ mới hỗ trợ những đội ngũ lớn hơn tương tác liên tục, và việc giữ một nhóm nhỏ rồi mặc kệ bất kỳ ai trên Internet trừ khi họ sẵn sàng đặt cả quả thận vào bản vá của mình cũng có những ưu điểm lớn
Chỉ là cách đó không có lợi cho việc lôi kéo người khác tham gia vào sản phẩm của bạn, nên bạn hoàn toàn có thể đi theo kiểu cũ, nhưng đội sẽ nhỏ hơn và có thể khó thu hút người dùng hơn
Dù vậy người dùng có quan tâm hay không thì cũng mặc, tôi dùng phần mềm để phục vụ trường hợp sử dụng của mình, và công khai nó dưới dạng mã nguồn mở chỉ vì nghĩ biết đâu còn hữu ích với người khác
Nói cụ thể hơn, mã nguồn mở chỉ hứa hẹn bốn quyền tự do cơ bản(https://en.wikipedia.org/wiki/The_Free_Software_Definition)
Ngoài ra, theo nghĩa đen là chẳng hứa hẹn gì khác, và điều đó cũng bao gồm việc miễn phí
Phần mềm tự do/mã nguồn mở có thể và nên thu tiền, và từ “free” ở đây không nói về tiền bạc
Tôi nhìn khá tích cực vào các vụ tấn công “chuỗi cung ứng” mã nguồn mở xảy ra gần đây trong nhiều cộng đồng, vì theo hướng lạc quan, hy vọng chúng khiến mọi người nhận ra rằng mã nguồn mở không phải là chuỗi cung ứng
Chi tiết có ở https://lobste.rs/s/cxwidw/no_one_owes_you_supply_chain_secu...
Nếu bạn không trả tiền cho nhà cung cấp, hoặc không có hợp đồng kèm cam kết lịch trình, thì bạn không có chuỗi cung ứng
Gần như mọi giấy phép FOSS đều có điều khoản kiểu “phần mềm này được cung cấp không kèm bảo hành”, mà chuỗi cung ứng thì hàm ý có bảo đảm, nên FOSS không phải chuỗi cung ứng
Tôi chán ngấy việc người ta đến đây rồi đối xử với “mã nguồn mở” như thể nó có “giá trị đạo đức”, trộn lẫn các khái niệm lấy cắp từ phần mềm tự do như thể hai thứ đó là một
Mã nguồn mở chỉ là thứ để các công ty phần mềm khổng lồ lấy từ vô số tình nguyện viên mà thôi
Đám người theo hành xử chuẩn mực chỉ tồn tại để gây chuyện
Chỉ cần nhìn vào các cuộc tranh cãi nút đỏ/nút xanh là thấy, kiểu độc miệng dữ dội đó chỉ có ý nghĩa khi cái nút thật sự tồn tại hoặc khi người ta thích cư xử tồi tệ
Những người ủng hộ quy tắc ứng xử với thiện chí đang nói về quyền tự do lập hội và tự do ngôn luận
Vấn đề là nếu nền tảng ghét ai đó thì có được cấm họ không, hay chỉ nên xử lý bằng tập quán thực dụng kiểu “hãy tử tế” của mailing list
Dĩ nhiên điều này còn tùy ai là người nắm quyền quyết định, nhưng dự án nào cũng vậy thôi
Bạn không thể vừa đòi tham gia vào dự án của người khác bằng cách đưa ra những điều kiện mâu thuẫn với mong muốn của bên lãnh đạo dự án, vừa đòi có quyền tự do lập hội
Tôi đoán ý tác giả khi nói “không cần một Code of Conduct phô trương” có thể là: nếu là dự án nhỏ chỉ muốn chia sẻ với thế giới và để ngỏ khả năng nhận đóng góp bên ngoài về sau, thì không cần phải dựng sẵn quy tắc ứng xử trước khi thực sự gặp tình huống đó
Không cần vò đầu bứt tai vì một vấn đề hoàn toàn giả định
Lý do tồn tại của quy tắc ứng xử là vì lựa chọn thay thế chỉ có thể là trừng phạt tùy tiện đối với vi phạm tùy tiện, hoặc một trạng thái vô chính phủ ngập spam hoàn toàn
Tôi không hiểu sao những người từng rao giảng netiquette giờ lại phản đối sự rõ ràng và một cộng đồng lành mạnh đến vậy
Nghĩ lại thì có thể đây là Goomba fallacy, và những người khinh thường quy tắc ứng xử có lẽ chính là những người ngày xưa liên tục gây flame war và spam trên Usenet thập niên 1990
Mã nguồn mở không chỉ là một lựa chọn giấy phép đơn thuần
Nó là phần mềm tự do được tái đóng khung để trông hấp dẫn hơn với doanh nghiệp, và cốt lõi của mã nguồn mở là việc các công ty phát triển phần mềm bằng cách hợp tác với công chúng hiệu quả hơn là phát triển kín
Vì vậy mã nguồn mở hàm ý một cộng đồng mở
Dĩ nhiên bạn có thể tung mã ra cho công chúng theo giấy phép dễ dãi mà không muốn phát triển cộng tác, và mã đó vẫn là mã nguồn mở
Việc mở mã là điều tốt và bạn không có nghĩa vụ phải làm hơn thế, nhưng đó không phải là làm theo đúng mục đích mà mã nguồn mở được thiết kế, và là bỏ qua một phần cốt lõi của nó
Những người nhìn vào mã nguồn mở rồi cho rằng đang có phát triển cộng tác không phải là vô lý
Vì đó chính là mục đích của phong trào mã nguồn mở
Phần mềm của bạn có thể không phù hợp với giả định đó, không sao cả, nhưng người phá vỡ chuẩn mực xã hội không phải họ mà là bạn
Tôi nghĩ đến Stallman, driver máy in, và việc người dùng sở hữu công việc của chính mình, nên những khẳng định dứt khoát như vậy về mục đích của mã nguồn mở nghe không đúng lắm
https://en.wikipedia.org/wiki/The_Open_Source_Definition
Trong đó không hề nói gì về phát triển cộng tác
Mọi người trở nên cảm tính, và thường muốn chăm sóc những người dùng mới không muốn học những điều cơ bản, hay người dùng nói chung
Tốt hơn là giữ mối quan hệ tách biệt với diễn đàn hỗ trợ nhưng nghiêm khắc, trả lời đúng lúc nhưng thờ ơ
coreboot hay MrChromebox là ví dụ tốt, anh ấy chỉ trả lời khi cần
Tôi đồng ý, và xin bổ sung rằng cũng không cần làm một trang marketing để thuyết phục mọi người dùng phần mềm của bạn
Thay vào đó, hoặc làm song song, cũng hay nếu giải thích mọi lý do vì sao không nên dùng phần mềm này
Càng nhiều người dùng thì càng nhiều vấn đề
Ứng dụng FOSS không nhất thiết phải được phát hành công khai, đó chỉ là kỳ vọng xã hội phổ biến mà thôi
FOSS cũng không có nghĩa là mã phải được cung cấp cho những người không phải khách hàng, và ai là khách hàng thì do nhà phát triển quyết định
FOSS khuyến khích việc bán lấy tiền, và bạn thậm chí có thể bán phần mềm của người khác vốn ban đầu miễn phí (xem https://www.gnu.org/philosophy/selling.en.html)
Mã nguồn mở gắn giấy phép không tự do vẫn là mã nguồn mở nhưng không phải FOSS, và nhà phát triển không cần phải thấy xấu hổ khi chọn giấy phép mã nguồn mở không tự do nếu muốn kiếm nhiều tiền hơn từ phần mềm hoặc áp thêm các hạn chế có lợi cho mình
Nó cũng có thể là copyleft
Tóm lại, chúng ta tạo LICENSE.md và phụ thuộc rất nhiều vào nó, nhưng chưa ai nghĩ đến việc tạo SOCIAL.md
Khi ai đó nói “mã nguồn mở”, nhiều người mặc định rằng “tác giả đang làm điều này vì con người, vì xã hội, vì mọi thứ xung quanh, và quan tâm đến việc phát triển dự án, thêm tính năng mới, đặc biệt là các tính năng tôi cần, cũng như cải thiện vì lợi ích của mọi người dùng. Nếu không thì tại sao lại công khai?”
Nhưng đó chỉ là kỳ vọng xã hội phổ biến nhất về FOSS, chứ còn lâu mới là trường hợp duy nhất
Việc thiếu sự phân biệt giữa mã nguồn mở theo nghĩa kỹ thuật và mã nguồn mở theo nghĩa xã hội là nguyên nhân chính của bất đồng, tranh cãi, và cuối cùng là kiệt sức xuất phát từ những kỳ vọng xã hội lệch nhau
Trước đây tôi phải giải thích vấn đề này và sự khác biệt đó cho một đám đông giận dữ, nhưng gần đây tôi thấy trong bài viết của Jeffrey Paul https://sneak.berlin/20250720/the-agpl-is-nonfree/ phép so sánh mã nguồn mở với quà tặng
Cách giải thích của tôi cuối cùng là: “nếu bạn không thích món quà đó hoặc nó không phù hợp, hãy vứt nó đi và quên nó đi”
Chỉ có một vài giấy phép được OSI phê duyệt nhưng không được coi là phần mềm tự do
Chỉ cần xem danh sách dài các giấy phép phần mềm tự do không tương thích GPL tại https://www.gnu.org/licenses/license-list.html
Hơn nữa, “mã nguồn mở không phải FOSS” là vô nghĩa, vì FOSS theo nghĩa đen là Free and Open Source Software
Giờ đây gần như lên GitHub ngay lập tức kèm theo file thực thi để ai cũng dùng được, không cần đi qua website mờ ám hay pipeline build kỳ quặc nào nữa
Không có “cộng đồng”, không có chính trị, không có quy tắc ứng xử, không có pull request hay issue, không có wiki, không có nhóm nòng cốt, nghe như thiên đường
Dạo này tôi thấy có quá nhiều cộng đồng gây hại cho chính dự án
Thậm chí tôi không thể nhớ nổi dù chỉ một lần cộng đồng từng giúp ích cho dự án mã nguồn mở theo bất kỳ cách nào
Nếu mục tiêu là tối đa hóa quyền kiểm soát bằng cách hy sinh chất lượng thì cũng được thôi
Chỉ là trong trường hợp đó, tôi nghi ngờ liệu bạn có thật sự đang tìm FLOSS hay không