Open source: vì sao chúng ta phải quan tâm tới cách quản lí project hơn

Từng có một thời khi những công nghệ then chốt luôn đến từ các ông lớn thương mại như IBM, Microsoft và Sun. Ngay cả khi Linux bắt đầu là một phần quan trọng của cơ sở hạ tầng CNTT, các doanh nghiệp vẫn chỉ sử dụng nó từ các công ty thương mại như Red Hat, cùng với giấy phép hỗ trợ doanh nghiệp. Nhưng sự gia tăng của nguồn mở đã thay đổi cả ngành công nghiệp này khi mà các công ty và người dùng đang dần trở nên độc lập và tự dựa vào chính mình nhiều hơn.

Điều đó không chỉ có nghĩa là vì do vấn đề về thị trường hay khả năng đọc code của họ đã được nâng cao. Mà là vì các tổ chức đằng sau những công nghệ chủ chốt không còn phải là những ông lớn doanh nghiệp; họ thường là cộng đồng. Vì thế nên những project nguồn mở không phải lúc nào cũng có ngân sách để bảo trì code của mình.

Lỗ hổng Heartbleed là do một lỗi đã có trong OpenSSL kể từ năm 2012; chính nhóm nhỏ những người duy trì OpenSSL cũng phải đang chật vật trong công việc tìm hợp đồng để kiếm sống vì sản phẩm của họ hoàn toàn là cho cộng đồng, không dùng để thu lợi. Như Jim Zemlin, giám đốc điều hành của Quỹ Linux đã nói đùa tại hội nghị Open Source Leadership Summit năm nay, “đó là khi chúng tôi phát hiện ra Internet được bảo vệ bởi hai người tên là Steve”

Do đó mà hình thức để có thể kiếm ngân sách duy trì những dự án nguồn mở cũng trở nên vô cùng đa dạng. Một số dự án thì may mắn đã có sự tham gia của các công ty trong nhiều năm, số khác được áp dụng mô hình bán các phiên bản doanh nghiệp hay cung cấp dịch vụ cloud của dự án đó. Nhiều dự án mã nguồn mở quan trọng là một phần của nền tảng cung cấp hỗ trợ, từ Apache Foundation đến Cloud Native Computing Foundation; những người khác cũng có nền tảng riêng của họ, như .NET.

Nhưng vẫn còn nhiều dự án có rất ít sự hỗ trợ; bao gồm một danh sách dài các công cụ nguồn mở mà rất nhiều dự án khác phụ thuộc vào, trong đó có một package được gọi là left-pad quyết định kéo tất cả 250 gói của họ từ NPM sau khi tranh chấp về tên một gói, khiến cho bị xung đột với React, Babel và những gói khác dựa vào chúng.

Dự án Core Infrastructure Initiative support từ Linux Foundation đã được bắt đầu trong sự trỗi dậy của Heartbleed nhằm cung cấp hỗ trợ về ngân sách lẫn sức người cho các dự án có nguồn lực hạn chế nhưng lại có nhiều project phụ thuộc vào. Ngoài ra, tính năng quét bảo mật cũng được cải thiện tốt hơn để có thể giúp loại bỏ mã độc hại như các backdoored containers đã bị xóa khỏi Docker Hub gần đây.

Nhưng khi không có một cấu trúc hoạt động chính thống như một công ty hay nền tảng, bạn sẽ phải đối mặt với những vấn đề nằm ngoài bug và bảo mật. Các tiêu chuẩn về hành vi trong các cộng đồng nguồn mở có thể thay đổi rất nhiều và có tác động rất lớn đến những người tham gia.

Xây dựng cộng đồng

