Tác nhân viết mã có thể làm phần mềm miễn phí quan trọng trở lại.

Gần đây tôi đã viết mã theo cảm xúc rất nhiều. Giống như, rất nhiều rất nhiều. Có lẽ không hẳn là “bệnh tâm thần AI” mà Andrej Karpathy đã nói đùa gần đây trên No Priors, nhưng cũng không quá xa vời.[1] Nhưng tôi càng rung cảm thì một ý nghĩ càng xuất hiện nhiều hơn, tức là Các đại lý mã hóa AI có thể sắp biến phần mềm miễn phí trở nên quan trọng hơn bao giờ hết. Không phải nguồn mở theo nghĩa nhạt nhẽo của công ty. Ý tôi là phần mềm miễn phí theo nghĩa của Stallman: phần mềm cho phép người dùng tự do chạy, nghiên cứu, sửa đổi và chia sẻ nó.

Ngay cả đối với một số ít người biết đến sự khác biệt này, nó vẫn mang lại cảm giác mang tính học thuật trong một thời gian dài. SaaS khiến việc quan tâm đến quyền tự do phần mềm trở nên khó khăn vì hầu hết mọi người ngay từ đầu chưa bao giờ nhìn thấy hoặc chạm vào mã nguồn của phần mềm mà họ phụ thuộc vào. Mã tồn tại trên máy chủ của người khác, nhà cung cấp xử lý các hoạt động và câu hỏi thực tế trở thành sự thuận tiện chứ không phải tự do.

Các đại lý thay đổi điều đó. Nếu một tác nhân có thể đọc cơ sở mã, hiểu và sửa đổi nó thay mặt bạn thì quyền truy cập vào mã nguồn sẽ không còn là một quyền mang tính biểu tượng đối với các lập trình viên mà trở thành một khả năng thiết thực cho nhiều người hơn. Đột nhiên, sự khác biệt giữa phần mềm bạn có thể thay đổi và phần mềm bạn chỉ có thể cầu xin bắt đầu thực sự trở nên quan trọng.

Và tôi không chỉ nghĩ điều này một cách trừu tượng. Gần đây, tôi đã cố gắng nhờ một nhân viên AI tùy chỉnh ứng dụng SaaS cho mình và trải nghiệm này đã khiến toàn bộ vấn đề trở nên cụ thể rất nhanh chóng.

Phần mềm miễn phí từng có tầm quan trọng sâu sắc nhưng đã lụi tàn khi SaaS khiến những quyền tự do đó trở nên không còn phù hợp.

Năm 1980, Richard Stallman[2] là lập trình viên tại Phòng thí nghiệm AI của MIT và ông gặp vấn đề với máy in. Phòng thí nghiệm có một máy in laser Xerox mới nhưng nó vẫn bị kẹt giấy. Stallman muốn khắc phục sự cố - hoặc ít nhất là thêm một tính năng để thông báo cho người dùng khi lệnh in của họ bị kẹt - nhưng Xerox không cung cấp cho anh mã nguồn. Phần mềm của máy in là độc quyền.

Việc này có vẻ như là chuyện nhỏ. Đó không phải là chuyện nhỏ với Stallman.

Anh ấy lớn lên trong một nền văn hóa điện toán nơi việc chia sẻ mã là điều bình thường. Khi bạn có phần mềm, bạn có mã nguồn, bởi vì tất nhiên bạn đã có - bạn sẽ sửa lỗi hoặc thêm tính năng bằng cách nào khác? Sự cố máy in Xerox đã kết tinh một điều gì đó cho anh ấy: một thế giới nơi phần mềm bị khóa, nơi bạn không thể nghiên cứu hoặc sửa đổi các công cụ mà bạn phụ thuộc vào, là một thế giới nơi người dùng đã mất đi thứ gì đó cơ bản.

Vì vậy, Stallman đã thành lập Tổ chức Phần mềm Tự do và dành bốn thập kỷ tiếp theo để truyền bá cái mà ông gọi là “bốn quyền tự do”:

• Quyền tự do 0: Quyền tự do chạy chương trình theo ý muốn của bạn, vì bất kỳ mục đích nào.
• Quyền tự do 1: Quyền tự do nghiên cứu cách chương trình hoạt động và thay đổi nó để thực hiện những gì bạn muốn.
• Tự do 2: Quyền tự do phân phối lại sao chép để bạn có thể giúp đỡ người khác.
• Quyền tự do 3: Quyền phân phối bản sao các phiên bản đã sửa đổi của bạn cho người khác.

“Tự do như trong lời nói,” anh ấy nói, “không tự do như trong bia.”

Thông điệp này đã gây được tiếng vang trong một thời gian. Những năm 1990 chứng kiến ​​sự bùng nổ của phần mềm miễn phí: Linux, Apache, MySQL, PHP - toàn bộ hệ thống sẽ cung cấp năng lượng cho hầu hết Internet. Các công ty như Red Hat đã chứng minh rằng bạn có thể xây dựng doanh nghiệp thực sự dựa trên nó. Eric Raymond đã viết “The Cathedral and the Bazaar” và lập luận rằng sự phát triển mở tạo ra phần mềm tốt hơn. Steve Ballmer của Microsoft gọi Linux là “một căn bệnh ung thư”. Nó giống như một cuộc chiến ý thức hệ thực sự vì linh hồn của máy tính.

Và rồi, lặng lẽ, trận chiến trở nên vô nghĩa, vì một lý do khá nhàm chán.

Nhưng chúng ta sẽ quay lại vấn đề đó sau.

Việc đổi tên thương hiệu “nguồn mở” bảo đảm việc chia sẻ mã trong khi loại bỏ triết lý về quyền người dùng.

