1 điểm bởi GN⁺ 2023-08-06 | 1 bình luận | Chia sẻ qua WhatsApp
  • Việc Red Hat thay đổi điều kiện cung cấp mã nguồn RHEL cần được nhìn trong bối cảnh lịch sử dài của Unix, GNU, Linux và IBM; phía IBM/Red Hat cho rằng họ vẫn tuân thủ nguyên tắc của GPL là “cung cấp mã nguồn cho người nhận bản nhị phân”
  • Phần mềm thời kỳ đầu được các nhà nghiên cứu và người dùng tạo ra, chia sẻ theo nhu cầu, nhưng từ thập niên 1980 trở đi, bản quyền và giấy phép được siết chặt, dẫn đến sự phân tách giữa EULA, hợp đồng mã nguồn, giấy phép tự do và GPL
  • GNU và Linux phát triển nhờ mã nguồn mở và đóng góp từ cộng đồng; sau khi IBM công bố đầu tư 1 tỷ USD vào Linux, hãng đã củng cố niềm tin vào hệ sinh thái bằng việc tuyển dụng lập trình viên và đối phó với vụ kiện SCO
  • RHEL là sản phẩm máy chủ doanh nghiệp lấy Fedora làm nền tảng thử nghiệm; Red Hat muốn thu hồi chi phí cho hỗ trợ, QA, tài liệu, phát hành và hệ thống hỗ trợ toàn cầu thông qua giấy phép khách hàng
  • Người dùng bản sao RHEL có thể chọn bản phân phối Linux khác, nhưng với các nhà làm bản sao, việc xây dựng một bản phân phối cạnh tranh với RHEL sẽ hiệu quả hơn là chỉ sao chép đơn thuần

Quan điểm cơ bản về thay đổi của Red Hat

  • Những thay đổi gần đây trong điều kiện bán hàng của Red Hat đã gây tranh cãi, nhưng cốt lõi là cách cung cấp mã nguồn cho khách hàng đã nhận bản nhị phân RHEL
  • Bản chất của GPL là bảo đảm mã nguồn và khả năng sửa đổi để người nhận bản nhị phân có thể sửa lỗi và mở rộng hệ điều hành
  • IBM/Red Hat cho rằng họ cung cấp mã nguồn và thông tin cần thiết để dựng bản phát hành cho khách hàng theo hợp đồng, đồng thời vẫn tiếp tục gửi các thay đổi trong mã GPL lên upstream
  • Không dễ gom tất cả lợi ích liên quan chỉ bằng từ “cộng đồng”, và những người dùng không cần cùng mức độ kỹ thuật và hỗ trợ như vậy có thể chọn các bản phân phối Linux khác

Từ chia sẻ phần mềm đến kỷ nguyên giấy phép

  • Khoảng năm 1969, việc lập trình chủ yếu do các nhà nghiên cứu, giáo sư và kỹ sư thực hiện để phục vụ công việc riêng, và nghề “lập trình viên chuyên nghiệp” vẫn chưa phổ biến
  • Các nhóm người dùng như DECUS phân phối phần mềm do khách hàng viết với chi phí gần như chỉ là sao chép, và nhiều người dùng công bố mã dưới dạng Public Domain
  • Khi đó, việc áp dụng bản quyền hay bằng sáng chế cho phần mềm còn hạn chế, nên để bảo vệ mã, người ta phải dựa vào bí mật thương mại, luật hợp đồng và phát hành bản nhị phân
  • Đầu thập niên 1980, khi luật bản quyền mạnh hơn được áp lên cả bản nhị phân lẫn mã nguồn, lập trình viên cần có giấy phép để giải thích quyền của người dùng
    • EULA xuất hiện cho người dùng cuối
    • Hợp đồng mã nguồn được áp dụng riêng cho lập trình viên

Nền tảng do Unix, BSD và GNU tạo nên

  • Unix bắt đầu tại Bell Labs năm 1969, rồi lan sang các trường đại học nghiên cứu như UC Berkeley, MIT, Stanford và CMU
  • BSD Unix của UC Berkeley cung cấp demand-paged virtual memory, native TCP/IP và nhiều tiện ích phong phú, trở thành nền tảng cho nhiều nhà cung cấp Unix thời kỳ đầu
    • Các sản phẩm như SunOS, Ultrix và HP/UX đã chọn nền tảng BSD
  • Cuốn chú giải Unix Version 6 của John Lions bị ngăn xuất bản chính thức trong thời gian dài, nhưng các bản sao của nó đã dạy cho vô số lập trình viên Unix về cấu trúc kernel và tư duy thiết kế
  • Giấy phép mã nguồn Unix của AT&T đắt đỏ và nhiều ràng buộc, nên một số công ty chọn các hợp đồng tái phân phối để bán hệ thống Unix-like chỉ ở dạng nhị phân
  • Richard M. Stallman, sau khi tiếp xúc với các bản phân phối Unix chỉ cung cấp bản nhị phân, đã khởi động dự án GNU từ nhận thức rằng người dùng không thể tự thực hiện các sửa đổi cần thiết
    • Mục tiêu của GNU là tạo ra một hệ điều hành tự do trong đó người phát hành bản nhị phân phải bảo đảm mã nguồn và khả năng chỉnh sửa cho người nhận
    • Những phần mềm trực tiếp hữu ích cho lập trình viên như emacs, bộ compiler và các utility được tạo ra trước

