Alasan untuk TIDAK membuka kode nirlaba sumber? [Tutup]


34

Saya penggemar berat kode sumber terbuka. Saya pikir saya mengerti sebagian besar keuntungan dari open source. Saya seorang peneliti mahasiswa sains, dan saya harus bekerja dengan cukup banyak perangkat lunak dan kode yang tidak open source (baik itu milik, atau itu tidak umum). Saya benar-benar tidak dapat melihat alasan yang bagus untuk ini, dan saya dapat melihat bahwa kodenya, dan orang-orang yang menggunakannya, pasti akan mendapat manfaat dari menjadi lebih umum (jika tidak ada yang lain, dalam sains sangat penting bahwa hasil Anda dapat direplikasi jika perlu, dan itu jauh lebih sulit jika orang lain tidak memiliki akses ke kode Anda).

Sebelum saya keluar dan mulai proselitisasi, saya ingin tahu: apakah ada argumen bagus untuk tidak merilis kode nirlaba di depan umum, dan dengan lisensi yang sesuai dengan OSI?

(Saya menyadari ada beberapa pertanyaan serupa di sekitar, tetapi sebagian besar fokus pada situasi di mana kode tersebut terutama digunakan untuk menghasilkan uang, dan saya tidak bisa banyak relevan dalam jawabannya.)

Klarifikasi: Dengan "tidak-untuk-untung", saya menyertakan motif keuntungan hilir, seperti pengakuan merek perusahaan induk dan ekspektasi keuntungan investor. Dengan kata lain, pertanyaannya hanya terkait dengan perangkat lunak yang TIDAK ada motif untung terkait dengan perangkat lunak tersebut.


+1 saat saya menemukan pertanyaan yang menarik. Tetapi saya bertanya-tanya apakah ini tempat yang tepat untuk menanyakan hal ini. Mungkin Anda akan mendapatkan perspektif yang berbeda dari situs SE lainnya, seperti situs PM.SE. Hanya sebuah saran.
haylem

@haylem, saya belum melihat PM.SE, tapi itu sepertinya lebih untuk aspek teknis manajemen proyek?
naught101

Apakah Anda akan secara aktif memelihara proyek setelahnya atau apakah itu kuburan kode. Dengan kata lain, apa masa depan proyek.

@ ThorbjørnRavnAndersen: ya, saya mengasumsikan pemeliharaan aktif, pengembangan, dan penggunaan kode.
naught101

Jawaban:


28

Anda perlu mempertimbangkan bahwa sumber terbuka kode Anda mungkin memerlukan upaya tambahan.

Sebagai contoh, dalam entri blog ini, insinyur Sun / Oracle menjelaskan upaya yang harus mereka ambil ketika membuka sumber kode mereka: Open Source atau Laundry Kotor?

Ketika kita bersiap untuk terjun ke dunia open source, salah satu dari banyak kegiatan yang terjadi adalah persiapan kode untuk sumber terbuka. Ada beberapa hal nyata yang perlu dilakukan. Misalnya, kode sumber kami mencakup campuran kode yang telah kami tulis dan kode yang telah kami lisensikan dari orang lain. Kita harus memisahkan yang terakhir dan hanya sumber terbuka potongan kode yang sesuai.

Kegiatan persiapan lainnya adalah "menggosok" kode informasi hak milik, menyebutkan pelanggan tertentu, pengembang, teknologi, dll. Ini agak kurang jelas, tetapi pertimbangkan contoh berikut:

/\*
 \* HACK - insert a time delay here because the stupid Intertrode
 \* Technologies framebuffer driver will hang the system if we
 \* don't. Those guys over there must really be idiots.
 \*/

Walaupun semua hal di atas mungkin benar, kita mungkin memiliki semacam hubungan dengan Intertrode Tech dan memiliki komentar seperti ini dalam kode dapat merusak bisnis kita dan karenanya harus dihapus. Bisa dibilang itu seharusnya tidak ada di tempat pertama, tapi sekarang saatnya untuk mengambilnya.

Bagian lain dari aktivitas "scrubbing" adalah menghilangkan kata-kata kotor dan kata-kata "tidak diinginkan" lainnya ...

Catatan semua perubahan di atas harus dilakukan untuk kode yang telah dianggap sangat OK sebagai sumber tertutup - yang membuatnya menjadi upaya ekstra murni untuk berbicara.