Đầu tiên, đây là một phần lịch sử mà tôi chưa biết trước khi nghiên cứu bài đăng này. Điều quan trọng là phải hiểu được điều gì đang xảy ra hiện nay.

Vào ngày 3 tháng 2 năm 1998, một nhóm người gặp nhau tại Viện Foresight ở Palo Alto — không phải là một tổ chức phần mềm mà là một tổ chức nghiên cứu về công nghệ nano. Christine Peterson, giám đốc điều hành của viện, đã đề xuất thay thế “phần mềm miễn phí” bằng một thuật ngữ mới: “nguồn mở”.[3] Lý do của cô ấy rất thực tế: mỗi khi bạn nói “phần mềm miễn phí”, mọi người đều nghĩ bạn muốn nói đến phần mềm miễn phí và bạn sẽ dành mười phút để giải thích sự khác biệt thay vì nói về phần mềm thực tế.

Vài tuần sau, tại “Hội nghị thượng đỉnh phần mềm miễn phí” tháng 4 năm 1998 của Tim O’Reilly, những người tham dự đã tranh luận về việc đặt tên và bỏ phiếu với tỷ lệ 9-6 cho “nguồn mở” thay vì các lựa chọn thay thế như “phần mềm nguồn” và “phần mềm miễn phí”.[4]

Điều quan trọng là những gì đã bị mất đi trong quá trình đổi thương hiệu. Eric Raymond và Bruce Perens đồng sáng lập Sáng kiến Nguồn Mở cùng tháng đó và Raymond đã xuất bản một tuyên ngôn có tên “Tạm biệt, ‘phần mềm miễn phí’; xin chào, ‘nguồn mở.'” Lập luận chính của ông: thuật ngữ cũ khiến các loại hình công ty lo lắng.[5]

Stallman đã không được mời tham dự “Hội nghị thượng đỉnh về phần mềm miễn phí” của Tim O’Reilly vào tháng 4 năm 1998 — sự kiện đã giúp củng cố câu chuyện về lãnh đạo mới. Linus Torvalds đã được mời. Larry Wall đã được mời. Guido van Rossum được mời. Stallman thì không.[4]

Tại sao điều này lại quan trọng? Bởi vì việc đổi thương hiệu “nguồn mở” không chỉ là một thay đổi về tiếp thị - nó là một sự cắt cụt về mặt triết học. “Nguồn mở” vẫn giữ nguyên các hoạt động chia sẻ mã nhưng đã loại bỏ một cách khéo léo các tuyên bố mang tính đạo đức về những gì người dùng xứng đáng. Như Stallman đã nói: “Nguồn mở là một phương pháp phát triển; phần mềm miễn phí là một phong trào xã hội.”[6] Raymond đã nói rõ rằng “phần mềm miễn phí” gây nhầm lẫn và khiến các loại hình công ty lo lắng.[5]

Thế giới doanh nghiệp yêu thích điều này. Bạn có thể sử dụng mã nguồn mở, đóng góp cho các dự án nguồn mở và xây dựng nhận diện thương hiệu nguồn mở mà không cần phải vật lộn với câu hỏi người dùng nợ những gì. Nguồn mở đã trở thành một phương pháp phát triển mà các tập đoàn có thể áp dụng mà không hề thay đổi mối quan hệ của họ với người dùng.

SaaS mở rộng quy mô bằng cách khai thác lỗ hổng cấp phép cho phép nhà cung cấp tránh chia sẻ các sửa đổi của họ.

Nhưng cuối cùng, đó không phải là một cuộc tranh luận chính trị hay triết học thực sự khiến phần mềm miễn phí bị gạt sang một bên – đó là SaaS.

GPL — giấy phép phần mềm miễn phí chính — yêu cầu bạn chia sẻ mã nguồn với bất kỳ ai mà bạn phân phối phần mềm đó. Từ khóa là “được phân phối”. Nếu bạn chưa bao giờ phân phối phần mềm — nếu bạn chỉ chạy phần mềm đó trên máy chủ của riêng mình và cho phép mọi người truy cập phần mềm đó qua web — thì giấy phép sẽ không được áp dụng. Bạn có thể lấy phần mềm miễn phí, sửa đổi nó, xây dựng doanh nghiệp trên đó và không bao giờ chia sẻ những sửa đổi của mình với bất kỳ ai.

Đây không phải là giả thuyết. Một ví dụ điển hình là AWS cung cấp các dịch vụ được quản lý xung quanh các dự án như Elaticsearch, điều này đã gây ra những tranh chấp rất công khai về việc nắm bắt giá trị, đóng góp và các điều khoản cấp phép.[7] Trong mô hình SaaS, các nghĩa vụ copyleft của GPL thường không được kích hoạt trừ khi phần mềm được phân phối, do đó các yêu cầu chia sẻ nguồn có thể được bỏ qua.[8]

Những con số kể câu chuyện về những gì xảy ra tiếp theo: từ những năm 2010 đến những năm 2020, các giấy phép cấp phép ngày càng trở nên chiếm ưu thế trong dữ liệu sử dụng nguồn mở.[9]

Đã có nỗ lực khắc phục điều này. AGPL (Affero GPL) được thiết kế để đóng lỗ hổng SaaS — nếu bạn sửa đổi phần mềm AGPL và cung cấp nó qua mạng, bạn phải chia sẻ mã nguồn.[8] Đó là một ý tưởng mạnh mẽ. Đến mức Google hiện duy trì chính sách công rộng rãi cấm mã AGPL trong Google.[10] Như Drew DeVault đã lập luận,
Lập trường chống AGPL của Google không chỉ là một biện pháp phòng ngừa pháp lý — mà nó còn mang tính chiến lược: “Bằng cách không khuyến khích việc sử dụng
AGPL trong cộng đồng rộng lớn hơn, Google hy vọng sẽ tạo ra một bộ phần mềm nguồn mở và miễn phí lớn hơn
họ có thể tự đáp ứng nhu cầu của mình mà không cần bất kỳ nghĩa vụ nào.”

