Abby Kearns, CEO của ActiveState – Phỏng vấn

Abby Kearns là CEO của ActiveState và là một nhà điều hành công nghệ với hơn 25 năm kinh nghiệm xây dựng và mở rộng các tổ chức phần mềm doanh nghiệp. Cô từng là CTO của Puppet, nơi cô đã giúp dẫn dắt một quá trình chuyển đổi chiến lược kết thúc với việc công ty được mua lại bởi Perforce Software. Trước đó trong sự nghiệp của mình, cô là CEO của Cloud Foundry Foundation, nơi cô đã hướng dẫn sự tăng trưởng của một trong những hệ sinh thái nền tảng đám mây mã nguồn mở lớn nhất trong ngành. Abby hiện đang là thành viên hội đồng quản trị của Akka (trước đây là Lightbend). Cô được biết đến với việc giúp các công ty dịch chuyển các thay đổi lớn trong đám mây, mã nguồn mở và AI thành chiến lược sản phẩm và tăng trưởng doanh nghiệp rõ ràng.

ActiveState là một công ty phần mềm của Canada được thành lập vào năm 1997, cung cấp các công cụ và nền tảng doanh nghiệp để xây dựng, quản lý và bảo mật phần mềm mã nguồn mở. Sản phẩm cốt lõi của công ty, Nền tảng ActiveState, giúp các đội phát triển, DevOps và bảo mật tự động hóa quản lý phụ thuộc, phát hiện và khắc phục các điểm yếu, và tạo ra môi trường phát triển an toàn và có thể tái tạo trên nhiều ngôn ngữ lập trình như Python, Perl và Tcl. Bằng cách cung cấp các thành phần mã nguồn mở đã được xây dựng và xác minh trước, và tích hợp chúng vào các quy trình làm việc hiện có, ActiveState nhằm mục đích giảm thiểu rủi ro bảo mật trong chuỗi cung ứng phần mềm đồng thời cải thiện năng suất của nhà phát triển và tăng tốc độ giao hàng ứng dụng.

Bạn đã dành sự nghiệp của mình tại điểm giao nhau của mã nguồn mở, nền tảng đám mây và chuyển đổi doanh nghiệp, từ việc lãnh đạo Cloud Foundry Foundation đến việc làm CTO tại Puppet. Điều gì đã thu hút bạn đến với vai trò CEO tại ActiveState, và tầm nhìn của bạn cho công ty trong giai đoạn tăng trưởng tiếp theo là gì?

Chủ đề xuyên suốt trong sự nghiệp của tôi là hoạt động tại điểm giao nhau của cộng đồng và cơ sở hạ tầng vào những thời điểm khi ngành công nghiệp đang đưa ra những quyết định sẽ tích lũy trong nhiều năm. Cloud Foundry là thời điểm đó cho đám mây gốc. Puppet là thời điểm đó cho quản lý cấu hình và giai đoạn đầu của những gì chúng ta gọi là DevSecOps. ActiveState là thời điểm đó cho quản trị mã nguồn mở.

Điều thu hút tôi đến đây là một vấn đề mà tôi đã theo dõi trong một thời gian dài. Mỗi doanh nghiệp mà tôi đã gặp đều chạy trên mã nguồn mở. Hầu hết trong số họ không thể nói với sự tự tin về mã nguồn mở mà họ đang chạy, liệu nó đã được vá hay không, hoặc ai là người chịu trách nhiệm về quyết định sử dụng nó. Khoảng trống đó, giữa việc mã nguồn mở đã trở nên cơ bản như thế nào và việc hầu hết các tổ chức áp dụng rất ít kỷ luật để quản trị nó, là nơi rủi ro của ngành công nghiệp đang tích lũy. ActiveState đã dành 20 năm để xây dựng cơ sở hạ tầng để đóng khoảng trống đó. Công việc của tôi là đảm bảo thị trường hiểu tại sao việc đóng nó lại là cấp thiết.

