Kebijaksanaan menggunakan kode sumber terbuka dalam produk perangkat lunak komersial


13

Saya sedang mencari menggunakan beberapa kode sumber terbuka di aplikasi web ASP.NET saya (khususnya necis ). Manajemen bukan penggemar, karena open source dipandang sebagai risiko yang telah menggigit kita sebelumnya. Rupanya pengembang sebelumnya harus menulis ulang hal-hal setelah komponen open-source gagal.

Kelihatannya pro:

  • Ia melakukan banyak hal bagi saya yang jika tidak akan melibatkan banyak kode boilerplate atau solusi yang direkomendasikan tetapi lebih lambat dari Microsoft (Entity Framework).

Cons:

  • Cukup rumit sehingga jika tiba-tiba gagal dalam produksi, saya akan kesulitan untuk memperbaikinya. Namun, ini digunakan pada situs dengan lalu lintas jauh lebih tinggi daripada milik saya, jadi saya tidak berpikir itu akan menjadi bagian berisiko tinggi dari proyek ini.

Apa konsensus di sini? Apakah tidak bijaksana untuk menggunakan kode sumber terbuka di proyek saya yang saya tidak tahu / mengerti serta saya lakukan kode saya sendiri?


15
ASP.NET dan tumpukannya bersumber terbuka.
Andrew T Finnell

11
"Apakah tidak bijaksana untuk menggunakan kode sumber terbuka di proyek saya yang saya tidak tahu / mengerti serta saya melakukan kode saya sendiri?" Berbeda dengan perpustakaan sumber tertutup yang merupakan kotak hitam?
user16764

5
@AndrewFinnell: Bukan dengan definisi gerakan FLOSS sendiri.
Pelaku

6
wrt proyek OS tertentu yang Anda pikirkan, mungkin menarik bahwa Dapper digunakan oleh StackExchange ...
Marjan Venema

4
Ini bukan pertanyaan teknis, ini bukan tentang yang lebih baik. Yang mana yang salah. MFC sudah mati, XP akan mati dalam waktu kurang dari 2 tahun dll. Proyek gratis dan sumber terbuka tidak akan mati jika ada gunanya, karena Anda atau orang lain dapat mengambil alih. Ini tentang siapa yang akan disalahkan. Jika Anda memilih Microsoft, jika tidak terduga, atau kesalahan Microsoft. Jika Anda menggunakan Free / opensource, itu akan menjadi kesalahan Anda.
ctrl-alt-delor

Jawaban:


20

Ini adalah pilihan yang harus Anda buat berdasarkan keadaan tertentu. Anda dapat mengurangi risiko Anda dengan:

  • menguji kerangka kerja secara menyeluruh, menghindari kemungkinan kejutan buruk menggigit Anda dalam lingkungan produksi, dan
  • menggunakan kopling longgar untuk meminimalkan jumlah kode yang tergantung pada kerangka kerja secara langsung, sehingga Anda dapat mengubah implementasi Anda sendiri jika harus melakukannya tanpa menulis ulang seluruh produk Anda.

Pada akhirnya, dengan proyek sumber terbuka yang banyak digunakan, Anda cenderung menghabiskan lebih banyak waktu untuk menulis sendiri daripada memperbaiki beberapa masalah yang Anda hadapi.


16

Saya akan mengatakan lebih jauh bahwa jika reaksi awal Anda adalah menulis sesuatu sendiri daripada melihat apakah orang lain telah menulisnya, Anda pasti akan gagal. Jangan anggap enteng semua jam kerja dan perbaikan bug yang telah masuk ke proyek-proyek open source mainstream.

Setelah Anda mulai masuk ke domain bisnis Anda, Anda akan lebih sulit menemukan OSS yang memenuhi kebutuhan Anda. Tetapi tidak perlu menerapkan kembali produk ORM lainnya. Jika necis cukup rumit sehingga Anda tidak akan dapat men-debug dan memperbaiki kode mereka, bagaimana Anda membenarkan menghabiskan semua jam kerja menulisnya dari awal? Selain itu, Anda bisa (harus?) Selalu melihat di luar kotak pada solusi NoSQL saat Anda melakukannya.

Bahkan Linus mengakui bahwa ia berusaha menemukan solusi SCM yang memenuhi semua kriteria sebelum mengembangkan Git. Setidaknya dia bisa menjelaskan mengapa tidak ada solusi yang cukup baik.