Việc áp dụng có giới hạn AGPL đã tạo ra một loạt các ứng biến. MongoDB đã chuyển sang Giấy phép Công cộng Phía Máy chủ. Redis Labs đã chuyển một số mô-đun Redis sang cấp phép theo kiểu Điều khoản Commons vào năm 2018 và Redis sau đó đã chuyển Redis lõi sang cấp phép nguồn kép có sẵn trước khi thêm AGPL vào Redis 8. HashiCorp đã chuyển Terraform sang Giấy phép Nguồn Kinh doanh. Elastic chuyển từ Apache sang SSPL/ELv2, sau đó thêm AGPL. Mỗi công tắc đều xác thực vấn đề tiềm ẩn trong khi không giải quyết được hoàn toàn vấn đề đó.[11]

Và thành thật mà nói thì sao? Từ góc độ người dùng, câu hỏi về quyền tự do phần mềm không còn quan trọng nữa. Khi phần mềm chạy trên máy chủ của người khác, việc có mã nguồn không giúp ích gì cho bạn. Bạn không thể chạy phiên bản đã sửa đổi của riêng mình vì bạn không chạy bất kỳ phiên bản nào — Salesforce chạy, Google chạy hoặc bất cứ ai. Bốn quyền tự do đã trở thành lý thuyết.

Trong một thời gian, sự đánh đổi có vẻ ổn. SaaS cực kỳ tiện lợi. Không cần cài đặt, cập nhật tự động, truy cập từ mọi nơi, người khác xử lý các bản vá bảo mật và bản sao lưu cũng như các trang 3 giờ sáng khi máy chủ ngừng hoạt động. Vì vậy, cuộc tranh luận về phần mềm miễn phí đã mờ nhạt dần. Con lắc đã chuyển động dứt khoát theo hướng thuận tiện và hầu hết chúng tôi - bao gồm cả tôi - đã chấp nhận giao dịch.

Sau đó, AI bắt đầu khiến người mua cảm thấy hối hận.

Quy trình làm việc Sunsama của tôi cho thấy SaaS đã đóng chặn các tùy chỉnh hữu ích như thế nào ngay cả đối với những người dùng có động lực.

Tôi sử dụng Sunsama để quản lý tác vụ. Đó là một sản phẩm đẹp và tôi thực sự thích nó. Nhưng tôi có một quy trình làm việc mà tôi muốn xây dựng và Sunsama đã khiến điều đó về cơ bản là không thể thực hiện được.

Quy trình làm việc rất đơn giản: khi tôi đang lướt Twitter và nhìn thấy một dòng tweet mà tôi muốn tương tác sau, cho dù đó là một bài viết tôi muốn đọc sau hay một công cụ AI loạn trí có chủ đề về loài mèo hoang miền Tây hoang dã mà tôi muốn thử, tôi muốn lưu nó cho Sunsama như một nhiệm vụ để tôi có thể lên lịch cho nó so với 20 tỷ việc khác mà cuối cùng tôi muốn làm.

Sunsama có tích hợp bảng chia sẻ iOS, nhưng iOS có nhiều thao tác nhấn và tôi không thích cách hoạt động của nó:

Đầu tiên, tác vụ mà nó tạo ra về cơ bản chỉ là một URL có bất kỳ tiêu đề nào mà iOS lấy từ dòng tweet. Tôi muốn LLM tạo tiêu đề nhiệm vụ như “Trả lời @whoever về câu hỏi của họ về đo lường phương tiện truyền thông” thay vì “tweet từ @dril” hoặc bất kỳ nội dung rác rưởi nào mà hành vi chia sẻ mặc định tạo ra.

Thứ hai, tôi không thể tự động gắn nhãn hoặc phân loại những nhiệm vụ này. Tôi muốn các bài đăng về sức khỏe được xếp vào danh mục #sức khỏe và các bài đăng về tuyển dụng được đưa vào danh mục #tuyển dụng. Nhưng bảng chia sẻ chỉ chuyển mọi thứ vào hộp thư đến của tôi.

Nhưng sở thích của tôi không liên quan vì tôi không thể thêm bất kỳ thông tin nào do LLM hỗ trợ vào quy trình làm việc này ngoài bất kỳ điều gì Sunsama quyết định đưa vào sản phẩm của họ. Nếu nhóm của Sunsama cung cấp một tính năng AI có thể tự động phân loại nhiệm vụ thì thật tuyệt. Nếu họ không làm vậy thì tôi không gặp may. Tôi chỉ có thể gửi yêu cầu tính năng và kiểm tra lại vào năm 2032.

Đây không phải là vấn đề về kỹ năng. Tôi biết cách viết mã. Tôi có thể xây dựng hệ thống quản lý công việc của riêng mình từ đầu. Hạn chế không phải là chuyên môn kỹ thuật - đó là thời gian và sự chú ý. Tôi có một công việc. Tôi có một cuộc sống. Lý do tôi sử dụng Sunsama là vì tôi không muốn tham gia vào công việc bảo trì phần mềm quản lý tác vụ.

Đây là món hời SaaS cổ điển. Nhận được sự thuận tiện, từ bỏ quyền kiểm soát.