Lãnh đạo của một công ty hoặc một cộng đồng làm gì khi hành vi của một contributor làm cho các đồng nghiệp không thoải mái hoặc không muốn làm việc với họ? Với một doanh nghiệp, họ sẽ có cấu trúc rõ ràng để giải quyết vấn đề này, từ các quy tắc trong sổ tay nhân viên đến bộ phận nhân sự của mình. Song song đó, công ty còn có một nhóm pháp lý để đánh giá xem các điều khoản của hợp đồng lao động có cho phép họ sa thải các thành viên không phù hợp hay không. Trong khi đó,một cộng đồng có thể có một quy tắc ứng xử và một ủy ban hoặc nhóm làm việc xem xét các khiếu nại, nhưng các quy tắc ứng xử – và đặc biệt là việc thực thi chúng – thường không thống nhất.

Ngay cả việc nhiều thanh viên từ bỏ một dự án vì những bất đồng cũng không thể kết thúc được nó. Nhưng ít nhất nó gây ra sự trì trệ trong tiến độ. Về lâu dài, khi chúng ta dựa ngày càng nhiều vào các công cụ nguồn mở, thì càng cần phải suy nghĩ về các quy trình, thủ tục và cách tổ chức chặt chẽ hơn để hỗ trợ các công cụ đó.

GitHub không phải là bên duy nhất duy trì nguồn mở, và nó không chỉ được sử dụng cho nguồn mở, mà thực tế là nó có thể xem như là một Instagram (hoặc LinkedIn) với Microsoft. Qua đó nói lên rất nhiều về tiềm năng của nguồn mở với các khách hàng của Microsoft. Có rất nhiều thảo luận kỹ thuật tại Open Source Leadership Summit năm nay, nhưng cũng có một sự tập trung rõ ràng về việc tăng tính chuyên nghiệp của nguồn mở để có thể hấp dẫn các doanh nghiệp rót vốn đầu tư hỗ trợ.

Kubernetes cũng đã được nhắc tới nhiều lần tại hội nghị như là một ví dụ về một dự án nguồn mở đặt sự chuyên nghiệp và rõ ràng lên hàng đầu. Theo Gold Goldberg, Google’s engineering director của các container và Kubernetes cho biết, những nỗ lực của dự án là nỗ lực có ý nghĩa khi nó chuyển từ một dự án Google sang thành cộng đồng, nhưng điều quan trọng là: “Những người muốn tham gia cộng đồng này cần biết và theo cách làm việc của chúng tôi. “

Sarah Novotny, người lãnh đạo chương trình cộng đồng Kubernetes của Google cho biết: “Chúng tôi phát triển nhanh đến mức giờ không biết đang cần gì”. Điều nổi bật là cách đánh giá những đóng góp không chỉ dựa vào code do ai viết. Nói cách khác, các cá nhân trong cộng đồng Kubernetes có thể trở nên nổi bật bằng những đóng góp nhưng “các công ty thì còn có thể làm được nhiều hơn thế với khả năng bảo đảm mọi thứ luôn chạy tốt dù ko hoàng nhoáng”

Đó là lý do tại sao Brendan Burns của Microsoft (đồng sáng lập dự án Kubernetes) đã trao giải thưởng cho nhóm dịch vụ Azure Kubernetes vào đầu năm nay với danh hiệu “Hall of Fame” và giải thưởng “wood and carry water” . Ông nói rằng giải thưởng là để tôn vinh những người thầm lặng đã giúp chúng ta đi mỗi ngày nhưng lại không cần sự hào nhoáng.”

Các nhóm CNTT sẽ đưa ra quyết định về những dự án nguồn mở nào sử dụng vì lý do kỹ thuật, nhưng việc quản trị tốt và cộng đồng lành mạnh là điều giữ cho dự án phát triển dài lâu. Như Nell Shamrell-Harrington, chủ trì buổi hội nghị, đã phát biểu – “kỹ năng kĩ thuật và giao tiếp là không thể tách rời và luôn cần thiết trong mọi dự án. Các phần của dự án nguồn mở chạm vào cả công nghệ và con người luôn là khó nhất và quan trọng nhất.”

Techtalk via zdnet