Pada titik tertentu dalam hidup saya, saya berhenti ingin menulis ulang semuanya sendiri dan ingin fokus menyelesaikan masalah dunia nyata. Sebagian besar masalah yang perlu diselesaikan dalam bisnis adalah spesifik domain. Temukan cara untuk menulis lebih sedikit kode tidak lebih.


2
+1 Saya setuju dengan semua itu kecuali di mana Anda mengatakan dia “(harus)” melihat NoSQL; setiap solusi penyimpanan data NoSQL - ada banyak - memiliki serangkaian trade-off khusus dengan database relasional SQL "standar", sehingga sulit untuk mengatakan "harus" tanpa banyak informasi. Terkadang itu adalah kompromi yang baik, dan terkadang tidak, tetapi Anda tidak dapat membuat pernyataan menyeluruh tentang hal itu. "NoSQL" hanyalah branding sampah di sekitar sekelompok teknologi dengan sedikit kesamaan selain tidak menjadi skema penyimpanan data yang paling umum.
Donal Fellows

Tapi semua yang Anda tulis, saya setuju. OSS yang baik membutuhkan banyak usaha dari bahu pengembang yang bekerja biasa (dan siapa yang ingin menggunakan OSS yang buruk?)
Donal Fellows

Dapper rumit karena digeneralisasikan. Jika saya menulis solusi saya sendiri, saya akan melakukan banyak kode konversi dataset-ke-objek boilerplate (yaitu MyClass.Property = set.Tables[0].Rows[i]["Property"].ToString()).
Tuan Jefferson

Setelah Anda mulai masuk ke domain bisnis Anda, Anda akan lebih sulit menemukan --OSS - apa pun yang memenuhi kebutuhan Anda. Kecuali jika bisnis Microsoft adalah bisnis Anda. (tapi saya suka sisa dari apa yang Anda katakan.)
ctrl-alt-delor

@ Richard Beberapa Jawaban saya mungkin tidak jelas. Pernyataan Anda adalah apa yang saya juga katakan. Mengapa fokus pada bagian yang telah dipecahkan berkali-kali seperti ORM. Fokus pada Domain Bisnis. ORM bukan domain bisnis kecuali jika Anda menjual produk ORM.
Andrew T Finnell

15

Catatan: Saya bukan karyawan Microsoft. Pendapat itu sepenuhnya pribadi. Banyak pemikiran dari 5-7 tahun terakhir menggunakan kedua open source dalam campuran dengan vendor besar sebagai pengembang.

Monokultur baik: Aturan pribadi saya untuk ASP.NET adalah memberikan preferensi kepada Microsoft dan jangan memilih kode pihak ke-3 (open source atau tidak) kecuali tidak ada pilihan lain. Monokultur bermanfaat, karena Anda dibawa oleh vendor besar, dan jumlah pengguna yang mengulangi pengalaman yang sama setiap saat cukup besar untuk mendapatkan bantuan dan mencari solusinya.

Kota-kota hantu: Masalah dengan open source pada 2012 adalah bukan 2000 atau 2005 lagi. Jumlah proyek terus bertambah, ketika jumlah pengguna, adopsi, kontributor hampir sama dengan tahun lalu. Penonton terbentang tipis. Banyak proyek menarik menjadi basi, ditinggalkan. Tidak ada yang namanya anggaran proyek open source. Jadi, ketika bunga berakhir, tidak ada seorang pun yang dengan jujur ​​mengumumkan bahwa dukungan telah berakhir dan mematikan lampu. Proyek tidak pernah mati untuk meninggalkan fokus perhatian publik pada sesuatu yang lebih baik dan baru. Jadi open source akan selalu tumbuh dan terpecah-pecah. Tidak memiliki umpan balik dalam bentuk imbalan moneter atau kematian finansial, mereka adalah entitas abadi, yang ada demi kemuliaan abadi.

20 derajat pemisahan: Setiap adopsi perpustakaan baru Anda memisahkan Anda dari arus utama, menggeser Anda ke minoritas tepi. Setelah memiliki 20 langkah seperti memilih konfigurasi keamanan, menggunakan versi tertentu, kerangka kerja, plugin, dll. Solusi Anda menjadi kombinasi tunggal yang unik secara global. Googling hanya akan membantu membuktikan betapa jarang atau uniknya masalah ini. Itu selalu merupakan masalah melayani diri sendiri, murni teknis. Bahkan tidak pernah relevan dengan bisnis nyata.