Dù sao thì tôi cũng đã cố gắng xây dựng quy trình làm việc và mọi lớp khép kín đều biến một ý tưởng đơn giản thành một bản hack dễ vỡ.

Có hỗ trợ chính thức hay không thì tôi cũng muốn có cái tiện ích nhỏ bé ngu ngốc của mình. Vì vậy, tôi quyết định thực sự cố gắng xây dựng nó. Tôi ngồi lại với Codex và nói: hãy tạo cho tôi một nút duy nhất trong bảng chia sẻ Twitter trên iOS để thêm dòng tweet dưới dạng tác vụ được gắn nhãn chính xác cho Sunsama của tôi.

Đơn giản phải không? Người đại diện hiểu ngay tôi muốn gì. Nó có thể thấy toàn bộ kiến trúc: Lối tắt iOS bắt URL được chia sẻ, gọi một hàm nhỏ không có máy chủ, hàm này trích xuất nội dung tweet, chuyển nó đến LLM để tạo tiêu đề tác vụ thông minh, sau đó tạo tác vụ trong Sunsama với danh mục phù hợp.

Về mặt khái niệm, đây là một dự án kéo dài 20 phút. Trên thực tế, nó đã trở thành một chuyến tham quan có hướng dẫn về mọi vấn đề xảy ra với phần mềm đã đóng.

Lớp 1: Sunsama không có API chính thức. Vào năm 2026. trang yêu cầu tính năng của họ cho một API đã mở từ tháng 12 năm 2019 và được người dùng yêu cầu. Một người bình luận gần đây đã viết "Có phải những người sáng lập đã thực sự bỏ qua tấm vé này trong gần sáu năm rồi không!? Thật thảm hại." Vì vậy, người đại diện của tôi, dù thông minh đến đâu, cũng không có cách nào phù hợp để tạo một nhiệm vụ theo chương trình.

Nhưng may mắn thay, một người dùng Sunsama tên là Robert Niimi đã đủ nản lòng để đảo ngược API nội bộ của Sunsama và xuất bản kết quả dưới dạng nguồn mở: a Chuyển tiếp API REST tự lưu trữ được gọi là sunsama-relay, cùng với máy chủ MCP được gọi là mcp-sunsama để Claude có thể sử dụng trực tiếp. Vì vậy, người đại diện của tôi có thể tạo các nhiệm vụ Sunsama — nhưng chỉ vì một người quyết tâm đã dành thời gian của mình để đảo ngược các luồng xác thực và công bố kết quả miễn phí. Nếu không có công việc của anh ấy, có lẽ tôi đã bỏ cuộc.

Lớp 2: Xác thực là mật khẩu thực của bạn. Vì không có API chính thức nên không có khóa API hoặc mã thông báo OAuth. API không chính thức xác thực bằng email và mật khẩu Sunsama thực tế của bạn. Vì vậy, chức năng không có máy chủ của tôi cần lưu trữ thông tin xác thực thực của tôi. Đây là hệ quả trực tiếp của mô hình SaaS — Sunsama chưa bao giờ lường trước hoặc ủng hộ trường hợp sử dụng này, vì vậy cách duy nhất để vào là đi qua cửa trước với danh tính bản rõ của bạn.

Lớp 3: Bức tường iOS. Tôi đã nhờ Codex xây dựng chức năng serverless, bao gồm trích xuất tweet, tạo tiêu đề do LLM hỗ trợ và tạo tác vụ Sunsama. Nó đã hoạt động. Nhưng sau đó tôi cần kết nối nó với Phím tắt iOS để có thể kích hoạt nó từ bảng chia sẻ Twitter. Codex có thể tạo Lối tắt iOS cho tôi theo chương trình không? Không. Apple ghi lại Ý định ứng dụng dành cho nhà phát triển hiển thị các hành động trong ứng dụng, nhưng không cung cấp định dạng tệp/API công khai được ghi lại để tạo các Phím tắt tùy ý cho người dùng cuối theo chương trình.[12] Vì vậy, tôi vẫn phải mở Phím tắt, nhấn qua trình tạo trực quan và thêm từng hành động theo cách thủ công. Tác nhân của tôi có thể viết một máy chủ TypeScript 200 dòng trong vài giây, nhưng nó không thể tự động hóa việc tạo Lối tắt iOS gồm 5 bước. iOS (mặc dù được xây dựng dựa trên BSD và sử dụng nhiều thành phần nguồn mở) là đối lập với phần mềm miễn phí.

Kết quả: Đây là những gì giải pháp “hoạt động” thực sự yêu cầu:

1. Một chức năng không có máy chủ mà tôi phải tự triển khai và lưu trữ
2. Khóa API Anthropic để tạo tiêu đề
3. Mật khẩu Sunsama thực tế của tôi được lưu trữ dưới dạng biến môi trường
4. Sự phụ thuộc vào API được thiết kế ngược không chính thức có thể bị hỏng bất cứ lúc nào
5. Một lối tắt iOS mà tôi phải tạo thủ công (sau rất nhiều lần sửa lỗi tỉ mỉ đến mức ngớ ngẩn, vì các thao tác phím tắt liên tục bị lỗi trong iOS với các thông báo lỗi không rõ ràng và không có nhật ký có thể truy cập được.)
6. Điểm cuối oEmbed của Twitter/X để lấy siêu dữ liệu nhúng tweet

Cuối cùng thì nó cũng thành công. Tôi có thể chia sẻ một dòng tweet và nhận được một nhiệm vụ có tiêu đề hay trong Sunsama vài giây sau đó và tôi đã sử dụng nó thường xuyên.

Nhưng hãy nhìn xem điều đó đã xảy ra:

