19 điểm bởi xguru 2024-08-12 | 5 bình luận | Chia sẻ qua WhatsApp
  • COO kiêm đồng sáng lập của chúng tôi, Anne, từng bị kiện khi còn là CEO của công ty thực phẩm Đức Delinero. Lý do là mứt mâm xôi do nhà cung cấp cung cấp được ghi nhãn là "Himbeermarmelade", nhưng tại Đức có Konfitürenverordnung (quy định về mứt), theo đó chỉ những sản phẩm có ít nhất 20% trái cây họ cam quýt mới được ghi là "marmelade"
  • Đây là một quy định đi ngược với ý nghĩa thường dùng của từ ngữ, nhưng vì đó là luật do một nhóm nhỏ bên liên quan tạo ra từ lâu nên vẫn buộc phải tuân theo
  • "Open source" hiện nay cũng có thể được xem là đang ở trong trạng thái tương tự. OSI, giống như Konfitürenverordnung, vẫn đang kiểm soát nghiêm ngặt một thuật ngữ đã phát triển khác với cách dùng phổ biến
  • Nhưng làm thế nào để tiến lên theo hướng mang tính xây dựng hơn?

Cách không làm "open source"

  • Khi GitButler phát hành mã phía client theo mô hình "Fair Sourcing" với một giấy phép không được OSI phê duyệt, chúng tôi đã cân nhắc rất nhiều về cách công bố
  • Phần lớn mọi người đồng nhất "open source" với "được công khai trên GitHub", đồng thời vì hàm ý phần nào rủi ro của các giấy phép GPL/copyleft, mọi người cũng đã rất quen với việc kiểm tra giấy phép áp dụng là gì
  • Dù vậy, chúng tôi không muốn dùng những cách nói mơ hồ như "Source Available'd", và để tránh gây nhầm lẫn, chúng tôi đã dùng từ "open" nhưng lại bị công kích
  • Từ đó chúng tôi nhận ra có một số ít người rất ồn ào đang cố gắng bảo vệ và quy định chặt chẽ thuật ngữ này
  • "Open source" không phải là phủ định logic của "closed source". Có một khoảng cách giữa cách hiểu phổ biến là công khai trên GitHub và có sự tham gia, với định nghĩa kỹ thuật gồm 10 tiêu chí về "open source" do OSI tự điều tiết