2
Nah, ini berlaku untuk perusahaan besar dengan basis kode yang ada, apalagi untuk kode yang ditulis sebagai Open Source dari awal.
Konrad Rudolph

1
@KonradRudolph OP menyebutkan saya harus bekerja dengan ... kode yang bukan open source (baik itu milik, atau bukan publik) yang berarti belum ada dari awal
agas

Bukankah hal yang sama terjadi dengan DOOM 3? Masalah Paten Keterlambatan Doom 3 Source Code Release
user16764

11

Keamanan.

Misalnya, Anda membangun kerangka web dan Anda sendiri yang menggunakannya.

Sebagai proyek nirlaba, Anda belum punya waktu untuk mendedikasikan untuk memeriksa setiap bit kode untuk kerentanan terhadap satu serangan atau yang lain:

  • CSRF
  • XSS
  • Injeksi SQL
  • Fiksasi sesi
  • Penggunaan perpustakaan pihak ketiga yang bermasalah atau bahkan bahasa

Sekarang, setelah bersumber dari proyek terbuka, Anda mengizinkan mata ramah untuk berkontribusi, tetapi Anda juga memungkinkan mata jahat penuh wawasan tentang pekerjaan Anda, dan, jika mereka menemukan server yang menjalankan kode Anda, Anda telah menghilangkan kemampuan Anda untuk menyembunyikan ketidaksempurnaan dalam ketidakjelasan.

Tentu saja, ini mungkin tidak berlaku untuk jenis perangkat lunak yang Anda kerjakan; dan seperti biasa ketidakjelasan bukanlah alasan untuk kemalasan dalam keamanan.

Namun, sama seperti yang saya temukan di beberapa level yang saya lewati di Stripe menangkap permainan bendera , mengetahui kode adalah salah satu cara termudah untuk menemukan kerentanan (dan kadang-kadang itu bisa menjadi satu-satunya cara).


7
Perdebatan ini telah berlangsung lama, dan kesan saya adalah bahwa open source lebih baik untuk keamanan, tetapi hanya jika proyek tersebut cukup populer (setidaknya di kalangan pengembang). Aneh bahwa tidak ada argumen yang benar-benar bagus di mana saja di internet (toh saya bisa menemukannya).
naught101

1
Dalam Kombinasi dengan komentar naught101s yang masuk akal. Jika orang yang kurang peduli dengan sumber Anda dan Anda gunakan dalam produksi kemungkinan cukup bagus bahwa seseorang "jahat" akan memeriksanya dan menggunakannya untuk melawan Anda (akhirnya)
schlingel

1
Keamanan melalui ketidakjelasan?
Danubian Sailor

3
@ lechlukasz Apakah Anda bahkan membaca seluruh posting?
Nicole

1
@Oleksi Terima kasih, tapi saya tahu itu. Saya berkata, "ketidakjelasan bukan alasan untuk kemalasan dalam keamanan." Pertanyaan ini bukan tentang buka vs tertutup, ini tentang membuka sistem yang sebelumnya ditutup. Kebetulan saya sepenuhnya setuju dengan tautan yang Anda posting, tetapi pengembangnya tidak sempurna dan ketika Anda membuka sebuah sistem, ada kemungkinan mata pertama untuk menemukan bug akan mengeksploitasinya alih-alih memperbaikinya untuk Anda.
Nicole

10

Alasan yang bagus untuk tidak membuka sumber adalah sebagian sumber Anda mungkin memiliki hak cipta. Seberapa sering Anda tidak mencari solusi cepat untuk masalah di web dan hanya mengambil potongan kode yang Anda temukan?

Yah, itu mungkin hak cipta dan saya tidak tahu apakah penulis ingin menemukan kodenya dilisensikan di bawah lisensi yang berbeda.


1
+1 untuk hak cipta. Hanya ingin menambahkan paten juga. Anda mungkin mengetahui bahwa proyek open-source Anda melanggar beberapa dari ribuan paten perangkat lunak yang dihuni oleh "korps". Video streaming? Dipatenkan. Iklan bayar per klik? Dipatenkan. Hanya beberapa contoh. Namun, kemungkinan "korps" tidak peduli - kecuali jika Anda adalah pesaing.
Amadeus Hein