Kualitas berasal dari fokus, uang tidak relevan: Tidak ada keunggulan perangkat lunak komersial vs open source. Seluruh komunitas devellopers hanyalah satu komunitas seperti biasanya. Vendor besar hanya memiliki keuntungan menua kode lebih lama, dalam kondisi yang lebih baik, dengan audiens yang lebih luas daripada kelompok open source.

Konsensus: Anda bertanya apakah ada konsensus. Mungkin tidak. Sayangnya sejumlah besar pengguna open source terlalu dipolitisasi. Lagipula open source adalah gerakan sosial. Open source kebal terhadap kritik, karena seringkali pendapat negatif akan dianggap sebagai anti-teknologi, serangan pribadi. Konsensus pribadi saya: tetap pada Microsoft.


3
+1: Saya tidak bisa mengatakan saya setuju sepenuhnya, tetapi terlalu baik untuk tidak .....
mattnz

14
"Tidak ada yang namanya anggaran proyek open source." tidak benar. Google memiliki anggaran untuk proyek-proyek sumber terbuka, dan Red Hat Inc. misalnya tidak dapat menjalankan bisnis mereka jika mereka tidak memasukkan cukup coder pada perangkat lunak mereka. Dan bagaimana dengan ini? microsoft.com/opensource/directory.aspx
ONOZ

14
Saya tidak setuju dengan satu kata pun yang Anda ucapkan.
Avio

11
Semua poin ini berlaku sama untuk proyek sumber tertutup. Menambahkan relung perpustakaan / kerangka sumber tertutup menambah keragaman. Teknologi berpemilik lama ditinggalkan jika tidak menghasilkan uang. Anda masih dapat mengkonfigurasi IIS untuk menjadi kupu-kupu unik itu sendiri. Komentar kualitas mengabaikan bahwa proyek open source bisa lebih besar dari (beberapa) vendor. Dan dunia bisnis sangat dipolitisasi, terutama dengan Microsoft.
Philip

3
Saya memiliki pengalaman sebaliknya. Kami mem-porting SQLite ke perangkat dan bisa mendapatkan dukungan langsung dari orang yang menulis sebagian besar. Tidak mungkin kami mendapatkan tingkat layanan dari perusahaan sumber tertutup. Beberapa proyek sumber terbuka benar-benar lebih kuat dan memiliki dukungan yang lebih baik daripada beberapa proyek sumber tertutup. Saya dapat menceritakan sebuah kisah tentang penggunaan kompiler Microsoft C ++ "standar industri" untuk OS / 2 dan bagaimana dukungannya ketika Microsoft memutuskan untuk memberikan jaminan pada OS / 2.
Gort the Robot

7

Saya telah mengerjakan sejumlah proyek yang berhasil untuk perusahaan besar yang menggunakan perangkat lunak open source dalam jumlah besar. Secara khusus, saya telah menggunakan Curl, SQLite, dan Webkit untuk perusahaan yang sangat besar dalam proyek-proyek sukses yang dikirimkan kepada pengguna akhir. Seperti yang orang lain katakan, itu hanya masalah berhati-hati tentang lisensi dan idealnya meminta pengacara untuk memeriksa.

Ada ratusan lisensi open source, tetapi umumnya terbagi dalam dua kategori, gaya BSD dan gaya GPL. Lisensi gaya BSD tidak mengharuskan Anda untuk membuka sumber kode Anda sendiri, dan umumnya hanya memiliki semacam klausa atribusi. Lisensi gaya GPL memang mengharuskan Anda untuk membuka sumber kode Anda sendiri. Sebagian besar perusahaan (termasuk perusahaan saya) umumnya terlihat curiga sehingga Anda ingin menghindari gaya GPL. Dapper tampaknya menggunakan lisensi Apache, yang merupakan gaya BSD. Selalu mencari tahu apa persyaratan lisensi umum sebelum Anda mulai coding.

Ada juga LGPL, yang merupakan kasus perbatasan yang menarik karena Anda dapat menggunakannya tanpa membuka kode Anda sendiri jika Anda membatasi akses ke batas biner. (Yaitu mengakses perpustakaan hanya sebagai perpustakaan dinamis.) Penggunaan perpustakaan LGPL sangat bisa dilakukan, Anda hanya harus lebih berhati-hati.

