Açık kaynakta pazarlamanın önemi hakkında Knative size neler söyleyebilir?

Yorum: Geliştiriciler iyi pazarlamaya karşı bağışık değildir ve açık kaynak projelerinin başarılı olması için tam olarak ihtiyaç duyulan şey budur. Sadece Knative insanlara sorun.

<a href="https://www.techrepublic.com/a/hub/i/r/2021/06/21/405fb893-a19c-4803-8cee-7ebd6c36f891/resize/770x/7a7dd1144e03e57789bf6e60cc87b793/open-source.jpg " target="_blank" data-component="modalEnlargeImage" data-headline="

" data-credit="Resim: Kheng Guan Toh/Shutterstock">Açık kaynak konsepti

Resim: Kheng Guan Toh/Shutterstock

Okunması gereken geliştirici içeriği

"Pazarlama, herhangi bir açık kaynak projesinin başarısı için kod kadar önemlidir." Bu kelimeler Todo Group'un sitesinden kesinlikle doğrudur, ancak aynı zamanda açık kaynak topluluğundaki birçok (çoğu?) tarafından da aynı şekilde kesin olarak göz ardı edilir.

Harika kodun sihirli bir şekilde evlat edinme ve topluluğa dönüşeceğini düşünmeyi seviyoruz.

Hayır!

Knative yazarlarından Ahmet Alp Balkan buna dikkat çekti. bir tweet ve sonra bir Blog yazısı. Blogda, "(W)e, Knative'in erken konumlanması ve mesajlaşmasında bazı hatalar yaptı (ki bu), projenin yaygın olarak benimsenen Kubernetes için bir eklenti olmasını engelledi" dedi. Bu, kolayca "20/20 sonradan anlaşılmış" olarak eleştirilebilir olsa da, aslında biraz öngörü ile açık olan bir şeydir. Açık kaynakta pazarlama önemlidir. Evet gerçekten.

GÖRMEK: Geliştirici tükenmişliğini önlemenin 10 yolu (ücretsiz PDF) (Teknik Cumhuriyeti)

Knative'i daha da iyi hale getirmek

Knative, Google'da doğdu ancak Red Hat ve diğerlerinin geliştirmeye yardımcı olmak için katılmasıyla kısa sürede bir topluluk projesi haline geldi. Başarısızlık sayılmaz. Yine de Balkan, daha iyi pazarlansaydı çok daha popüler olabileceğini düşünüyor -belki de Kubernetes'in kendisi kadar popüler. Blogunda belirttiği sorun, Knative'i benimseyenlerin bunu neden ve nasıl kullanmaları gerektiğini anlamalarıydı:

Knative'in ilk versiyonu üç bölümden oluşuyordu: Sunma, Eventing ve Build. Bunlar üç ortogonal endişe gibi görünebilir, çünkü gerçekten öyleydiler…. Sunucusuz çalışma için 'sunma'nın gerekli bir bileşen olduğunu ve insanların sunucusuz ortamlarda 'etkinlik' yaptığını ve bu ikisinin bazı temel mantığı paylaştığını belirtmekte fayda var. Ama bunun ötesinde, ortak hiçbir şeyleri yok.

Bu güne kadar, Knative hala hem hizmet veriyor hem de etkinlik yapıyor. Bu, proje gerçekten iki şey yaptığı için benimseme kararlarını muhtemelen bozan bir karışıklık yaratır; bir değil. Knative hakkında daha fazla bilgi edinmeye çalışan bir geliştiricinin 'ikisini de kullanmam gerekiyor mu', 'ayrı olarak kurabilir miyim' gibi sorular sorması ve algılanan karmaşıklık nedeniyle projeyi kullanmaması tamamen normaldir.

