Rug pull, fork và chế độ phong kiến trong mã nguồn mở

• Bài viết tổng hợp cách động lực quyền lực trong hệ sinh thái mã nguồn mở vận hành giữa doanh nghiệp, nhà phát triển và người dùng, cùng tác động của hai chiến thuật gây xáo trộn là rug pull (đổi giấy phép) và fork
• Khi các nhà cung cấp đám mây lớn nắm ảnh hưởng rất mạnh, những dự án xoay quanh một công ty duy nhất có thể cấp phép lại để tái phân bổ quyền lực, và fork xuất hiện như một phản ứng đối trọng
• Phân tích các trường hợp Elasticsearch→OpenSearch, Terraform→OpenTofu, Redis→Valkey, Puppet→OpenVox cho thấy những mô thức khác nhau về tái cấu trúc cộng đồng và dịch chuyển người đóng góp
• Áp dụng CLA, sự chi phối của một công ty duy nhất, thời điểm chuyển giao cho quỹ là các tín hiệu rủi ro của rug pull; trong khi quản trị trung lập và mở rộng tầng đóng góp từ nhiều tổ chức được khuyến nghị như chiến lược ứng phó
• Kết luận, việc đổi giấy phép có thể là công cụ kiềm chế các nhà cung cấp đám mây, nhưng đồng thời cũng làm suy yếu quyền của người đóng góp; còn khả năng fork đóng vai trò răn đe đối với các quyết định của doanh nghiệp

---

Cấu trúc quyền lực trong mã nguồn mở, rug pull và fork

• Trong hệ sinh thái phần mềm mã nguồn mở, các tập đoàn lớn, doanh nghiệp vừa và nhỏ, người đóng góp và người dùng đều sử dụng quyền lực của mình để tác động đến định hướng phần mềm và cấu trúc doanh thu
• Đặc biệt, các nhà cung cấp đám mây lớn có xu hướng nắm quyền lực đáng kể và thường chiếm ưu thế so với các công ty nhỏ hoặc cộng đồng
• Trong bối cảnh đó, nhà phát triển hoặc công ty sở hữu dự án có thể thay đổi giấy phép phần mềm (rug pull), hoặc ngược lại cộng đồng hay doanh nghiệp khác có thể tiến hành fork, tạo ra sự dịch chuyển quyền lực

Tổng quan về động lực quyền lực và các chiến thuật

• Trong thế giới mã nguồn mở, các nhà cung cấp đám mây lớn nắm giữ quyền lực kênh phân phối và phát hành mạnh nhất, hình thành một cấu trúc khai thác các công ty nhỏ, người đóng góp và người dùng
  • Tương tự như việc kiểm soát đất đai trong thời phong kiến, các nhà cung cấp đám mây biến phần mềm mã nguồn mở thành dịch vụ trong khi né tránh đóng góp
  • Các công ty nhỏ đảm nhận phần lớn công việc phát triển nhưng ở vào thế bất lợi vì các nhà cung cấp đám mây có thể sử dụng miễn phí
• Với chiến thuật rug pull, các công ty nhỏ cấp phép lại phần mềm để đối phó với các nhà cung cấp đám mây, nhưng điều này lại gây thiệt hại lớn hơn cho người đóng góp và người dùng
  • Khi các nhà cung cấp đám mây chuyển dự án thành dịch vụ mà không đóng góp, quyền lực của công ty nhỏ bị suy yếu
  • Việc cấp phép lại gây bất lợi cho người dùng, nhưng có thể tái cân bằng quyền lực thông qua fork
• Ở các dự án do một công ty duy nhất dẫn dắt, rủi ro rug pull cao hơn, nên cần đánh giá uy tín của công ty, dù điều này có thể trở nên vô nghĩa nếu xảy ra mua bán sáp nhập hoặc phá sản
  • Áp lực từ nhà đầu tư có thể dẫn đến việc cấp phép lại nhằm tăng doanh thu, đặc biệt khi phải cạnh tranh với nhà cung cấp đám mây
  • Bằng cách dùng giấy phép hạn chế hơn để khiến bên khác khó thương mại hóa, công ty tìm cách dịch chuyển cán cân quyền lực