Lược sử ngắn về mã nguồn mở

  • Trong thời kỳ đầu của ngành máy tính những năm 1950-60, phần mềm gắn liền với phần cứng nên không cần tách biệt riêng, và các công ty phần cứng đã tự do phân phối nó
  • Sang thập niên 1970-80, khi phần cứng trở thành hàng hóa phổ thông, phần mềm bắt đầu có giá trị riêng, và các tập đoàn lớn như IBM, AT&T bắt đầu hạn chế quyền truy cập vào mã nguồn mà họ đã bỏ chi phí phát triển
  • Để đáp lại, Richard Stallman và những người khác bắt đầu tạo ra hệ điều hành và công cụ riêng được bảo vệ khỏi lợi ích doanh nghiệp, đồng thời dùng các giấy phép có tính tương hỗ như GPL để buộc IBM, AT&T nếu dùng thành quả đó thì cũng phải biến phần mềm của họ thành phần mềm tự do

    "Nếu chúng tôi không được chơi với đồ chơi của các bạn, thì các bạn cũng không được chơi với đồ chơi của chúng tôi."

    • Họ gọi phong trào này là "phần mềm tự do" và đã tạo ra nhiều công cụ tuyệt vời như Emacs và hệ thống trình biên dịch GNU. Đây vẫn là các công cụ nền tảng của phần lớn nền điện toán hiện đại ngày nay
    • Trọng tâm cốt lõi của phong trào phần mềm tự do là bảo đảm quyền tự do cho người dùng trong việc chạy, sao chép, phân phối, nghiên cứu, thay đổi và cải tiến phần mềm. Đó là những quyền tự do đã bị các lợi ích doanh nghiệp xung quanh họ tước đi vào thời điểm đó
  • Đầu những năm 1990, với kernel Linux của Linus Torvalds, một hệ điều hành hoàn chỉnh đã hình thành, và hệ sinh thái phần mềm tự do như stack LAMP phát triển mạnh, đến mức các doanh nghiệp cũng bắt đầu sử dụng và phụ thuộc vào nó
  • Năm 1997, Eric Raymond công bố bài tiểu luận "The Cathedral and the Bazaar", lập luận rằng mô hình phát triển phần mềm tự do ưu việt hơn mô hình đóng, và bài viết này đã được trích dẫn để biện minh cho quyết định mở mã nguồn của Netscape Navigator Suite
    • Khi Netscape quyết định công khai mã nguồn, tại một phiên họp chiến lược ở Palo Alto, Raymond cùng một số nhà phát triển Linux và phần mềm tự do nổi bật đã thống nhất tạo và sử dụng thuật ngữ mới là "open source"

    "Những người tham dự cuộc họp tin rằng các lý do thực dụng và mang tính kinh doanh đã thúc đẩy Netscape công khai mã nguồn là một cách có giá trị để giao tiếp với những người dùng và nhà phát triển phần mềm tiềm năng, cũng như thuyết phục họ tham gia cộng đồng để xây dựng và cải thiện mã nguồn. Những người tham dự cũng tin rằng sẽ rất hữu ích nếu có một nhãn duy nhất để nhận diện cách tiếp cận này và phân biệt nó với nhãn “phần mềm tự do”, vốn tập trung hơn vào triết học và chính trị."

  • Điều quan trọng là giữa "phần mềm tự do" và "open source" không có khác biệt thực chất nào về pháp lý hay thực tiễn
    • Phần lớn giấy phép đều tương thích và được công nhận theo cả hai định nghĩa
    • "Open source" chỉ đơn thuần là một cách tái định vị thân thiện hơn với doanh nghiệp, nhằm tách các mục tiêu chính trị của Stallman và phong trào của ông ra khỏi tính thực dụng của việc mở phần mềm, để nhiều công ty như Netscape chấp nhận việc công khai mã nguồn chuyên nghiệp hơn
  • Hoặc như phía phong trào phần mềm tự do từng nói

    "Open source là một phương pháp phát triển, còn phần mềm tự do là một phong trào xã hội."

Mã nguồn mở và thời đại GitHub

  • Cụm từ "open source" được định nghĩa và tiếp thị vào năm 1998, tức là cách đây hơn 25 năm. Vậy trong 25 năm qua của ngành điện toán, điều gì đã xảy ra với mã nguồn mở và phát triển phần mềm?
  • Đặc biệt trong 10 năm gần đây, GitHub và phong cách phát triển phần mềm kiểu GitHub đã có tác động cực lớn đến mã nguồn mở
  • Năm 1998, người ta còn đang cố thuyết phục doanh nghiệp chấp nhận phần mềm mở, còn hiện nay gần như toàn bộ phần mềm mã nguồn mở đều do doanh nghiệp viết hoặc tài trợ
  • Một trong những thay đổi lớn nhất là "sự chuẩn hóa quy trình phát triển", đặc biệt do GitHub dẫn dắt
  • Trước đây có khác biệt lớn giữa các dự án phần mềm mở và các dự án doanh nghiệp, nhưng giờ gần như không còn khác biệt
    • Ai cũng dùng Git
    • Gần như mọi người đều dùng pull request (hoặc merge request, hoặc các cách khác sao chép lại cơ chế này)
    • Hầu hết các đội dùng một dạng nào đó của GitHub Flow (trunk-based development, GitLab Flow, v.v.)
  • Giờ đây điểm khác biệt duy nhất chỉ là kho mã có công khai hay không. Cách đây 25 năm quy trình còn đầy ma sát, nhưng bây giờ việc mở mã gần như không cần thay đổi quy trình gì

