Abby Kearns, CEO ActiveState – Seri Wawancara

Abby Kearns adalah CEO ActiveState dan eksekutif teknologi dengan lebih dari 25 tahun pengalaman membangun dan mengembangkan organisasi perangkat lunak enterprise. Sebelumnya, dia menjabat sebagai CTO Puppet, di mana dia membantu memimpin transformasi strategis yang berakhir dengan akuisisi perusahaan oleh Perforce Software. Sebelumnya dalam karirnya, dia adalah CEO Cloud Foundry Foundation, memandu pertumbuhan salah satu ekosistem platform cloud open source terbesar di industri. Abby saat ini menjabat di dewan Akka (sebelumnya Lightbend). Dia dikenal karena membantu perusahaan menerjemahkan pergeseran besar dalam cloud, open source, dan AI menjadi strategi produk dan pertumbuhan enterprise yang jelas.

ActiveState adalah perusahaan perangkat lunak Kanada yang didirikan pada 1997 yang menyediakan alat dan platform enterprise untuk membangun, mengelola, dan mengamankan perangkat lunak open source. Penawaran intinya, Platform ActiveState, membantu tim pengembangan, DevOps, dan keamanan untuk mengotomatisasi pengelolaan ketergantungan, mendeteksi dan memperbaiki kerentanan, dan membuat lingkungan pengembangan yang aman dan dapat diulang di seluruh bahasa pemrograman seperti Python, Perl, dan Tcl. Dengan menyediakan komponen open source yang telah dibangun sebelumnya dan mengintegrasikannya ke dalam alur kerja yang ada, ActiveState bertujuan untuk mengurangi risiko keamanan dalam rantai pasokan perangkat lunak sambil meningkatkan produktivitas pengembang dan mempercepat pengiriman aplikasi.

Anda telah menghabiskan karir Anda di persimpangan open source, platform cloud-native, dan transformasi enterprise, dari memimpin Cloud Foundry Foundation hingga menjabat sebagai CTO di Puppet. Apa yang membuat Anda mengambil peran CEO di ActiveState, dan apa visi Anda untuk perusahaan dalam fase pertumbuhan berikutnya?

Benang merah dalam karir saya telah beroperasi di persimpangan komunitas dan infrastruktur pada saat industri membuat keputusan yang akan berkompromi selama bertahun-tahun. Cloud Foundry adalah saat itu untuk cloud-native. Puppet adalah saat itu untuk pengelolaan konfigurasi dan tahap awal apa yang sekarang kita sebut DevSecOps. ActiveState adalah saat itu untuk tata kelola open source.

Apa yang membuat saya tertarik di sini adalah masalah yang telah saya lihat selama bertahun-tahun. Setiap perusahaan yang saya temui berjalan di atas open source. Kebanyakan dari mereka tidak dapat mengatakan dengan percaya diri apa open source yang mereka jalankan, apakah itu telah diperbarui, atau siapa yang bertanggung jawab atas keputusan untuk menggunakannya. Celah antara seberapa penting open source telah menjadi dan seberapa sedikit ketat organisasi menerapkan tata kelola itu adalah di mana risiko industri terkumpul. ActiveState telah menghabiskan dua puluh tahun membangun infrastruktur untuk menutup celah itu. Tugas saya adalah memastikan pasar memahami mengapa menutupnya mendesak.

Visi untuk fase berikutnya adalah jelas: ActiveState menjadi jawaban default untuk pertanyaan tentang dari mana open source enterprise berasal. Bukan pemindai. Bukan laporan. Sumber yang dipercaya, diverifikasi, dan diperbaiki terus menerus yang organisasi dapat tunjuk ketika regulator, dewan, atau responden insiden bertanya tentang bagaimana mereka mengelola rantai pasokan perangkat lunak mereka.

ActiveState memposisikan diri sebagai lapisan kritis dalam mengamankan rantai pasokan perangkat lunak pada saat AI mempercepat generasi kode. Bagaimana AI secara fundamental mengubah profil risiko perangkat lunak open source?

Pengembangan yang dibantu AI memecahkan asumsi dasar yang seluruh rantai alat tata kelola open source dibangun: bahwa pengembang membuat keputusan sadar untuk memasukkan ketergantungan.

