Merilis perangkat lunak open source terlalu cepat [ditutup]


37

Apa tanggung jawab moral untuk merilis perangkat lunak open source terlalu cepat? Misalnya, produk hampir lengkap yang belum sepenuhnya diuji.

Apa harapan programmer? Tunggu sampai sepenuhnya diuji, atau lepaskan ke open source dan kemudian lanjutkan pengembangan, pengujian, dan peningkatan lebih lanjut?

Kekhawatirannya adalah bahwa perangkat lunak bersumber terbuka dan berpotensi menyebabkan masalah bagi konsumen.

Apakah ini ketakutan yang tidak berdasar?


10
Tambahkan penafian jika Anda khawatir. :)
Vaughan Hilts

18
Kelemahan dari merilis terlalu cepat adalah bahwa dorongan publisitas yang Anda dapatkan ketika rilis mungkin hilang jika perangkat lunak tidak dapat digunakan. Kemudian, rilis berikutnya "ya, saya mencobanya, itu mengisap". Ini tentu saja tergantung pada seberapa banyak Anda perlu membuatnya dalam bentuk dan target audiens.
Davidmh

@VaughanHilts Saya tidak khawatir tentang seseorang yang menjadi marah, kekhawatiran semata-mata terletak pada keinginan untuk perbaikan distribusi dan konsumsi perangkat lunak. Yang terakhir inilah yang tidak ingin saya derita karena terlalu bersemangat untuk dibebaskan.
Thomas Stringer

@ Davidvid: Itu akan menjadi perhatian utama saya juga, "sekali terbakar, dua kali malu".
Matthieu M.

8
Melepaskan sumber tetapi bukan binari mungkin merupakan cara yang baik untuk mencegah orang-orang dengan harapan salah menggunakan perangkat lunak Anda sebelum siap.
Pasang kembali Monica

Jawaban:


56

Saya percaya sebaliknya bahwa Anda harus merilis perangkat lunak open source sesegera mungkin. Tidak ada "terlalu cepat" untuk itu (tetapi harus dikompilasi).

Atau setidaknya menerbitkan kode sumber sangat awal dan terus menerus (misalnya dengan sering mendorong pada github ), tanpa membuat rilis resmi .

Namun, sangat penting untuk menandainya sebagai tahap alfa atau beta, dan jika mungkin untuk mengatakan (misalnya dalam file READMEatau TODO, dan di beberapa blog, dll ...) apa yang hilang, tidak diuji, atau dalam kondisi buruk. Anda juga harus menggunakan nomor versi untuk menyampaikan informasi tersebut.

Dengan perangkat lunak gratis , yang terbaik yang harus terjadi adalah seseorang melirik kode sumber dan mengusulkan Anda perbaikan kecil. Inilah sebabnya mengapa Anda membuat perangkat lunak Anda gratis!

Oleh karena itu, Anda perlu membuat pekerjaan harian Anda terlihat pada perangkat lunak gratis Anda! Kontributor eksternal akan kesal jika tambalan mereka tidak berfungsi, atau merupakan duplikat, kode sumber perangkat lunak Anda saat ini.

Apa yang harus Anda takuti adalah tidak ada yang tertarik dengan perangkat lunak Anda (dan berkontribusi padanya). Menarik minat pihak luar ke perangkat lunak gratis (khususnya, menarik kontributor eksternal) adalah perjalanan yang panjang.


33

TL; DR:

Lepaskan Dini. Lepaskan Sering.

Anekdot pribadi:

Saya sangat senang dengan proyek yang sedang saya kerjakan. Suka, sangat bersemangat. Aku tidak bisa tidur nyenyak di malam hari. Jadi, saya mendorong co-dev saya untuk merilis v1.0 lebih cepat dari yang dia inginkan.

Itu sungguh mengerikan. Tidak ada yang berhasil seperti yang seharusnya. Ada bug di setiap belokan, tetapi kami mencatatnya dan memperbaikinya. Kami bahkan memiliki beberapa pengadopsi awal yang mengirimkan bug yang mungkin tidak kami temukan. Satu atau dua minggu kemudian kami merilis rilis baru yang membahas banyak masalah dan kemudian kembali untuk membangun fitur baru.

Melepaskan lebih awal adalah hal terbaik yang bisa kami lakukan. Itu menempatkan produk kami di depan pengguna nyata. Melakukan bug yang terbuka ini, kami mungkin atau mungkin tidak menemukan dan membuat proyek kami lebih baik. Ini juga membuat para pengadopsi awal tahu bahwa kami serius tentang proyek ini. Akan ada lebih banyak rilis dan pengembangan aktif.

Itu bisa dengan mudah pergi sebaliknya juga. Kami bisa mengabaikan laporan bug itu. Atau kita bisa tidak bereaksi dengan cepat. Itu mungkin cerita yang berbeda jika kami butuh 3 bulan untuk merilis v1.1, bukan beberapa minggu.


9
Kedengarannya seperti satu-satunya kesalahan besar Anda menyebutnya "v1.0". Umumnya pengguna berharap untuk menunjukkan produk "selesai" dalam arti bahwa itu dapat digunakan untuk tujuan yang dimaksudkan, bebas dari bug yang jelas, dll. "Lepaskan lebih awal" adalah baik, tetapi pengguna harus diberi tahu bahwa mereka adalah kelinci percobaan.
R ..