• Việc tạo ra fork sau một rug pull là một hình thức hành động tập thể mang tính phản kháng để khôi phục quyền lực, nhưng nguy cơ thất bại cao do thiếu nhân lực và tài nguyên
  • Các công ty lớn hoặc nhà cung cấp đám mây có thể dùng nguồn lực để hỗ trợ fork, nhưng fork phổ biến không phải lúc nào cũng thành công
  • Có những trường hợp không xuất hiện fork như MongoDB hay Sentry; trong khi việc Perforce mua lại Puppet rồi đóng phát triển đã dẫn tới fork OpenVox

So sánh các trường hợp chính

Dawn Foster phân tích nhiều trường hợp rug pull, fork và các tác động sau đó dựa trên dữ liệu. (Một phần kết quả được công bố qua bộ dữ liệu Jupyter notebook)

• Elasticsearch → OpenSearch
  • Sau khi Elastic cấp phép lại sang SSPL vào năm 2021, AWS đã tổ chức fork OpenSearch
  • Ở Elastic, tỷ trọng người đóng góp nội bộ gần như không thay đổi lớn trước và sau fork; còn OpenSearch tiếp tục mang đặc điểm đóng góp do Amazon dẫn dắt
  • Phân tích cho thấy ngay cả sau khi chuyển giao cho Linux Foundation vào năm 2024, không quan sát thấy sự bùng nổ đóng góp bên ngoài
• Terraform → OpenTofu
  • Ngay sau khi HashiCorp chuyển sang BSL vào năm 2023, OpenTofu đã ra mắt dưới Linux Foundation
  • Terraform vẫn duy trì mô hình đóng góp chủ yếu từ nội bộ, trong khi nhiều người đóng góp mới từ các công ty khác nhau nhanh chóng đổ vào OpenTofu
  • Trường hợp này gợi ý rằng fork do người dùng dẫn dắt + một quỹ trung lập ngay từ đầu có lợi cho việc hình thành cộng đồng năng động
• Redis → Valkey
  • Ngay sau khi Redis chuyển sang SSPL vào năm 2024, nhiều người đóng góp bên ngoài hiện có đã chuyển sang Valkey
  • Redis là một trường hợp ngoại lệ khi tỷ lệ đóng góp bên ngoài vốn đã cao trước fork; sau fork, con số này giảm mạnh xuống 0 đóng góp bên ngoài, còn Valkey khởi đầu như một cộng đồng liên minh đa doanh nghiệp
• Puppet → OpenVox
  • Sau khi bị Perforce mua lại (2022), dự án rơi vào tình trạng đóng kín quá trình phát triển và phát hành cùng với giảm tần suất phát hành, khiến cộng đồng thúc đẩy fork OpenVox để đáp trả

Quan sát dữ liệu và chỉ số

• Sau rug pull, thường quan sát thấy số lượng fork trên GitHub tăng vọt, được diễn giải như một tín hiệu proxy cho việc cộng đồng đang cân nhắc hard fork
  • Về dài hạn, có xu hướng bản gốc và fork cùng tiếp tục tiến lên song song, nhưng phân tích cho thấy bản gốc đã cấp phép lại có xu hướng giảm mức sử dụng
• Ra mắt dưới chiếc ô của một quỹ có lợi cho thu hút đóng góp ở giai đoạn đầu của dự án mới, nhưng chuyển giao sau đó có thể mang lại hiệu quả hạn chế
  • Trường hợp OpenSearch cho thấy chỉ riêng việc chuyển giao không đảm bảo đóng góp bên ngoài tăng vọt

Tín hiệu rủi ro và hướng dẫn

• Việc sử dụng CLA (Contributor License Agreement) là tín hiệu cho thấy quyền cấp phép lại được tập trung vào doanh nghiệp, từ đó làm trầm trọng thêm mất cân bằng quyền lực
  • Các dự án dựa trên DCO (Developers Certificate of Origin) có xu hướng ít rủi ro rug pull hơn
• Cần kiểm tra mô hình quản trị; sự chi phối của một công ty duy nhất và quyền lãnh đạo tập trung là các yếu tố rủi ro
  • Những dự án có quỹ trung lập, lãnh đạo đa tổ chức và nền tảng đóng góp bên ngoài thường có lợi thế hơn về tính bền vững
• Độ rộng và chiều sâu của cơ sở người đóng góp cũng là tiêu chí đánh giá cốt lõi
  • Doanh nghiệp cần cử trực tiếp người đóng góp vào các dự án mà mình phụ thuộc để đồng thời tăng ảnh hưởng và tính bền vững
  • Metric và practitioner guide của CHAOSS có thể được dùng để chẩn đoán và cải thiện sức khỏe dự án

Gợi ý cho cộng đồng và quản trị

