OpenTelemetry đang gặp vấn đề: Quá ít maintainer, quá nhiều cam kết ổn định

Phân tích dữ liệu từ các repository chính của OpenTelemetry trong 24 tháng cho thấy một nghịch lý: dự án càng cố gắng cam kết ổn định lâu dài thì càng khiến việc phát triển bị tắc nghẽn, trong khi số lượng maintainer thực chất rất mỏng. Các SDK PHP và Ruby chỉ có 1-2 người đảm nhận hầu hết công việc, và một tính năng mới có thể mất hàng trăm ngày để đi từ ý tưởng đến người dùng cuối. Bài viết đề xuất một tầng beta có giới hạn thời gian và sự minh bạch hơn về mức độ bảo trì giữa các ngôn ngữ.

Vấn đề không chỉ là "chưa hoàn thiện"

Trong nhiều năm, một trong những lời phàn nàn đáng tin cậy nhất khi tôi cố kéo một đội ngũ từ SDK của nhà cung cấp cụ thể sang OpenTelemetry là: "Tại sao mọi thứ có vẻ chưa xong?". SDK của các nhà cung cấp quan sát (observability) thường được thiết kế "ngu ngốc" một cách có chủ đích — bạn cài đặt, dashboard tự hiển thị dữ liệu, người khác lo phần kết nối, và bạn tiếp tục công việc của mình. OpenTelemetry thì ngược lại, chào đón bạn bằng vô số nhãn "experimental" và khoảng sáu cách khác nhau để hoàn thành bất kỳ nhiệm vụ nào.

Điều này không có gì sai — dự án chưa bao giờ nhắm tới mục tiêu đó. Tôi luôn tôn trọng việc họ kiên định xây dựng một hệ thống thực sự trung lập với nhà cung cấp. Nhưng khi thời gian trôi qua, tôi bắt đầu lo lắng. Các cuộc thảo luận trong repo semantic-conventions kéo dài lê thê. Các ngôn ngữ khác nhau có câu chuyện hoàn toàn khác nhau: Golang và .NET là công dân hạng nhất, còn các ngôn ngữ khác tụt hậu hàng năm trời. Tôi bắt đầu đặt nhiều câu hỏi trước khi khuyên các đội nhỏ áp dụng OTel — những đội không có thời gian, ngân sách và năng lượng cảm xúc cho nó.

Phân tích dữ liệu 24 tháng

Để kiểm chứng cảm giác "có gì đó không ổn ở vùng đất OTel", tôi so sánh OTel với hai dự án CNCF khác là Envoy và Prometheus. Nhìn vào dữ liệu 24 tháng:

• Envoy có sự phân bố tốt về tác giả, người merge và người đóng issue — một băng ghế dự bị tốt.
• OpenTelemetry PHP chỉ có 2 người đảm nhận hầu hết việc merge, chiếm 78,7% tổng số PR.
• OpenTelemetry Ruby cũng tương tự: 78,7% PR được merge bởi một người duy nhất.
• Ngay cả các SDK "khỏe nhất" như Golang (36,9% top-1 merger) và .NET (31,5%) vẫn không thể so với Envoy (35,8% nhưng với 28 người merge khác nhau).

Các tác giả không nên đồng thời là người merge và người đóng issue. Lý tưởng nhất là những nhiệm vụ này nên được phân bố đều hơn.

Quá trình thêm tính năng mới: Một vòng lặp kéo dài hàng trăm ngày

Tôi đã theo dõi quy trình từ OTEP (OpenTelemetry Enhancement Proposal) đến Specification, rồi đến Semantic conventions, rồi xuống từng SDK. Kết quả thật bất ngờ: sự chậm trễ không nằm ở semconv mà nằm ở giai đoạn triển khai xuống SDK.

Ví dụ, trong repo Python, các PR chậm nhất không liên quan đến semconv:

• #4646 — Tích hợp OpAMP: 361 ngày
• #4576 — OTLP HTTP max_export_batch_size: 314 ngày
• #4676 — SDK logs refactor: 126 ngày

Lý do thực sự là cơ chế "Approve Public API check" — yêu cầu thêm một maintainer khác duyệt. Điều này nghe có vẻ hợp lý, nhưng nó quay lại vấn đề ban đầu: không đủ maintainer.

Vòng luẩn quẩn của sự ổn định

Sự thật là OTel đang cố gắng làm quá nhiều thứ với quá ít người. Khi một tính năng được đánh dấu là "stable", bạn gần như không thể thay đổi nó mãi mãi. Điều này tạo ra một động lực:

1. Mọi người có xu hướng tranh luận về mọi vấn đề tiềm ẩn trước khi phát hành.
2. Các cuộc tranh luận kéo dài hàng trăm ngày.
3. Khi tính năng được duyệt, nó rơi vào tay một nhóm maintainer đã quá tải.

Tôi không nghĩ breaking changes lại tàn phá cộng đồng đến mức những lời hứa hẹn này ngụ ý, miễn là chúng được truyền thông tốt. Với lực lượng maintainer mỏng như vậy, chắc chắn phải có sự nhượng bộ.

Đề xuất giải pháp

Sau khi nhìn toàn cảnh, tôi đề xuất ba hướng:

1. Thêm tầng Beta có giới hạn thời gian:

Giữa "Experimental" và "Stable", thêm một mức "Beta" với cam kết: tính năng sẽ tồn tại ít nhất 12 tháng, được tiếp cận dễ dàng hơn cho người dùng cuối. Điều này giúp dự án nhận được phản hồi thực tế thay vì để các tính năng experimental chết trong "vùng tối" mà 99% người dùng không bao giờ chạm tới.

2. Công khai các mức độ bảo trì khác nhau:

Thành thật mà nói, việc ngụ ý Go và Ruby được bảo trì ở cùng tiêu chuẩn là gây hiểu lầm. Đây không phải là lời chê trách nhóm Ruby — họ đang làm việc anh hùng với những gì họ có. Nhưng giả vờ có sự tương đương khi không có sẽ tạo ra sự nhầm lẫn và bực bội thầm lặng. Công khai các mức bảo trì cho phép mọi người đưa ra lựa chọn sáng suốt.

3. Tăng cường tuyển maintainer:

Cộng đồng nói chung dường như không biết rằng dự án đang rất cần thêm người — đặc biệt là những người độc lập, không bị ràng buộc bởi lợi ích của các công ty tài trợ. OpenTelemetry đang làm công việc xuất sắc, thậm chí anh hùng với quy mô này. Nhưng để thực sự thay thế các SDK độc quyền, chúng ta cần thực dụng hơn về những gì khả thi trong các cam kết ổn định.

Biểu đồ phân bố hoạt động của OpenTelemetry

Dữ liệu 24 tháng cho thấy sự tập trung quá mức vào một số ít maintainer.

Kết luận

OpenTelemetry là một dự án tuyệt vời, nhưng nó đang ở ngã ba đường. Một mặt, sự nghiêm túc về độ ổn định là điều đáng quý. Mặt khác, nó đang tạo ra một rào cản vô hình cho chính sự phát triển của dự án. Không ai muốn một phần mềm quan trọng như vậy lại có nguy cơ "sụp đổ" vì một người duy nhất nghỉ việc.

Tôi hy vọng những con số này sẽ mở ra cuộc trò chuyện thực chất hơn về cách duy trì dự án trong dài hạn — bởi vì nếu không, câu chuyện "OTel chưa xong" sẽ còn kéo dài mãi.

Bạn có thể xem lại dữ liệu thô tại đây: data.zip