Sáu lớp giải pháp, ba cơ chế xác thực khác nhau, sự phụ thuộc vào dự án kỹ thuật đảo ngược của người lạ, cơ sở hạ tầng mà tôi hiện chịu trách nhiệm và Lối tắt iOS được tạo thủ công mà tôi không thể kiểm soát hoặc chia sẻ phiên bản.

Hãy so sánh điều này với những gì sẽ xảy ra nếu Sunsama và iOS là phần mềm miễn phí: tác nhân đọc mã nguồn, hiểu mô hình dữ liệu tác vụ, sửa đổi hành vi của bảng chia sẻ mặc định theo ý thích của tôi, thế là xong. Mười phút dành cho Codex, không cần kỹ thuật đảo ngược, không có API vùng xám.

Nhân viên AI cuối cùng cũng có thể thực hiện quyền tự do sử dụng phần mềm thay mặt cho những người không biết viết mã.

Lập luận ban đầu của Stallman có một điểm yếu thực sự và chính đáng — điểm yếu mà các nhà phê bình đã đúng khi xác định trong nhiều thập kỷ. Bốn quyền tự do — chạy, nghiên cứu, sửa đổi, phân phối lại — giả định trước khả năng đọc và sửa đổi mã nguồn. Đối với đại đa số người dùng máy tính, khả năng đó không tồn tại.

Lời phê bình này đã được đưa ra nhiều lần. Protesilaos Stavrou đã trình bày rõ ràng : chỉ riêng giấy phép phần mềm miễn phí sẽ không trao quyền cho người dùng để được thực sự tự do nếu họ thiếu chuyên môn để thực hiện các quyền tự do đó - phong trào đã thu hẹp trọng tâm của mình vào các yêu cầu pháp lý và mã, hạn chế đối tượng của nó một cách hiệu quả ở những người đam mê kỹ thuật. Mahmoud Mazouz đã đưa ra một lập luận có liên quan: ngay cả khi mã nguồn có sẵn, chi phí thực tế của việc xây dựng, hiểu và sửa đổi nó vẫn rất cao đối với hầu hết mọi người. Bốn quyền tự do được viết cho các lập trình viên và hầu hết mọi người không phải là lập trình viên.

Các đại lý hoàn toàn lật ngược điều này.

Hãy nghĩ xem tác nhân mã hóa AI thực sự là gì: đó là một trung gian có thể thực hiện quyền tự do kỹ thuật thay mặt cho người dùng không rành về kỹ thuật. Khi bạn nói với Claude hoặc Codex “làm cho trình quản lý tác vụ của tôi tự động phân loại các tweet tôi lưu”, bạn đang thực hiện Quyền tự do 1 - quyền tự do nghiên cứu và sửa đổi - thông qua proxy. Bạn không cần phải hiểu cơ sở mã. Bạn không cần biết lược đồ GraphQL là gì. Bạn chỉ cần mô tả những gì bạn muốn và người đại diện sẽ thực hiện các quyền tự do về kỹ thuật cho bạn.

Điều này thu hẹp khoảng cách giữa quyền tự do phần mềm như một quyền trừu tượng và quyền tự do phần mềm như một khả năng thực tế. Bốn quyền tự do luôn được viết như thể cuối cùng ai đó sẽ đọc được mã. Vào năm 2026, cuối cùng thì điều gì đó cũng có thể và có thể thay mặt bạn làm điều đó.

Hãy xem điều này có ý nghĩa gì đối với một người không rành về kỹ thuật bị mắc kẹt trong tình huống Sunsama của tôi. Ngày nay, họ không có lựa chọn nào. Họ không thể mã hóa một cách giải quyết. Họ không thể thiết kế ngược một API. Họ có thể gửi yêu cầu tính năng và đợi sáu năm. Thế thôi. Mối quan hệ của họ với phần mềm là một mối quan hệ hoàn toàn phụ thuộc và khi phần mềm không làm được những gì họ cần, họ chỉ… sống chung với nó. Bất kỳ ai đã từng chiến đấu với một công cụ SaaS cứng nhắc đều gần như nhưng chưa hiểu rõ cảm giác này.

Bây giờ hãy giao cho người đó một đại lý. Nếu phần mềm là nguồn mở và miễn phí, tác nhân có thể đọc cơ sở mã, hiểu mô hình dữ liệu và thực hiện sửa đổi chính xác mà người dùng cần. Không phải là một cách giải quyết. Không phải là hack. Một sửa đổi thực tế về cách thức hoạt động của phần mềm, phù hợp với nhu cầu cụ thể của một người. Người chưa bao giờ có thể viết một dòng mã giờ đây thực sự là người sử dụng quyền lực ở mức cao nhất - bởi vì người đại diện của họ có thể như vậy.

Nhưng nếu phần mềm đó là SaaS độc quyền thì sao? Đặc vụ chạm vào những bức tường giống như tôi đã chạm vào. Không có mã nguồn. Có thể là API (gần như chắc chắn với giới hạn tốc độ và các hoạt động được hỗ trợ hạn chế.) Nếu không thì không có cách nào.

Điều này làm cho quyền tự do phần mềm trở nên ít mang tính học thuật hơn và phù hợp thực tế hơn so với nhiều thập kỷ trước. Không chỉ đối với tôi (và nó rất phù hợp với tôi!) mà ngày càng phù hợp với tất cả mọi người, dù có kỹ thuật hay không. Bốn quyền tự do không còn là một quyền lý thuyết nữa mà bắt đầu là sự khác biệt thực tế giữa “người đại diện của tôi đã giải quyết việc này cho tôi trong mười phút” và “Đồ ngốc, đồ ngu ngốc tuyệt đối. Bạn nghĩ bạn có thể giải quyết được vấn đề của chính mình không?”