Bước tiếp theo của mã nguồn mở là gì

  • Khi gần như mọi doanh nghiệp đều dùng và tạo ra phần mềm mã nguồn mở, có phải phong trào mã nguồn mở (phần mềm tự do) đã thành công không?
  • Hiện tại thế giới mã nguồn mở có hai vấn đề lớn: "tính bền vững của lập trình viên" và "liệu mã nguồn mở thương mại có khả thi hay không"

Vấn đề tính bền vững của lập trình viên

  • Khi mức độ phụ thuộc vào mã nguồn mở tăng mạnh, các vấn đề về tính bền vững và bảo trì cũng nổi lên. Vụ khai thác backdoor trong XZ Utils là một ví dụ nổi tiếng gần đây
  • Gần như mọi maintainer đều đang vật lộn với kiệt sức và quấy rối. Việc kiếm sống bằng cách viết và duy trì phần mềm mã nguồn mở gần như là không thể
  • Phần lớn lập trình viên và maintainer mã nguồn mở hiện nay được các tập đoàn lớn tài trợ
    • Nếu nhìn vào Linux, Git, Ruby, React, v.v., phần lớn contributor của các dự án mã nguồn mở quan trọng đều được tuyển dụng chuyên nghiệp bởi các nhà tài trợ doanh nghiệp như GitHub, Microsoft, Red Hat
  • Một lập trình viên rất khó có thể duy trì các dự án như XZ Utils mà vẫn có được sinh kế tử tế
    • Lý tưởng nhất là thay vì một công ty trả tiền cho lập trình viên, hàng nghìn công ty sẽ mỗi bên trả một khoản nhỏ cho các maintainer chuyên nghiệp
  • Vấn đề lớn là hiện chưa có cách tốt để làm điều này
    • Có những sáng kiến đầy hứa hẹn như GitHub Sponsors, Thanks.dev, Liberapay, Tidelift, nhưng vẫn chưa giải quyết được bài toán về động lực phù hợp để doanh nghiệp đóng góp
  • Sentry đã và đang thúc đẩy một sáng kiến mới tên là OSS Pledge, và GitButler dự định sẽ tham gia khi ra mắt vào tháng 10
  • Tuy nhiên, vẫn chưa rõ liệu những cách tiếp cận như vậy có thể giải quyết được vấn đề lớn và ngày càng gia tăng về tính bền vững của lập trình viên trong hệ sinh thái mã nguồn mở hay không

Vấn đề của mã nguồn mở thương mại

  • Các lập trình viên từ lâu đã lớn lên cùng tình yêu dành cho mã nguồn mở và cộng đồng mở, nên khi bắt đầu công ty hay dự án, họ mặc định muốn làm theo hướng mở
    • Nhưng cũng giống như các maintainer cá nhân, mã nguồn mở ở cấp doanh nghiệp cũng có bài toán bền vững
  • Như các trường hợp của Elasticsearch và Redis cho thấy, khi đầu tư thời gian và tiền bạc để phát triển phần mềm một cách chuyên nghiệp, luôn có rủi ro rằng các tập đoàn lớn như Amazon sẽ lấy thành quả đó để cạnh tranh trực tiếp với chính bạn
  • Nhiều nhà sáng tạo chuyên nghiệp muốn đầu tư vào phần mềm mà vẫn bảo đảm sau này nó sẽ không bị dùng theo cách bất lợi cho họ
    • Điều đó đồng nghĩa với việc phải sáng tạo hơn trong cấp phép hoặc đóng mã nguồn lại
  • Tôi tin rằng phong trào Fair Source là một giải pháp xuất sắc và cần thiết cho vấn đề đang gia tăng này, đồng thời lấp khoảng trống trong hệ sinh thái mã nguồn mở vốn đã gây ra ngày càng nhiều vấn đề và nhầm lẫn trong vài năm qua
    • Đây là một thuật ngữ mới chỉ các dự án chuyên nghiệp phần lớn theo hướng permissive, có thể truy cập mã nguồn và có sự tham gia của cộng đồng GitHub; tôi cho rằng đây là giải pháp rất cần thiết để khuyến khích nhiều dự án trước đây được phát triển kín nay chuyển sang công khai hơn