• Việc thúc đẩy mô hình quản trị trung lập và mở rộng người đóng góp bên ngoài là biện pháp thực chất để kiềm chế rug pull
  • Chính khả năng fork đã làm tăng chi phí của quyết định cấp phép lại đối với doanh nghiệp, từ đó tạo ra hiệu ứng răn đe
• Trả lời câu hỏi của Hazel Weakly về các cơ chế bảo vệ, người trình bày nhắc tới việc Valkey và OpenTofu thành công như những ví dụ thực tế đã buộc các doanh nghiệp xem xét lại ý định cấp phép lại
  • Dirk Hohndel nhấn mạnh rằng thu hút nhiều người đóng góp bên ngoài hơn sẽ làm tăng rủi ro rug pull và từ đó khiến ban điều hành phải cân nhắc kỹ hơn

Kết luận

• Khi ảnh hưởng của các nhà cung cấp đám mây lớn ngày càng mạnh, hệ sinh thái mã nguồn mở đang dần chuyển sang một cấu trúc mang tính phong kiến
• Việc thay đổi giấy phép giúp kiềm chế sức mạnh của các công ty đám mây, nhưng trong quá trình đó cũng tạo ra tác dụng phụ là làm suy giảm quyền của những người đóng góp cộng đồng
• Tuy nhiên, với người đóng góp và người dùng, vẫn tồn tại công cụ phản công mang tên 'fork', đây là sức mạnh riêng của mã nguồn mở mà thời phong kiến không có
• Khả năng fork trên thực tế ảnh hưởng đến các quyết định chính sách trong tương lai của doanh nghiệp; trên thực tế, thành công của Valkey và OpenTofu đã khiến một số công ty rút lại kế hoạch rug pull
• Sau cùng, tính trung lập trong quản trị của dự án và việc kích hoạt người đóng góp bên ngoài là chìa khóa để ngăn rug pull và duy trì một hệ sinh thái lành mạnh

Tài liệu tham khảo

• Slide thuyết trình: Power Dynamics, Rug Pulls & Other Impact on Sustainability

[ndrgrd]

Vì việc fork hiện vẫn chưa dễ dàng, nên sẽ rất tốt nếu có các tổ chức liên quan đến mã nguồn mở hỗ trợ việc này.

[GN⁺]

Ý kiến trên Hacker News

• Có ý kiến cho rằng các dự án dùng CLA (Contributor License Agreement) dễ xảy ra rug pull hơn — tức công sức của người đóng góp bị một nhóm nhỏ chiếm hữu — trong khi các dự án dùng DCO (Developers Certificate of Origin) thì ít mất cân bằng kiểu này hơn. Khi ký CLA, bạn trao cho dự án quyền cấp phép lại phần mã mình đóng góp. Nghĩa là kể cả bạn đóng góp cho một dự án GPL bằng mã GPL thì giấy phép vẫn có thể bị đổi. Nếu vốn đã là giấy phép permissive thì CLA không ảnh hưởng nhiều, nhưng với copyleft (ví dụ GPL) thì chỉ bên thu chữ ký CLA mới có thể độc quyền hóa, nên trở nên thiếu công bằng. Muốn tránh rug pull thì nên dùng giấy phép copyleft và tránh ký CLA. Còn với giấy phép permissive thì cần hiểu rằng rug pull là “một phần của cuộc chơi”
  • Các dự án GNU cũng yêu cầu CLA, nhưng có lẽ họ không làm vậy với mục đích rug pull
  • Cần làm rõ rằng ký CLA không phải lúc nào cũng đồng nghĩa trao toàn bộ quyền cấp phép lại; còn tùy từng CLA. Ví dụ, theo điều khoản CLA của Canonical(liên kết), phần đóng góp của tôi vẫn được cam kết cung cấp theo giấy phép hiện có. Quan trọng là phải đọc và hiểu CLA. Phần lớn CLA vẫn để bản quyền thuộc về người đóng góp, nên bạn vẫn giữ quyền làm điều mình muốn với phần đóng góp của mình. Vấn đề cốt lõi là niềm tin vào chủ dự án có thể bị phá vỡ. CLA trao quyền kiểm soát cho chủ dự án nên làm tăng rủi ro rug pull. Muốn đối phó với rug pull thì trên thực tế phải fork và tự cộng tác trực tiếp thì mới có lợi. Trường hợp giấy phép copyleft đi kèm CLA (ví dụ AGPL + CLA) thậm chí có thể còn có hại hơn permissive + CLA. AGPL buộc phải công khai mã nguồn cả khi triển khai dưới dạng dịch vụ, nhưng với CLA thì chủ dự án có thể vận hành dịch vụ đóng mà không cần công khai các cải tiến. Thực tế đã có những trường hợp như Incus và LXD, nơi tổ hợp giấy phép và CLA dẫn đến chia rẽ cộng đồng và hạn chế chia sẻ mã(bài viết chi tiết)
  • Có người cho rằng hiện tượng rug pull không tồn tại trong mã nguồn mở. Bản sao GPL sẽ tồn tại mãi mãi
  • Dùng giấy phép permissive thì khả năng rug pull cao hơn thật, nhưng cũng cần chỉ ra rằng CLA không phải lúc nào cũng trao toàn bộ quyền
  • Có ý kiến cho rằng việc dùng diễn ngôn tiêu cực như "rug pull" trong mã nguồn mở theo hướng quá thuần khiết là không lành mạnh. Dự án cần phải bền vững. Trong bối cảnh các nhà cung cấp cloud lớn đang độc chiếm hạ tầng, thay vì các lập trình viên nhỏ lẻ tranh cãi quanh dự án mã nguồn mở hoặc dự án dựa trên CLA, tốt hơn là dồn năng lượng vào việc giảm bớt thế độc quyền của các tập đoàn lớn