Tầm nhìn cho giai đoạn tăng trưởng tiếp theo là rõ ràng: ActiveState trở thành câu trả lời mặc định cho câu hỏi về nơi mã nguồn mở doanh nghiệp đến từ đâu. Không phải là một công cụ quét. Không phải là một báo cáo. Một nguồn đáng tin cậy, đã được xác minh, liên tục được khắc phục, mà các tổ chức có thể trỏ đến khi các cơ quan quản lý, hội đồng quản trị hoặc người phản hồi sự cố hỏi về cách họ quản trị chuỗi cung ứng phần mềm của mình.

ActiveState đang định vị mình như một lớp quan trọng trong việc bảo mật chuỗi cung ứng phần mềm tại thời điểm khi AI đang tăng tốc việc tạo mã. Làm thế nào AI cơ bản thay đổi hồ sơ rủi ro của phần mềm mã nguồn mở?

Phát triển được hỗ trợ bởi AI phá vỡ một giả định cơ bản mà toàn bộ chuỗi công cụ quản trị mã nguồn mở được xây dựng: rằng một nhà phát triển đã đưa ra một quyết định có chủ ý để bao gồm một phụ thuộc.

Mỗi yêu cầu SBOM, mỗi công cụ SCA, mỗi quy trình quản lý điểm yếu đều giả định rằng có một người trong vòng lặp đã chọn thư viện đó. Khi AI tạo mã, các phụ thuộc đến trong sản xuất mà không ai chọn, xem xét hoặc trong nhiều trường hợp thậm chí không biết chúng có ở đó. Công cụ quản trị đang tìm kiếm các quyết định. AI đang thực hiện các thay đổi sản xuất mà bỏ qua quyết định hoàn toàn.

Có một lớp thứ hai trong điều này. Các công cụ mã hóa đã thúc đẩy việc áp dụng AI, các chuẩn mực về năng suất, các cuộc khảo sát của nhà phát triển, các ngôi sao trên GitHub, không có khung đánh giá nào bao gồm bảo mật như một biện pháp đầu tiên. Ngành công nghiệp đã tối ưu hóa cho tốc độ và chính xác và đã xuất xưởng cơ sở hạ tầng mà không hỏi liệu đầu ra có an toàn hay không. Đó không phải là một thất bại của công cụ. Đó là một thất bại trong lãnh đạo về cách đưa ra quyết định áp dụng.

Bạn đã nói rằng mã nguồn mở không được quản lý đang trở thành một điểm yếu lớn của doanh nghiệp. Tại sao quản trị mã nguồn mở hiện đang lên đến cấp hội đồng quản trị, và những gì mà các giám đốc điều hành vẫn đang đánh giá thấp?

Nó đang đạt đến cấp hội đồng quản trị vì môi trường quản lý đã thay đổi cấu trúc trách nhiệm. Đạo luật Tính bền bỉ của mạng (EU Cyber Resilience Act), yêu cầu tiết lộ của Ủy ban Chứng khoán và Giao dịch (SEC), hướng dẫn Thiết kế an toàn của Cơ quan An ninh mạng và Cơ sở hạ tầng (CISA): những khuôn khổ này đang thay đổi câu hỏi từ “Bạn có một công cụ quét không?” sang “Bạn có thể chứng minh phần mềm của mình an toàn tại điểm xuất xứ không?” Đó là những câu hỏi rất khác nhau, và hầu hết các tổ chức không thể trả lời câu hỏi thứ hai.

Điều mà các giám đốc điều hành vẫn đang đánh giá thấp là rằng đây là một vấn đề cấu trúc, không phải là một vấn đề về nguồn lực. Các tổ chức mà tôi thấy đang phản ứng với rủi ro mã nguồn mở bằng cách thêm nhiều công cụ quét hơn không giải quyết được vấn đề cơ bản. Quét phát hiện vấn đề sau khi chúng đã vào môi trường của bạn.

Khi mọi thứ đều được đánh dấu, không có gì được ưu tiên, và khối lượng cảnh báo trở thành một rối loạn chức năng riêng của nó. Các tổ chức sẽ điều hướng thành công là những tổ chức không mua thêm công cụ. Họ là những tổ chức thay đổi cách họ đưa ra quyết định về mã nguồn mở nào sẽ vào môi trường của họ, và ai sẽ chịu trách nhiệm về những quyết định đó.