Tương lai của hợp tác

  • Tương lai của mã nguồn mở không chỉ đơn thuần là "Open Source" và 10 điều lệ kiểu Konfitürenverordnung của OSI
  • Đó là sự kết hợp giữa Open Source khả thi và có giá trị cho mọi người, Fair Source cần thiết cho các khoản đầu tư an toàn, và nguồn tài trợ chung quy mô lớn cho các thư viện mở nền tảng cùng các dự án quan trọng
  • Chúng ta cần làm cho việc duy trì các thư viện mã nguồn mở quan trọng trở nên bền vững, đồng thời chấp nhận và bình thường hóa một lớp giấy phép thương mại bền vững nhưng vẫn cho phép truy cập mã nguồn
  • Cần mã nguồn mở hóa mọi thứ có thể bằng các giấy phép OSI theo hướng cho phép tối đa, và trên hết là biến closed source thành chuyện của quá khứ
  • Những gì bạn có thể làm ngay bây giờ là
    • biến phần mềm đóng của mình thành Fair Source và
    • nếu bạn phụ thuộc vào mã nguồn mở, hãy tham gia OSS Pledge

5 bình luận

 
bus710 2024-08-13

Sống trong một thế giới tư bản, thực tế là không thể chỉ tập trung duy nhất vào mã nguồn mở. Mặt khác, tôi cũng nghĩ rằng nếu đó là những thư viện hay tiện ích thực sự quan trọng thì sẽ tốt hơn nếu nhận được nhiều tài trợ hơn từ các doanh nghiệp.

Các tiện ích desktop/terminal trong không gian người dùng đặc biệt khó nhận được kiểu hỗ trợ này. Nếu là kernel thì các tập đoàn lớn hỗ trợ rất nhiều, nếu là mobile thì App Store đã được thương mại hóa rất tốt, còn web hay firmware thì thường được phát triển sau khi đã phân tích thị trường ở một mức độ nào đó nên bớt đáng lo hơn. Nhưng với những phần mềm và thư viện mà người dùng phổ thông âm thầm sử dụng, việc đặt ra ngưỡng tiếp cận vốn cũng không dễ, nên có lẽ thực sự rất khó để kiếm tiền. Mã nguồn mở tuy khá sôi động nhưng cũng không dễ để vươn lên vượt xa hơn thế.

 
bus710 2024-08-13

Vì tôi yêu mã nguồn mở và thường xuyên sử dụng nó, nên tôi cũng mong những người âm thầm tận tâm phát triển vì số đông ở những nơi không ai thấy được hưởng lợi nhờ việc thiết lập giấy phép phù hợp.

 
chabulhwi 2024-08-13

Trong bài viết của Drew Devault, "So you want to compete with or replace open source (Vậy là bạn muốn cạnh tranh với hoặc thay thế mã nguồn mở?)", có đoạn sau.

From https://drewdevault.com/2024/07/…:

Nevertheless, the revolutionary economics of FOSS are based on collaboration, and are incompatible with competition.

Phần mềm tự do và mã nguồn mở tạo ra lợi ích chung khi những người đóng góp thuộc các tổ chức khác nhau cùng hợp tác, nhưng với fair source software, những người đóng góp khác hầu như không có hoặc không có lý do gì để hợp tác miễn phí vì một cá nhân hay tổ chức đang hưởng vị thế độc quyền.

Dù sao thì tôi cũng nghĩ fair source tốt hơn closed source, và tôi cũng không muốn người duy trì phần mềm mã nguồn mở lại không thể nhận được đền đáp cho công sức của mình dù họ muốn như vậy.

Tuy nhiên, tôi nghi ngờ rằng fair source có thể hưởng lợi từ các đóng góp phát triển miễn phí như mã nguồn mở hay không. Và khi ai đó phát hành phần mềm của mình dưới dạng mã nguồn mở, họ nên ghi nhớ rằng mình sẽ không nhận được bồi thường tài chính từ bất kỳ người dùng nào, và phần mềm đó có thể trở thành "bữa trưa miễn phí" cho các ông lớn cloud.