Neden çerçeveler için ödeme kültürü yok? [kapalı]

"Yalın" girişimlerin ve uygulama mağazası döneminin son eğiliminin yan etkilerinden biri, tüketicilerin daha küçük oyunlar / ürünler için küçük fiyatlar ödemeye alışmasıdır.

Örneğin.:

• Ayda yaklaşık 5 ABD doları ücret alan çevrimiçi SAAS (ürünün temel kamp stili)
• Kısa, eğlenceli ve ucuz oyunlar (0,99 $ App Store'dan)

Bu pazar, “bir şeyi iyi yapmak ve insanları bunun için ücretlendirmek” ile tanımlanmıştır. DHH of Rails / 37 Sinyaller şöhret, web siteniz para kazanmayacaksa, bunu yapmak için uğraşmayın.

Aynı kural çerçeveler için neden geçerli değil?

Orada birçok yazılım çerçevesi projesi var - birçoğu olgun ve özellik bakımından zengin, geliştiricilere önemli bir değer sunuyor, ancak bunlar için bir ödeme piyasası veya kültürü yok gibi görünüyor.

Ücretli projeler genellikle UI bileşen araç setleri gibi şeylerdir ve genellikle ücretsiz alternatifler lehine marjinalleştirilir.

Bu neden?

Şüphesiz programcılar / işletmeler Ruby, Rails, Hibernate, Spring, Ant, Groovy, Gradle gibi projelere katkıda bulunmanın değerini görürler (liste uzar).

Bu çerçevelerin bunları kullanmak isteyen herkes için ücretlendirmeye başlamasını önermiyorum, ancak geliştiricilerin çerçeveyi geliştirmeye yatırım yaptıkları andan itibaren para kazanmalarına izin verecek anlamlı bir iş modeli olması gerektiğini önermiyorum.

Bu modelin neden ortaya çıkmadığı / başarılı olamadığı hakkında herhangi bir düşünceniz var mı?

Düzenleme Açık olmak gerekirse: Bu ücretsiz, açık kaynak yazılım önemini oynarken aşağı hakkında bir yazı değildir. Bu, çerçeveler için ödeme kültürünün neden var olmadığını sormakla ilgili bir yazı.

Serbest / açık kaynaklı yazılımlarda kesinlikle değer-fiyat-ticaret değeri vardır.

Ekonominin çoğunda, ürün için para veya hizmet için para ticareti yapıyoruz. Bunu yapmak çok uygun. Gerçekten de bunu ekonominin ticari yazılım kısmında yapıyoruz.

Ancak genellikle dostluk için para ya da romantizm için para ticareti yapmayız. Arkadaşlık için arkadaşlık ve aşk için romantizm yapıyoruz.

Benzer şekilde, serbest / açık kaynaklı yazılımda etik, DHH ve Rails'e katkıda bulunanları şu yollarla bildirerek: Ruby, Rails, Linux ve diğerlerinin belgelerini yazmak, yamalara katkıda bulunmak, belgeleri yazmak / güncellemek / düzeltmek ve evangelize etmektir. genel olarak ücretsiz / açık kaynaklı yazılım projelerinin Değer için değer ticaretini böyle yaparız.

"Bu çerçevenin [çerçeveler için para harcaması] neden ortaya çıkmadığını / başarılı olamadığını" sormak, aynı modelin arkadaşlıklar veya romantizm söz konusu olduğunda neden ortaya çıkmadığını / başarılı olamadığını sormaktır. Arkadaşlık teklif eden biri para istemez - karşılığında arkadaşlık ister. Aynı şekilde romantizm. Aynı şekilde, birçok durumda yazılım.

Bu sorunun bu sorudaki cevaplarla cevaplanabileceğini düşünüyorum Programcılar neden kapalı kaynak uygulamaları yazıyor ve sonra bunları ücretsiz yapıyor? .

Ve sadece ona eklerdim:

Inanıyorum çerçeve ücretsiz yaparak acemi ve hobi programcı ciddi programlama ilgi kazanmak olduğunu. Bu yolu onlar için kolaylaştırır. Zaten özgür olmayan platformların, onlardan daha az kabul edildiğini gördük. Dahası, serbest çerçeveler genellikle topluma katkıda bulunmak isteyen bir grup insan tarafından geliştirilir.

Her zaman iki farklı kültürden birine inmiş gibi görünüyor. "Paralı yazılım için para ödüyorum" grubu ve "Zamana sahip yazılım için para ödüyorum" grubu var.

Bir kuruluşta BT'yi düşünün. Bir şirketin ağ izlemesi yapmak istediğini varsayalım. Ya A) Görev kritiktir ve tonlarca para pompalamaya değer (Openview, Netcool). Veya B) Sıkı bütçe, daha az ile yapabileceğinizi yapın (Nagios, MRTG).

Aynı şekilde, Microsoft / Apple'a yaklaşma yazılımıyla "büyüyen" insanlar da vardır. Para ödüyorsunuz ve bir şeyler çalışmalı. Yeni bir işlevsellik istiyorsunuz, bunun için ödeme yapıyorsunuz. Öte yandan, zamanlarıyla ödemeye alışkın olan insanlar var. Unix, Açık kaynak, java, vb. Daha fazla işlevsellik istiyorsanız, kendiniz yazar veya birisinin sizin için düzeltmesini sağlarsınız.

Apple'ın Android mağazasına uygulama mağazasını düşünün. İPhone'da Angry Birds'ü satın alırsınız, ancak Android'de ücretsiz olarak (reklamlarla) alırsınız. İş yerinde farklı kültürler. Angry Birds, yaklaşık 0,99 sentlik bir uygulama mağazasında çılgınca başarılı, ancak Android Market'te 0,25'lik bir ücret bile olsa çok küçük bir pazar payına sahip olacağını biliyorlardı.

Sanırım çerçeveler ikinci kampta başladı ve bu yüzden şimdilik böyle. Bir çerçeveyi bitmiş bir ürün büyükannenin kullanabileceği şekilde pazarlayamazsınız, birisi onu bir sarf malzemesi yapmak için zaman harcamak zorundadır. Zamanı koymak için kullanılan insanlar hem zaman hem de para ile ödeme yapmaya alışkın değildir.

Şüphesiz programcılar / işletmeler Ruby, Rails, Hibernate, Spring, Ant, Groovy, Gradle gibi projelere katkıda bulunmanın değerini görürler (liste uzar).

Müşteriler ve işverenlerle yaşadığım deneyimden, Açık Kaynak yazılımını güçlü kullanan (ve onu kullanarak çok para kazanan veya tasarruf eden) işletmelerin ellerinden geldiğince geri vermemelerinin birkaç nedenini fark ettim:

• Açık Kaynak modelinin nasıl çalıştığını anlamadı ve bu nedenle projeleri güçlü tutmak için bağış ihtiyacının eksik olduğunun farkında değil

• Genellikle bir bağışta ne olacağı netlik eksikliği

• Vergi sorunları, düşülebilirlik konusunda belirsizlik

• Aydınlanmamış yönetim / kontrol ("Bunun bedelini ödemek zorunda kalmazsak, neden onlara para vermeliyiz?) "Bunun için bütçemiz yok. Belki gelecek yıl")

Bu sorunların her birinin herhangi bir Açık Kaynak projesinde bir dereceye kadar ele alınabileceğini düşünüyorum, ancak çoğunlukla daha net iletişim kurma konusunda uzmanlık eksikliği ve işlerden daha ileri bir şekilde bağış istemek konusunda bazı isteksizlikler nedeniyle yapılmıyor. yol.

Açık Kaynak topluluğunun "para yok, bürokrasi yok, yükümlülük yok" ruhunu seviyorum ama bazen düşünüyorum - 200 dolarlık MS Office işyeri lisansı yerine OpenOffice kullanan her işletme OOo'ya sadece 2 $ bağışlarsa, ya da başka bir Açık Kaynak projesi?

Açık kaynaklı yazılım kullanmanın en büyük riski, hiçbir resmi desteğinin olmamasıdır. Temel olarak, kodun sahibi sizsiniz. İlk başta "ücretsiz" yazılım kullanmak daha karlı gibi görünse de, evde bakım maliyetlerinin sonunda tescilli bir çözümün maliyetini tartma olasılığını hesaba katmanız gerekir. Bazı kuruluşlar bu riski göze almak istemiyor.

Sorunun bir kısmı, uygulamalar için (örneğin, eğlenceli oyunlar, 37 sinyal ürünleri, çevrimiçi SAAS) ödemelere karşı çerçeveleri karşılaştırıyor gibi görünüyor, ancak bunlar elma ve portakal. Tüketiciler uygulama satın alırken, geliştiriciler tüketiciler için uygulama oluşturmak için çerçeveler kullanırlar. Ve elbette, geliştiriciniz bir kullanıcıysa ve çerçeveler üzerinde geliştirmedikleri zaman uygulama satın alırsa bir tüketici olabilir.

Çerçeveler satılabilecek uygulamalara dönüştürülene kadar kutudan hiçbir şey yapmaz.

Ancak, çerçeveler ve bileşen kümeleri ve RAD paketleri vb.

"AwesomeWork" adında bir çerçeve oluşturduğumu düşünelim (orijinal ha?). Şimdi insanlar hiç kullanmadılar ve onlara yardım edip etmeyeceğinden emin değiller ve onlara biraz faydası olmayan bir şey için para ödemek istemeyeceklerinden emin değiller (hatta beğenirlerse!) Bu yüzden ücretsiz olarak serbest bırakıyorum. Şimdi, potansiyel kârları kaybettiğim için bir aptal mıyım çünkü 5 dolarlık bir lisans karşılığında satabiliyor olabilir miyim? Hayır, çünkü sözümü çıkardığımda ve insanlar çerçevemi kullanmaya başladıkça, şu anda açılan ikincil bir pazar var: kitaplar. Şimdi AwesomeWork hakkında bir kitap yazabilir (diyelim ki "Do [Awesome] Work Son!" Diyelim, üzgünüm bunu vardı). Kitabın satışları istikrarlı bir şekilde devam ediyor, şimdi AwesomeWork için bazı güncellemeler yapmaya ve bunu AwesomeWork 2.0 altında serbest bırakmaya karar verdim ve "Do [Awesome] Work Son!

Yukarıdaki senaryo, birisinin çerçevesini ücretsiz olarak serbest bırakmasının ana nedeni olduğunu söylemiyorum, ancak yine de bunu yapmaktan bir miktar para kazanabileceklerini gösteriyor.

Yan Not: Ücretli birkaç çerçeve vardır (ancak ücretsiz ancak sınırlı özelliklere sahip bir topluluk sürümü sunabilirler). Akla gelen WebSharper , web sitelerinin tamamen F # ile yazılmasına izin verir.