"Khách hàng trả phí của chúng tôi cần X, khi nào các bạn sẽ sửa?"
(twitter.com/maximilianhils)- Một trường hợp trong đó người dùng doanh nghiệp có khách hàng thuộc các ngành được quản lý chặt chẽ như ngân hàng và cơ quan liên bang đã gây áp lực lên dự án mã nguồn mở mitmproxy bằng cách yêu cầu công khai lịch phát hành bản tiếp theo trong một issue mở, nói rằng khách hàng của họ không thể sử dụng phần mềm vì có các lỗ hổng High và Critical đã được biết đến
- Tuy nhiên, lỗ hổng đó nằm ở phần của một thư viện mà mitmproxy không sử dụng, nên trên thực tế không ảnh hưởng đến người dùng
- Thay vì từ chối yêu cầu, maintainer đã trả lời rằng nếu cần một bản phát hành vá lỗi đúng hạn thì hai bên có thể ký hợp đồng hỗ trợ trả phí (support contract), đồng thời hướng dẫn liên hệ qua email trong hồ sơ
- Người dùng doanh nghiệp sau đó gửi email phản đối, nói rằng họ hiểu câu trả lời này là "một trò đùa hoặc một nỗ lực tống tiền được ngụy trang khéo léo"
- Điểm cốt lõi không phải là câu hỏi về lịch phát hành là sai, mà là cần một thái độ hợp tác như "chúng tôi có thể giúp bằng đóng góp hay tài trợ như thế nào"; người viết bình luận ban đầu về sau đã gửi lời xin lỗi chân thành
Bối cảnh vụ việc
- Theo phần giải thích ngữ cảnh đính kèm, có một lỗ hổng trong thư viện được phân phối cùng mitmproxy, nhưng nó nằm ở phần mà mitmproxy không dùng nên không ảnh hưởng đến người dùng thực tế
- Sau khi sự việc này lan truyền rộng rãi (went viral) ở bên ngoài, ngữ cảnh bổ sung đã được giải thích thêm
Yêu cầu ban đầu từ người dùng doanh nghiệp (GitHub issue)
- 16 giờ trước, một người dùng đã nhắc đến thành viên dự án @Prinzhorn và hỏi về mốc thời gian mục tiêu (target date) cho bản phát hành tiếp theo
- Họ giải thích rằng các khách hàng trong ngành được quản lý chặt chẽ (regulated industries) như ngân hàng và cơ quan liên bang bị cấm theo quy định không được dùng phần mềm có lỗ hổng đã biết ở mức High hoặc Critical
- Họ muốn xác định quan điểm của công ty mình về việc chờ đợi (waiting), nhưng yêu cầu phải có một dạng mốc thời gian mục tiêu nào đó
Phản hồi của maintainer mhils
- Thành viên mhils trả lời 15 giờ trước rằng nếu phía công ty quan tâm đến một bản phát hành vá lỗi kịp thời để đáp ứng yêu cầu tuân thủ của doanh nghiệp, thì anh sẵn sàng thiết lập một hợp đồng hỗ trợ
- Anh cũng cho biết thông tin liên hệ nằm ở địa chỉ email trong hồ sơ (kèm ký hiệu ":-)")
Email phản đối ("Concerning response")
- Sau đó, một email với tiêu đề "Concerning response" đã được gửi từ địa chỉ thuộc miền us.ibm.com tới github@hi.ls (ghi ngày Jul 14, 2023)
- Email mở đầu bằng "Mr. Hils" và nói rằng thay vì làm căng thẳng vấn đề hoặc khiến issue tracker trên GitHub rối thêm bởi những lời lẽ không cần thiết, mục đích là để giải thích rõ hơn yêu cầu về mốc thời gian nhằm nhận được câu trả lời trực tiếp
- Họ cũng nói hy vọng email theo dõi này không bị tiếp nhận một cách khó chịu, và nhấn mạnh rằng đó không phải là ý định của họ
- Ở phần được nhấn mạnh, người viết nói rằng họ cho rằng phản hồi của maintainer không phải phản hồi chính thức của dự án mà là một trò đùa, hoặc tệ hơn là một nỗ lực tống tiền được ngụy trang khéo léo (thinly veiled extortion attempt) (câu bị ngắt giữa chừng khi nói rằng sau đó họ xem lại tài liệu chính thức của dự án)
Tóm tắt lập trường của maintainer
- Anh khẳng định rõ rằng câu trả lời đó không phải trò đùa
- Cách tiếp cận kiểu "khách hàng trả phí của chúng tôi cần X, khi nào các bạn sửa" có thể không phải cách tốt nhất để giới thiệu bản thân với một dự án mã nguồn mở
- Anh thừa nhận việc hỏi về lịch phát hành tự nó không gây khó chịu và là một câu hỏi hợp lệ (valid)
- Tuy nhiên, điểm mấu chốt là ngữ cảnh nên là "chúng tôi quan tâm đến việc này, chúng tôi có thể giúp để biến nó thành hiện thực như thế nào" (đóng góp hoặc tài trợ), chứ không phải "bạn đang gây vấn đề cho khách hàng của chúng tôi"
Kết lại
- Người viết bình luận ban đầu đã gửi lời xin lỗi chân thành (genuine apology), và maintainer nói rằng anh thực sự trân trọng điều đó
- Anh kêu gọi mọi người giả định thiện ý (assume good intentions) và đối xử tử tế với nhau
1 bình luận
Ý kiến trên Hacker News
Nếu đọc issue nàyhttps://github.com/mitmproxy/mitmproxy/issues/6051, thì yêu cầu của IBM hợp lý hơn nhiều so với những gì hiện ra trong tweet
Vấn đề là có một CVE trong dependency của mitmproxy, mitmproxy đã cập nhật dependency đó vào tháng 3 nhưng đến giờ vẫn chưa phát hành bản stable có chứa bản cập nhật ấy. Phía IBM đang hỏi: “Khi nào các bạn định gắn thẻ phát hành, có lịch trình nào để chúng tôi báo lại cho khách hàng không?”
Đặc biệt, họ không hỏi “khi nào các bạn sẽ sửa”. Cái cần sửa thì đã không còn, và câu hỏi gần hơn với “khi nào các bạn định tạo một bản phát hành mới có chứa bản cập nhật dependency này?”
Tôi không cho rằng bản thân câu hỏi đó là vô lý. Tất nhiên, nếu họ muốn những bản sửa kiểu này được triển khai trong một khoảng thời gian nhất định thì việc yêu cầu hợp đồng hỗ trợ cũng không phải là vô lý, nhưng câu trả lời ngay lập tức là “hãy liên hệ qua email về hợp đồng hỗ trợ” có vẻ hơi quá
Maximilian không có nghĩa vụ phải cung cấp lịch phát hành cho người không trả tiền, và nếu IBM thực sự cần một timeline thì việc đề nghị họ trả phí cũng chẳng có gì lạ. Nếu IBM coi việc này quan trọng đến vậy thì ngay hôm nay họ cũng có thể tự làm một bản phát hành nội bộ của mitmproxy
Lý do tôi nói “hãy liên hệ qua email về hợp đồng hỗ trợ” là vì 1) tôi đã nói rõ ngay trong thread đó rằng sẽ không phát hành bản vá cho việc này và 2) phía bên kia nhấn mạnh tác động tới các khách hàng trả phí của họ
Vì vậy lúc đó tôi chỉ còn biết nói thế thôi. Tôi đồng ý là có thể diễn đạt tốt hơn, nhưng tôi không cảm thấy câu trả lời của mình hoàn toàn là quá đáng
Bản thân CVE đó cũng là thứ vớ vẩn, và chúng tôi không dùng phần đó của dependency
Tại sao maintainer phải làm không công trong khi người đưa ra yêu cầu lại được hưởng lợi từ lao động miễn phí đó
Điều không hợp lý là thái độ xem đó là điều hiển nhiên của FrugalGuy. Đòi maintainer mã nguồn mở làm việc miễn phí rồi lại đi tố là tống tiền thì phải là một kiểu đạo đức giả khá đặc biệt. Không thể ép buộc một tình nguyện viên làm dự án free/open source bán thời gian phải đáp ứng yêu cầu được
Tôi là OP. Nói cho rõ thì bản thân câu hỏi về phát hành hoàn toàn không có vấn đề gì và là hợp lý
Chỉ là bối cảnh nên là “chúng tôi quan tâm đến việc này, chúng tôi có thể giúp thế nào để nó xảy ra?”, dù là đóng góp hay trả tiền. Không nên là “vì các anh mà khách hàng của chúng tôi gặp vấn đề”
Tôi không mong người đưa ra yêu cầu chỉ vì lỡ lời mà bị khốn đốn, mà chỉ mong các tập đoàn lớn có được mối quan hệ lành mạnh với phần mềm tự do và mã nguồn mở
Việc đưa ra đề nghị loại hợp đồng đó thực ra đã là khá tử tế rồi. FrugalGuy hoàn toàn có thể nhận được câu trả lời là “hãy gửi pull request”, và không biết liệu anh ta có thích điều đó không
Nhưng nếu vấn đề là không có bản phát hành cho một bản sửa đã được làm xong, thì tôi không rõ có thể giải quyết nó bằng đóng góp hay tiền bạc như thế nào
Điều này nghe đúng kiểu những kẻ ngớ ngẩn về an ninh thông tin còn chẳng biết mình đang “sửa” cái gì. Hễ hệ thống tự động báo có CVE là họ nghĩ phải “vá” ngay
Họ không xem nội dung cáo buộc của CVE là gì, cũng không kiểm tra xem cách sử dụng cụ thể của họ có thực sự dễ bị khai thác hay không. Họ không biết, cũng không quan tâm, và cũng chẳng phải lập trình viên. Họ chỉ biết là phải xóa cho được cái ô checkbox đó
Bên h2database cũng từng có chuyện tương tự. Một “nhà nghiên cứu bảo mật” phát hiện ra rằng nếu làm điều mà người ta đã bảo là đừng làm thì sẽ có chuyện xấu xảy ra, vậy mà vẫn đòi CVE và cuối cùng cũng lấy được. Chỉ cần nhìn kỹ là thấy nhảm nhí, nhưng với những người này thì điều quan trọng duy nhất là CVE đó tồn tại
Lời của một nhà phát triển h2database: https://github.com/h2database/h2database/issues/3686#issueco...
“Thật khó hiểu vì sao tôi phải có dù chỉ một chút cảm thông với một ‘tập đoàn lớn’ đang dùng một dự án mã nguồn mở do tình nguyện viên phát triển. Hãy thuê ai đó bằng tiền của công ty để xử lý, hoặc trả tiền cho một thư viện thương mại tương tự.”
Ngay cả khi họ có quyền cho ngoại lệ trong một tình huống cụ thể, họ có thể vẫn phải làm thêm nhiều giấy tờ để biện minh cho quyết định đó. Đống giấy tờ bổ sung ấy làm chậm tiến độ, và bất lợi cho chỉ số đánh giá hiệu suất của họ
“Nếu truyền mật khẩu qua dòng lệnh thì các tiến trình khác trên hệ thống có thể xem bằng
ps”Chuyện hiển nhiên là thế. Nếu như vậy mà là CVE mức “nghiêm trọng cao” thì tôi cũng có thể tự xưng là nhà nghiên cứu bảo mật được. Tôi nghĩ ra ít nhất năm sáu ứng dụng cũng cho phép làm y hệt, chỉ kèm cảnh báo “đừng làm thế này”
Đội an ninh thông tin đẩy lỗ hổng xuất hiện trong báo cáo lên, quản lý thì hoảng sợ
Nhà phát triển phải cập nhật liên tục. Cả những dependency không chạy production cũng vậy. Có thể xin ngoại lệ, nhưng đó lại là một nỗi đau đầu hoàn toàn khác
Rồi sau đó quản lý lại tự hỏi vì sao công việc phát triển chậm đi
Tôi thậm chí còn nghi ngờ có ai thực sự xem phần còn lại hay không
Một dự án của tôi cũng từng đột nhiên bị dồn dập các bình luận kiểu “bao giờ thì sửa”, “tôi cũng bị ảnh hưởng và việc này rất quan trọng”. Sự quan tâm tăng vọt đột ngột như vậy khá là kỳ lạ
Nhưng rồi vào khoảng thời gian đó, tôi nhận được một email xin lỗi nói rằng sếp ở một công ty nào đó đã bảo nhân viên gây áp lực lên tôi bằng cách giả vờ như có nhiều người bị ảnh hưởng hơn thực tế rất nhiều
Có vẻ ai đó đã học được ở chỗ làm của họ rằng giọng điệu hung hăng hoặc mang tính đe dọa rất hiệu quả, nhưng lại không hiểu rằng vị thế đàm phán ở đây hoàn toàn khác
Có một khác biệt tinh tế giữa “tôi cần biết khi nào việc này xong để lên kế hoạch” và “tôi đang kiếm tiền từ công việc của anh nên anh phải làm cái này, làm nhanh lên”
Nếu người yêu cầu bỏ bớt thông tin bối cảnh đi khi hỏi, thì giọng điệu đã nghiêng nhiều hơn về vế đầu và ít giống vế sau hơn
Nếu lý do đó cũng có vẻ quan trọng với nhiều người dùng khác, nó có thể giúp người bảo trì quyết định có nên ưu tiên thêm tính năng hoặc sửa lỗi sớm hơn không. Nếu có cách workaround thì điều đó cũng có thể giúp tìm ra
Gọi đó là tống tiền nhà phát triển thì không công bằng, nhưng theo tôi bản thân tin nhắn đầu tiên không có vấn đề gì
Khi dùng phần mềm mã nguồn mở mà còn đòi hỏi cả hỗ trợ thì cảm giác có quyền đòi hỏi của doanh nghiệp là cực kỳ lớn. Tôi ước gì các giấy phép có hạn chế sử dụng được dùng rộng rãi hơn, và OSI đừng chỉ nói kiểu “đó không phải mã nguồn mở!!!”
Những giấy phép như vậy có thể ngăn tình huống này
Dù sao thì việc OSI và FSF giữ lập trường cứng rắn ở đây cũng là điều tốt. Nếu ưu tiên của bạn không trùng với họ, tại sao họ phải thay đổi để làm bạn hài lòng
Cứ dùng giấy phép bạn thích là được. Kể cả khi họ không phê duyệt. Tôi không hiểu tại sao đó lại là vấn đề. Ngay từ đầu bạn đã không chia sẻ các giá trị của họ, vậy tại sao các tổ chức đó phải đóng dấu chấp thuận cho lựa chọn giấy phép của bạn
Với các nhà tài trợ doanh nghiệp, việc không ủng hộ hạn chế sử dụng không phải lỗi mà là tính năng
Xung quanh định nghĩa mã nguồn mở và phần mềm tự do cũng có rất nhiều tính giáo điều. Nếu không đi theo các định nghĩa này thì rất dễ bị kéo đến công kích, và các định nghĩa đó thường được đối xử như kinh thánh. Những người ủng hộ thậm chí không chấp nhận khả năng rằng chúng có thể cần được điều chỉnh để phù hợp với thực tế năm 2023
Ngay cả khi tạo ra thuật ngữ mới để tránh xung đột, những người cổ xúy mã nguồn mở và phần mềm tự do vẫn cố chấp dùng ngôn ngữ của riêng họ để kiểm soát câu chuyện. Thứ ngôn ngữ đó được thiết kế để mang hàm ý tiêu cực ngay trong cộng đồng của họ
Quyền tự do của người dùng được chạy phần mềm cho bất kỳ mục đích nào là tự do số 0, và Stallman đã giải thích rất thuyết phục vì sao hạn chế sử dụng không giúp ích: https://www.gnu.org/philosophy/programs-must-not-limit-freed...
Cũng giống như điều khoản miễn trừ bảo hành, phần mềm tự do được trao đi vô điều kiện. Đã được tặng cả quyền sửa theo ý muốn mà còn đòi hỗ trợ và bảo trì miễn phí thì thật bất lịch sự. Tôi không nghĩ đổi giấy phép sẽ khiến kiểu người bất lịch sự đó biến mất
Và ngoài giấy phép ra, có thể vẫn có những lựa chọn thân thiện với mã nguồn mở hơn so với với doanh nghiệp. Ví dụ, nếu ai đó muốn nêu một vấn đề nghiêm trọng thì phải công khai mã tái hiện lỗi
Ngay cả thời thập niên 80, khi hỗ trợ thường được cung cấp miễn phí, tôi đã nghe nhiều chuyện các công ty làm như vậy với phần mềm sao chép lậu. Thứ duy nhất làm giảm trò đó là hợp đồng hỗ trợ trả phí
Phản ứng thực tế duy nhất là kiện vì vi phạm giấy phép, nhưng không có nhiều nhà phát triển mã nguồn mở có đủ phương tiện để làm vậy với các tập đoàn lớn, chứ đừng nói là doanh nghiệp tầm trung
Hành vi của “FrugalGuy” thì non nớt và trẻ con, nhưng người bảo trì mitmproxy lẽ ra có thể trả lời theo cách tốt hơn, vừa lịch sự vừa dứt khoát, không để lại chỗ cho hiểu lầm hay drama
“Theo giấy phép của mitmproxy, phần mềm này được cung cấp nguyên trạng, không có bảo hành, và những người bảo trì dự án hiện đang bị ràng buộc bởi các ưu tiên và đầu việc khác”
“Vì vậy, chỉ riêng tuyên bố trong GitHub issue tracker là không đủ để biện minh cho việc tăng mức ưu tiên của issue. Cách duy nhất để nâng ưu tiên issue là ký hợp đồng hỗ trợ, được cung cấp tại [here]. Tôi sẵn sàng trao đổi thêm về các điều khoản”
Cỡ bằng lương một năm của một kỹ sư thì với quy mô của một số công ty là số tiền chẳng đáng gì, và có vẻ việc sửa lỗi có thể xong trong vài tuần, như vậy là công bằng
Hoặc nếu thực sự không muốn trả tiền, thì cứ phân công một kỹ sư của công ty mình trong vài tháng để vá phần mà khách hàng trả tiền cần rồi đóng góp ngược lên upstream
Đính chính: chuyện bằng mức đãi ngộ một năm của kỹ sư chỉ là ước lượng hạn chế và không chính xác của tôi. Tôi không ở vị trí để nói chính xác nó đáng giá bao nhiêu, nhưng tôi đoán với một kỹ sư chưa quen codebase thì có lẽ sẽ tốn vài tháng công sức
Chỉ là làm vậy có thể phát sinh các vấn đề tuân thủ khác, và có lẽ đó là lý do họ không làm. Tất nhiên đó không phải vấn đề của dự án mã nguồn mở
https://github.com/mitmproxy/mitmproxy/issues/6051#issuecomm...
Chỉ đơn giản hỏi “có ngày mục tiêu nào cho bản phát hành tiếp theo không?” thì không có gì sai. Vì đó không phải là đòi hỏi
Cách diễn đạt “chúng tôi đang cố xây dựng lập luận nội bộ theo hướng chờ đợi, nhưng cần một ngày mục tiêu nào đó” khiến chữ “cần” ở đây được hiểu là những người khác đang yêu cầu anh ta, chứ không phải anh ta đang yêu cầu các nhà phát triển mitmproxy
Trong bình luận này, người viết đang đưa ra một yêu cầu đồng thời giải thích động cơ thương mại/cá nhân phía sau yêu cầu đó. Chỉ đến khi quay lại qua email với những từ như tống tiền thì mới thành vấn đề
Bài gốc đã có cả bối cảnh lẫn tên công ty. Việc phát tán issue GitHub thật trong khi tác giả rõ ràng cố tránh điều đó mới là hành động tệ hại
FrugalGuyà, thật cạn lời