Sự thay đổi này đã được thể hiện rõ ở nhiều nhà tư tưởng, những người coi các tác nhân làm tăng giá trị của sự cởi mở.

Những người khác đang bắt đầu kết nối những điểm này lại, mặc dù từ những góc độ khác nhau.

Vào tháng 1 năm 2026, Nawaz Dhandala tại OneUptime đã viết về cách các tác nhân AI mang lại cho phần mềm nguồn mở một “lợi thế không thể vượt qua” so với các lựa chọn thay thế nguồn đóng, bởi vì các tác nhân có thể đọc, hiểu và sửa đổi mã nguồn thực tế thay vì bị giới hạn ở mức được nhà cung cấp ưu ái API. Việc đóng khung của anh ấy rất hữu ích: câu hỏi không phải là “chúng ta có đủ chuyên môn để tùy chỉnh điều này không?” nữa, đó là “chúng ta có muốn toàn quyền kiểm soát kho phần mềm của mình không?”

Martin Alderson đã đưa ra một lập luận liên quan , nhận thấy rằng trước đây anh ấy đã tìm kiếm một công cụ SaaS trả phí để giải quyết, giờ đây anh ấy chỉ cần một đại diện giải quyết “trong vài phút, chính xác theo cách tôi muốn”. Anh ấy cũng giải quyết vấn đề phản đối việc bảo trì (điều mà tôi nghĩ là quan trọng), tức là. rằng các đại lý giảm đáng kể chi phí bảo trì và không giống như một kỹ sư đã xây dựng công cụ nội bộ của bạn rồi rời công ty, “các đại lý không rời đi”.

John Loeber đã mở rộng đối số vào tháng 2 năm 2026, dự đoán “một đợt hồi hương lớn dữ liệu người dùng từ nhiều dịch vụ rời rạc về một nơi”, bởi vì việc lưu trữ dữ liệu cục bộ sẽ khiến AI của bạn trở nên hữu ích hơn đáng kể. Ông gọi điều này là “cực kỳ hy vọng cho các giá trị nguồn mở” và “giảm giá cho phần mềm độc quyền”.

Ngay cả Vitalik Buterin cũng cân nhắc , viết vào tháng 7 năm 2025 rằng anh ấy đã chuyển từ ủng hộ các giấy phép dễ dãi sang copyleft, lập luận rằng “sự cởi mở khác 0 là cách duy nhất mà thế giới cuối cùng không hội tụ về một tác nhân kiểm soát mọi thứ”. Khi người xây dựng Ethereum nói với bạn rằng cơ chế đồng thuận giấy phép cho phép là sai, thì điều đó ít nhất cũng đáng được chú ý.

Con lắc có thể quay trở lại trạng thái mở, nhưng sự thuận tiện và tính kinh tế của người bảo trì vẫn là vấn đề quan trọng.

Vì vậy, đây là nơi tôi muốn nói với bạn rằng câu trả lời rõ ràng là tất cả chúng ta nên chuyển sang phần mềm nguồn mở tự lưu trữ và giành lại quyền tự do sử dụng máy tính của mình.

Nhưng tôi sẽ không nói với bạn điều đó vì thực ra trước đây tôi đã từng tự lưu trữ phần mềm và tôi biết chi phí của nó.[13]

Tự lưu trữ có nghĩa là bạn chịu trách nhiệm cập nhật bảo mật, sao lưu, chứng chỉ SSL, DNS và tất cả chi phí hoạt động khác mà nhà cung cấp SaaS xử lý cho bạn. Và tôi đã không có đủ thời gian. Lý do tôi sử dụng Sunsama là vì tôi đang cố gắng quản lý thời gian của mình tốt hơn. Việc thêm “duy trì cơ sở hạ tầng tự lưu trữ của tôi” vào danh sách nhiệm vụ sẽ không đạt được mục đích.

Ngoài ra còn có một quan điểm đáng báo động đáng được quan tâm. Một bài báo làm việc năm 2026 do CEU liên kết (“Vibe Coding Kills Open Source”) lập luận rằng mã hóa rung cảm có thể làm hỏng nguồn mở bằng cách cắt đứt vòng phản hồi của người dùng-người duy trì.[14] Adam Wathan, người tạo ra Tailwind CSS, đã báo cáo rằng lưu lượng truy cập tài liệu đã giảm ~40% kể từ đầu năm 2023 ngay cả khi mức sử dụng Tailwind tăng lên và cho biết doanh thu đã giảm ~80%; ông cũng cho biết 75% đội ngũ kỹ sư của Tailwind vừa bị sa thải.[15] Mitchell Hashimoto, người tạo ra Terraform, công khai cho biết ông đang cân nhắc việc đóng cửa các PR bên ngoài và sau đó chuyển Ghostty sang mô hình đóng góp dựa trên chứng từ để ứng phó với làn sóng đóng góp chất lượng thấp do AI tạo ra.[16]

Nếu các tác nhân sử dụng phần mềm nguồn mở mà không hỗ trợ hệ sinh thái tạo ra phần mềm đó thì toàn bộ mọi thứ sẽ sụp đổ. Bốn quyền tự do của Stallman cho chúng ta biết người dùng xứng đáng được hưởng những gì. Họ không nói gì về những gì người bảo trì xứng đáng được hưởng. Khoảng cách đó cuối cùng có thể còn quan trọng hơn bản thân các quyền tự do.