• Người đóng góp và maintainer thường còn yếu thế hơn cả các công ty nhỏ. Dù vậy, nếu là giấy phép tự do thì khi không hài lòng vẫn có thể fork để đi theo con đường mới. Trường hợp Valkey cho thấy động lực giấy phép thay đổi quanh Redis khá thú vị. Cảm giác vấn đề hiện nay là cộng đồng lập trình viên nói chung đã quá quen với việc dùng dịch vụ cloud nên không còn chủ động fork hay tự triển khai lại OS, compiler, DB như trước. Cũng thường bị bỏ qua rằng các công ty cloud như AWS cung cấp dịch vụ đã góp phần nâng độ nhận diện cho dự án (ví dụ ElasticSearch trở nên nổi tiếng hơn sau khi có trên AWS). Cloud cũng đóng góp cho kernel, gcc, jdk..., nhờ đó các công ty nhỏ cũng gián tiếp được hưởng lợi. Thay vì dễ dàng chỉ trích các cloud lớn, có lẽ nên nghĩ lại về chính mô hình kinh doanh; nếu ngay từ đầu đã là sản phẩm đóng thì sẽ chẳng ai quan tâm
• Nếu không nhận phần mềm dưới dạng binary mà tự build trực tiếp từ source code, khả năng ứng phó khi có sự kiện như rug pull sẽ cao hơn. Người cài từ binary/image của vendor sẽ khó chuyển sang fork hơn, trong khi việc chuyển hạ tầng build sang nguồn mới tương đối đơn giản. Bạn cũng có thể tự áp dụng bản sửa lỗi hoặc tính năng cần thiết, nên giảm phụ thuộc vào bên bảo trì
  • Đó cũng là lý do có người thích Guix. Build từ source là mặc định, nhưng vẫn cung cấp gói binary thông qua cache. Nếu không có binary thì hệ thống sẽ tự build source theo cách reproducible. Ngay cả bản vá cũng có thể cài đơn giản bằng cùng package manager nên không cần hạ tầng build riêng. Với môi trường triển khai quy mô lớn thì có build server sẽ hiệu quả hơn
  • Không hiểu vì sao lại bị downvote, nhưng tôi đồng ý. Build từ source nhìn chung không quá khó (xem sqlite)
  • Cũng có ý kiến nhắc rằng trên thực tế mức độ tự do còn phụ thuộc vào giấy phép phần mềm. Có phần mềm thương mại cũng cung cấp source nhưng giấy phép không cho phép tự do chỉnh sửa. Ví dụ các sản phẩm thương mại dựa trên ngôn ngữ script, hoặc các trường hợp công ty tư vấn bàn giao source cho khách hàng nhưng quyền biên dịch lại phải trả thêm phí riêng
