1 điểm bởi GN⁺ 2026-01-16 | 1 bình luận | Chia sẻ qua WhatsApp
  • sự phụ thuộc vào mã nguồn mở đã trở thành cốt lõi trong vận hành doanh nghiệp, thói quen xem đó là thứ hiển nhiên được dùng miễn phí đang bị chỉ trích
  • Cấu trúc hiện tại phụ thuộc vào quyên góp hoặc tài trợ không bền vững, và cần một phương thức huy động vốn mới
  • Cách làm được đề xuất là GitHub thu thêm 1 USD mỗi tháng cho mỗi người dùng và tích lũy khoản này vào quỹ mã nguồn mở để phân bổ theo mức sử dụng
  • Việc phân bổ dựa trên các dự án được nhắc đến trong package.json hoặc requirements.txt, và được nêu là có cấu trúc tương tự mô hình chia sẻ doanh thu của Spotify
  • Trong bối cảnh mã nguồn mở đang nâng đỡ hạ tầng trên toàn thế giới, bài viết nhấn mạnh sự cần thiết của một cơ chế đền bù bền vững

Nêu vấn đề về sự phụ thuộc miễn phí vào mã nguồn mở

  • Chỉ ra rằng nhận thức coi mã nguồn mở là miễn phí “như bia miễn phí” là không bình thường
    • Đằng sau mã nguồn là lao động thực sự, và cách nhìn đó chỉ như sở thích hay đóng góp tự nguyện đơn thuần là một tiền đề sai lầm
  • Hệ sinh thái mã nguồn mở hiện nay đang phụ thuộc vào quyên góp hoặc tài trợ, và đây là một cấu trúc thiếu ổn định
    • Các nhà phát triển phải tiếp tục xin tài trợ như thể đang đi van nài để được chú ý
    • Một số dự án đang đối mặt với thực tế khó duy trì sinh kế và phải tìm “lifeline”

Đề xuất một cách huy động vốn mới thông qua GitHub

  • Đưa ra phương án GitHub thu thêm 1 USD mỗi tháng cho mỗi người dùng từ tất cả tổ chức và tích lũy khoản này vào Quỹ Mã Nguồn Mở (Open Source Fund)
    • Quỹ sẽ được giữ dưới dạng escrow để quản lý minh bạch
  • Số tiền tích lũy sẽ được phân bổ dựa trên mức sử dụng, tức là phân chia theo mức độ mỗi dự án được nhắc tới trong package.json hoặc requirements.txt
    • Cũng có thể bao gồm cả lệnh FROM trong Dockerfile
  • Mô hình này được mô tả là tương tự cách Spotify phân chia doanh thu cho nghệ sĩ
    • Dù mô hình của Spotify không hoàn hảo, ít nhất nó vẫn là một hệ thống phân bổ có cấu trúc tối thiểu để tham khảo

Cách triển khai và cấu trúc tham gia

  • Quỹ được vận hành theo hình thức tham gia mặc định (opt-out)
    • Các tổ chức có thể rút khỏi chương trình nếu không muốn tham gia
  • Các tổ chức tham gia có thể nhận những lợi ích mang tính biểu tượng như “huy hiệu ma thuật” hoặc quyền thiết lập CSS nền hồ sơ
  • Người đề xuất nói rằng: “Ý tưởng này còn dang dở và lỏng lẻo, nhưng không thể nói tình trạng hiện tại là ‘ổn’ được”

Mối quan tâm về tính bền vững của mã nguồn mở

  • Trong cấu trúc hiện tại, mã nguồn và công sức đang nâng đỡ hạ tầng cốt lõi của toàn thế giới đang bị sử dụng mà không có bất kỳ đền bù nào
  • Bài viết nhấn mạnh sự cần thiết của một cấu trúc tuần hoàn tài chính mới để duy trì mã nguồn mở
  • Cũng nêu quan điểm rằng “không rõ sẽ đưa các dự án lớn như Linux vào thế nào, nhưng phải bắt đầu từ đâu đó”

Kết luận

  • Người đề xuất kỳ vọng những người thông minh hơn mình có thể phát triển thêm các phương án cụ thể
  • Thông điệp cốt lõi là “cấu trúc tài chính cho mã nguồn mở hiện nay không bền vững và cần thay đổi”