Vì vậy, tôi không nghĩ câu trả lời chỉ đơn giản là “tự mình quay lại điều hành mọi thứ”. Mô hình SaaS đã giải quyết được những vấn đề thực sự và tôi không muốn từ bỏ lợi ích. Và hệ sinh thái nguồn mở có những vấn đề về tính bền vững mà các tác nhân có thể khiến chúng trở nên tồi tệ hơn trước khi cải thiện chúng.

Điều tôi nghĩ là chúng ta sẽ cần những mô hình mới mang lại cho chúng ta những lợi ích tùy chỉnh của phần mềm miễn phí trong khi vẫn duy trì được sự tiện lợi của SaaS. Tôi vẫn chưa biết chính xác nó trông như thế nào. Có thể đó là các sản phẩm SaaS hoàn toàn cởi mở và có khả năng mở rộng hơn những gì chúng ta có ngày nay, với hệ thống plugin thực sự và phạm vi phủ sóng API đầy đủ cũng như khả năng chạy mã tùy chỉnh trên dữ liệu của bạn. Hoặc có thể đến năm 2027, Claude hoặc Codex sẽ không chỉ có thể viết mà còn có thể lưu trữ và vận hành phần mềm.

Thành thật mà nói thì đó là TBD. Ngành công nghiệp vẫn chưa tìm ra điều này. Nhưng tôi nghĩ nhu cầu sắp trở nên rất lớn, bởi vì các đại lý sẽ làm cho chi phí của phần mềm đóng trở nên cực kỳ rõ ràng.

Tiêu chí mua hàng tiếp theo sẽ là liệu đại lý của bạn có thực sự có thể thay đổi phần mềm để phù hợp với nhu cầu của bạn hay không.

Tôi cũng nghĩ rằng trong 1-2 năm tới, chúng ta sẽ chứng kiến sự thay đổi có ý nghĩa trong cách mọi người đánh giá phần mềm. “Đại lý của tôi có thể tùy chỉnh đầy đủ điều này không?” sẽ trở thành một câu hỏi thực sự mà người bình thường hỏi, giống như cách chúng ta hỏi “cái này có ứng dụng di động không?” hoặc “nó có tích hợp với Slack không?”

Tôi chắc chắn sẽ không muốn trở thành CTO của một SaaS kế thừa sống dựa trên giả định rằng “chi phí chuyển đổi” sẽ cho phép nó tiếp tục ép người dùng vào các quy trình làm việc cứng nhắc và UX khó hiểu.

John Gilmore có câu nói nổi tiếng rằng “Mạng coi kiểm duyệt là thiệt hại và các lộ trình xung quanh nó.”[17] Tôi nghĩ chúng ta sắp thấy một phiên bản này dành cho phần mềm đóng. Khi các tác nhân trở thành cách chính mà mọi người tương tác với các công cụ của họ, họ sẽ coi phần mềm không miễn phí là thiệt hại — như một trở ngại giữa người dùng và những gì người dùng muốn — và định tuyến xung quanh nó. Đôi khi điều đó có nghĩa là các API kỹ thuật đảo ngược giống như Robert Niimi đã làm cho Sunsama. Đôi khi điều đó có nghĩa là các đại lý phải xây dựng các giải pháp thay thế nguồn mở nhẹ một cách nhanh chóng. Đôi khi, điều đó chỉ có nghĩa là thay mặt người dùng gửi các yêu cầu theo kiểu GDPR “tải xuống theo dữ liệu” và xây dựng lại toàn bộ bản thay thế tùy chỉnh từ đầu.

Với vai trò là CTO của Upwave, tôi cũng giả định rằng kỷ nguyên phần mềm của chúng ta được con người sử dụng sắp kết thúc và tôi đang hướng chúng ta tới việc xây dựng các khả năng giúp các tác nhân AI tích hợp dễ dàng nhất có thể (và làm như vậy theo cách người dùng của họ ưa thích.) Chúng tôi chưa có kế hoạch cho phép người dùng trực tiếp sửa đổi mã phân tích hoặc đường dẫn dữ liệu chạy trên máy chủ của chúng tôi, nhưng thành thật mà nói…có lẽ chúng tôi nên làm vậy.

Tôi chắc chắn sẽ không muốn trở thành CTO của bất kỳ công ty SaaS nào không có hào nước kiểu “7 quyền lực” chính hãng - hiệu ứng mạng mạnh mẽ, bộ dữ liệu độc quyền (sức mạnh của Upwave), khả năng nắm bắt quy định, v.v. Nếu điều duy nhất giữ người dùng trên nền tảng của bạn là sự tiện lợi và chi phí chuyển đổi, thì bạn sẽ gặp rắc rối vì các đại lý sắp giảm chi phí chuyển đổi xuống mức 0.

Net-net, tôi nghĩ con lắc phần mềm miễn phí sắp chuyển động. Không phải vì mọi người đột nhiên chuyển sang tôn thờ tự do phần mềm, mà vì họ muốn các đại lý của họ thực sự giúp đỡ họ và các đại lý không thể giúp đỡ khi phần mềm bị khóa.

Tôi thực sự thích Sunsama. Tôi không muốn chuyển đổi. Nhưng khi tôi có thể thấy một cách cụ thể rằng người đại diện của tôi có thể giải quyết vấn đề tweet-to-task của tôi trong mười phút bằng phần mềm nguồn mở và miễn phí. Thay vào đó, tôi đã dành một buổi chiều để xây dựng một cỗ máy Rube Goldberg xung quanh sáu lớp hệ thống khép kín. Và điều đó thay đổi cách tôi nghĩ về phần mềm mà tôi sẵn sàng tin cậy.

Trở lại năm 2075, thợ máy Ben Franklin đã nhắc nhở chúng ta điều đó