Seçim iyidir, ancak yapılan seçimi açıkça ifade etmek daha iyidir. Veya Balkan'ın şu sonuca vardığı gibi, seçimi bir şekilde tamamen ortadan kaldırmak için: "Bence Knative yalnızca hizmet veren bileşen olmalıydı. Güçlü bir markaya ve 'daha iyi mikro hizmetler ağı oluşturmak için bir eklenti' gibi bir mesajı olurdu Kubernetes'te."

Balkan, bunun yerine Knative'in "Kubernetes için yapı taşları" olarak konumlandırıldığını ve bir şirketin Knative ile kendi Heroku'larını yuvarlamak için kullanabileceği türden bir şey olduğunu söyledi. "Bu, çok küçük ve niş bir izleyici kitlesi olduğu ortaya çıktı" diye önerdi. Knative'i belirli kullanım durumları için tanımlama (pazarlama) fırsatları vardı, ancak proje bunun yerine kullanılabilecek birçok farklı şeyi vurgulamaya çalıştı. Ünlü bir açık kaynak geliştiricisi olan Simon Willison, sorunu seslendirdi bu yaklaşımla: "Knative markasının çok fazla şey kapsadığını merak ediyorum? Ne olduğunu anlamakta çok zorlandım…" Willison, Knative'in ne işe yaradığı konusunda kendi sonucuna vardı, ancak Knative projesinin bu pazarlama ödevini onun için yapması yerine bu işi yapmak zorundaydı.

O zaman şu "ev ödevi" hakkında konuşalım.

Pazarlamadan hoşlanmayanlara pazarlama

Geliştiricilerin pazarlamaya karşı bağışıklığı tanıdık bir kibirdir. Ayrıca yanlış. Balkan'ın Knative'deki bulgularında olduğu gibi, harika kodun başarısı, geliştiricilerin açık kaynaklı bir proje bulmalarına ve bunu neden kullanmaları gerektiğini hızla anlamalarına yardımcı olacak harika bir pazarlamaya bağlıdır. "Pazarlama", Silikon Vadisi'nden geçen Otoyol 101'deki reklam panoları anlamına gelmez. 16.000'den fazla geliştiriciyle daha iyi pazarlama anlattı Anketlerinde SlashData, belgeler, öğreticiler/nasıl yapılır videoları vb.

GÖRMEK: Başarılı bir geliştirici kariyeri nasıl oluşturulur (ücretsiz PDF) (Teknik Cumhuriyeti)

Ama onu nasıl tanımlarsak tanımlayalım, pazarlama açık kaynak başarısı için kritik öneme sahiptir.

Popüler Envoy projesinin yaratıcısı Matt Klein bunu şöyle ifade ediyor: bir röportajda:

Bir girişime (büyümek için gerekli faaliyetlere) bakarsanız, insanları işe alma, pazarlama, mühendislik vb. şeylere odaklanacaksınız. Bir şirketi başarılı kılmak için tüm bunların bir araya gelmesi gerekir. Açık kaynak için gerçekten aynı. Pazarlamanız var, PR'ınız var, mühendisliğiniz var, işe alımlarınız var, bu da bakıcılar ve katkıda bulunanlar bulmak. Ve bunların hepsini iyi yapmazsanız, projeniz muhtemelen başarılı olmayacaktır.

Tecrübelerime göre, çok az açık kaynak geliştiricisi projelerine bu şekilde yaklaşıyor. Bu bir hatadır ve belirli bir projeye katkıda bulunabilecek insan türlerini de sınırlar. Pazarlama ve halkla ilişkiler gibi işlevlerin bir projenin çekiciliğini genişletmek için yararlı olduğunu fark ettiğinizde, daha fazla kişiye katkıda bulunma şansı verirsiniz. Ayrıca projenizin geniş çapta benimsenme şansını da önemli ölçüde artırıyorsunuz. Sadece Knative insanlara sorun.

Açıklama: AWS için çalışıyorum ancak burada ifade edilen görüşler bana aittir.

Ayrıca bkz.

Source link

İlk yorum yapan olun

Bir yanıt bırakın

E-posta hesabınız yayımlanmayacak.


*