1
Hehe. Itu sebenarnya bukan argumen menentang open source, tetapi menentang pembajakan. Tapi Anda benar, saya yakin ini adalah masalah dalam banyak kode pribadi besar.
naught101

1
@ naught101 Setuju. Open source hanya memaparkan masalah. Hak kepemilikan tertutup dalam kasus ini adalah masalah tidak ketahuan;)
Andres F.

Jadi Anda mengatakan bahwa salah satu alasan untuk menjaga sumber tertutup adalah untuk memungkinkan Anda menyembunyikan pelanggaran hak cipta biasa? Tidakkah menurut Anda itu alasan yang agak tidak etis untuk digunakan?
Mark Booth

1
Tidak etis .... mungkin, alasan yang sangat bagus untuk tidak open source, tentu saja.
Pieter B

6

Anda harus berhati-hati dengan cara memilih lisensi untuk menghindari kemungkinan masalah pertanggungjawaban.

Seorang pengacara mungkin orang yang lebih baik untuk diajak bicara tentang hal ini, tetapi ide umumnya adalah apa yang terjadi jika seseorang menggunakan (atau menyalahgunakan) aplikasi dan itu menyebabkan kerugian? Apakah kamu bertanggung jawab? Jelas ini akan tergantung pada jenis perangkat lunak apa yang Anda tulis, tetapi Anda harus selalu berhati-hati dengan apa yang lisensi Anda katakan tentang kewajiban Anda. Ini bisa menjadi hal yang sulit untuk dilakukan dengan benar, jadi mungkin lebih mudah untuk tidak merilis kode sumber.


1
Ya, itu poin yang bagus, dan sebagian besar lisensi OS biasanya memiliki beberapa teks yang mencakup pantat di suatu tempat. Saya kira saya mengasumsikan lisensi jenis "tidak bertanggung jawab diterima".
naught101

4

Peringatan: Saya Bukan Pengacara .

Nah, jika itu bukan untuk-keuntungan dan kekayaan intelektualnya sangat terkait dengan kode perangkat lunak, maka beberapa mungkin ingin melindunginya dari penggunaan kembali secara komersial, atau bahkan dieksploitasi secara kejam untuk membuat salinan karbon dari perangkat lunak Anda.

Beberapa alasan lain - yang mungkin berakar pada yang pertama, sebenarnya - adalah bahwa dalam kasus Anda banyak penelitian kelas atas terjadi dengan pendanaan swasta, dan biasanya investor ingin melihat ROI. Dan sejauh ini, tidak semua pelaku industri perangkat lunak (atau pendatang baru) telah sepenuhnya diyakinkan tentang kelayakan model sumber terbuka (kemungkinan besar karena kurangnya pengetahuan dan pemahaman tentang perizinan, atau oleh ketakutan sederhana bahwa perizinan tidak akan mencegah kejahatan). menggunakan dan menyalin).

Selain itu, perusahaan-perusahaan ini tidak ingin digugat kembali oleh orang-orang yang berusaha untuk mendapat untung di belakang mereka, dan perizinan dipandang sebagai perlindungan dalam hal ini juga, dengan alasan baik atau tidak.

Ini mungkin tidak tampak begitu, tetapi mungkin organisasi nirlaba menguntungkan bagi pendiri atau investor mereka. Manfaatnya tidak langsung. Jadi mereka memiliki minat besar pada NFP yang kuat dan tidak dikalahkan oleh pesaing (meskipun Anda juga tidak akan sering berpikir tentang "pesaing" di pasar nirlaba), dan mereka ingin menjaga mereka IP, bahkan jika dengan biaya tidak mendapatkan bola mata gratis untuk meninjau kode mereka untuk menemukan masalah dan memperbaikinya sejak dini.

Perhatikan juga bahwa undang-undang hak cipta berbeda dari satu negara ke negara lain. Banyak negara Eropa menganggap undang-undang hak cipta AS dan sistem paten AS agak bodoh, misalnya, jadi ada latar belakang budaya dan bobot yang sulit dilepaskan.

Tuliskan 2 sen saya pada subjek.

(Saya banyak bekerja di universitas, dan baru-baru ini dalam bioinformatika dan layanan kesehatan ... Ini pertanyaan berulang bagi saya dan kolega saya :))


