Mengapa tidak ada budaya membayar untuk kerangka kerja? [Tutup]


9

Salah satu efek samping dari tren baru-baru ini dari "Lean" startups, dan era app store, adalah bahwa konsumen lebih terbiasa membayar harga kecil untuk game / produk kecil.

Misalnya.:

  • SAAS Online yang mengenakan biaya ~ $ 5 / bulan (gaya produk basecamp)
  • Game yang pendek, menyenangkan, dan murah ($ 0,99 dari app store

Pasar ini telah didefinisikan dengan "melakukan satu hal dengan baik, dan membebani orang untuk itu." DHH of Rails / 37 Sinyal ketenaran berpendapat bahwa jika situs web Anda tidak akan menghasilkan uang, jangan repot-repot membuatnya.

Mengapa aturan yang sama tidak berlaku untuk kerangka kerja?

Ada banyak proyek kerangka kerja perangkat lunak di luar sana - banyak yang matang dan kaya fitur, yang menawarkan nilai signifikan bagi pengembang, namun tampaknya tidak ada pasar atau budaya membayar untuk ini.

Tampaknya proyek-proyek yang mengenakan biaya uang sering kali hal-hal seperti perkakas komponen UI, dan sering dipinggirkan demi alternatif gratis.

Kenapa ini?

Tentunya programmer / bisnis melihat nilai dalam berkontribusi kembali ke proyek-proyek seperti Ruby, Rails, Hibernate, Spring, Ant, Groovy, Gradle, (daftarnya terus berlanjut).

Saya tidak menyarankan bahwa kerangka kerja ini harus mulai mengenakan biaya bagi siapa saja yang ingin menggunakannya, tetapi harus ada model bisnis yang bermakna yang akan memungkinkan para pengembang untuk mendapatkan uang dari saat mereka berinvestasi mengembangkan kerangka kerja.

Adakah pemikiran mengapa model ini belum muncul / tidak berhasil?

Sunting Agar jelas: Ini bukan posting tentang memainkan peran penting perangkat lunak sumber terbuka gratis. Ini adalah posting tentang menanyakan mengapa budaya pembayaran untuk kerangka kerja tidak ada.


5
-1 Tidak semuanya tentang uang. Banyak orang melakukan hal-hal untuk bersenang-senang, rasa prestasi dan tidak peduli untuk menghasilkan uang dari hal-hal itu.
Orbling

7
Apakah itu menjamin downvote?
Mchl

Kerangka kerja apa yang Anda harapkan layak untuk dibayar?

1
@Orbling Saya tidak menyarankan semua adalah tentang uang. Ini bukan tentang yang absolut. Saya bertanya mengapa tidak ada model bisnis yang kuat di ruang ini. Keduanya tidak saling eksklusif.
Marty Pitt

1
Bahkan beberapa situs web tidak dirancang dengan ide menghasilkan uang secara langsung. Ini adalah bentuk iklan-sendiri untuk memiliki situs blog / portofolio.
Matthew Whited

Jawaban:


11

Benar-benar ada etika nilai perdagangan untuk nilai dalam perangkat lunak sumber bebas / terbuka.

Di sebagian besar perekonomian, kami berdagang uang-untuk-produk atau uang-untuk-layanan. Sangat mudah untuk melakukannya. Memang, kami melakukannya di bagian perangkat lunak komersial ekonomi.

Tapi kami umumnya tidak memperdagangkan uang untuk persahabatan atau uang untuk romansa. Kami berdagang persahabatan-untuk-persahabatan dan romansa-untuk-romansa.

Demikian juga, dalam perangkat lunak sumber bebas / open-source, etika adalah untuk membayar DHH dan kontributor untuk Rails dengan: melaporkan bug untuk, berkontribusi patch, menulis / memperbarui / memperbaiki dokumentasi untuk, dan menginjili Ruby, Rails, Linux, dan semua proyek perangkat lunak bebas / sumber terbuka secara umum. Itulah cara kami memperdagangkan nilai demi nilai.

Bertanya mengapa "model ini [membebankan biaya untuk kerangka kerja] belum muncul / berhasil" sama dengan menanyakan mengapa model yang sama ini tidak muncul / berhasil ketika menyangkut persahabatan atau romansa. Seseorang yang menawarkan persahabatan tidak menginginkan uang - ia menginginkan persahabatan sebagai balasannya. Demikian juga romansa. Demikian juga, dalam banyak kasus, perangkat lunak.


2
Terima kasih atas tanggapannya, tapi saya tidak yakin metafornya benar. Orang-orang melaporkan bug untuk, mengevaluasi dll, Windows, Basecamp, dll. Demikian juga, banyak pengembang menerima lebih banyak nilai dari Rails daripada yang mereka lakukan dari Basecamp - dalam hal menghemat waktu mereka & mencapai tujuan akhir mereka lebih cepat. Saya pikir perbedaan antara kerangka kerja dan produk cukup buram - misalnya, Perusahaan akan membayar untuk Oracle, tetapi tidak untuk Hibernate.
Marty Pitt

3
Juga, ada model bisnis yang cukup mapan untuk memperdagangkan uang untuk romansa - tergantung pada definisi romansa Anda.
Marty Pitt

1
Dan saya pasti akan menawarkan persahabatan untuk mendapatkan uang. Kedengarannya seperti model bisnis yang bagus bagi saya.
Josh

4
Ada model bisnis yang cukup mapan untuk perdagangan uang-untuk-romansa, sama seperti ada model bisnis yang cukup mapan untuk perdagangan uang-untuk-perangkat lunak. Tetapi beberapa orang yang bersedia menawarkan percintaan hanya bersedia menerima percintaan sebagai pembayaran, dan beberapa orang yang bersedia menawarkan perangkat lunak hanya bersedia menerima perangkat lunak (atau laporan bug, saran fitur, mengerjakan dokumentasi, terjemahan, atau evangelisasi) sebagai pembayaran. Itu tergantung pada orang yang menawarkan romansa, dan itu tergantung pada orang yang menawarkan perangkat lunak.
yfeldblum

2
@Marty Pitt: Anda memiliki konsep romansa yang sangat aneh.
Orbling

3

Saya pikir pertanyaan ini dapat dijawab dengan jawaban dalam pertanyaan ini. Mengapa programmer menulis aplikasi sumber tertutup dan kemudian membuatnya gratis? .

Dan saya hanya akan menambahkannya:

Apa yang saya yakini adalah dengan membuat kerangka bebas, kami memungkinkan programmer pemula dan hobi untuk mendapatkan minat dalam pemrograman yang serius. Ini membuat jalan lebih mudah bagi mereka. Kita telah melihat bahwa platform yang tidak gratis sering kurang diadopsi. Selain itu kerangka kerja gratis biasanya dikembangkan oleh sekelompok orang yang ingin berkontribusi kembali ke masyarakat.


3

Tampaknya selalu turun ke salah satu dari dua budaya yang berbeda. Ada grup "Saya membayar perangkat lunak dengan uang" dan grup "Saya membayar perangkat lunak dengan waktu".

Pertimbangkan TI dalam suatu organisasi. Katakanlah suatu perusahaan ingin melakukan pemantauan jaringan. Itu baik A) Misi kritis dan layak memompa banyak uang ke (Openview, Netcool). Atau B) Anggaran ketat, lakukan apa yang dapat Anda lakukan dengan lebih sedikit (Nagios, MRTG).