Setiap mandat SBOM, setiap alat SCA, setiap alur kerja pengelolaan kerentanan mengasumsikan ada manusia dalam loop yang memilih untuk menarik perpustakaan. Ketika AI menghasilkan kode, ketergantungan tiba di produksi yang tidak dipilih, ditinjau, atau dalam banyak kasus bahkan diketahui ada. Alat tata kelola sedang mencari keputusan. AI membuat perubahan produksi yang melewati keputusan sepenuhnya.

Ada lapisan kedua untuk ini. Alat pengkodean yang mengarahkan adopsi AI, benchmark produktivitas, survei pengembang, bintang GitHub, tidak ada dari kerangka evaluasi ini yang mencakup keamanan sebagai ukuran pertama. Industri mengoptimalkan kecepatan dan kesalahan dan mengirim infrastruktur tanpa bertanya apakah outputnya aman. Itu bukan kegagalan alat. Itu kegagalan kepemimpinan dalam membuat keputusan adopsi. Kami sekarang beroperasi pada skala pada fondasi yang tidak pernah dievaluasi untuk risiko yang diperkenalkannya.

Anda telah mengatakan bahwa open source yang tidak dikelola menjadi kerentanan utama enterprise. Mengapa tata kelola open source sekarang naik ke tingkat dewan, dan apa yang masih kurang dipahami oleh eksekutif?

Ini mencapai dewan karena lingkungan regulasi telah berubah struktur akuntabilitas. Undang-Undang Ketahanan Cyber EU, persyaratan pengungkapan SEC, pedoman Desain Aman CISA: kerangka kerja ini menggeser pertanyaan dari “Apakah Anda memiliki pemindai?” ke “Bisakah Anda membuktikan perangkat lunak Anda aman pada titik asal?” Itu adalah pertanyaan yang sangat berbeda, dan kebanyakan organisasi tidak dapat menjawab pertanyaan kedua.

Apa yang masih kurang dipahami oleh eksekutif adalah bahwa ini adalah masalah struktural, bukan masalah sumber daya. Organisasi yang saya lihat merespons risiko open source dengan menambahkan lebih banyak alat pemindai tidak menyelesaikan masalah dasar. Pemindai mendeteksi masalah setelah mereka telah memasuki lingkungan Anda.

Ketika semua yang diberi tanda, tidak ada yang diprioritaskan, dan volume peringatan menjadi disfungsi operasionalnya sendiri. Organisasi yang akan menavigasi ini dengan sukses bukanlah mereka yang membeli lebih banyak alat. Mereka adalah yang mengubah cara mereka membuat keputusan tentang apa open source yang memasuki lingkungan mereka, dan siapa yang bertanggung jawab atas keputusan tersebut.

Dengan open source sekarang tertanam di sebagian besar tumpukan perangkat lunak enterprise, bagaimana organisasi harus memikirkan kembali open source sebagai infrastruktur daripada hanya kemudahan pengembangan?

Model mental yang kebanyakan organisasi gunakan sudah ketinggalan zaman. Open source dimulai sebagai kemudahan pengembangan. Pengembang dapat menarik perpustakaan, bergerak lebih cepat, dan menghindari merekayasa ulang komponen dasar. Kerangka itu masuk akal ketika open source adalah opsional dan suplemen.

Itu bukan kenyataan saat ini. Open source adalah fondasi perangkat lunak modern. Sembilan puluh enam persen aplikasi termasuk komponen open source. Ini bukan lapisan kemudahan di atas infrastruktur milik. Ini adalah infrastruktur. Dan infrastruktur harus dikelola seperti infrastruktur, dengan kebijakan eksplisit tentang apa yang memasuki lingkungan, kepemilikan yang ditentukan untuk pemeliharaan dan perbaikan, dan akuntabilitas yang berada pada tingkat organisasi yang tepat.

Organisasi yang lebih maju dalam hal ini telah membuat pergeseran yang disengaja: konsumsi open source adalah keputusan strategis dengan konsekuensi keamanan dan keuangan, bukan pengaturan default yang dikelola oleh pengembang secara individu. Pergeseran itu memerlukan kebijakan, proses operasional, dan akuntabilitas eksekutif yang jelas. Kebanyakan organisasi belum membuat pergeseran itu.

Anda telah memimpin organisasi melalui beberapa gelombang teknologi. Bagaimana pergeseran AI yang didorong saat ini membandingkan dengan transisi sebelumnya seperti cloud dan DevOps dalam hal kecepatan dan gangguan?