Với mã nguồn mở hiện được nhúng trên hầu hết các ngăn xếp phần mềm doanh nghiệp, các tổ chức nên nghĩ lại mã nguồn mở như cơ sở hạ tầng thay vì chỉ là một tiện ích phát triển?

Mô hình tinh thần mà hầu hết các tổ chức đang làm việc là một thập kỷ quá cũ. Mã nguồn mở bắt đầu như một tiện ích phát triển. Nhà phát triển có thể kéo thư viện, di chuyển nhanh hơn và tránh tái phát minh các thành phần cơ bản. Khung đó có ý nghĩa khi mã nguồn mở là tùy chọn và bổ sung.

Đó không phải là hiện thực hiện tại. Mã nguồn mở là nền tảng của phần mềm hiện đại. 96% ứng dụng bao gồm các thành phần mã nguồn mở. Nó không phải là một lớp tiện ích trên đỉnh của cơ sở hạ tầng độc quyền. Nó là cơ sở hạ tầng. Và cơ sở hạ tầng phải được quản trị như cơ sở hạ tầng, với các chính sách rõ ràng về những gì vào môi trường, quyền sở hữu được xác định cho bảo trì và khắc phục, và trách nhiệm nằm ở cấp độ thích hợp của tổ chức.

Các tổ chức đang đi đầu trong lĩnh vực này đã thực hiện một sự thay đổi có chủ ý: tiêu thụ mã nguồn mở là một quyết định chiến lược với các hậu quả về bảo mật và tài chính, không phải là một thiết lập mặc định mà các nhà phát triển quản lý riêng lẻ. Sự thay đổi đó đòi hỏi phải có chính sách, quy trình vận hành và trách nhiệm rõ ràng của ban điều hành. Hầu hết các tổ chức vẫn chưa thực hiện sự thay đổi đó.

Bạn đã dẫn dắt các tổ chức qua nhiều làn sóng công nghệ. Sự thay đổi do AI thúc đẩy hiện tại so với các chuyển đổi trước đó như đám mây và DevOps về tốc độ và gián đoạn như thế nào?

Phong trào AI hiện tại rất giống với các chuyển đổi công nghệ trước đó. Khi đám mây xuất hiện như một mô hình phân phối, các tổ chức coi đó là một lựa chọn công nghệ thuần túy đã mắc sai lầm rất khác so với các tổ chức nhận ra đó là một chuyển đổi kiến trúc và vận hành. Những tổ chức không thực hiện chuyển đổi quản trị đã trả giá cho nó trong nhiều năm với IT bóng tối, vượt chi phí, và nợ kỹ thuật và bảo mật.

Điều khác biệt về sự thay đổi AI hiện tại là tốc độ và sự vô hình. Việc áp dụng đám mây là có thể nhìn thấy. Bạn biết khi tổ chức của bạn đang di chuyển khối lượng công việc từ trên cơ sở đến đám mây. DevOps là có thể nhìn thấy: các tổ chức đang tái cấu trúc các đội, thay đổi đường ống phân phối, và viết lại quy trình. Các công cụ mã hóa AI đang được áp dụng nhà phát triển theo nhà phát triển, cuộc gọi công cụ theo cuộc gọi công cụ, và rủi ro đang tích lũy trong cơ sở mã trước khi hầu hết các tổ chức đã đăng ký rằng một quyết định quản trị đã được thực hiện.

Nhiều công ty gặp khó khăn trong việc chuyển đổi việc áp dụng mã nguồn mở thành một mô hình kinh doanh bền vững. Điều gì phân biệt các công ty thành công với những công ty thất bại?

Các tổ chức đã xây dựng các doanh nghiệp bền vững trên mã nguồn mở chia sẻ một đặc điểm: họ có kỷ luật về sản phẩm mà họ thực sự đang bán. Họ không bán phần mềm mã nguồn mở, mà là miễn phí. Họ bán chuyên môn, hỗ trợ vận hành, cơ sở hạ tầng quản trị, hoặc dịch vụ quản lý làm cho phần mềm miễn phí có thể hoạt động ở quy mô doanh nghiệp.

