Blog

Ghostty rời GitHub: Ý nghĩa cho nhà phát triển công cụ

Ashley Innocent

Ashley Innocent

30 tháng 4 2026

Ghostty rời GitHub: Ý nghĩa cho nhà phát triển công cụ

Vào ngày 28 tháng 4 năm 2026, Mitchell Hashimoto thông báo rằng Ghostty, trình giả lập terminal mã nguồn mở của anh, sẽ rời GitHub. Anh là người dùng GitHub số 1299. Anh tham gia vào tháng 2 năm 2008. Anh đã sử dụng nền tảng này gần như mỗi ngày trong hơn 18 năm. Không điều gì trong số đó còn quan trọng vào ngày anh viết bài đăng; anh đã ghi nhật ký về các sự cố ngừng hoạt động kiểu “gần như mỗi ngày đều có một lỗi X”, và một lỗi GitHub Actions vào ngày công bố đã chặn các đánh giá PR của anh trong hai giờ. Phán quyết của anh rất thẳng thắn: “Đây không còn là nơi để làm việc nghiêm túc nếu nó cứ chặn bạn hàng giờ mỗi ngày, mỗi ngày.”

Nếu bạn xây dựng các công cụ dành cho nhà phát triển, đây là thông báo bạn nên đọc kỹ hai lần. Hashimoto không phải là người dùng GitHub bình thường; anh là người đồng sáng lập HashiCorp dựa trên GitHub, đã phát hành Terraform, Vagrant, Vault, Consul và Boundary thông qua nó, và là người dùng GitHub số 1299. Khi một người dùng có hồ sơ như vậy rời bỏ nền tảng phát triển chiếm ưu thế nhất trên Trái đất, câu chuyện này lớn hơn việc một trình giả lập terminal tìm kiếm một ngôi nhà mới. Đây là một tín hiệu về độ tin cậy, sự phụ thuộc vào nền tảng (lock-in) và chi phí để xây dựng một công cụ mà các nhà phát triển khác phụ thuộc vào mỗi ngày. Bài viết này sẽ phân tích những gì Hashimoto đã nói, ý nghĩa của nó đối với bất kỳ ai phát hành công cụ dành cho nhà phát triển, và các mô hình bảo vệ hệ thống của bạn khỏi cùng một cạm bẫy.

Để có ngữ cảnh rộng hơn về cách các công cụ dành cho nhà phát triển trong kỷ nguyên AI đang thay đổi quy trình làm việc chuẩn GitHub, hãy xem cách viết tệp AGENTS.md và cách sử dụng GitHub Copilot và API thanh toán cho các nhóm. Để tìm hiểu quan điểm của một nhóm về việc tự động hóa xung quanh các lỗ hổng độ tin cậy của GitHub, hãy xem bài viết về bot phân loại Clawsweeper.

nút

Tóm tắt

Những gì Hashimoto nói trong bài đăng

Bài đăng thông báo ngắn gọn, đây cũng là một phần của thông điệp. Không có tuyên ngôn, không chỉ trích Microsoft, không quảng cáo cho một nền tảng thay thế. Hashimoto trình bày rõ ràng dòng thời gian: anh bắt đầu ghi nhật ký các sự cố ngừng hoạt động của GitHub, nhật ký đầy lên nhanh hơn anh mong đợi, và vào buổi sáng anh viết bài đăng, một lỗi GitHub Actions đã ngăn anh đánh giá PR trong hai giờ. Anh kết luận rằng nền tảng này không còn đủ tin cậy cho loại công việc anh thực hiện trên Ghostty.

Các con số xung quanh thông báo đáng được xem xét kỹ lưỡng. Ngày 27 tháng 4 năm 2026, một ngày trước bài đăng của Hashimoto, đã chứng kiến một sự cố ngừng hoạt động lớn của GitHub ảnh hưởng đến Actions, các gói và bề mặt API. Nhật ký mà anh đề cập trong bài đăng đã có từ trước sự cố đó; anh đã theo dõi mô hình này trong nhiều tháng. Anh coi động thái này là điều đã được âm thầm lên kế hoạch, không phải là phản ứng trước một ngày tồi tệ duy nhất. Sự cố ngừng hoạt động ngày 27 tháng 4 đã ảnh hưởng đến thời điểm, chứ không phải quyết định.