Dalam pengalaman saya, kode sumber terbuka tidak lebih cenderung berubah menjadi buggy atau gagal daripada solusi berbayar, atau, dalam hal ini, roll solusi Anda sendiri. Jika Anda melihat beberapa alat open source yang lebih menonjol, kualitasnya sangat tinggi.

Anda mungkin ingin menghindari proyek yang kecil, atau tidak selesai. Mungkin tergoda untuk mengambil sesuatu yang tampaknya memenuhi kebutuhan Anda, tetapi jika mereka adalah sesuatu yang disatukan oleh beberapa orang, tidak pernah selesai dan tidak didukung, mungkin itu tidak sepadan dengan usaha. (Kecuali jika Anda bersedia mengerjakan kode secara langsung.)


7

Pernahkah Anda mengalami kegagalan komponen proprietary sebelumnya? Saya telah menemukan banyak bug dalam perangkat lunak dari perusahaan besar dan kecil. Masalah ini bukan masalah dengan open source per se, melainkan lebih tentang kematangan proyek.

Sepertinya Anda ingin menggunakan proyek dewasa yang menawarkan dukungan. Beberapa proyek sumber terbuka menawarkan dukungan berbayar, atau memiliki komunitas yang cukup besar sehingga Anda bisa mendapatkan jawaban di forum publik. Mungkin Anda harus membuat prioritas kriteria kedewasaan dan dukungan ketika memilih perpustakaan, apakah itu perpustakaan tertutup atau sumber terbuka.

Anda perlu mengakui bahwa Anda mengambil risiko lebih besar jika Anda memutuskan untuk menggunakan proyek yang belum matang, atau yang dengan dukungan terbatas. Karena itu, Anda perlu menentukan apa rencana mitigasi risiko Anda. Anda mungkin melakukan lebih banyak pengujian pada perangkat lunak pihak ketiga, misalnya.


6

Diasumsikan masalah lisensi tidak ada masalah di sini: melihat Dapper dengan cepat, saya perhatikan itu hanya 2255 baris yang terdokumentasi dengan baik, kode yang dapat dibaca . Itu adalah

  • cukup besar sehingga Anda dapat berinvestasi beberapa hari atau minggu untuk menghasilkan kode dengan kualitas yang sebanding dengan melakukan hal yang sama
  • cukup kecil sehingga Anda dapat memahami apa yang dilakukannya dan memperbaiki bug apa pun dalam kode tersebut jika muncul dalam produksi

Jika Anda akan menulis sesuatu seperti itu sendiri dan "menemukan kembali roda", Anda memiliki risiko yang jauh lebih tinggi bahwa kode Anda sendiri akan menampilkan bug dalam produksi, dan Anda akan benar-benar "kesulitan untuk memperbaikinya".

Apa yang harus Anda lakukan di sini, jika Anda memperkenalkan bagian open source ke dalam proyek Anda, maka Anda harus mengambil tanggung jawab penuh untuk kode itu, sama seperti jika Anda telah menulisnya sendiri. Pastikan kode berada dalam kondisi Anda dapat mempertahankannya, jika perlu. Jangan salahkan "penulis" kode itu jika sesuatu tidak berfungsi seperti yang diharapkan.

Dalam salah satu proyek kami, kami juga memperkenalkan beberapa komponen open source, mulai dari yang berukuran kecil seperti Dapper hingga perpustakaan yang memiliki sekitar 20K hingga 30K baris kode. Kami harus selalu melakukan beberapa perubahan, memperbaiki beberapa bug, mengurangi sesuatu, dll., Tapi itu tidak masalah, karena kami mengharapkannya. Bahkan waktu untuk debugging termasuk, menggunakan open source menyelamatkan kita banyak pekerjaan.