Ngược lại, các tổ chức thất bại có xu hướng混 hợp việc áp dụng cộng đồng với động lực thương mại. Họ không phải là cùng một điều. Một số lượng ngôi sao GitHub cao hoặc một cộng đồng lớn cho thấy nhà phát triển tìm dự án hữu ích. Nó không cho thấy người mua sẽ trả tiền cho nó, hoặc điều mà nhà phát triển tìm thấy hữu ích là điều mà các tổ chức thực sự cần. Việc dịch từ việc áp dụng nhà phát triển sang giá trị doanh nghiệp đòi hỏi xây dựng điều gì đó ngoài mã nguồn mở itself, và các tổ chức thất bại trong việc làm rõ sự khác biệt đó một cách rõ ràng, trong định vị, sản phẩm, và chuyển động bán hàng của họ, có xu hướng không sống sót sau quá trình chuyển đổi sang quy mô.

Từ kinh nghiệm của bạn trong việc mở rộng các tổ chức dẫn đầu bởi nhà phát triển, những thách thức lãnh đạo lớn nhất khi chuyển đổi từ tăng trưởng dẫn đầu sản phẩm sang các hoạt động quy mô doanh nghiệp là gì?

Thách thức lớn nhất là những kỹ năng và trực giác đã khiến bạn thành công trong tăng trưởng dẫn đầu sản phẩm sẽ chống lại bạn ở quy mô doanh nghiệp. Tăng trưởng dẫn đầu sản phẩm thưởng cho việc di chuyển nhanh, lặp lại công khai, tối ưu hóa cho trải nghiệm nhà phát triển, và để việc áp dụng dẫn dắt chuyển động thương mại. Bán hàng doanh nghiệp thưởng cho quá trình có chủ ý, mối quan hệ điều hành, chu kỳ dài, và khả năng ánh xạ sản phẩm của bạn đến các kết quả quan trọng với người mua không phải là nhà phát triển.

Lỗi lãnh đạo mà tôi thường thấy nhất là giả định rằng chuyển đổi chủ yếu là một vấn đề về chuyển động bán hàng. Nó không phải là như vậy. Đó là một vấn đề về thiết kế tổ chức. Đội đã xây dựng sản phẩm, định vị, và các mối quan hệ khách hàng sớm thường không phải là đội có thể thực hiện chuyển động doanh nghiệp. Nhận ra điều đó mà không mất đi những gì đã làm cho sản phẩm đáng mua ở nơi đầu tiên là thực sự khó. Những nhà lãnh đạo làm điều đó tốt là những người trung thực về những phần nào của tổ chức cần phải phát triển và xây dựng các khả năng mới mà không tháo dỡ văn hóa đã tạo ra sản phẩm.

Bạn đã làm việc rộng rãi tại điểm giao nhau của bảo mật và năng suất của nhà phát triển. Làm thế nào các công ty có thể cân bằng giữa tốc độ và đổi mới với nhu cầu ngày càng tăng về các thành phần phần mềm an toàn và đáng tin cậy?

Khung tốc độ so với bảo mật là một lựa chọn sai lầm đã tồn tại vì công cụ đã củng cố nó. Khi bảo mật được thực hiện như một cổng xem xét ở cuối quy trình phát triển, nó là một nút thắt. Khi nó được thực hiện như một nguồn được quản lý của các thành phần đáng tin cậy mà các nhà phát triển kéo từ đầu quy trình, nó không làm chậm mọi thứ.

Những người đã giải quyết căng thẳng này đã làm điều đó bằng cách thay đổi nơi bảo mật xảy ra. Không phải xem xét mã sau khi nó được viết. Không quét các artifact sau khi chúng được xây dựng. Quản trị những gì đi vào danh mục mà các nhà phát triển và công cụ AI kéo từ. Nếu nguồn là đáng tin cậy, thì tốc độ không bị hạn chế bởi xem xét bảo mật vì công việc bảo mật đã xảy ra ở phía上游. Đó là một quyết định kiến trúc, không phải là một quyết định văn hóa. Nó đòi hỏi đầu tư vào cơ sở hạ tầng quản trị, nhưng nó không đòi hỏi phải chọn giữa di chuyển nhanh và giao hàng an toàn.