Demikian juga ada orang yang "tumbuh" dengan cara Microsoft / Apple dalam mendekati perangkat lunak. Anda membayar uang dan barang-barang harus bekerja. Anda ingin fungsionalitas baru, Anda membayarnya. Di sisi lain ada orang yang terbiasa membayar dengan waktu mereka. Unix, Open source, java, dll. Jika Anda ingin lebih banyak fungsi, Anda menulis sendiri atau mengaktifkan seseorang untuk memperbaikinya untuk Anda.

Pertimbangkan toko aplikasi Apple ke pasar Android. Anda membeli Angry Birds di iPhone, tetapi dapatkan secara gratis (dengan iklan) di Android. Budaya yang berbeda sedang bekerja. Angry Birds sangat sukses di app store dengan biaya 0,99 sen, tetapi mereka tahu bahwa akan memiliki pangsa pasar yang sangat kecil jika mereka mengenakan biaya bahkan 0,25 di Android Market.

Saya pikir kerangka kerja dimulai di kamp terakhir, dan itulah yang terjadi sekarang. Anda tidak dapat memasarkan kerangka kerja karena nenek moyang produk jadi dapat menggunakan, seseorang harus menginvestasikan waktu untuk membuatnya menjadi bahan habis pakai. Orang-orang yang terbiasa mengatur waktu tidak terbiasa membayar dengan waktu dan uang.


1

Tentunya programmer / bisnis melihat nilai dalam berkontribusi kembali ke proyek-proyek seperti Ruby, Rails, Hibernate, Spring, Ant, Groovy, Gradle, (daftarnya terus berlanjut).