Satu hal untuk dipikirkan di sini: dalam kasus Anda, Anda menyebutkan bahwa ada alternatif yang diterima secara luas dari vendor besar yang tersedia (MS Entity Framework, di mana Anda tidak perlu membayar biaya lisensi tambahan!). Anda tidak ingin menggunakannya karena pertimbangan kinerja. Saya sungguh-sungguh merekomendasikan untuk tidak membiarkan kinerja menjadi satu-satunya atau poin utama yang harus dipertimbangkan. Pertanyaan yang harus Anda tanyakan di sini: apakah Dapper memiliki semua fungsi yang Anda butuhkan sekarang dan untuk masa hidup yang diharapkan dari perangkat lunak Anda? Atau bisakah Anda meramalkan bahwa Anda akan mencapai batas Dapper dengan cepat, dan Anda harus menambahkan banyak fungsi yang hilang di sekitarnya, apa yang mungkin Anda tidak perlu jika Anda memutuskan untuk menggunakan EF di tempat pertama? Jika yang terakhir terjadi, saya akan merekomendasikan untuk tidak menggunakan Dapper. Juga tanyakan pada diri sendiri: apakah EF benar-benar tidak cukup cepat untuk aplikasi Anda,


1
+1 untuk masalah lisensi. Periksa dengan cermat bahwa menggunakan beberapa komponen open-source tidak akan memaksa Anda untuk open-source kode Anda sendiri juga. Saya tidak percaya ini akan menjadi kasus untuk sebagian besar open-source, dan jika Anda hanya menggunakannya untuk menghasilkan atau meng-host kode Anda akan ada lebih banyak tersedia, tetapi tetap perlu diperiksa.
Lunivore

Bahkan jika kinerjanya kurang diperhatikan, EF memberi saya lebih sedikit kontrol. Memperkenalkan caching sedikit lebih sulit jika perlu di ujung jalan; Dapper akan lebih mudah masuk ke dalam solusi yang lebih khusus, di samping mendorong perlunya caching lebih jauh di jalan di tempat pertama.
Tuan Jefferson

Di sisi lain, menginginkan solusi khusus dibandingkan EF terdengar agak seperti NIHS. Skema data saya cukup kompleks dengan banyak hubungan (kunci asing), dan sampai ke titik di mana solusi khusus saya mengelola hubungan tersebut serta EF akan keluar dari kotak tentu akan memakan waktu.
Tuan Jefferson

@ Mr.Jefferson: serius, saya tidak bisa memberi Anda nasihat yang baik apa solusi yang lebih baik dalam kasus Anda, itu adalah sesuatu yang harus Anda selesaikan sendiri. Saya hanya mencoba memberi Anda beberapa petunjuk apa yang harus dipertimbangkan.
Doc Brown

+1. Anda mengemukakan beberapa poin yang sangat bagus dengan pos ini. @ Mr.Jefferson: Saya telah menggunakan Entity Framework untuk beberapa waktu sekarang, dan telah cukup berhasil dalam mengelola kinerja melalui ad-hoc caching pada repositori tertentu setelah menemukan di mana letak hambatannya. Selain itu, produk kami cukup kompleks, tetapi saya masih belum harus menulis satu query SQL. Saya merasa EF telah memberi saya banyak kendali.
StriplingWarrior

2

Seperti yang saya lihat, ini adalah tindakan penyeimbang.

Jika Anda membuat diri Anda bergantung pada vendor, hampir pasti dukungan itu akan hilang sebelum lama

  • Karena mereka memiliki programmer untuk membayar, sehingga mereka harus terus membuat versi baru dan memastikan yang lama tidak mungkin didapat dan tidak lagi berfungsi (pada platform yang lebih baru) sehingga yang baru akan memiliki pasar.

  • Jika mereka tidak dapat menjual cukup untuk membenarkan model bisnis, mereka meneruskannya dari perusahaan A ke perusahaan B ke C, yang masing-masing cukup mengubahnya lagi, Anda tidak dapat menggunakan yang baru tanpa pemrograman ulang, dan Anda bisa ' tidak mendapatkan yang lama yang berfungsi.

  • Mereka hanya memutuskan bahwa mereka tidak akan lagi mendukungnya karena terlalu banyak masalah dan tidak ada uang di dalamnya. Semua uang ada di aplikasi baru.

Jadi, jika Anda ingin membangun sesuatu yang tidak harus terus ditulis ulang setiap beberapa tahun, open source dapat menjadi teman Anda.


1

Saya pikir itu bijaksana jika uji tuntas yang cukup dilakukan dan tampaknya Anda sudah melakukan beberapa pekerjaan rumah sehubungan dengan sejarah dan aktivitas proyek tertentu. Kemampuan untuk memperluas / menambah fitur dalam kode sumber juga merupakan pro besar. Dengan pengujian yang memadai Anda dapat meminimalkan risiko di sisi lain. Sulit untuk sepenuhnya memahami semua dependensi dalam kode Anda, tetapi setidaknya dalam hal ini Anda akan dapat sepenuhnya debug dan melihat kode jika perlu.