Khác biệt giữa giấy phép tự do và GPL

  • Các trường như MIT và UC Berkeley muốn phân phối mã nghiên cứu hơn là bán nó, nhưng sau khi bản quyền được áp dụng, họ cần giấy phép quy định điều kiện sử dụng và giới hạn trách nhiệm
  • Những giấy phép này về sau được gọi là giấy phép tự do trong thế giới mã nguồn mở
    • Lập trình viên có thể tạo bản phân phối chỉ ở dạng nhị phân
    • Không cần công bố cho người dùng cuối các thay đổi ngoài phần mã nguồn ban đầu đã nhận
  • GPL được xem là giấy phép có tính ràng buộc buộc người dùng cuối đã nhận bản nhị phân cũng phải có thể xem các thay đổi
  • Ban đầu đã có nhiều hiểu lầm về GPL
    • Có người nghĩ rằng bản nhị phân được tạo bằng GNU compiler cũng sẽ chịu GPL
    • Cũng có người cho rằng không thể bán mã GPL, nhưng RMS đã bác bỏ điều đó
  • Các công ty như Walnut Creek và Prime Time Freeware for Unix từng bán CD-ROM và DVD gộp nhiều mã nguồn mở khác nhau

Áp lực của thị trường Unix và sự trỗi dậy của Linux

  • Các nhà cung cấp hệ thống như DEC, HP, Sun và IBM đã xây dựng các hệ điều hành Unix-like dựa trên AT&T System V hoặc dòng BSD, và để làm vậy họ tuyển kỹ sư, người viết tài liệu, nhân sự QA và quản lý sản phẩm
  • Để tạo ra một hệ thống Unix-like có sức cạnh tranh, mỗi công ty được cho là phải chi khoảng 1–2 tỷ USD mỗi năm
  • Microsoft bán cùng một hệ điều hành bất kể nhà sản xuất PC nào và gây áp lực lên các hãng Unix khi mở rộng sang thị trường hệ điều hành máy chủ
  • Dự án kernel Linux bắt đầu vào cuối năm 1991 nhờ nhiều điều kiện hội tụ, và đến cuối năm 1993 đã bước vào giai đoạn nhiều bản phân phối cùng phát triển
    • Phần mềm từ GNU, MIT, BSD và các dự án độc lập đã sẵn có
    • Thông tin về bên trong hệ điều hành trên Internet ngày càng nhiều
    • Internet tốc độ cao bắt đầu vào đến hộ gia đình
    • Các bộ xử lý giá rẻ hỗ trợ demand-paged virtual memory trở nên phổ biến
    • Có cả may mắn và thời cơ
    • Có một người lãnh đạo dự án vừa cứng đầu vừa có sức hút
  • Các bản phân phối như Soft Landing Systems, Yggdrasil, Debian, Slackware và Red Hat xuất hiện; một số là bản phân phối thương mại, một số bắt đầu như dự án cộng đồng

Linux và mô hình cộng đồng

  • Một lý do khiến Linux được công chúng chú ý sớm hơn BSD là vì BSD khi đó bị ràng buộc trong vụ kiện “Unix Systems Labs Vs BSDi”
  • GPL tạo ra hiệu ứng động là buộc phân phối mã nguồn kèm bản nhị phân, và vì bất kỳ ai cũng có thể khởi động dự án bản phân phối mà không cần xin phép nên đã xuất hiện hàng trăm bản phân phối
  • X Window System xuất phát từ MIT Project Athena, và Kerberos cũng ra đời từ cùng dự án này
  • Việc phát triển X Window System sau đó chuyển từ MIT và Project Athena sang X Consortium; X Consortium mở cửa năm 1993 và đóng cửa năm 1996
  • OSF được thành lập để chuẩn hóa mã nguồn và API của các hệ Unix, rồi sáp nhập với X/Open năm 1996 để trở thành Open Group
  • Nhiều consortium ban đầu rất dồi dào ngân sách, nhưng rồi rơi vào mô thức các công ty tham gia nghĩ rằng “công ty khác sẽ trả tiền”, dẫn đến cạn vốn

Bài toán bền vững của phát triển FOSS

  • Trong giai đoạn đầu của FOSS, một số ít lập trình viên làm việc đầy nhiệt huyết cho một số ít người dùng và thường không nhận thù lao
  • Khi số người dùng tăng nhanh hơn số lập trình viên, áp lực bảo trì ngày càng lớn
  • Tình trạng thiếu người đặc biệt nổi bật ở các mảng “không hào nhoáng” như QA, release engineering, tài liệu và bản địa hóa
  • Một số lập trình viên cảm thấy khó chịu khi người khác kiếm tiền từ đoạn mã họ đóng góp miễn phí, nhưng cũng có quan điểm cho rằng doanh nghiệp phải kiếm được tiền từ Linux thì Linux mới có thể tiến nhanh
  • Theo thời gian, cộng đồng không chỉ bao gồm người viết mã mà còn cả người làm tài liệu, dịch thuật và truyền thông; về sau số người chỉ dùng gratis software mà không hiểu freedom software cũng tăng lên