Dari pengalaman saya dengan klien dan majikan, saya telah memperhatikan beberapa alasan mengapa bisnis yang menggunakan perangkat lunak Open Source dengan kuat (dan menghasilkan atau menghemat banyak uang dengan menggunakannya) tidak memberikan kembali sebanyak yang mereka bisa:

  • Tidak memahami bagaimana model Open Source bekerja, dan dengan demikian hilang kesadaran akan perlunya sumbangan untuk menjaga proyek tetap kuat

  • Seringkali kurang jelas apa yang akan terjadi dengan sumbangan

  • Masalah pajak, ketidakpastian tentang pengurangan pajak

  • Kesulitan untuk orang-orang teknis yang membenarkan sumbangan (atau cara lain untuk memberi kembali seperti acara hosting, dll.) Di depan manajemen / pengendalian yang tidak tercerahkan ("Jika kita tidak harus membayar untuk itu, mengapa kita harus memberi mereka uang? Untuk bersikap baik "Kami tidak punya anggaran untuk itu. Mungkin tahun depan")

Saya cenderung berpikir masing-masing masalah ini dapat diatasi sampai batas tertentu dalam proyek Open Source apa pun, tetapi sebagian besar tidak dilakukan karena kurangnya keahlian dalam cara berkomunikasi yang lebih jelas, dan beberapa keengganan untuk meminta sumbangan dari bisnis secara lebih maju. cara.

Saya suka semangat "tidak ada uang, tidak ada birokrasi, tidak ada kewajiban" dari komunitas Open Source tapi kadang-kadang saya berpikir - bagaimana jika setiap bisnis yang menggunakan, katakanlah, OpenOffice alih-alih $ 200 lisensi MS Office workplace akan menyumbangkan hanya $ 2 ke OOo, atau beberapa proyek Open Source lainnya?


0

Risiko utama menggunakan perangkat lunak open source adalah kenyataan bahwa ia tidak memiliki dukungan resmi. Pada dasarnya, Anda memiliki kodenya. Meskipun pada awalnya tampaknya lebih menguntungkan untuk menggunakan perangkat lunak "gratis" Anda harus mempertimbangkan kemungkinan bahwa biaya pemeliharaan dalam rumah mungkin akhirnya menimbang biaya solusi berpemilik. Beberapa organisasi tidak mau mengambil risiko itu.


0

Sebagian dari pertanyaan itu tampaknya membandingkan kerangka kerja terhadap pembayaran untuk aplikasi (misalnya game yang menyenangkan, 37 produk sinyal, SAAS online) tetapi itu adalah apel dan jeruk. Konsumen membeli aplikasi sedangkan pengembang menggunakan kerangka kerja untuk membangun aplikasi bagi konsumen. Dan tentu saja, pengembang Anda mungkin konsumen jika ia adalah pengguna dan membeli aplikasi, ketika mereka tidak mengembangkan kerangka kerja.

Kerangka kerja tidak melakukan apa pun di luar kotak sampai mereka berubah menjadi aplikasi yang dapat dijual.

Namun jika kita hanya membandingkan alat pengembang, seperti frameworks vs komponen set vs RAD suites, dll maka saya pikir ada beberapa diskusi bagus yang bisa didapat tentang hal-hal apa yang dibayar dan tidak.


Poin bagus - meskipun saya pikir ini adalah garis yang cukup kabur membedakan suatu produk dari suatu kerangka kerja. Orang membayar untuk Oracle DB, tetapi tidak untuk Hibernate. Pada akhirnya, semua alat ini memberikan nilai bagi orang yang mengkonsumsinya. Saya berpendapat bahwa Spring memberikan nilai dengan cara yang sama seperti yang dilakukan oleh IDE - keduanya adalah alat yang membantu pengguna mendapatkan pekerjaan yang dicapai lebih cepat.
Marty Pitt

0

Mari kita bayangkan bahwa saya membuat kerangka kerja yang disebut "AwesomeWork" (asli ya?). Sekarang orang tidak pernah menggunakannya dan tidak yakin apakah itu akan membantu mereka dan tidak ingin membayar uang untuk sesuatu yang mungkin tidak menguntungkan mereka sedikit pun (jika mereka menyukainya!) Jadi saya merilisnya secara gratis. Sekarang, apakah saya bodoh karena kehilangan potensi keuntungan karena saya mungkin bisa lolos dengan menjualnya seharga $ 5 lisensi? Tidak, karena ketika saya menyampaikan berita dan orang-orang mulai menggunakan kerangka kerja saya, ada pasar sekunder yang sekarang terbuka: buku. Sekarang saya dapat menulis buku tentang AwesomeWork (sebut saja "Do [Awesome] Work Son!", Maaf harus melalui itu di). Jadi penjualan buku berjalan stabil, sekarang saya memutuskan untuk membuat beberapa pembaruan untuk AwesomeWork dan merilisnya di bawah AwesomeWork 2.0 dan lihatlah, saya bisa menjual "Do [Awesome] Work Son!

Saya tidak mengatakan skenario di atas adalah alasan utama bahwa seseorang akan merilis kerangka kerja mereka secara gratis, tetapi itu menunjukkan bahwa mereka masih dapat menghasilkan uang dari melakukannya.

Catatan Sisi: Ada beberapa kerangka kerja yang melakukan charge (meskipun mereka dapat menawarkan edisi komunitas gratis tetapi dengan fitur terbatas). Salah satu yang terlintas dalam pikiran adalah WebSharper , yang memungkinkan situs web ditulis sepenuhnya dalam F #.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.