Gerakan AI yang didorong saat ini sangat mirip dengan pergeseran teknologi sebelumnya. Ketika cloud muncul sebagai model pengiriman, organisasi yang memperlakukannya sebagai pilihan teknologi murni membuat kesalahan yang sangat berbeda dibandingkan dengan organisasi yang mengenali itu sebagai pergeseran arsitektur dan operasional. Mereka yang gagal membuat transisi tata kelola membayarnya selama bertahun-tahun dalam IT bayangan, biaya overrun, dan utang teknis dan keamanan.

Apa yang berbeda tentang pergeseran AI yang didorong saat ini adalah kecepatan dan ketidak terlihatannya. Adopsi cloud terlihat. Anda tahu ketika organisasi Anda bermigrasi beban kerja dari on prem ke cloud. DevOps terlihat: organisasi sedang merestruktur tim, mengubah pipa pengiriman, dan menulis proses ulang. Alat pengkodean AI diadopsi pengembang per pengembang, panggilan alat per panggilan, dan risikonya terkumpul dalam basis kode sebelum kebanyakan organisasi telah mendaftarkan bahwa keputusan tata kelola telah dibuat.

Banyak perusahaan bergelut untuk mengubah adopsi open source menjadi model bisnis yang berkelanjutan. Apa yang membedakan perusahaan yang sukses dari mereka yang gagal?

Organisasi yang telah membangun bisnis berkelanjutan di atas open source berbagi satu karakteristik: mereka disiplin tentang apa produk yang sebenarnya mereka jual. Mereka tidak menjual perangkat lunak open source, yang gratis. Mereka menjual keahlian, dukungan operasional, infrastruktur tata kelola, atau layanan terkelola yang membuat perangkat lunak gratis tersebut layak pada skala enterprise.

Di sisi lain, organisasi yang gagal cenderung membingungkan adopsi komunitas dengan traksi komersial. Mereka tidak sama. Jumlah bintang GitHub yang tinggi atau komunitas besar menandakan bahwa pengembang menemukan proyek tersebut berguna. Ini tidak menandakan bahwa pembeli akan membayar untuk itu, atau bahwa hal yang pengembang temukan berguna adalah hal yang organisasi sebenarnya butuhkan. Terjemahan dari adopsi pengembang ke nilai enterprise memerlukan membangun sesuatu di luar open source itu sendiri, dan organisasi yang gagal membuat perbedaan itu dengan jelas, dalam posisi, produk, dan gerakan penjualan mereka, cenderung tidak bertahan dalam transisi ke skala.

Dari pengalaman Anda dalam menskalakan organisasi yang dipimpin pengembang, apa tantangan kepemimpinan terbesar ketika beralih dari pertumbuhan yang dipimpin produk ke operasi skala enterprise?

Tantangan terbesar adalah bahwa keterampilan dan insting yang membuat Anda sukses dalam pertumbuhan yang dipimpin produk bekerja melawan Anda pada skala enterprise. Pertumbuhan yang dipimpin produk menghargai bergerak cepat, mengiterasi di publik, mengoptimalkan pengalaman pengembang, dan membiarkan adopsi memimpin gerakan komersial. Penjualan enterprise menghargai proses yang disengaja, hubungan eksekutif, siklus panjang, dan kemampuan untuk memetakan produk Anda ke hasil yang penting bagi pembeli yang tidak phải pengembang.

Kesalahan kepemimpinan yang paling saya lihat adalah mengasumsikan transisi ini terutama merupakan masalah gerakan penjualan. Ini bukan. Ini adalah masalah desain organisasi. Tim yang membangun produk, posisi, dan hubungan pelanggan awal sering tidak sama dengan tim yang dapat mengeksekusi gerakan enterprise. Mengenali bahwa tanpa kehilangan apa yang membuat produk layak dibeli pada awalnya sangat sulit. Pemimpin yang melakukannya dengan baik adalah mereka yang jujur tentang bagian mana dari organisasi yang perlu berkembang dan membangun kemampuan baru tanpa membongkar budaya yang menciptakan produk.

Anda telah bekerja secara luas di persimpangan keamanan dan produktivitas pengembang. Bagaimana perusahaan dapat menyeimbangkan kecepatan dan inovasi dengan kebutuhan yang semakin meningkat akan komponen perangkat lunak yang aman dan tepercaya?

Pengelompokan kecepatan versus keamanan adalah pilihan yang salah yang telah bertahan karena alatnya telah memperkuatnya. Ketika keamanan diterapkan sebagai gerbang tinjauan di akhir proses pengembangan, itu adalah bottleneck. Ketika diterapkan sebagai sumber komponen tepercaya yang diatur yang pengembang tarik dari awal proses, itu tidak melambatkan apa pun.