Phần mềm lậu và chi phí của phần mềm tự do

  • Phần mềm lậu là hành vi sao chép và sử dụng bất hợp pháp trái với giấy phép
  • Một số thành viên trong cộng đồng FOSS xem nhẹ quyền sở hữu trí tuệ hoặc bản quyền, nhưng nếu không có bản quyền thì quyền kiểm soát phần mềm cũng biến mất
  • Tại một hội nghị ở Brazil, khi có người nói “nên dùng Free Software”, khán giả đáp lại rằng “toàn bộ phần mềm của chúng tôi đều free”
    • Khi đó gần 90% phần mềm desktop ở Brazil là hàng lậu
    • Trong hoàn cảnh đó, một phần lợi thế chi phí thấp của Free Software bị mất đi
  • Theo quan điểm này, nếu mọi người dùng kernel Linux đều trả 1 USD cho mỗi nền tảng phần cứng, thì phần lớn việc phát triển FOSS có thể dễ dàng được hỗ trợ

IBM tham gia Linux

  • Bên trong IBM đã có những người tin vào FOSS và làm dự án trong thời gian riêng; Daniel Frye muốn tập hợp họ thành một tổ chức FOSS nội bộ để thúc đẩy Linux tiến lên
  • Tác giả nhớ rằng Lou Gerstner của IBM từng gửi một lá thư với đại ý trước đây công ty chỉ theo mã nguồn mở khi có lý do kinh doanh, còn trong tương lai sẽ chỉ đi theo mã nguồn đóng khi có lý do kinh doanh
  • IBM vào thời điểm đó công bố sẽ đầu tư 1 tỷ USD vào Linux, tạo ra cú sốc lớn
  • Sau đó IBM tuyển các lập trình viên Linux làm việc toàn thời gian ở nhiều mảng liên quan đến Linux, và cũng trả lương cho lập trình viên trong các lĩnh vực như Apache Web Server
  • Khoảng một năm sau, IBM đã thu hồi khoản đầu tư 1 tỷ USD đầu tiên và tuyên bố sẽ đầu tư thêm 1 tỷ USD nữa
  • IBM bán mảng laptop và desktop cho Lenovo và mua lại Price Waterhouse Cooper, chuyển hướng thành công ty giải pháp kinh doanh
    • Từ đó, các giải pháp kinh doanh không còn nhất thiết bị ràng buộc chỉ với phần cứng và phần mềm của IBM
    • Open Source được xem là yếu tố giúp các nhà cung cấp giải pháp của IBM tạo ra giải pháp tốt hơn với chi phí thấp hơn

Vai trò của IBM trong vụ kiện SCO

  • Santa Cruz Operations từng tạo ra bản phân phối Unix dựa trên mã AT&T, rồi sau đó được bán cho Caldera Group
  • Sau khi đổi tên thành SCO, Caldera theo đuổi chiến lược kiện các nhà cung cấp Linux với cáo buộc Linux chứa mã nguồn AT&T và vi phạm điều kiện cấp phép
  • Phần lớn cộng đồng Linux cho rằng cáo buộc này là sai, và từ kinh nghiệm từng đọc các hợp đồng giữa AT&T và Novell, tác giả cũng khó tin rằng Santa Cruz Operations thực sự sở hữu bản quyền mã AT&T
  • IBM, Novell, Red Hat và các bên khác đều tham gia cuộc chiến pháp lý; cuối cùng, tòa án được tóm lược là đã kết luận SCO chỉ có thể nêu vấn đề về hợp đồng đã chấm dứt với IBM, còn Linux thì không có vấn đề gì
  • Trong quá trình đó, việc Big Blue tham gia cuộc chiến pháp lý đã tạo niềm tin cho các nhà cung cấp và người dùng Linux rằng mọi việc sẽ ổn thỏa