3
Iya nih. Saya setuju dengan itu di depan mata. Agar adil, saya pikir saya sudah benar-benar mengujinya. Saya pikir itu 1.0 pada waktu @R ... saya salah.
RubberDuck

12

Ini sama dengan perangkat lunak sumber tertutup. Komunikasi itu penting.

Beri tahu pengguna tentang keadaan perangkat lunak itu dan mengapa tersedia untuk diunduh.

Perangkat lunak akan selalu menyebabkan masalah pelanggan, tidak peduli apakah itu sepenuhnya diuji atau tidak. Sebagian besar pelanggan menerima kenyataan itu, dan beberapa pelanggan tidak pernah melakukannya. Tetapi jika perangkat lunak akan menyebabkan lebih banyak masalah daripada yang bisa diharapkan, ada kewajiban moral untuk memberi tahu pelanggan tentang risiko yang mereka ambil. Informasi harus dalam bentuk singkat (label "Alpha / Beta / EarlyAccess") *, dan secara rinci: Daftar masalah yang diketahui, solusi, dan pertimbangan khusus, misalnya jika kemungkinan data dapat rusak.

* Ketahuilah bahwa pengguna telah dilatih oleh beberapa perusahaan perangkat lunak besar untuk menganggap "Beta" sebagai keadaan di mana perangkat lunaknya agak padat, sehingga memberi tahu pengguna bahwa perangkat lunaknya "Beta" sering kali bukan informasi yang memadai.


3
Haruskah kita menyimpulkan bahwa "beta" seharusnya tidak terlalu solid? Saya menduga "perusahaan perangkat lunak besar" menyebutnya "beta" ketika akan siap berproduksi, untuk menghadapi perangkat lunak tersebut ke data dunia nyata. Mungkin menyebutnya prototipe ?
Pierre Arlaud

2
Label "Beta" sekarang memiliki arti yang berbeda untuk orang yang berbeda, jadi menurut saya, kami tidak dapat menyimpulkan banyak dari label "Beta" selain bahwa perangkat lunaknya berada di antara "agak dapat digunakan" dan "hampir selesai". Beberapa pelanggan akan menyimpulkan sesuatu, dan tidak semua dari mereka akan menyimpulkan hal yang sama. Itu sebabnya saya memberi komentar.
Peter

3
Saya cenderung menggunakan istilah "alpha build" sekarang untuk prototipe build. Ini memberi orang perasaan bahwa "Hal ini bahkan belum beta, orang! Jangan berharap itu hampir selesai."
RubberDuck

2
Anda bisa mendistribusikannya dalam bentuk yang berbeda, misalnya hanya dalam bentuk sumber, tanpa paket biner.
el.pescado

3
@SteveJessop sebelum industri game mengubah apa yang kami maksud dengan "beta", saya akan setuju dengan Anda. =)
RubberDuck

7

Tidak ada tanggung jawab moral sama sekali. Tidak ada yang dipaksa untuk menggunakan perangkat lunak setengah matang Anda.

Satu-satunya hal yang perlu diperhatikan adalah kredibilitas Anda.


2
tanpa penjelasan, jawaban ini dapat menjadi sia-sia jika ada orang yang memposting pendapat yang berbeda. Misalnya, jika seseorang memposting klaim seperti "Ada tanggung jawab moral. Seseorang mungkin tergoda untuk menggunakan perangkat lunak setengah matang Anda. Kredibilitas Anda bukan satu-satunya hal yang perlu dikhawatirkan." , bagaimana jawaban ini membantu pembaca untuk memilih dua pendapat yang bertentangan? Pertimbangkan untuk mengeditnya dalam bentuk yang lebih baik, agar sesuai dengan pedoman Cara Menjawab .
nyamuk

6
@gnat: Tidak benar bahwa jawaban ini tanpa penjelasan - penjelasannya adalah kalimat berikutnya: "Tidak ada yang dipaksa untuk menggunakan perangkat lunak setengah matang Anda". Ini adalah penjelasan singkat, ya, tetapi masih merupakan ALASAN untuk mengatakan "tidak ada tanggung jawab moral apa pun"
slebetman

@gnat: hal yang sama dapat dikatakan tentang sebagian besar jawaban. "Saya tidak percaya Anda harus melepaskan [...] Tidak terlalu penting untuk menandai itu [...]". Apakah Anda mengharapkan lebih banyak sumber eksternal untuk jawaban ini?
Pierre Arlaud

2
Ada yang baik dan buruk. Saya setuju dengan Anda, tetapi akan menyenangkan melihat Anda mendukungnya dengan argumen yang lebih kuat.
RubberDuck

6

Pengalaman saya adalah bahwa ada keseimbangan yang harus dicapai.