• Sau cú rug pull của Elasticsearch, việc Amazon trực tiếp đóng góp cho fork mã nguồn mở(OpenSearch) có thể xem là một kết quả nhất định, dù không đúng với ý định ban đầu. Tuy vậy, việc doanh nghiệp lớn tạo ra mất cân bằng giữa người đóng góp và bên hưởng lợi, từ đó làm dự án trở nên bất ổn, vẫn là một chủ đề quan trọng
  • Việc sử dụng phần mềm theo đúng giấy phép là không có vấn đề gì; ngược lại, nếu lập trình viên hay startup chỉ chăm chăm vào lan rộng và tăng trưởng rồi dùng giấy phép permissive, đến khi cloud lớn tham gia lại coi đó là vấn đề thì khá mâu thuẫn. Không thể có cả hai cùng lúc
  • Kết quả Elastic mong muốn là tăng doanh thu giấy phép, nhưng nhiều người dùng đã chuyển sang fork, khiến độ tin cậy của Elastic giảm đi. Cạnh tranh giữa OpenSearch và ElasticSearch có thể lại là điều tích cực cho hệ sinh thái, nhưng giờ hai sản phẩm đã mất tương thích và vị thế của Elastic cũng suy yếu
  • Các giấy phép copyleft như AGPL/GPL buộc phải đóng góp lại mã, nhờ đó có thể tạo ra vòng phản hồi mà không cần giấy phép độc quyền
• Dự án mã nguồn mở không phải cứ đổi giấy phép là rug pull sẽ dễ xảy ra. Vấn đề căn bản hơn là thực tế này không phải một môi trường không tưởng nơi ai cũng có thể làm việc miễn phí mà vẫn có chất lượng sống tốt. Không có maintainer thì “chu kỳ bán rã” của dự án sẽ ngắn đi; nếu không có tài trợ thì xu hướng chuyển sang giấy phép đóng sẽ càng tăng tốc
  • Điều này gợi nhớ đến vụ Mojang/Microsoft và cộng đồng Bukkit. Trong quá trình tuyển dụng lập trình viên, họ âm thầm mua lại dự án và để tình nguyện viên làm không công suốt nhiều năm, cuối cùng người đó dùng DMCA để đóng dự án. Xem chi tiết hơn tại: blog
  • Suy cho cùng vẫn là vấn đề incentive. Ngay cả khi tự làm phần mềm mã nguồn mở thì các nhà cung cấp cloud vẫn có thể dễ dàng lấy về để kiếm tiền. Tôi hiểu đó là ý nghĩa của cấu trúc giấy phép FOSS (Fully Open Source Software), nhưng xã hội dường như đã quá quen với lao động không công. Vì vậy các cách tiếp cận mới như SSPL (Source-available licensing) ngày càng có vẻ hấp dẫn. Việc AGPL chỉ khác SSPL một điều khoản mà một bên được coi là foss còn bên kia thì không, tạo cảm giác khái niệm đang khá rối
• Có thể hiểu tâm trạng khó chịu của người dùng trước rug pull, nhưng trên thực tế công ty đang chủ động phát triển và duy trì dự án cũng có giới hạn tài chính nên chỉ còn vài lựa chọn. Nếu không có mô hình doanh thu thì việc đổi giấy phép gần như là điều khó tránh. Một số phương án được nhắc tới là crowdfunding, giảm khối lượng công việc, bán merchandise, hoặc nếu không có thêm nguồn lực thì báo trước việc chuyển sang hướng mở hơn. Bài liên quan
  • Bản chất sự bất mãn là họ từng công bố dưới dạng OSS để tăng người dùng rồi đột ngột đổi sang giấy phép đóng hơn. Nếu ngay từ đầu không phải OSS thì đã không có cảm giác bị phản bội, nhưng vấn đề nằm ở chỗ bắt đầu bằng OSS để thu hút người dùng rồi sau đó thay đổi
  • Mongo, Elastic, Redis, Hashicorp... không hẳn đang trong khủng hoảng tài chính nghiêm trọng vào thời điểm rug pull. Trường hợp Hashicorp thậm chí có thể là chiến lược nâng giá trị trước khi bị mua lại