Mô hình kinh doanh của Red Hat và RHEL

  • Red Hat khởi đầu là một công ty nhỏ ở Raleigh mạnh về kỹ thuật nhưng yếu về kinh doanh và marketing; Bob Young gia nhập và giúp định hình chính sách cũng như phương hướng công ty
  • Bob Young từng ví Red Hat sẽ trở thành “Heinz ketchup của Linux”, và Red Hat kiếm tiền bằng mô hình bán dịch vụ
  • Theo thời gian, Red Hat tập trung vào mảng doanh nghiệp lấy RHEL làm trung tâm
    • Desktop chỉ quan trọng như nền tảng phát triển cho RHEL, còn phát triển desktop được giao cho Fedora
    • Fedora đóng vai trò nền tảng thử nghiệm để đưa các ý tưởng mới vào RHEL sau này
  • Khách hàng RHEL là các tổ chức như doanh nghiệp và chính phủ, nơi đòi hỏi tính “mission critical” và “always on”, thường vận hành không phải hàng chục hay hàng trăm mà là hàng nghìn hệ thống
  • Những khách hàng như vậy quan tâm đến các điều kiện dịch vụ như MTTF, MTTR, uptime 99.999% và các điều khoản phạt, đồng thời kỳ vọng hỗ trợ cấp 2, cấp 3 chứ không chỉ hỗ trợ tuyến đầu thông thường
  • Red Hat đầu tư vào hỗ trợ doanh nghiệp, QA, tài liệu, chứng nhận và release engineering, còn khách hàng trả tiền cho những giá trị đó

Công ty full-stack và logic IBM mua Red Hat

  • Việc Oracle mua tài sản trí tuệ của Sun Microsystems được xem là chiến lược full-stack nhằm kiểm soát cả phần cứng, hệ điều hành và ứng dụng
  • Công ty full-stack có thể thay đổi toàn bộ stack để mang lại lợi ích cho ứng dụng, đồng thời kiểm thử toàn stack để tìm ra điểm yếu và sự kém hiệu quả
  • IBM và Apple được xếp vào nhóm công ty full-stack; sản phẩm của họ có thể đắt hơn nhưng nhiều khách hàng nghiêm túc vẫn sẵn sàng trả tiền
  • IBM cần một giải pháp full-stack dựa trên Linux để dùng cho mảng giải pháp kinh doanh, và RHEL của Red Hat có danh tiếng cùng năng lực kỹ thuật của một giải pháp doanh nghiệp

Bản sao RHEL và thay đổi điều kiện của Red Hat

  • Theo thời gian, một số khách hàng hình thành mô hình chỉ mua số ít hệ thống RHEL, còn các hệ thống còn lại thì dùng bản phân phối khác tương thích bug-for-bug với Red Hat
  • Cách làm này giúp giảm chi phí cho khách hàng, nhưng làm Red Hat nhận ít doanh thu hơn dù vẫn phải bỏ ra cùng lượng công việc, khiến công ty chịu áp lực phải tăng giá giấy phép, cắt giảm nhân sự hoặc từ bỏ các dự án khác
  • IBM/Red Hat đã đưa ra quyết định kinh doanh là chỉ phân phối mã nguồn và thông tin build cho những khách hàng mua giấy phép cho tất cả hệ thống đang chạy RHEL
  • Điều kiện này được cho là phù hợp với tinh thần cốt lõi của GPL
    • Người đã nhận bản nhị phân có thể nhận mã nguồn để sửa lỗi và mở rộng
    • Red Hat và IBM vẫn tiếp tục gửi các thay đổi đối với mã GPL lên upstream
    • Việc chia sẻ ý tưởng với cộng đồng rộng lớn hơn vẫn tiếp tục
  • Tác giả không gọi các nhà phát triển bản sao là “freeloader”, nhưng cho rằng những người dùng sử dụng bản sao mà không đóng góp lại cho cộng đồng dưới bất kỳ hình thức nào thì khá gần với freeloading

Đề xuất tạo cạnh tranh thay vì làm bản sao

  • Sau thay đổi của Red Hat, nhiều bản phân phối tuyên bố sẽ tiếp tục làm “not RHEL”, điều này có thể khiến người dùng phổ thông càng bối rối hơn về việc nên dùng bản phân phối nào
  • Quan điểm ở đây là thay vì mỗi bên tạo một bản sao riêng, sẽ tốt hơn nếu cùng nhau làm một bản phân phối tốt, hoặc tạo ra đối thủ thực sự của RHEL
  • Việc SuSE tuyên bố đầu tư 10 triệu USD để tạo đối thủ cạnh tranh với RHEL được đánh giá tích cực
    • Tuy vậy, việc xây dựng cùng kênh kinh doanh, đội hỗ trợ toàn cầu và hệ thống hỗ trợ doanh nghiệp như thế không hề rẻ
    • 10 triệu USD có thể chỉ là điểm khởi đầu
  • Khách hàng RHEL nên lựa chọn dựa trên giá trị hỗ trợ mà Red Hat/IBM và các đối tác kênh cung cấp
  • Nếu IBM không còn muốn làm ăn với kiểu khách hàng chỉ mua một bản RHEL rồi vận hành phần còn lại bằng bản phân phối miễn phí, thì những khách hàng đó nên tìm nhà cung cấp Linux doanh nghiệp khác chấp nhận mô hình này

