Yan projeler ve açık kaynak: kariyere kattıkları ve gerçek maliyeti
Yan projelerin ve açık kaynağın kariyere etkisini dürüstçe değerlendirmek: getiri, maliyet ve bir projeyi ne zaman arşivlemenin doğru olduğu.
Birkaç yıl önce PHP topluluğuna küçük bir kütüphane yayımladım: InitPHP. Başlangıçta kendi işimi kolaylaştırmak için yazdım; sonra açık kaynak olarak paylaştım. Bu süreç bana yan proje ve açık kaynak konusunda hiçbir makalenin tam aktaramadığı bir şeyi öğretti: getiri ve maliyet aynı anda gerçek.
Looplio ise farklı bir boyut: tamamen kendi ürünüm, ticari hedefi olan, tek başıma yürüttüğüm bir SaaS (hizmet olarak yazılım). Bu ikisi arasındaki fark, yan projenin kariyere ne kattığını anlamak için iyi bir referans noktası.
Getiri: özgürce öğrenme alanı
Asıl işte büyük bir kod tabanı var; değişiklikler dikkatli yapılıyor, teknoloji seçimleri tartışma gerektiriyor, bağımlılık güncellemeleri test süreçlerine takılıyor. Bu doğru ve gerekli — ama öğrenme hızını kısıtlıyor.
Yan proje bu kısıtlamanın olmadığı yerdir. Yeni bir dili deneyebilirsiniz, farklı bir mimari seçebilirsiniz, “acaba şu çalışır mı” sorusunu gerçek kodla yanıtlayabilirsiniz. Hata yapmanın maliyeti düşük. Bu özgürlük, dikkatli ve yavaş olan asıl iş ortamından farklı bir öğrenme ritmi sağlıyor.
InitPHP’yi geliştirirken PHP’nin derinliklerini — tip sistemini, trait kullanımını, sınıf tasarımını — asıl işte mümkün olmayan bir titizlikle inceledim. Looplio’da React Native ve Expo ile mobil geliştirme öğrendim; asıl işimde mobil yoktu.
Getiri: portföy ve görünürlük
Bir işe alım sürecinde ya da bir danışmanlık görüşmesinde “şu projeyi inceleyebilirsiniz” diyebilmek güçlü bir şey. Çalıştığınız şirketteki koda bağlantı veremezsiniz; ama kendi projenize verebilirsiniz.
Açık kaynak burada ek bir boyut ekliyor: insanların kullandığı, sorun bildirdiği, katkı yaptığı bir proje. Bu yalnızca teknik kapasiteyi değil; kodunuzu başkasının okuyacağı bilinciyle yazmayı, sorunları takip etmeyi, karar gerekçelerini belgelemeyi de gösteriyor.
Getiri: network
Bir kütüphaneyi kullanmaya başlayan başka geliştirici, bir sorun bildiren biri, bir katkıcı. Bu bağlantılar organik büyüyor ve zaman içinde beklenmedik biçimlerde karşınıza çıkıyor. Konferanslarda tanışmalar, tavsiyeler, açık rol duyuruları — çoğu bu bağlantılar üzerinden.
Looplio bir build-in-public süreci yürütüyor: ne yaptığımı, hangi kararları neden aldığımı paylaşıyorum. Bu da bir tür ağ oluşturma; farklı alanlardaki insanlarla kesişim noktası.
Gerçek maliyet: zaman
Her açık kaynak kütüphanesinin görünmeyen bir bütçesi var: sürüm çıkarmak, hata bildirimi yanıtlamak, PR incelemek, belgeleri güncel tutmak. Bu zamanın ücret ödemesi yok; kariyer getirisi var ama anında ve tahmin edilebilir değil.
Başlangıçta bunu küçümsedim. “Bir sürüm çıkarmak ne kadar sürer ki” — büyük bir şey değilse birkaç saattir. Ama birden fazla projeniz varsa, bu saatler hızla birikirler. Ve bir gün hafta sonunun tamamını bir kütüphane sürümüne ayırdığınızda, bunun gerçek bir zaman yatırımı olduğunu net anlıyorsunuz.
Gerçek maliyet: dikkat
Zamanla kardeş ama daha sinsi: dikkat bölünmesi. Asıl işinizde bir projeyi düşünürken, bir de aktif yan projeniz varsa, zihninizin bir kısmı hep orada. “Şu hatayı da bakmam lazım” ya da “InitPHP için o değişikliği yapmayı unutmayayım” gibi arka planda çalışan düşünceler.
Bu düşünce yükünün maliyeti saat cinsinden ölçülmüyor ama gerçek. Özellikle birden fazla aktif proje varsa.
Gerçek maliyet: sürdürme yükü ve “her şeyi açık kaynak yapma” baskısı
Topluluğun bir beklentisi var: “iyi bir geliştirici açık kaynak katkı yapar.” Bu baskı gerçek. Ama şunu söyleyeyim: her yazdığınız şeyi açık kaynak yapmak zorunda değilsiniz.
Bir kütüphane açık kaynak olmadan da var olabilir. İç araçlarınız, deneysel projeleriniz, henüz bitirmediğiniz şeyler — bunları yayımlamak zorunda değilsiniz. Topluluktan gelen baskıyı değil, kendi motivasyonunuzu dinleyin.
InitPHP’yi açık kaynak yaptım çünkü gerçekten başkalarının işine yarayacağını düşündüm; ve yaradı. Looplio’yu kapalı tutuyorum çünkü ticari bir ürün. Her ikisi de bilinçli karar.
Bir projeyi ne zaman bitirmeli, ne zaman arşivlemeli
Sürdürmediğiniz ama silmediğiniz projeler de bir yük taşır: eski sürüm bağımlılıkları olan sorular geliyor, hata bildirimleri açılıyor, “hâlâ aktif mi” soruları soruluyor.
Arşivleme kararı şu sorularla geliyor: Son altı aydır aktif kullananı var mı? Ben hâlâ bakıyor muyum? Daha iyi alternatifler ortaya çıktı mı? Üçüne de “hayır” veya “evet, evet, evet” yanıtı veriyorsanız, arşivlemek dürüst bir karar.
Bunu erkenden yapabilmek hem sizi hem de kullanıcıları dürüstçe bilgilendiriyor.
Yan projeyi araç mı, kaçış mı yaptığınızı ayırt etmek
Bu soruyu sormak zor ama değerli: yan proje şu an gerçekten öğrenmek ya da üretmek için mi, yoksa asıl işin hayal kırıklığından kaçmak için mi?
Her ikisi de zaman zaman olur. Ama kaçış amaçlı bir yan proje sizi tüketiyor; meşru motivasyonu olan bir proje sizi besliyor. Bu farkı hissetmek için projeyi “neden yapıyorum” sorusuna bazen dürüst bir yanıt vermek gerekiyor.
Ben bu soruyu kendime düzenli sorarım. Cevap değiştiğinde, yan projeyi nasıl ele aldığım da değişiyor.