1 bình luận

 
GN⁺ 2026-01-16
Ý kiến trên Hacker News
  • Tôi là người thích đóng góp mã nguồn mở không công
    Sẽ càng vui hơn nếu người khác cũng thích những gì tôi làm
    Tôi không nghĩ thái độ kỳ vọng được trả công cho mọi dòng code là điều phổ quát
    Nếu làm mã nguồn mở mà lại mong chờ đền đáp, thì ngay từ cách tiếp cận đã sai rồi
    Nhưng nếu bạn đang phụ thuộc vào công sức của ai đó, thì vẫn cần có sự quan tâm mang tính cộng đồng

    • Tôi nghĩ những người bỏ qua góc nhìn này cũng là kiểu người xem UBI (thu nhập cơ bản phổ quát) hay lưới an sinh xã hội là thứ “làm giảm động lực”
      Nhiều người sáng tạo và biết quan tâm đến người khác được thúc đẩy không phải bởi tiền, mà bởi niềm vui thuần túy của việc sáng tạo
      Nếu sinh kế cơ bản được đảm bảo, thế giới sẽ có nhiều nghệ thuật, cộng đồng và mã nguồn mở hơn rất nhiều
    • Tôi đồng ý rằng bạn nói đúng
      Điều tôi muốn nói là không nên coi loại lao động này như món quà từ trên trời rơi xuống
      Khi dự án phát triển lớn hơn thì trách nhiệm cũng tăng theo, và việc toàn bộ gánh nặng dồn lên một người là không công bằng
      Giống như vụ backdoor xz hay PocketBase FAQ, cần có sự hỗ trợ ở cấp độ hệ thống
    • Tôi cũng thích mã nguồn mở, nhưng đến một lúc nào đó code của tôi lại trở thành hạ tầng cốt lõi
      Trong tình huống như vậy, rất thiếu một mô hình chuyển đổi từ “việc làm cho vui” sang “trách nhiệm ở mức công việc”
      Vì lý do đó mà nhiều maintainer bị burnout
    • Tôi làm mã nguồn mở vì niềm vui được học hỏi và sáng tạo
      Dự án GitHub của tôi giống như một hòn đảo riêng
      Tôi vui khi có PR, nhưng đôi khi cũng có cảm giác như người khác đang tô thêm lên bức tranh của mình
      Tôi không mong được trả công, chỉ cần mọi người cứ tự do fork theo giấy phép của tôi là được
      Với những người sáng tạo như chúng tôi, đừng can thiệp và hãy cho chúng tôi tự do là sự tôn trọng lớn nhất
    • Tôi cũng làm mã nguồn mở vì lý do tương tự
      Đó là món quà tôi dành cho thế giới
      Tất nhiên nếu có chút đền đáp thì cũng tốt, nhưng nếu đi kèm nghĩa vụ hay điều kiện thì tôi vẫn thích cách tự do hiện tại hơn
  • Mã nguồn mở về bản chất là món quà tự nguyện
    Đổi lại, người làm chỉ nhận được một chút danh tiếng hoặc cảm giác thỏa mãn

    • Vấn đề là gánh nặng bảo trì
      Nhiều công ty đang đẩy việc sửa lỗi hay xử lý vấn đề bảo mật sang cho maintainer
      Cấu trúc như vậy là không bền vững, và cuối cùng sẽ dẫn đến burnout cùng những thư viện bị bỏ hoang
      Nếu doanh nghiệp thiếu tài nguyên hay chuyên môn, họ nên đền đáp bằng tài trợ
    • Có ý kiến cho rằng thật mệt mỏi khi cứ chỉ trích những người đang sử dụng đúng theo điều kiện giấy phép
    • Có người cho rằng đòi tiền cho thứ đã cho miễn phí thì vô lý
    • Lời giải tự nhiên cho vấn đề này là các chương trình trợ cấp công hoặc tư
      Cần có một cơ chế trả công xứng đáng cho những người đang duy trì hạ tầng cốt lõi
  • Lời giải cho bài toán tài chính của mã nguồn mở không phải là bắt buộc thanh toán
    Cấu trúc như vậy đi ngược lại tinh thần mã nguồn mở
    Maintainer và người dùng không có nghĩa vụ gì với nhau
    Nếu không thích thì cứ gửi PR hoặc fork
    Mã nguồn mở không phải phần mềm thương mại mà là không gian chia sẻ tự do

    • Nhưng việc quyết định ai sẽ nhận tiền cũng là một vấn đề
      Nếu dựa theo độ phổ biến, phần lớn tiền sẽ chảy vào JavaScript
    • Thực ra ý nghĩa gốc của mã nguồn mở không phải là “miễn phí” mà là tự do sửa đổi và truy cập
      Tức là nó gần với “tự do ngôn luận” hơn là “bia miễn phí”
  • Giả định đứng sau đề xuất này rằng “FOSS chủ yếu là sản phẩm của tình nguyện viên” là sai
    Nhiều phần mềm nguồn mở tôi dùng là do các tập đoàn lớn tạo ra
    Ví dụ React là của Meta, TypeScript là của Microsoft, còn Chrome là của Google

    • Nhưng Chrome cũng không phải FOSS hoàn toàn
      Google Chrome là trình duyệt thương mại dựa trên Chromium
      Chromium được fork từ WebKit (Apple), còn WebKit lại được fork từ KHTML của KDE
    • Hơn nữa Chrome còn phụ thuộc vào cả mã không phải của Google như libxml2
      Gần đây maintainer của libxml2 từ chức, khiến cấu trúc phụ thuộc kiểu này lại được chú ý
  • Nếu đã phát hành theo giấy phép mã nguồn mở, thì không cần ngạc nhiên khi mọi người dùng miễn phí
    Nếu muốn kiếm doanh thu thì lẽ ra nên chọn giấy phép khác

    • Nếu không thích việc doanh nghiệp thương mại hóa theo cách không tương thích với FOSS thì lẽ ra nên dùng GPL
    • Giấy phép là do chủ sở hữu bản quyền quyết định
      Cũng có nhiều lựa chọn như dual license hoặc copyleft để yêu cầu đền bù cho việc sử dụng thương mại
  • Đề xuất phân phối tiền cho mã nguồn mở theo mức độ sử dụng là không hiệu quả
    Nhiều lượt tải xuống không có nghĩa là giá trị hay công sức bảo trì lớn
    Tôi cũng có một gói npm đạt hàng chục triệu lượt tải, nhưng nó đã hoàn thiện rồi và hầu như không cần động tới
    Rất khó tồn tại một thuật toán vừa đáp ứng được chống gian lận lẫn hiệu quả

  • Nếu có cơ chế như vậy thì spam code do AI tạo ra sẽ bùng nổ
    Điều tương tự đã từng xảy ra trong vụ lừa đảo nhạc AI trên Spotify

    • Thực tế, vấn đề spam kiểu này cũng đã xuất hiện ở Tea.xyz
    • Hơn nữa, cũng có lời đồn rằng bản thân Spotify đang tạo ra nhạc AI
  • Tôi đã sống nhờ trợ cấp và tiền tài trợ trong vài năm nay
    Nền tảng tài trợ cho mã nguồn mở đã có rất nhiều, vấn đề không nằm ở nền tảng mà là thái độ của lập trình viên
    Nếu muốn được trả tiền thì phải nói rõ điều đó
    Phần lớn đều giấu link tài trợ sâu trong FAQ
    Nhưng nếu trực tiếp lên tiếng, đáng ngạc nhiên là mọi người lại sẵn sàng cho tiền
    Streamer trên Twitch còn kiếm được tiền, thì không có lý do gì những người làm phần mềm hữu ích như chúng ta lại không thể
    Nếu là người dùng doanh nghiệp, cách hiệu quả là chủ động liên hệ để đề xuất tài trợ

    • Ví dụ, Krita đã tăng quy mô nhóm từ 2 lên 4 người nhờ bán có phí trên Steam và Windows Store
      Liên kết liên quan
  • Nếu có cơ chế này thì spam dependency vô nghĩa sẽ tăng lên
    Đã có một số lập trình viên cố nhét những package vô dụng vào PR để tăng lượt tải xuống
    Vì số lượt tải cao được dùng như chỉ số năng lực trong hồ sơ

    • Nếu cấu trúc như vậy xuất hiện, maintainer sẽ phải chú ý hơn nữa đến việc giám sát spam dependency
  • Nếu muốn làm sản phẩm thì cứ làm sản phẩm rồi bán
    Nó nổi tiếng được là vì đã được phát hành miễn phí, nên sau đó quay lại đòi tiền là mâu thuẫn
    Nếu ngay từ đầu là trả phí thì người ta đã tự làm hoặc dùng thứ khác rồi