Kết luận cá nhân

  • Jon “maddog” Hall cho biết ông đã làm việc với mã nguồn mở và việc cung cấp mã nguồn cho khách hàng từ trước cả khi Open Source, Free Software Foundation và dự án GNU ra đời
  • Đóng góp cho cộng đồng không chỉ giới hạn ở viết mã, viết tài liệu hay gửi bug report
    • Có thể quảng bá Free Software tại trường học, doanh nghiệp và cơ quan nhà nước
    • Có thể lập Linux Club hoặc hỗ trợ các hoạt động Upgrade to Linux
  • Doanh nghiệp có thể đặt ra điều kiện kinh doanh miễn là không vi phạm giấy phép, và khách hàng có quyền chấp nhận hoặc từ chối
  • Việc mô tả Red Hat và IBM là “ác” trong khi không nhìn cùng cách đó với các công ty dựa trên giấy phép tự do nhưng không bảo đảm mã nguồn cho người dùng cuối, hoặc chỉ cung cấp giấy phép mã nguồn đóng và không cho phép bản sao, là một thái độ thiếu cân bằng
  • Với các nhà nghiên cứu, sinh viên, người dùng hobby và những người gần như không có tiền, vẫn có hàng trăm bản phân phối Linux hỗ trợ cả những kiến trúc mà RHEL không bao phủ