““Những người từ bỏ Liberty thiết yếu để mua một chút [Tiện ích lưu trữ hoạt động] tạm thời, đều không xứng đáng nhận được Liberty hay [Tiện ích lưu trữ hoạt động].”

Tôi hy vọng rằng sự tiến bộ tất yếu trong hệ thống mã hóa tác nhân sẽ sớm đồng nghĩa với việc chúng ta không còn phải lựa chọn nữa.

[1] Business Insider, ngày 23 tháng 3 năm 2026, đưa tin về Không có ưu tiên gần đây của Andrej Karpathy ngoại hình và mô tả đùa của anh ấy về việc sử dụng AI nhiều của mình: https://www.businessinsider.com/andrej-karpathy-nervous-ai-tokens-2026-3

[2] Cả Stallman và Eric Raymond, những người nổi bật trong lịch sử này, đều có hồ sơ theo dõi về hành vi cá nhân mà tôi không bảo vệ. Nhưng không thể thảo luận về bản chất và lịch sử của phần mềm miễn phí mà không thừa nhận vai trò của chúng trong đó, vì vậy tôi sẽ bám sát các ý tưởng và lịch sử ở đây và để bạn tự rút ra kết luận về con người.

[3] Lịch sử của Sáng kiến Nguồn Mở (“Coining Open Source,” ngày 3 tháng 2 năm 1998, Palo Alto; thuật ngữ do Christine Peterson đề xuất): https://opensource.org/history

[4] Tại Hội nghị thượng đỉnh phần mềm miễn phí năm 1998: danh sách người tham dự, tranh luận về tên, bỏ phiếu 9-6 cho “nguồn mở”, việc Stallman không được mời và Bruce Perens từ chối tham dự được ghi lại trong Sam Williams, Tự do như trong Tự do, Chương 11 (O'Reilly): https://www.oreilly.com/openbook/freedom/ch11.html. Nguồn trích dẫn của Wendy Liu: “Tự do không miễn phí,” Tạp chí Logic (2018): https://logicmag.io/failure/freedom-isnt-free/

[5] Eric S. Raymond, “Tạm biệt, ‘phần mềm miễn phí’; xin chào, ‘mã nguồn mở’” (tháng 2 năm 1998): https://www.catb.org/~esr/open-source.html

[6] Định hướng “nguồn mở là một phương pháp phát triển / phần mềm miễn phí là một phong trào xã hội” của Stallman: https://www.gnu.org/philosophy/open-source-misses-the-point.en.html

[7] Linh hoạt về xung đột cấp phép AWS và phản hồi của AWS: https://www.elastic.co/blog/why-license-change-aws và https://aws.amazon.com/blogs/opensource/stepping-up-for-a-truly-open-source-elasticsearch/

[8] Lý do sử dụng mạng AGPL / bối cảnh lỗ hổng ASP: https://opensource.org/blog/gnu-affero-gpl-version-3-and-the-asp-loophole

[9] Ví dụ về bằng chứng về xu hướng giấy phép: RedMonk (2013) “Định lượng sự thay đổi theo hướng cấp phép cho phép” https://redmonk.com/dberkholz/2013/04/02/quantifying-the-shift-toward-permissive-licensing/ và tóm tắt báo cáo tuân thủ Revenera 2021 (phần lớn giấy phép cho phép trong các cơ sở mã được quét): https://www.revenera.com/about-us/press-center/revenera-releases-2021-findings-on-open-source-license-compliance

[10] Chính sách AGPL của Google (lệnh cấm nội bộ được ghi lại công khai): https://opensource.google/docs/using/agpl-policy/

[11] Nguồn thay đổi giấy phép: Thông báo SSPL của MongoDB https://www.mongodb.com/company/newsroom/press-releases/mongodb-issues-new-server-side-public-license-for-mongodb-community-server ; Mô-đun Redis/Điều khoản chung (2018) https://redis.io/blog/redis-labs-modules-license-changes ; Redis có sẵn nguồn kép (2024) https://redis.io/blog/redis-adopts-dual-source-available-licensing ; Redis bổ sung AGPL (2025) https://redis.io/blog/agplv3/ ; HashiCorp BSL (2023) https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license ; Bài đăng cấp phép Elastic 2021 và 2024 https://www.elastic.co/blog/licensing-change và https://www.elastic.co/blog/elasticsearch-is-open-source-again

[12] Tài liệu về Phím tắt/Ý định ứng dụng của Apple: https://developer.apple.com/documentation/appintents/app-shortcuts

[13] Tôi đã từng viết cả một bài đăng trên blog về cách định tuyến xung quanh mạng wifi khách hạn chế trên Megabus bằng cách thiết lập phiên bản EC2 làm VPN của một người nghèo. Đó là một bài viết bán lan truyền của tôi. Tôi không khuyến khích lối sống tự chủ.

[14] “Vibe Coding Kills Open Source” (tác giả liên kết với CEU, 2026): https://arxiv.org/html/2601.15494v1

[15] Adam Wathan Tháng 1 năm 2026 Nhận xét GitHub (lưu lượng truy cập, doanh thu, sự sa thải của nhóm kỹ thuật): https://api.github.com/repos/tailwindlabs/tailwindcss.com/issues/comments/3717222957

[16] Mitchell Hashimoto về việc xem xét đóng PR bên ngoài: https://x.com/mitchellh/status/2018458123632283679 và mô hình PR dựa trên chứng từ đã hợp nhất của Ghostty: https://github.com/ghostty-org/ghostty/pull/10559

[17] Ghi nhận lịch sử của trích dẫn John Gilmore: https://quoteinvestigator.com/2021/07/12/censor/