Anh cũng nói rõ về các giới hạn. Ghostty rời đi; các dự án khác của anh vẫn ở lại GitHub hiện tại. Kho lưu trữ Ghostty sẽ vẫn là một bản sao chỉ đọc tại URL hiện tại; một nền tảng mới sẽ lưu trữ quá trình phát triển tích cực, bao gồm các vấn đề (issues), yêu cầu kéo (pull requests) và CI. Anh đang đàm phán với nhiều nhà cung cấp, cả thương mại và FOSS, và chưa cam kết với một điểm đến cụ thể. Quá trình di chuyển sẽ được triển khai dần dần, không phải là một ngày cờ đỏ.

Sự bỏ sót cũng nói lên nhiều điều như những lời nói. Hashimoto không đề cập đến tính năng, giá cả, hay định hướng sản phẩm. Phàn nàn là bề mặt mà anh phụ thuộc vào ngừng phản hồi hàng giờ liền, và một dự án phát hành phần mềm không thể chạy trên một nền tảng không hoạt động.

Tại sao góc độ độ tin cậy lại quan trọng hơn việc di chuyển

Hầu hết các bài viết về thông báo này đều đặt sai câu hỏi. Câu hỏi thú vị không phải là Ghostty sẽ đi đâu; câu hỏi thú vị là làm thế nào một nền tảng với chiều sâu kỹ thuật như GitHub lại đến mức mà người dùng OG nổi bật thứ hai của nó đã rời đi vì lý do độ tin cậy. Câu hỏi thú vị thứ hai là điều đó nói lên điều gì về các công cụ mà phần còn lại của chúng ta đang xây dựng.

Ba điều làm cho thông báo này khác biệt so với các bài đăng thông thường kiểu “Tôi đang rời bỏ X”.

Đối với bất kỳ ai điều hành một công cụ dành cho nhà phát triển, sự kết hợp đó là âm thanh của kịch bản tồi tệ nhất của bạn. Một người dùng lâu năm, không có động cơ chính trị, không có tranh cãi công khai, chỉ là sự tích lũy lặng lẽ các mục “thứ này hôm nay không hoạt động” cho đến khi tính toán không còn hợp lý nữa. Không có phản hồi PR nào cho một nhật ký.

Điều này có ý nghĩa gì nếu bạn xây dựng công cụ dành cho nhà phát triển

Nếu sản phẩm của bạn nằm trên lộ trình quan trọng của một nhà phát triển, thông báo của Hashimoto là một lời nhắc kiểm tra căng thẳng. Hãy chạy nó đối với dịch vụ của riêng bạn.

Hãy xem xét 90 ngày cuối cùng của các sự cố trên trang trạng thái của bạn, cộng với các sự cố suy giảm chưa được báo cáo mà nhóm của bạn biết nhưng trang trạng thái không hiển thị. So sánh chúng với giờ làm việc của 20 khách hàng hàng đầu của bạn. Đếm xem bao nhiêu giờ trong số đó đã bị lãng phí chờ đợi bạn. Nếu câu trả lời là “nhiều hơn không mỗi tuần cho mỗi người dùng nặng,” bạn đang đi trên cùng một quỹ đạo.

Độ tin cậy đang ổn định thì tốt. Độ tin cậy đang âm thầm suy giảm là một cái bẫy. Nhật ký của Hashimoto đã ghi lại một mô hình, không phải một sự kiện đơn lẻ. Nếu bạn không có ngân sách lỗi cho mỗi thành phần mà ai đó đọc vào sáng thứ Hai, bạn không thể biết các con số của mình đang di chuyển theo hướng nào.

