- Khi một sản phẩm phần cứng bị ngừng vòng đời (EOL), có ý kiến cho rằng doanh nghiệp phải bắt buộc công khai phần mềm đó dưới dạng mã nguồn mở
- Phong trào Right to Repair đã đạt được tiến triển, nhưng có đề xuất rằng ở cấp độ Liên minh châu Âu cần cưỡng chế bằng pháp luật việc công khai phần mềm khi EOL
- Ví dụ được nêu gồm trường hợp cân thông minh bị mất chức năng vì ứng dụng ngừng hỗ trợ, và trường hợp Car Thing của Spotify sau khi bị khai tử đã biến thành rác thải điện tử
- Doanh nghiệp không cần công khai toàn bộ codebase, mà chỉ cần công bố thông số phần cứng và giao thức kết nối để cộng đồng có thể tự phát triển ứng dụng
- Vì tính bền vững và quyền của người dùng, một cách tiếp cận mã nguồn mở để hồi sinh phần cứng đã bị khai tử là điều thiết yếu
Sự cần thiết của mã nguồn mở khi phần cứng bị khai tử
-
Khi một sản phẩm phần cứng bước vào trạng thái EOL(End of Life), doanh nghiệp nên công khai phần mềm dưới dạng mã nguồn mở
- Bài viết chỉ ra vấn đề: sản phẩm đã ngừng bán nhưng vẫn còn hoạt động, song lại trở nên vô dụng vì phần mềm ngừng được hỗ trợ
- Để ngăn tình trạng này, tác giả cho rằng cần có cơ chế cưỡng chế pháp lý
-
Phong trào Right to Repair đã tăng cường quyền lợi người tiêu dùng, nhưng xa hơn nữa, có đề xuất rằng Liên minh châu Âu (EU) nên bắt buộc công khai phần mềm khi EOL
- Quan điểm này cho rằng Ủy ban châu Âu (European Commission) nên đưa ra quy định buộc doanh nghiệp công khai phần mềm tại thời điểm ngừng vòng đời sản phẩm
Trải nghiệm cá nhân và các ví dụ vấn đề
-
Trong trường hợp cân thông minh, phần cứng vẫn hoạt động bình thường nhưng ứng dụng bị ngừng, khiến chức năng lưu dữ liệu biến mất
- Dù vẫn có thể kết nối Bluetooth, ứng dụng không còn được phát triển nên thiết bị gần như trở nên vô dụng
- Bài viết bày tỏ sự bất mãn và vấn đề lãng phí trước thực tế phần cứng hoàn chỉnh lại bị “khai tử” chỉ vì doanh nghiệp ngừng hỗ trợ
-
Bài viết cũng nhắc đến trường hợp Car Thing của Spotify bị khai tử
- Khi dịch vụ kết thúc vào cuối năm 2024, phần cứng trị giá 200 USD đã gần như chỉ sau một đêm trở thành rác thải điện tử
- Trường hợp Bose công khai loa SoundTouch dưới dạng mã nguồn mở trước khi EOL được đánh giá tích cực, nhưng vẫn bị xem là ngoại lệ hiếm hoi
Đề xuất giải pháp thực tế
-
Doanh nghiệp không cần công khai toàn bộ codebase
- Thay vào đó, chỉ cần công bố thông số phần cứng và giao thức kết nối trên kho lưu trữ GitHub là đủ
- Cộng đồng có thể dựa vào đó để tự phát triển ứng dụng riêng
-
Nhờ các cách tiếp cận phát triển mới như vibe-coding, ngay cả người không chuyên cũng có thể dễ dàng tham gia
- Đây là thời điểm mà cả người dùng phổ thông cũng có thể trực tiếp can thiệp và cải tiến phần cứng
Tính bền vững và quyền của người dùng
- Một cách tiếp cận mã nguồn mở để hồi sinh phần cứng đã bị khai tử là cần thiết về môi trường và đạo đức
- Điều này có thể giảm phát sinh rác thải điện tử không cần thiết và duy trì một hệ sinh thái công nghệ bền vững
- Nếu phần cứng đã thành “cục gạch”, thì công khai phần mềm để cộng đồng có cơ hội tái sử dụng là phương án tốt nhất
1 bình luận
Ý kiến trên Hacker News
Cách chắc chắn nhất để một dự án EOL (End-of-Life) được chuyển sang mã nguồn mở là ngay từ đầu hãy bắt đầu bằng mã nguồn mở
Những lời hứa kiểu “sẽ công khai sau khi đạt mục tiêu” hay tuyên bố sẽ công khai nếu công ty phá sản đều không có nhiều ý nghĩa
Phải bắt đầu bằng mã nguồn mở thì nhà đầu tư và cộng đồng mới có thể tin tưởng
Nên chi tiền cho các công ty làm sản phẩm mã nguồn mở và phần cứng mở, đồng thời hỗ trợ các nghệ sĩ phát hành tự do
Việc chỉ trích doanh nghiệp vì không công khai sau EOL rốt cuộc cũng chỉ là hành động mang tính trình diễn
Ngay cả các tập đoàn lớn cũng khó chống lại nhu cầu thống nhất từ người tiêu dùng
Giống như FSF đã phổ cập phần mềm tự do, cần có giáo dục người tiêu dùng và một sự chuyển đổi văn hóa
Cần xây dựng một văn hóa cộng đồng người tiêu dùng nơi ý kiến của chuyên gia được chia sẻ nhanh chóng
Quan trọng là nỗ lực tạo ra thay đổi thực chất thay vì thái độ hoài nghi
Chỉ với áp lực từ người tiêu dùng thì rất khó, và cần có quy định pháp lý
Hầu hết các hệ thống phụ thuộc vào chuỗi ký mã để hoạt động theo kiểu “fail closed”
Nhưng khi chủ thể ký ban đầu biến mất, cần có cấu trúc “fail open” để có thể ủy quyền quyền ký cho một chủ thể mới
Đề xuất chỉ công khai thông số phần cứng và giao thức thì thiếu tính thực tế
Phần lớn thiết bị không đơn giản chỉ là giao thức kết nối, và thông số kỹ thuật cũng có thể tìm ra bằng cách phân tích PCB
Chỉ cần công khai cách flash firmware và mức firmware tối thiểu là cũng đủ
Tuy nhiên mỗi sản phẩm có hoàn cảnh khác nhau nên cần tiếp cận theo từng trường hợp
Với các thiết bị như router, nơi secure boot được ghi vào e-fuse, thì chỉ công khai mã nguồn mở là không giải quyết được
Trong trường hợp này, nhà sản xuất nên lưu khóa ký dưới dạng escrow để sau EOL vẫn có thể chạy phần mềm mới
Kẻ tấn công chiếm được tên miền hết hạn có thể tạo botnet
Thay vào đó cần có quy trình như thao tác nút vật lý để người dùng chủ động chấp thuận cài firmware bên thứ ba
Người dùng có quyền sửa đổi thiết bị của mình mà không cần sự cho phép từ nhà sản xuất
Tôi cũng thấy bức bối khi phải vứt bỏ phần cứng vẫn còn dùng được chỉ vì EOL
Nhưng cách tiếp cận kiểu “hãy hình sự hóa việc tạo ra rác thải điện tử” thì thiếu tính thực tế
Ví dụ: nếu sản phẩm không thể thực hiện chức năng chính thì phải hoàn tiền toàn bộ, trừ khi nhà sản xuất đưa phần mềm cần thiết vào public domain
Luật như vậy có thể kiềm chế các tập đoàn lớn như Google, những bên làm sản phẩm trở nên vô dụng bằng cách tắt máy chủ
Nếu biến Windows 10 thành mã nguồn mở, chiến lược dài hạn của Microsoft sẽ sụp đổ
Ý tưởng này còn thú vị hơn cả chính khái niệm “mã nguồn mở”
Ví dụ, nếu UBNT công khai boot chain đã EOL để Cambium có thể dùng firmware đó,
kết quả có thể không phải là hỗ trợ từ cộng đồng mà là cuộc cạnh tranh cập nhật sản phẩm vĩnh viễn
Tối thiểu thì họ phải không cản trở việc chạy phần mềm thay thế mà người dùng muốn dùng
Đa số người dùng khi máy chủ biến mất sẽ không cài lại firmware mà просто vứt thiết bị đi
Vì vậy cần có thiết kế không phụ thuộc vào máy chủ bên ngoài
Ví dụ: loa thông minh nên hỗ trợ streaming qua mạng nội bộ, bóng đèn nên hỗ trợ ghép nối bằng giao thức tiêu chuẩn
May mắn là các tiêu chuẩn như Matter over Thread đang phát triển theo hướng đó
Google Nest Thermostat thế hệ 1 và 2 là một ví dụ tiêu biểu
Dự án No Longer Evil đã hồi sinh thiết bị này bằng firmware mã nguồn mở
Nó loại bỏ sự phụ thuộc vào đám mây của Google và cho phép người dùng tự host máy chủ hoặc điều khiển độc lập
Nhờ vậy, phần cứng đắt tiền này đã có lại sự sống
Tôi cảm thấy hiện nay giống như một thời kỳ tăm tối nào đó
Trước đây lò sưởi chỉ cần nối đất một chân là chạy, nhưng các mẫu sau đó chuyển sang giao thức đóng nên khó can thiệp hơn
Tuy nhiên các mẫu mới nhất lại hỗ trợ chuẩn OpenTherm, giúp việc hack trở nên dễ hơn
Dạo này có rất nhiều phần cứng mở dựa trên ESP32 hay Raspberry Pi, nên tôi tự làm GUI bằng ESPHome + LVGL rồi tích hợp vào home automation
Mức độ hoàn thiện cao đến mức bạn bè còn tưởng đó là sản phẩm thương hiệu
Tôi nghĩ “điều đó sẽ không xảy ra”
May là nhờ AI và Android, việc reverse engineering giao thức đã trở nên dễ hơn
Chỉ cần phân tích APK cũng có thể thu được nhiều thông tin, nên tôi đang tự làm app và server cho Limitless Pendant mà tôi mua trước khi Meta thâu tóm
Tôi chưa tự viết lấy một dòng code nào
Không ai mong đợi hỗ trợ trọn đời
Nhưng thật khó chấp nhận việc chức năng cơ bản cũng bị giết chỉ vì backend ứng dụng hay lộ trình sản phẩm biến mất
Nếu thiết bị vẫn còn ổn về điện và cơ khí, thì ít nhất việc sử dụng tối thiểu phải được bảo đảm