Saat ini, saya sedang bekerja (dalam arti menjawab pertanyaan dan memberikan saran pengembangan, tanpa melihat kode apa pun) dengan pengembang yang membuat proyek FOSS yang sangat menarik yang menggunakan kode yang saya tulis. Rilis publik telah berulang kali tertunda oleh realisasi perubahan desain yang akan membuat proyek jauh lebih baik dalam jangka panjang, tetapi yang membutuhkan penulisan ulang kode yang signifikan yang sudah ditulis dan itu sudah "berfungsi". Pandangan saya adalah, seandainya rilis yang berfungsi tetapi tidak sempurna dibuat segera setelah ada sesuatu yang berfungsi untuk ditampilkan, ide-ide untuk perubahan (dan tambalan yang sebenarnya) bisa saja berasal dari komunitas yang lebih luas yang tertarik pada proyek ini dan mempercepatnya daripada memiliki masalah muncul perlahan, satu per satu, sebagai pengembang memikirkan mereka dan meminta umpan balik desain dari saya dan anggota komunitas lain yang tertarik. Jadi dari sudut pandang ini, saya sangat mendukung "rilis awal, rilis sering".

Di sisi lain, rilis berkualitas rendah dapat membuat proyek baru terlihat buruk bahkan sebelum proyek dimulai. Beberapa perangkap yang pernah saya lihat meliputi:

  • Pohon kerangka dengan definisi antarmuka tetapi tidak ada kode.
  • Kode yang tidak berhasil dikompilasi untuk siapa pun selain pengembang.
  • Tidak ada instruksi untuk membangun / menjalankan program.
  • Tidak ada dokumentasi tentang aspek-aspek apa yang diharapkan dapat berfungsi.
  • Deskripsi yang tidak jelas tentang apa yang bahkan atau akan dilakukan program.
  • Kurangnya demonstrasi kegunaan.

Untuk poin terakhir, saya memikirkan hal-hal seperti:

  • Kompiler / interpreter yang bahkan tidak dapat mengkompilasi / menjalankan program tipe hello-world.
  • Emulator yang setidaknya tidak dapat menjalankan program sampel atau menunjukkan bahwa ia melakukan sesuatu.
  • Alat pengolah gambar yang tidak dapat melakukan apa pun selain memuat dan menyimpan kembali gambar yang tidak dimodifikasi.
  • Game dengan apa pun kecuali layar judul.

Jenis-jenis masalah ini mengarah pada gambar "vaporware" yang mungkin sulit untuk diguncang kecuali Anda sangat terbuka tentang kurangnya kode kerja untuk memulai.

Akhirnya, buat nomor versi Anda masuk akal. Jangan panggil proyek Anda "1.0" sampai proyek melakukan apa yang diharapkan pengguna tanpa crash. Saya selalu beruntung dengan menggunakan nomor versi di sekitar "0,5" untuk rilis publik awal dan pergi dari sana, tetapi saya juga melihat hal-hal seperti "0,1" atau "0,10" yang masuk akal.


1

Ada satu kasus ketika merilis perangkat lunak bebas dapat memiliki konsekuensi negatif. Beberapa spesifikasi dilisensikan kepada publik dengan syarat bahwa semua implementasi yang didistribusikan kepada publik harus memenuhi spesifikasi sepenuhnya ketika pertama kali diterbitkan. Penerbit secara hukum melarang Anda mendistribusikan implementasi spesifikasi yang sedang dikerjakan. Tanpa lisensi khusus yang dinegosiasikan dari penerbit spec, Anda harus membaginya dengan siapa pun hingga lulus semua tes. Ini memaksa "model katedral" (sebagaimana Eric S. Raymond menyebutnya) pada implementasi spesifikasi.

Salah satu spesifikasi di bawah lisensi tersebut adalah Spesifikasi Bahasa Jawa . Pembatasan ini berlaku untuk pengembang mesin virtual yang kompatibel dengan JVM, tetapi untungnya tidak untuk pengembang aplikasi yang berjalan di JVM.

Artikel " 4 Pergeseran Detail Tentang Microsoft 'Open Source' .NET " oleh Liu Qihao & Ciaran O'Riordan menyebutkan kemungkinan menafsirkan Microsoft Patent Promise untuk .NET Library dan Komponen Runtime untuk mengecualikan implementasi CLR yang tidak lengkap dengan cara yang sama. . Tetapi sekali lagi, ini tidak berlaku untuk aplikasi yang berjalan di CLR.


2
Ini hanya penting jika Anda ingin membuat implementasi JRE / JDK, bukan program java yang berjalan di atasnya, AFAIK.
sjas

@sjas Apakah Anda mencoba menyiratkan bahwa JLS adalah satu-satunya spek yang kemungkinan akan dijumpai yang memiliki batasan "lengkap atau simpan untuk Anda sendiri"?
Damian Yerrick

Anda mencoba menyiratkan bahwa saya menyiratkan ini. ;)
sjas

@ Terima kasih. Adakah cara lain yang bisa saya gunakan untuk membuat jawaban ini bermanfaat?
Damian Yerrick

Saya tidak downtote btw. Saya sudah menyelesaikan kesalahpahaman, yang saya miliki ketika pertama kali membaca jawaban Anda. Anda dapat memasukkannya dalam posting Anda jika Anda ingin mengubah sesuatu.
sjas
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.