Nhật ký tồn tại vì người dùng không tin tín hiệu công khai. Trang trạng thái của bạn nên hoạt động sôi nổi, không lạnh nhạt. Nếu một tính năng bị suy giảm, hãy đánh dấu nó. Nếu một khu vực chậm, hãy đánh dấu nó. Nếu hàng đợi nền của bạn chậm 30 phút, hãy đánh dấu nó. Người dùng có thể thấy sự thật theo thời gian thực sẽ không bắt đầu ghi nhật ký.

Thời gian hoạt động 99.95% nhưng gom tất cả thời gian ngừng hoạt động vào giờ làm việc của nhà phát triển còn tệ hơn 99.9% thời gian hoạt động được phân bổ đều. Nếu khối lượng công việc của bạn là một phiên đánh giá PR kéo dài bốn giờ, hai giờ ngừng hoạt động bất cứ lúc nào là không liên quan; hai giờ ngừng hoạt động trong phiên đó là toàn bộ phiên. Hãy đo lường khả dụng dựa trên đường cong sử dụng thực tế của khách hàng, chứ không phải của bạn.

Sự phụ thuộc vào nền tảng và cái giá của việc “luôn là GitHub”

Cụm từ Hashimoto dùng để nói về bản thân là câu trích dẫn đáng giá nhất trong bài đăng: “Đối với tôi, việc đặt dự án ở đâu chưa bao giờ là một câu hỏi: luôn là GitHub.” Đó là cái giá của thói quen, và là cái giá mà hầu hết các nhà phát triển không định giá đúng.

Khi một nền tảng duy nhất là mặc định cho các kho lưu trữ (repos), vấn đề (issues), PR, CI, phân phối gói, bản phát hành và nhận dạng, diện tích bề mặt của “sự phụ thuộc vào nền tảng” lớn hơn nhiều so với diện tích bề mặt của “lịch sử git.” Bạn có thể clone một repo git đến bất cứ đâu; bạn không thể clone một trình theo dõi vấn đề, lịch sử đánh giá PR, một chủ đề thảo luận, kho lưu trữ bí mật của GitHub Actions, hoặc quy trình làm việc đánh giá gắn với CODEOWNERS chỉ bằng một lệnh. Chi phí di chuyển có hình dạng giống như một tảng băng trôi.

Chi phí đó chồng chất đối với những người xây dựng công cụ. Nếu công cụ dành cho nhà phát triển của bạn nằm trong một GitHub Action, phân phối qua Marketplace, xác thực chống lại GitHub OAuth và phát hành bản phát hành qua GitHub Packages, độ tin cậy của công cụ của bạn là một phần phụ thuộc của độ tin cậy của GitHub. Ngân sách lỗi của bạn là một phần nhỏ của họ. Khách hàng của bạn trải nghiệm thời gian ngừng hoạt động của bạn khi họ sử dụng công cụ của bạn, nhưng họ cũng trải nghiệm thời gian ngừng hoạt động của bạn khi GitHub ngừng hoạt động và công cụ của bạn ngừng phản hồi. Việc đổ lỗi không phải lúc nào cũng chính xác; nhưng trải nghiệm của khách hàng thì có.

Công việc tách rời không hào nhoáng nhưng đó là công việc cần làm. Hãy làm cho mọi phụ thuộc có thể thay thế được. Coi GitHub là một trong số các nhà cung cấp, chứ không phải là cơ sở hạ tầng. Kiểm tra đường dẫn thay thế hàng quý. Di chuyển các phần phù hợp hơn với một nền tảng khác; giữ lại các phần không phù hợp. Lời nói của Hashimoto về “di chuyển dần dần” là hình thức đúng đắn cho mọi người, không chỉ riêng anh ấy.

Các nền tảng thay thế, tóm tắt

Các điểm đến tiềm năng cho Ghostty là kiến thức công khai về hình dạng nếu không phải là tên. Các lựa chọn đáng tin cậy tính đến cuối tháng 4 năm 2026:

Hashimoto không cam kết với một lựa chọn nào. Tín hiệu trong sự im lặng là không có lựa chọn nào là sự thay thế rõ ràng cho tất cả những gì GitHub làm, đây chính là vấn đề: khi một nền tảng hấp thụ toàn bộ ngăn xếp, việc thay thế nó một cách sạch sẽ là điều khó khăn ngay từ cấu trúc.