Tanyakan kepada manajemen mengapa itu gagal sebelumnya, apakah uji tuntas yang memadai telah dilakukan?


Saya tidak tahu banyak tentang apa yang terjadi. Itu sebelum saya tiba di sini.
Tuan Jefferson

0

jquery memiliki opsi untuk menggunakan lisensi MIT, sehingga banyak situs web komersial dan pemerintah juga menggunakan jquery. Situs web Microsoft juga menggunakan jquery! Jadi yang menjadi perhatian adalah perizinan. Hindari menggunakan GPL / LGPL sudah cukup.

"Berapa lama untuk memperbaiki kerusakan yang dilaporkan?" Setelah melaporkan bug, bug dapat diperbaiki dalam beberapa menit, jam, atau hari. Untuk situasi yang mendesak, staf mungkin hanya "menarik git" untuk mendapatkan sumber dan mengkompilasi sendiri. Dia hanya melaporkan versi seperti "v1.2.3-101-gd62fdae" kepada manajemen, yang dapat dilacak.


0

Open source benar-benar tentang legalitas, bukan kualitas kode. Ada produk open source yang baik dan buruk, sama seperti ada yang baik dan buruk. Saya percaya dilema Anda adalah apakah akan menggunakan proyek yang dikembangkan oleh komunitas sukarelawan.


-1

Apakah Anda yakin bahwa masalah manajemen adalah masalah teknis.

Saya mengatakan ini sebagai pencampuran OS dan kegiatan komersial adalah bidang penambangan yang legal, dan lebih dari satu manajer memiliki "Tolong Jelaskan" dari tim hukum / CEO atau lebih buruk, dari organisasi lain. Sebagian besar manajer yang saya kenal, bahkan mereka yang secara aktif merangkul perangkat lunak OS, (benar) sangat berhati-hati untuk sepenuhnya memahami situasi hukum yang mereka hadapi asal mula. Jika Anda mengadopsi perangkat lunak OS dan membuat perubahan, Anda berkewajiban mengembalikan perubahan itu kepada komunitas. Dalam beberapa kasus, kewajiban ini legal, dalam moral lainnya. Dalam beberapa lisensi OS, semua yang Anda lakukan menjadi OS hanya dengan menautkannya.

Dari sudut pandang teknis, itu benar-benar hanya keputusan antara produk yang bersaing - Ajukan beberapa pertanyaan dasar - Bisakah Anda mendapatkan dukungan yang Anda butuhkan untuk paket yang Anda pilih?, Berapa lama untuk mendapatkan perbaikan untuk cacat yang dilaporkan, berapa biayanya per pengembang, per tahun atau satu mati dll. OS memiliki banyak 0 di kolom $, tetapi sering memiliki yang kosong di yang lain - hanya Anda dan bos Anda yang dapat memutuskan apakah berat 0 kosong atau kosong.

Dan satu hal lagi yang perlu diingat - "Tidak ada yang dipecat membeli IBM". (yaitu manajemen berbicara untuk "Jika Anda menghabiskan banyak uang itu harus menjadi produk yang lebih baik daripada yang gratis"


5
Ironisnya, IBM mungkin adalah penjual perangkat lunak berbasis Open Source terbesar di dunia. Apache http server, Eclipse dll.
James Anderson

7
Menjual OSS tidak ilegal. Kenapa bisa begitu?
Pelaku

1
IBMS httpServer adalah apache murni, hanya dilengkapi dengan perjanjian dukungan.
James Anderson

2
Banyak hal berubah. Sekarang manajemen mulai berpikir bahwa jika Anda membuat perusahaan membayar komponen yang dimiliki perusahaan lain secara gratis, Anda bodoh.
Avio

2
"Kolom lain" jarang kosong untuk sumber terbuka. Anda selalu dapat memperoleh dukungan dari konsultan atau vendor distribusi atau seseorang dan Anda juga dapat mendukung diri sendiri. Lebih banyak kolom seringkali kosong untuk perangkat lunak komersial, karena Anda tidak tahu kualitas dukungan mereka sebelumnya dan jarang membantu seperti yang Anda perlukan.
Jan Hudec
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.