Làm thế nào bạn nhìn thấy vai trò của các hệ sinh thái mã nguồn mở được kiểm soát hoặc đáng tin cậy sẽ phát triển trong vài năm tới khi các công cụ AI ngày càng tạo ra mã và phụ thuộc?

Vai trò của các nguồn mã nguồn mở được kiểm soát hoặc đáng tin cậy sẽ chuyển từ một thực hành tốt nhất sang một yêu cầu cơ bản. Sự thay đổi đó được thúc đẩy bởi hai điều không thể đảo ngược.

Thứ nhất là môi trường quản lý. Trong cảnh quan năm 2026, việc chứng minh nguồn gốc phần mềm ngày càng trở thành một yêu cầu pháp lý, không phải là một tiêu chuẩn tự nguyện. Hội đồng và các cơ quan quản lý đang đặt câu hỏi mà các tổ chức không thể trả lời.

Thứ hai là tốc độ phát triển của AI. Khi các công cụ AI tạo ra nhiều mã hơn và kéo nhiều phụ thuộc hơn, khối lượng các thành phần chưa được kiểm tra sẽ vượt quá khả năng của bất kỳ tổ chức nào để xem xét thủ công. Các tổ chức đã thiết lập một danh mục được kiểm soát, được quản lý bởi chính sách, như nguồn mặc định cho các nhà phát triển và công cụ AI của họ sẽ có thể theo kịp tốc độ của AI với quản trị bảo mật phù hợp. Các tổ chức vẫn đang dựa vào các đăng ký công cộng và xem xét thủ công sẽ phải đối mặt với một khoảng trống ngày càng rộng giữa tốc độ mã được tạo ra và mức độ nó được đánh giá.

Các hệ sinh thái được kiểm soát là câu trả lời cơ sở hạ tầng cho một vấn đề mà phát triển AI đã làm cho không thể tránh khỏi.

Là một trong số ít nữ CEO trong không gian mã nguồn mở và cơ sở hạ tầng, bạn đã thấy những thay đổi gì trong sự đa dạng lãnh đạo trong những năm qua, và những gì vẫn cần được cải thiện?

Đã có sự thay đổi thực sự. Khi tôi bắt đầu sự nghiệp của mình, đại diện của phụ nữ trong các vai trò điều hành trong mã nguồn mở và cơ sở hạ tầng thấp đến mức những ngoại lệ đáng chú ý. Điều đó ít đúng hơn bây giờ. Có nhiều phụ nữ trong các vị trí kỹ thuật và điều hành cao cấp, nhiều tổ chức đã chuyển qua giai đoạn tuyên bố đa dạng và đang thực hiện các thay đổi cấu trúc, và nhiều mô hình hơn cho lãnh đạo trong không gian này có thể trông như thế nào.

Trường hợp kinh doanh để đóng khoảng trống còn lại không phải là trừu tượng. Các vấn đề mà ngành công nghiệp đang làm việc trên bây giờ, rủi ro chuỗi cung ứng phần mềm, quản trị AI, các thay đổi tổ chức cần thiết để làm cho bảo mật trở thành một thực hành hàng đầu, là những vấn đề khó. Các đội đa dạng tạo ra kết quả tốt hơn trên các vấn đề khó. Không phải là một vấn đề về khát vọng mà là một vấn đề về cách các quan điểm khác nhau đưa ra những giả định mà các đội đồng nhất bỏ qua. Tôi đã thấy điều này trực tiếp. Các tổ chức đã thực sự tiến bộ trong việc thuộc về, không chỉ là đại diện, là những tổ chức mà lợi thế hoạt động đó thể hiện trong công việc của họ.

Thuộc về vẫn còn không đồng đều trên toàn ngành. Việc ở trong phòng không giống như có quan điểm của bạn được cân nhắc thực sự. Sự khác biệt đó là nơi giai đoạn tiến bộ tiếp theo cần phải xảy ra.

Cảm ơn bạn vì cuộc phỏng vấn tuyệt vời, độc giả muốn tìm hiểu thêm có thể truy cập ActiveState.