Mereka yang telah menyelesaikan ketegangan ini telah melakukannya dengan menggeser di mana keamanan terjadi. Tidak meninjau kode setelah ditulis. Tidak memindai artefak setelah dibangun. Mengatur apa yang masuk ke dalam katalog yang pengembang dan alat AI tarik dari. Jika sumbernya tepercaya, kecepatan tidak terbatas oleh tinjauan keamanan karena pekerjaan keamanan terjadi di hulu. Itu adalah keputusan arsitektur, bukan budaya. Ini memerlukan investasi dalam infrastruktur tata kelola, tetapi tidak memerlukan memilih antara bergerak cepat dan mengirim dengan aman.

Bagaimana Anda melihat peran ekosistem open source yang dikurasi atau tepercaya berkembang selama beberapa tahun mendatang, karena alat AI semakin banyak menghasilkan kode dan ketergantungan?

Peran sumber open source yang dikurasi atau tepercaya akan bergeser dari praktik terbaik menjadi persyaratan dasar. Pergeseran itu didorong oleh dua hal yang tidak akan berbalik.

Pertama adalah lingkungan regulasi. Dalam lanskap 2026, kemampuan untuk mendemonstrasikan provenance perangkat lunak semakin menjadi persyaratan hukum, bukan standar sukarela. Dewan dan regulator bertanya pertanyaan yang tidak dapat dijawab oleh organisasi yang menarik langsung dari registri publik.

Kedua adalah kecepatan pengembangan AI. Ketika alat AI menghasilkan lebih banyak kode dan menarik lebih banyak ketergantungan, volume komponen yang tidak diverifikasi yang memasuki produksi akan melebihi kapasitas organisasi mana pun untuk meninjau mereka secara manual. Organisasi yang telah membangun katalog yang dikurasi dan dikelola kebijakan sebagai sumber default untuk pengembang dan alat AI mereka akan dapat mencocokkan kecepatan AI dengan tata kelola keamanan yang sesuai. Organisasi yang masih mengandalkan registri publik dan tinjauan manual akan menghadapi kesenjangan yang semakin lebar antara seberapa cepat kode dihasilkan dan seberapa menyeluruhnya kode tersebut dievaluasi.

Ekosistem yang dikurasi adalah jawaban infrastruktur untuk masalah yang pengembangan AI telah membuat tidak terhindarkan.

Sebagai salah satu dari sedikit CEO perempuan di ruang open source dan infrastruktur, apa perubahan yang telah Anda lihat dalam keragaman kepemimpinan selama bertahun-tahun, dan apa yang masih perlu ditingkatkan?

Telah terjadi perubahan nyata. Ketika saya memulai karir saya, representasi perempuan dalam peran eksekutif di open source dan infrastruktur rendah enough sehingga pengecualian itu terlihat. Itu kurang benar sekarang. Ada lebih banyak perempuan dalam posisi teknis senior dan eksekutif, lebih banyak organisasi yang telah bergerak melampaui fase pernyataan diversitas yang bersifat tampilan dan membuat perubahan struktural, dan lebih banyak model untuk apa kepemimpinan di ruang ini bisa terlihat seperti.

Kasus bisnis untuk menutup celah yang tersisa tidak abstrak. Masalah yang industri ini kerjakan sekarang, risiko rantai pasokan perangkat lunak, tata kelola AI, perubahan organisasi yang diperlukan untuk membuat keamanan menjadi praktik pertama, adalah masalah yang sulit. Tim yang beragam menghasilkan hasil yang lebih baik pada masalah yang sulit. Bukan sebagai masalah aspirasi tetapi sebagai masalah bagaimana perspektif yang berbeda mengungkapkan asumsi yang tim homogen miss. Saya telah melihat ini secara langsung. Organisasi yang telah membuat kemajuan nyata pada kepemilikan, bukan hanya representasi, adalah mereka di mana keuntungan operasional itu muncul dalam pekerjaan.

Kepemilikan masih tidak merata di seluruh industri. Berada di ruangan tidak sama dengan memiliki perspektif Anda benar-benar dihargai. Perbedaan itu adalah di mana fase berikutnya dari kemajuan perlu terjadi.

Terima kasih atas wawancara yang luar biasa, pembaca yang ingin mempelajari lebih lanjut dapat mengunjungi ActiveState.