1 bình luận

 
GN⁺ 2023-08-06
Ý kiến trên Hacker News
  • Từ cuối thập niên 90, tôi đã dùng Red Hat Linux (ban đầu là Caldera Linux, một bản clone của thập niên 90), Fedora, RHEL và các bản clone của nó (Scientific, CentOS, Rocky) cho cá nhân, giáo dục và công việc, đồng thời cũng khuyến nghị chúng cho desktop và server
    Tôi từng nói rằng nếu muốn dùng Linux thì có hai lựa chọn ổn định và được hỗ trợ tốt là Red Hat và Debian, nhưng tôi cho rằng gần đây Red Hat đã chết. RIP
    Giờ tôi không chắc Fedora có tiếp tục là một dự án mã nguồn mở năng động hay không. Nếu IBM hiện đang giết các bản clone RHEL, tại sao phải mạo hiểm tin rằng Fedora sẽ không phải là mục tiêu tiếp theo?
    Tôi biết người ta nói “RHEL phái sinh từ Fedora”, “Fedora là một dự án mã nguồn mở riêng”, nhưng hiện nay RHEL phái sinh từ CentOS Stream. Vậy Fedora cần để làm gì, và tại sao Red Hat phải cung cấp kỹ sư và hạ tầng cho Fedora?
    Đúng là Fedora là dự án riêng, nhưng phần lớn đóng góp đến từ nhân viên Red Hat. Nếu ngày mai IBM quyết định CentOS Stream là đủ và ngừng chi trả chi phí cho Fedora, liệu Fedora có thể tự đứng vững độc lập không?
    Đây có thể chỉ là nỗi sợ hãi, bất định và nghi ngờ (FUD), nhưng tôi không còn tin tưởng bản phân phối Linux thuộc sở hữu IBM nữa. Máy cá nhân của tôi đã chuyển sang Debian, và trong công việc tôi cũng khuyên dùng Debian. Tôi cho rằng một tổ chức tùy biến nhiều bản cài Linux mà lại chọn một bản phân phối dựa trên Red Hat/IBM đầy bất định thay vì một dự án mã nguồn mở hoàn toàn không ràng buộc là vô trách nhiệm. Bị lừa một lần thì lỗi ở người ta, nhưng lần thứ hai là lỗi của mình; tôi sẽ không để IBM chơi mình lần nữa

    • Với câu hỏi “RHEL giờ phái sinh từ CentOS Stream. Vậy cần Fedora để làm gì?”, nếu đã trải qua hệ sinh thái Red Hat đủ lâu thì bạn nên biết rằng mỗi bản phát hành CentOS Stream là một bản phát hành Fedora đã được đóng băng
      Fedora vẫn đóng vai trò bãi thử cho mọi thứ của CentOS, và do đó cho mọi thứ của RHEL. Tôi tò mò không biết có lập luận nào phản đối cách phát triển dùng một “bản phân phối tương lai” như Fedora để mô hình hóa các bản phát hành RHEL về sau
    • Tôi đến với Linux muộn hơn nhiều, qua Ubuntu, nhưng cũng vì những lý do tương tự mà cuối cùng đến với Debian. Debian trông như bản phân phối thuần khiết nhất, nhưng đồng thời cũng rất phổ biến và được hỗ trợ tốt
    • Fedora được dùng trong WSL 2 VM để chạy Podman trên Windows. Ít nhất ở hình thức này, có vẻ nó sẽ còn tồn tại một thời gian
  • Nói cho những ai không theo sát kernel Linux: maddog là một nhân vật huyền thoại
    Góc nhìn của ông rất thú vị và đáng trân trọng, đặc biệt là cách ông đặt vấn đề dựa trên lịch sử. Biết lịch sử thực sự giúp nắm được bối cảnh. Bài gốc dài nhưng đáng đọc

    • Jon Hall trong thập niên 90 về cơ bản đã đóng vai trò như người đại diện của Linus Torvalds. Khi còn ở DEC, ông đã giúp Linus đến đúng nơi, gặp đúng người, để hệ điều hành từng được mô tả là “một sở thích và sẽ không lớn hay chuyên nghiệp” đi vào quỹ đạo như chúng ta biết ngày nay
      Tôi nhỏ hơn Jon Hall khoảng 30 tuổi, nên ngoài những câu chuyện truyền miệng hay bài viết được lưu lại thì không thể trực tiếp biết về thành tựu của ông. Ông cũng không để lại một cuốn sách best-seller hay phần mềm mà tôi có thể dùng (được rồi, có Linux for Dummies), nên tôi cứ thấy mọi người gọi ông là huyền thoại nhưng không hiểu vì sao
      Cuối cùng tôi đã hỏi cộng đồng kernel Linux và được giải thích về phạm vi đóng góp của ông. Theo một nghĩa nào đó, ông là người cố vấn của Linus. Khi họ gặp nhau năm 1994, Linus là sinh viên 25 tuổi, còn Jon là quản lý marketing 44 tuổi của DEC. Tôi thường tưởng tượng cuộc trò chuyện của họ như cảnh “Này cậu, nghe tôi cho kỹ. Bây giờ việc cậu cần làm là thế này”
      Nghĩ đến điều đó, có một câu trong tiểu sử Wikipedia của Jon Hall nổi bật. Câu đó nói rằng trong thời gian làm việc tại Digital, ông lần đầu quan tâm đến Linux và đóng vai trò quan trọng trong việc bảo đảm thiết bị và tài nguyên để Linus Torvalds thực hiện bản port đầu tiên lên nền tảng Alpha của Digital
      Một dòng trong kinh nghiệm trên LinkedIn cũng cho thấy cùng góc nhìn đó. Senior Marketing Manager, DEC, 1983-1998: gặp Linus Torvalds năm 1994, nhận ra giá trị thương mại của Linux, bảo đảm kinh phí để port Linux sang bộ xử lý Alpha 64-bit và mở ra một dòng kinh doanh trị giá hàng chục tỷ đô la cho các siêu máy tính hiệu năng cao dựa trên Linux
      WP: https://en.wikipedia.org/wiki/Jon_Hall_(programmer)
      LI: https://www.linkedin.com/in/maddog/
    • Khi tôi ở nhóm Alpha của DEC, maddog bước vào trong một cuộc họp; ông là “người máy tính” nổi tiếng đầu tiên tôi gặp nên tôi đã hơi cư xử như fan. Tôi phải giải thích cho sếp đi cùng biết ông là ai. Tôi cũng từng thấy một chiếc xe trên cao tốc gắn biển số UNIX của New Hampshire “Live Free or Die”
    • Ông đã viết Linux for Dummies, và nếu tôi nhớ đúng thì ở bìa sau có kèm một bản sao Red Hat
    • Tôi luôn kính trọng Maddog, và từng may mắn gặp ông tại một hội nghị Linux ở Birmingham, Anh khi tôi ngoài 20 tuổi. Tôi đã mua cà phê cho ông; lúc đó thu nhập của tôi ít đến mức đến cà phê cho mình cũng khó kham nổi, nhưng tôi cảm thấy đó như một huy hiệu danh dự khi được trò chuyện 5 phút với người khổng lồ trong ngành điện toán này
  • Tôi đồng ý với câu “coi những người dùng các bản clone này mà không đóng góp lại cho cộng đồng dưới bất kỳ hình thức nào là ‘kẻ đi nhờ miễn phí’”, nhưng đó vốn là phần mà phần mềm tự do đã chấp nhận ở một mức độ nào đó. Việc cho đi thứ gì đó miễn phí cũng có nghĩa là không phải ai cũng sẽ trả lại điều gì đó, hoặc thậm chí chẳng trả lại gì

    • Nhìn vào ngữ cảnh trước sau, “kẻ đi nhờ miễn phí” ở đây không chỉ toàn bộ những người không đóng góp, mà chỉ một nhóm con: những người đã ký hợp đồng kinh doanh với IBM/Red Hat nhưng không muốn tuân thủ hợp đồng đó
    • Với FreeBSD thì ai cũng làm như vậy. Phần lớn thiết bị mạng là các biến thể BSD được rút gọn
      Điểm khác với những thứ như Oracle Awesome Linux là phía đó đang bán phần việc tạo giá trị gia tăng và hệ sinh thái của Red Hat như một dịch vụ. Thực tế là kiểu “nếu muốn được hỗ trợ cùng các sản phẩm khác của chúng tôi thì hãy mua cái này. Chúng tôi phân phối đúng như Red Hat phát hành”
      Theo tôi, thay đổi của Red Hat gần với việc khiến mô hình kinh doanh độc quyền kiểu “Oracle Red Hat for X” trở nên đắt đỏ hơn. Những người không kham nổi RHEL cho hạ tầng hiệu năng cao phục vụ học thuật thì vẫn không kham nổi và đơn giản là chọn thứ khác
      Ở đây la ó về Fedora cũng chẳng có nhiều ý nghĩa. Fedora là một dự án có mục đích thương mại nhằm đáp ứng nhu cầu của công ty, và nó sẽ tồn tại cho đến ngày không còn tồn tại nữa
      Red Hat không phải Microsoft. Ai cũng thừa nhận có rất nhiều bản phân phối, và trong đó có nhiều bản rất tốt. Bạn có thể bắt đầu một bản phân phối ngay hôm nay. Nhưng “được thôi, cứ dùng Debian vậy” cũng không hẳn là một câu trả lời hợp lệ. Debian là một dự án và sản phẩm xuất sắc, nhưng nếu bạn chọn Red Hat vì những lý do khác chứ không phải vì nhận được CD tặng kèm tạp chí năm 1998, thì Debian rất có thể sẽ không lý tưởng nếu không bỏ ra nhiều công sức. Rốt cuộc đây là bài toán tiền bạc giữa chi phí để con người tự làm và chi phí giao cho Red Hat để con người đi làm việc khác
    • Câu “không phải ai cũng đóng góp lại điều gì đó” có thể mở rộng thành gần như chẳng ai đóng góp lại. 99% không cho gì cả, 0,9% thì phàn nàn, báo lỗi hoặc quyên góp ở mức nào đó, và chỉ 0,1% thực sự đóng góp lại mã tính năng
  • Tôi nhớ chuyện trước đây từng quyên góp máy chủ và hosting cho dự án Fedora. Khi cấu hình máy chủ, tôi hỏi người phụ trách: “Chắc anh muốn chạy RHEL nhỉ?”, người đó đáp “vâng”; tôi hỏi tiếp “anh có license key dùng được không?”, thì họ nói “có thể kiếm được, nhưng phiền lắm, cứ cài CentOS đi”

    • Ở công ty cũ, để thoát khỏi hp-ux/Solaris, chúng tôi đã cử 10 người đi học lớp về cấu trúc bên trong kernel Red Hat
      Giảng viên khuyên dùng CentOS để luyện tập sau khóa học (trước khi CentOS bị mua lại). Sau đó, một trong các dự án cuối cùng lại dùng Red Hat
    • Chính là chuyện này. Vấn đề lớn hơn tiền là quản lý đăng ký
    • Tôi không hề thích những gì Red Hat đang làm, nhưng có một điều tôi đã thấy. Trong 20 năm qua tôi phát triển phần mềm doanh nghiệp cho Linux, và lần cuối tôi thấy các tập đoàn khổng lồ kiểu này thực sự có license RHEL là thời RHEL 6
      Sau đó toàn là CentOS và các bản clone; trong một thời gian, khi mọi người nói RHEL, có vẻ như thực ra họ muốn nói CentOS
      Qt cũng tương tự. Dù gần như toàn bộ phần mềm phụ thuộc vào Qt, họ vẫn ở lại Qt 4.x để khỏi phải trả tiền cho Digia
    • Lạ thật. RHEL không có “license key”
  • Với tư cách nhân viên Red Hat, tôi biết ơn góc nhìn của maddog. Tôi ước những người khác cũng có thể nhìn rộng như ông ấy về những việc các công ty làm cho nguồn mở
    Khi thấy công việc được tạo ra như thế nào từ bên trong, góc nhìn sẽ khác đi. Tôi ước có thể cho mọi người biết chúng tôi thực sự bán gì. Chúng tôi không bán phần mềm hay license phần mềm
    Chúng tôi cũng không né tránh giấy phép nguồn mở, và cũng không thay đổi giấy phép. Chúng tôi đang cố giữ cho những con người của mình, những người làm các việc có giá trị với khách hàng, tiếp tục có việc để làm. Rất nhiều việc chúng tôi làm được đưa lên các dự án upstream và chia sẻ với đối thủ cạnh tranh, cộng đồng và người dùng

    • Những người tuyệt đối sẽ không trả tiền cho Red Hat lại đang lo rằng Red Hat sẽ không giữ nghĩa vụ pháp lý với những người trả tiền cho Red Hat
    • Nếu cơ cấu khiến lương của một người bị cắt khi họ hiểu một điều gì đó, thì rất khó khiến họ hiểu điều đó
  • Thật vui khi được nghe những câu chuyện lịch sử hay như thế này từ maddog. Khi ông ấy thực hiện một trong những chuyến thăm Austin được nhắc trong bài, tôi đang làm ở LTC, và đã có cơ hội vừa ăn trưa vừa trò chuyện với ông. Chắc khoảng 20 năm trước
    Luôn thú vị khi nghe một người ở tuổi 70 nhìn nhận điều gì trong sự nghiệp của mình là “điểm ngoặt”. Cách các điểm ngoặt của tôi và của họ đan xen với nhau cũng đặc biệt ấn tượng
    Tôi đã ở giữa vụ lùm xùm SCO, nhưng không chắc có thể nói một phần trong đó hay không. Có lẽ giờ các luật sư của công ty đã nghỉ hưu hoặc qua đời đủ nhiều rồi nên tôi có thể nói những gì mình muốn nói. Nếu có động lực
    Tôi vui vì maddog vẫn chia sẻ câu chuyện của mình. Càng lớn tuổi, tôi càng ít hứng thú chia sẻ bất cứ điều gì với bất kỳ ai trên Internet. Những cuộc trò chuyện có ý nghĩa với tôi gần như đều diễn ra trực tiếp dạo gần đây, nên việc chia sẻ hoặc tham gia với những người tôi không quen biết cá nhân dường như không mấy đáng giá

  • Công ty nơi tôi làm việc từng muốn cài RHEL lên thiết bị máy chủ hiệu năng cao mà chúng tôi sản xuất, nhưng họ báo giá khoảng 1 triệu USD cho mỗi giấy phép và không thể thương lượng. Như vậy sản phẩm của chúng tôi sẽ trở nên quá đắt
    Vì thế cuối cùng chúng tôi chuyển sang CentOS rồi sang Rocky, và thuê một đội khoảng 30 người để quản lý việc đó (đồng thời phụ trách cả các dự án khác). Tôi tôn trọng Red Hat và quyền quản lý phần mềm theo cách họ muốn, nhưng qua trải nghiệm vài năm qua, tôi có cảm giác họ đang cố vắt kiệt tối đa từ thương hiệu. Tôi tò mò 5 năm tới sẽ ra sao

  • Ở đoạn “tôi bắt đầu lập trình vào năm 1969”, “thực ra không chỉ khó bán phần mềm mà còn không thể áp dụng bản quyền”, tôi thắc mắc liệu tình hình pháp lý thực tế năm 1969 có đúng như vậy không. Có thật là không thể áp dụng bản quyền cho phần mềm không?
    Việc tác giả tin như vậy vào năm 1969 thì hoàn toàn hợp lý, nhưng tôi tò mò liệu niềm tin đó có chính xác về mặt pháp lý hay không

    • https://en.wikipedia.org/wiki/Software_copyright#History
      Tôi không hành nghề luật vào thời điểm đó, nhưng theo hiểu biết được nghe lại thì khi ấy chưa rõ bản quyền có áp dụng cho phần mềm hay không, và nếu có thì áp dụng như thế nào. Tuy vậy, các bên nhạy bén nhìn chung dự đoán rằng sẽ xuất hiện một hình thức bảo hộ nào đó cho phần mềm đã được viết ra, vượt ra ngoài phạm vi bí mật kinh doanh
      Đã có đủ loại câu hỏi, lý thuyết và đề xuất về việc liệu điều đó sẽ diễn ra trong khuôn khổ luật bản quyền, hay thông qua một cơ chế riêng dành cho phần mềm. Câu trả lời của Mỹ trở nên rõ ràng khi “computer program” được đưa vào định nghĩa phạm vi của luật bản quyền. Ngay cả hiện nay, khi bàn về các vấn đề còn tồn tại, người ta vẫn tiếp tục viện dẫn CONTU, ủy ban đã thúc đẩy khuyến nghị đó
    • Trước khi các khuyến nghị của CONTU được phản ánh thành luật vào thập niên 1970, việc liệu có thể có bản quyền đối với mã nguồn phần mềm hay không là điều rất không rõ ràng. Đây cũng là một lý do chính khiến IBM đưa giấy phép phần mềm vào một số phần mềm của System/360
    • https://en.m.wikipedia.org/wiki/CONTU
      https://en.wikipedia.org/wiki/Software_copyright#History
      Thật kỳ lạ khi không tin Jon Hall nhưng lại muốn tin một người lạ bất kỳ trên mạng xã hội
  • Tôi đã gặp maddog tại một sự kiện mà tôi đồng tổ chức ở Paris khoảng năm 2000. Chúng tôi đặt rất nhiều câu hỏi, và ông ấy đưa ra những câu trả lời sâu sắc. Đôi khi ông ấy trả lời bằng cách bọc nó trong một câu chuyện dài, giống như bài viết được liên kết
    Điều tôi nhớ nhất là câu này. “Hỏi: Làm thế nào chúng ta có thể giúp Linux giành thêm thị phần trên desktop, vượt qua vài điểm phần trăm mà nó đã có?”
    “Đáp: Không thể làm vậy. Hãy tìm một thị trường hiện chưa dùng máy tính, tạo ra một sản phẩm giải quyết nhu cầu của thị trường đó, và để sản phẩm đó dùng Linux. Ví dụ, hãy nghĩ đến smartphone”

  • Thật vui khi thấy maddog vẫn tích cực tham gia FOSS
    Vào khoảng cuối thập niên 90, tại COMDEX ở Chicago, ông ấy từng thuyết phục tôi và một người bạn trông gian hàng của ông ấy vài giờ để ông ấy có thể đi quanh khu triển lãm. Tôi không nhớ đó là LPI, LI hay một tổ chức nào khác liên quan đến Linux. Tôi nghĩ chúng tôi đã phát CD bản phân phối và giải thích về Linux cho mọi người
    Đó là thời kỳ điên rồ khi Linux đang càn quét thế giới PC, và Tux có mặt ở khắp nơi