Bài học cho các nhóm API

Nếu bạn xây dựng API hoặc các công cụ API thay vì trình giả lập terminal, cùng một mô hình sẽ áp dụng với tên được thay đổi. Thay thế “GitHub Actions” bằng “API thượng nguồn mà sản phẩm của bạn phụ thuộc.” Thay thế “vấn đề và PR” bằng “hộp thư đến nơi khách hàng của bạn nói với bạn rằng có điều gì đó không ổn.” Câu hỏi cấu trúc vẫn như cũ: bao nhiêu phần công việc của khách hàng của bạn phụ thuộc vào một dịch vụ mà bạn không kiểm soát, và làm thế nào bạn vẫn hữu ích khi dịch vụ đó bị lỗi?

Ba mô hình tồn tại khi tiếp xúc với thực tế.

Quy trình làm việc kiểu Apidog cho công việc API có khả năng phục hồi trông như thế nào

Cụ thể, đây là mô hình mà hầu hết các nhóm sử dụng để tự bảo vệ khỏi các sự cố ngừng hoạt động của nhà cung cấp thượng nguồn.

  1. Tải xuống Apidog và tạo một dự án cho mỗi bề mặt API thượng nguồn mà bạn phụ thuộc.
  2. Định nghĩa sơ đồ yêu cầu và phản hồi một lần. Apidog tạo một máy chủ giả lập từ sơ đồ để vòng lặp phát triển không bao giờ bị chặn bởi dịch vụ thượng nguồn.
  3. Lưu trữ thông tin xác thực dưới dạng bí mật có phạm vi môi trường. Cùng một cấu trúc yêu cầu chạy với dev (giả lập), staging (sandbox) và prod (trực tiếp) bằng cách chuyển đổi môi trường.
  4. Viết các bài kiểm tra hợp đồng chạy trên mỗi bản phát hành; các bài kiểm tra tương tự chạy với mọi nhà cung cấp bạn hỗ trợ, vì vậy một sự hồi quy trên Nhà cung cấp A sẽ xuất hiện trước khi khách hàng nhìn thấy nó.
  5. Khi một API thượng nguồn bị suy giảm, hãy chuyển môi trường sang giả lập và tiếp tục. Sản phẩm vẫn được phát hành ngay cả khi dịch vụ thượng nguồn không hoạt động.

Mô hình này không dành riêng cho Ghostty hay AI; đó là mô hình API có khả năng phục hồi đã mang lại lợi ích cho mọi nhóm áp dụng nó trước khi họ cần. Bài đăng của Hashimoto là lời nhắc nhở mới nhất rằng bạn nên áp dụng nó trước khi cần, chứ không phải sau đó.

Những gì các nhà phát triển đang đọc từ thông báo

Các phản ứng trong 48 giờ đầu tiên được chia thành một vài nhóm.

Các phản ứng quan trọng không nằm trên mạng xã hội. Chúng nằm bên trong các tổ chức kỹ thuật đã chọn GitHub làm nền tảng cho mọi thứ họ phát hành. Các cuộc trò chuyện đang diễn ra trên Slack ngay bây giờ: làm thế nào để giảm thiểu rủi ro này, chính sách nội bộ của chúng ta về việc sao chép sang nền tảng thứ hai trông như thế nào, và sách lược rời đi là gì?

Những bài học thực tiễn cho hệ thống của riêng bạn

Một danh sách kiểm tra ngắn gọn, mang tính ý kiến cá nhân:

Để có một ví dụ cụ thể về công cụ API, bài đăng về xây dựng các quy trình làm việc bền vững sống sót qua sự cố ngừng hoạt động của nhà cung cấp sẽ trình bày cùng một mô hình với mã, sử dụng DeepSeek và OpenAI làm ví dụ về nhà cung cấp kép. Các hình dạng thay đổi; nguyên tắc thì không.

Câu hỏi thường gặp

nút

Thực hành thiết kế API trong Apidog

Khám phá cách dễ dàng hơn để xây dựng và sử dụng API

Đăng ký miễn phíTải xuống