Hrm .. Saya agak mempertimbangkan kode dan IP dalam pertanyaan saya. Mungkin seharusnya saya membuatnya lebih jelas. Saya akan berpikir ROI dan merek pertimbangan sebagaimana motif keuntungan ... (Saya menyadari bahwa "ilmu" sedikit samar-samar, dan bahwa banyak dari ilmu pengetahuan adalah menguntungkan - bidang saya (sistem ilmu bumi pasti tidak meskipun).
naught101

Klarifikasi pertanyaannya. Maaf atas kerepotannya.
naught101

Saya menganggap bidang Anda menguntungkan. Ini mungkin tidak memiliki pasar yang luas, tetapi itu tidak berarti itu tidak menguntungkan. Dalam fqct, saya menganggapnya melibatkan uang yang cukup besar. Mengapa Anda merasa sebaliknya?
haylem

Saya dalam pemodelan iklim. Tidak ada yang membayar untuk model iklim. Tidak ada yang membayar untuk menggunakan model iklim. Tidak ada untung dari menggunakan perangkat lunak. Orang-orang dibayar untuk melakukan penelitian menggunakan model-model itu (dan ini sering termasuk menulis model), dan waktu komputasi kadang-kadang dibayar, tetapi kedua hal ini berarti bahwa berbagi kode akan membuat segalanya lebih murah (lebih banyak waktu untuk dihabiskan untuk penelitian daripada menulis kode , lebih sedikit waktu yang terbuang untuk fasilitas HPC). Saya tidak benar-benar melihat bagaimana perangkat lunak itu terkait dengan keuntungan apa pun.
naught101

1
@psr: Saya pikir itu tidak ada gunanya: ada hasil yang menguntungkan untuk hasil penggunaan model, tetapi tidak perlu banyak uang yang dilakukan dalam menjual perangkat lunak yang mengimplementasikan model. Mengejutkan saya juga, tetapi bisa sangat baik.
haylem

1

Setidaknya ada dua jenis open source.

Jika sikap Anda adalah "ini sesuatu yang berguna, saya sudah selesai dengan itu" (dan itu ternyata akurat) maka ada sedikit kerugian.

Di sisi lain, jika sikap Anda adalah "Saya benar-benar bersemangat dan saya ingin beberapa pengguna nyata membantu mendorong pengembangan di masa depan" maka pikirkan dengan sangat hati-hati. Anda harus menghabiskan waktu mendukung pengguna, banyak dari mereka yang tidak tahu apa-apa. Anda harus mempertimbangkan permintaan yang saling bertentangan untuk fitur dan perangkat tambahan. Anda akan merasa semakin sulit untuk melakukan perubahan, untuk menjaga kompatibilitas ke belakang.


3
Saya tidak benar-benar melihat bagaimana melepaskan kode mengharuskan siapa pun untuk memberikan dukungan? Dan dalam sains setidaknya, sebagian besar pengguna cukup tahu, setidaknya tentang proses, jika bukan kode itu sendiri.
naught101

1
@ naught101: Tidak mewajibkan, tetapi jika ada yang menggunakan kode Anda, Anda akan mendapatkan email, pertanyaan, saran ... yang akan membutuhkan upaya untuk mengatasinya, kecuali Anda memilih untuk mengabaikannya. Di luar sains, banyak pengguna tidak terlalu mengerti sehingga Anda mungkin menemukan diri Anda membantu orang-orang dengan masalah pengaturan dasar dll. Hanya karena Anda merilis beberapa kode. Setidaknya saya pernah mengalaminya. Bahkan penafian gaya BSD "asalkan apa adanya" dll. Tidak - dan tidak seharusnya - menghentikan orang dari meminta bantuan.
Joonas Pulakka

1
Terpilih karena jawaban ini tidak benar-benar tidak dapat diterapkan dibandingkan yang lain. @JoonasPulakka: tentu saja seharusnya tidak menghentikan orang untuk meminta bantuan. Tapi itu harus menghentikan mereka mengharapkan jawaban. Juga, jika Anda memiliki perangkat lunak yang sebenarnya di depan umum, maka mungkin Anda memiliki tanggung jawab yang sama kepada pengguna terlepas dari apakah kode Anda bersifat publik (tergantung pada EULA, mungkin). Mungkin Anda harus mengharapkan lebih banyak pertanyaan dari pengembang jika Anda merilis kode, tetapi
alangkah baiknya
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.