• Gần đây còn xuất hiện ngày càng nhiều trường hợp dựng lên governance board, đưa ra quy trình vận hành bị siết chặt bởi quy định để khiến giới kỹ thuật tự rút lui, rồi đàn áp ý kiến phản đối và thu hồi quyền trong dự án. Một bầu không khí kiểu Orwell núp dưới danh nghĩa “an toàn” đang được đưa vào cộng đồng
• Gần như mọi người dùng mã nguồn mở đều là free rider. Chúng ta sử dụng dự án một cách tự do mà không đóng góp gì. Có thể xem mã nguồn mở như một món quà vô điều kiện, hoặc như văn hóa tham khảo bài làm của người khác. Nếu muốn cống hiến cho thế giới thì hãy sẵn sàng làm, nhưng đừng kỳ vọng bất kỳ phần thưởng nào. Việc gọi thay đổi giấy phép là rug pull cũng là một cách nhìn thiên lệch. Dù sao thì chúng ta đã nhận được mã, và dù việc đổi hướng là điều đáng tiếc, không gì trên đời là tồn tại mãi mãi
  • Nhận định rằng "đa số chúng ta chỉ dùng mà không đóng góp lại gì" không hoàn toàn đúng. Trên thực tế nhiều dự án đã nhận được đóng góp đa dạng từ code, test, tài liệu, marketing đến truyền bá. Những dự án này không phải sản phẩm âm thầm được đưa ngẫu nhiên lên GitHub, mà là kết quả của việc công ty bỏ nhiều tiền thuê developer evangelist để quảng bá ưu điểm kỹ thuật và giấy phép, mở rộng tập người dùng. Trong bối cảnh đó, nhận hàng loạt đóng góp và code rồi đột ngột đổi giấy phép, nhất là khi các dự án FOSS khác đang phụ thuộc vào nó, chính là lý do bị chỉ trích là rug pull. Nếu là một dự án tự nhiên được đưa lên GitHub không có marketing gì rồi dần được chấp nhận thì có lẽ đã không bị xem là rug pull; nhưng những trường hợp như vậy gần như rất hiếm
  • Cũng không nhất thiết phải vận hành theo cách đó. Doanh nghiệp hoặc tổ chức có nguồn lực hoàn toàn có thể tăng tính bền vững bằng cách đóng góp tài chính và kỹ thuật cho các dự án mã nguồn mở mà họ phụ thuộc. Có thể thành lập Open Source Program Office, phân tích toàn bộ phần mềm và dependency đang sử dụng, dành thời gian của contributor và tài trợ tiền bạc, đồng thời khuyến khích các đơn vị cùng ngành xây dựng văn hóa tương tự
• Ngay tại công ty hiện tại, ban điều hành cũng đang rối vì các vấn đề rug pull. Họ luôn ưu tiên ký hợp đồng hỗ trợ cho hệ thống, nhưng các tình huống tương tự đã lặp lại với Chef, CentOS, VMWare, Broadcom... Dù đã sẵn sàng trả tiền để dùng, dịch vụ bảo trì cơ bản vẫn lên tới vài nghìn đến vài chục nghìn đô mỗi năm, mà vẫn không tạo được niềm tin. Trong tình cảnh đó, có cảm giác thà tài trợ cho foundation hoặc trực tiếp thuê maintainer OSS định kỳ còn tốt hơn. Trước đây từng khá hoài nghi với đề xuất này, nhưng càng ngày càng có nhiều sự đồng tình. Nếu là cá nhân tôi, thay vì trả tiền cho VMWare thì tôi sẽ thuê các lập trình viên Proxmox hoặc qemu
  • Tôi nghĩ đó là một ý tưởng đúng đắn. Việc rà soát mọi phần mềm và dependency đang dùng, đóng góp thời gian phát triển lẫn tiền bạc để bảo đảm tính bền vững, và lan tỏa thái độ này trong cùng ngành là rất quan trọng
  • Điều thú vị là các công ty được nhắc tới từng lập open source program office để làm tốt hơn với cộng đồng, nhưng khi tổ chức trở nên quá lớn thì sự hai mặt — khoảng cách giữa lợi ích cộng đồng và lợi ích doanh nghiệp — dường như là cái giá tất yếu
• Fork không phải chuyện dễ, muốn thành công phải có con người và nguồn lực. Mã nguồn mở rốt cuộc chỉ vận hành được khi có đủ người đóng góp. Nếu một fork chết yểu, điều đó có nghĩa là dự án ấy có quá nhiều free rider. Vấn đề lớn nhất của rug pull, theo một góc nhìn, thực chất là quảng cáo sai sự thật. Thu hút khách hàng bằng lời hứa mã nguồn mở rồi khi thấy bất lợi cho mình lại phá bỏ cam kết đó là điều có vấn đề về mặt đạo đức. Tuy vậy, việc ngừng đóng góp tự thân không phải điều đáng lo; không ai có nghĩa vụ phải gắn bó với dự án mãi mãi, nên cá nhân hay công ty rút lui cũng là chuyện tự nhiên