ຜູ້ພັດທະນາບາງຄົນກໍາລັງເຮັດຜິດຕໍ່ຊອບແວໂອເພນຊອດ

gettyimages-1159346361-malicious-code-skull-crossbones.jpg

Getty Images

ຫນຶ່ງໃນສິ່ງທີ່ເຮັດໃຫ້ປະລາດທີ່ສຸດກ່ຽວກັບ open-source ບໍ່ແມ່ນວ່າມັນຜະລິດຊອບແວທີ່ຍິ່ງໃຫຍ່. ມັນແມ່ນວ່ານັກພັດທະນາຈໍານວນຫຼາຍເຮັດໃຫ້ egos ຂອງເຂົາເຈົ້າຫລີກໄປທາງຫນຶ່ງເພື່ອສ້າງໂຄງການທີ່ຍິ່ງໃຫຍ່ໂດຍການຊ່ວຍເຫຼືອຂອງຄົນອື່ນ. ຢ່າງໃດກໍຕາມ, ໃນປັດຈຸບັນ, ມືຂອງນັກຂຽນໂປລແກລມກໍາລັງວາງຄວາມກັງວົນຂອງຕົນເອງກ່ອນຫນ້າທີ່ດີຂອງຊອບແວ open-source ຈໍານວນຫຼາຍແລະອາດຈະທໍາລາຍສໍາລັບທຸກຄົນ.

ຕົວຢ່າງ, ຜູ້ຮັກສາຊຸດຜູ້ຈັດການ JavaScript ຂອງ RIAEvangelist, Brandon Nozaki Miller, ຂຽນແລະຕີພິມຊຸດລະຫັດແຫຼ່ງເປີດ npm ທີ່ເອີ້ນວ່າ peacenotwar. ມັນໄດ້ພຽງເລັກນ້ອຍແຕ່ພິມຂໍ້ຄວາມເພື່ອສັນຕິພາບກັບ desktops. ມາຮອດປະຈຸ, ບໍ່ເປັນອັນຕະລາຍ. 

ຫຼັງຈາກນັ້ນ Miller ໄດ້ໃສ່ລະຫັດອັນຕະລາຍເຂົ້າໄປໃນຊຸດເພື່ອຂຽນທັບລະບົບໄຟລ໌ຂອງຜູ້ໃຊ້ຖ້າຄອມພິວເຕີຂອງພວກເຂົາມີທີ່ຢູ່ IP ຂອງລັດເຊຍຫຼືເບລາຣູດ. ຫຼັງຈາກນັ້ນລາວໄດ້ເພີ່ມມັນເປັນການເພິ່ງພາອາໄສຄວາມນິຍົມຂອງລາວ node-ipc ໂຄງ​ການ​ແລະ​ຄວາມ​ວຸ່ນ​ວາຍ​ທັນ​ທີ​! ເຄື່ອງແມ່ຂ່າຍແລະ PC ຈໍານວນຫລາຍໄດ້ຫຼຸດລົງຍ້ອນວ່າພວກເຂົາປັບປຸງລະຫັດໃຫມ່ທີ່ສຸດແລະຫຼັງຈາກນັ້ນລະບົບຂອງພວກເຂົາໄດ້ຖືກລຶບລ້າງອອກ. 

ການປ້ອງກັນຂອງ Miller, "ນີ້ແມ່ນທັງໝົດສາທາລະນະ, ເປັນເອກະສານ, ມີໃບອະນຸຍາດ ແລະແຫຼ່ງເປີດ,” ບໍ່ໄດ້ຖືຂຶ້ນ. 

Liran Tal, ໄດ້ Snyk ນັກຄົ້ນຄວ້າຜູ້ທີ່ເປີດເຜີຍບັນຫາກ່າວວ່າ, "ເຖິງແມ່ນວ່າການກະທໍາທີ່ເຈດຕະນາແລະເປັນອັນຕະລາຍ [ຖືກ] ຮັບຮູ້ໂດຍບາງຄົນວ່າເປັນການກະທໍາທີ່ຖືກຕ້ອງຂອງການປະທ້ວງ, ມັນສະທ້ອນເຖິງຊື່ສຽງໃນອະນາຄົດຂອງຜູ້ຮັກສາແນວໃດ ແລະຫຸ້ນສ່ວນໃນຊຸມຊົນນັກພັດທະນາ? ຜູ້ຮັກສານີ້ຈະໄດ້ຮັບຄວາມໄວ້ວາງໃຈອີກເທື່ອຫນຶ່ງທີ່ຈະບໍ່ຕິດຕາມການກະທໍາໃນອະນາຄົດໃນການກະທໍາດັ່ງກ່າວຫຼືຮ້າຍແຮງກວ່າເກົ່າສໍາລັບໂຄງການທີ່ພວກເຂົາເຂົ້າຮ່ວມບໍ?” 

Miller ບໍ່ແມ່ນ crank Random. ລາວຜະລິດລະຫັດທີ່ດີຫຼາຍ, ເຊັ່ນ node-ipc, ແລະ Node HTTP Server. ແຕ່, ທ່ານສາມາດໄວ້ວາງໃຈລະຫັດໃດໆຂອງລາວທີ່ຈະບໍ່ເປັນອັນຕະລາຍບໍ? ໃນຂະນະທີ່ລາວອະທິບາຍວ່າ "ບໍ່ແມ່ນ malware, [ແຕ່] ໂປແກມປະທ້ວງທີ່ຖືກບັນທຶກໄວ້ຢ່າງຄົບຖ້ວນ,” ຄົນອື່ນບໍ່ເຫັນດີນໍາ venomously. 

ດັ່ງທີ່ນັກຂຽນໂປລແກລມ GitHub ຂຽນວ່າ, "ສິ່ງທີ່ຈະເກີດຂື້ນກັບນີ້ແມ່ນວ່າທີມງານຮັກສາຄວາມປອດໄພໃນບໍລິສັດຕາເວັນຕົກທີ່ບໍ່ມີຫຍັງກ່ຽວຂ້ອງກັບລັດເຊຍຫຼືການເມືອງແມ່ນຈະເລີ່ມເຫັນ. ຊອບແວຟຣີ ແລະແຫຼ່ງເປີດເປັນຊ່ອງທາງສໍາລັບການໂຈມຕີລະບົບຕ່ອງໂສ້ການສະຫນອງ (ເຊິ່ງນີ້ແມ່ນທັງຫມົດ) ແລະພຽງແຕ່ເລີ່ມຕົ້ນຫ້າມຊອບແວຟຣີແລະ open-source - ທັງຫມົດຊອບແວຟຣີແລະ open-source - ພາຍໃນບໍລິສັດຂອງພວກເຂົາ." 

ດັ່ງທີ່ນັກພັດທະນາ GitHub ອື່ນທີ່ມີ handle nm17 ຂຽນວ່າ, "The ປັດໄຈຄວາມໄວ້ວາງໃຈຂອງແຫຼ່ງເປີດ, ເຊິ່ງອີງໃສ່ຄວາມຕັ້ງໃຈຂອງນັກພັດທະນາໃນປັດຈຸບັນແມ່ນຫມົດໄປ, ແລະໃນປັດຈຸບັນ, ຫຼາຍຄົນຮູ້ວ່າມື້ຫນຶ່ງ, ຫ້ອງສະຫມຸດ / ຄໍາຮ້ອງສະຫມັກຂອງພວກເຂົາອາດຈະຖືກຂູດຮີດເພື່ອເຮັດ / ເວົ້າໃດກໍ່ຕາມ dev random ໃນອິນເຕີເນັດຄິດວ່າ ' ເປັນສິ່ງທີ່ຖືກຕ້ອງທີ່ເຂົາເຈົ້າເຮັດ.'”

ທັງສອງເຮັດໃຫ້ຈຸດທີ່ຖືກຕ້ອງ. ເມື່ອທ່ານບໍ່ສາມາດໃຊ້ລະຫັດແຫຼ່ງເວັ້ນເສຍແຕ່ວ່າທ່ານເຫັນດີກັບຈຸດຢືນທາງດ້ານການເມືອງຂອງຜູ້ຜະລິດ, ທ່ານສາມາດນໍາໃຊ້ມັນດ້ວຍຄວາມຫມັ້ນໃຈໄດ້ແນວໃດ? 

ຫົວໃຈຂອງ Miller ອາດຈະຢູ່ໃນສະຖານທີ່ທີ່ຖືກຕ້ອງ — Slava Ukraini! — ແຕ່ຊອບແວ open-source ຕິດເຊື້ອ payload ທີ່ເປັນອັນຕະລາຍແມ່ນວິທີທີ່ຖືກຕ້ອງເພື່ອປົກປ້ອງການບຸກລຸກຂອງຣັດເຊຍໃນຢູເຄລນບໍ? ບໍ່​ມັນ​ບໍ່​ແມ່ນ. 

ວິທີການເປີດແຫຼ່ງພຽງແຕ່ເຮັດວຽກຍ້ອນວ່າພວກເຮົາໄວ້ວາງໃຈເຊິ່ງກັນແລະກັນ. ເມື່ອຄວາມໄວ້ວາງໃຈນັ້ນຖືກທໍາລາຍ, ບໍ່ວ່າດ້ວຍສາເຫດອັນໃດ, ກອບພື້ນຖານຂອງ open-source ຈະແຕກ. ໃນຖານະເປັນ Greg Kroah-Hartman, ຜູ້ຮັກສາ Linux kernel ສໍາລັບສາຂາທີ່ຫມັ້ນຄົງ, ກ່າວວ່າໃນເວລາທີ່ນັກສຶກສາຈາກມະຫາວິທະຍາໄລ Minnesota ໄດ້ພະຍາຍາມໃສ່ລະຫັດທີ່ບໍ່ດີຢູ່ໃນ Linux kernel ສໍາລັບການທົດລອງໃນປີ 2021 ກ່າວວ່າ, "ສິ່ງທີ່ພວກເຂົາເຮັດແມ່ນພຶດຕິກໍາທີ່ເປັນອັນຕະລາຍໂດຍເຈດຕະນາແລະ. ​ແມ່ນ​ບໍ່​ເປັນ​ທີ່​ຍອມ​ຮັບ​ໄດ້ ​ແລະ​ບໍ່​ມີ​ສິນ​ທຳ​ທັງ​ໝົດ.”

ປະຊາຊົນໄດ້ໂຕ້ຖຽງກັນມາດົນນານວ່າ open-source ຄວນປະກອບມີບົດບັນຍັດດ້ານຈັນຍາບັນເຊັ່ນກັນ. ຕົວຢ່າງ, ປີ 2009 ຂໍ້ຍົກເວັ້ນໃບອະນຸຍາດສາທາລະນະທົ່ວໄປ (eGPL), ສະບັບປັບປຸງຂອງ GPLv2, ພະຍາຍາມຫ້າມ "ຂໍ້ຍົກເວັ້ນ," ເຊັ່ນຜູ້ໃຊ້ທະຫານແລະຜູ້ສະຫນອງ, ບໍ່ໃຫ້ໃຊ້ລະຫັດຂອງມັນ. ມັນລົ້ມເຫລວ. ໃບອະນຸຍາດອື່ນໆເຊັ່ນ: ໃບອະນຸຍາດ JSON ດ້ວຍຄວາມຊື່ສັດທີ່ຫວານຊື່ນ "ຊອບແວຈະຖືກນໍາໃຊ້ເພື່ອຄວາມດີ, ບໍ່ແມ່ນຄວາມຊົ່ວ" ປະໂຫຍກທີ່ຍັງຄົງຢູ່, ແຕ່ບໍ່ມີໃຜບັງຄັບມັນ.  

ຫວ່າງມໍ່ໆມານີ້, ນັກເຄື່ອນໄຫວ ແລະຜູ້ພັດທະນາຊອບແວ Coraline Ada Ehmke ໄດ້ນຳສະເໜີໃບອະນຸຍາດແຫຼ່ງເປີດທີ່ຮຽກຮ້ອງໃຫ້ຜູ້ໃຊ້ປະຕິບັດສິນທຳ. ໂດຍສະເພາະ, ນາງ ໃບອະນຸຍາດ Hippocratic ເພີ່ມເຂົ້າ ໃບອະນຸຍາດແຫຼ່ງເປີດ MIT ຂໍ້ໜຶ່ງລະບຸວ່າ: 

"ຊອບແວອາດຈະບໍ່ຖືກໃຊ້ໂດຍບຸກຄົນ, ບໍລິສັດ, ລັດຖະບານ, ຫຼືກຸ່ມອື່ນໆສໍາລັບລະບົບຫຼືກິດຈະກໍາທີ່ຫ້າວຫັນແລະໂດຍເຈດຕະນາເປັນອັນຕະລາຍ, ເປັນອັນຕະລາຍ, ຫຼືຖ້າບໍ່ດັ່ງນັ້ນໄພຂົ່ມຂູ່ຕໍ່ຮ່າງກາຍ, ຈິດໃຈ, ເສດຖະກິດ, ຫຼືສະຫວັດດີການທົ່ວໄປຂອງບຸກຄົນຫຼືກຸ່ມຜູ້ດ້ອຍໂອກາດໃນ. ການລະເມີດຖະແຫຼງການສາກົນກ່ຽວກັບສິດທິມະນຸດຂອງສະຫະປະຊາຊາດ.”

ສຽງດີ, ແຕ່ມັນບໍ່ແມ່ນແຫຼ່ງເປີດ. ທ່ານເຫັນ, open-source ແມ່ນຢູ່ໃນແລະຂອງຕົນເອງເປັນຕໍາແຫນ່ງດ້ານຈັນຍາບັນ. ຈັນຍາບັນຂອງມັນແມ່ນບັນຈຸຢູ່ໃນ Free Software Foundation's (FSF)'s ສີ່ເສລີພາບທີ່ຈໍາເປັນ. ນີ້ແມ່ນພື້ນຖານສໍາລັບໃບອະນຸຍາດເປີດແຫຼ່ງທັງຫມົດແລະປັດຊະຍາຫຼັກຂອງພວກເຂົາ. ໃນຖານະທີ່ເປັນຜູ້ຊ່ຽວຊານດ້ານກົດໝາຍແຫຼ່ງເປີດ ແລະ ອາຈານສອນກົດໝາຍ Columbia, Eben Moglen, ກ່າວໃນເວລານັ້ນວ່າ ໃບອະນຸຍາດດ້ານຈັນຍາບັນບໍ່ສາມາດເປັນຊອບແວຟຣີ ຫຼື ໃບອະນຸຍາດແຫຼ່ງເປີດ: 

"ເສລີພາບສູນ, ສິດທິໃນການດໍາເນີນໂຄງການສໍາລັບຈຸດປະສົງໃດກໍ່ຕາມ, ມາກ່ອນໃນສີ່ເສລີພາບເພາະວ່າຖ້າຜູ້ໃຊ້ບໍ່ມີສິດນັ້ນກ່ຽວກັບໂຄງການຄອມພິວເຕີທີ່ເຂົາເຈົ້າດໍາເນີນການ, ໃນທີ່ສຸດເຂົາເຈົ້າບໍ່ມີສິດທິໃດໆໃນໂຄງການເຫຼົ່ານັ້ນທັງຫມົດ. ຄວາມພະຍາຍາມໃຫ້ການອະນຸຍາດພຽງແຕ່ສໍາລັບການນໍາໃຊ້ທີ່ດີ, ຫຼືຫ້າມສິ່ງບໍ່ດີໃນສາຍຕາຂອງຜູ້ອອກໃບອະນຸຍາດ, ລະເມີດຂໍ້ກໍານົດເພື່ອປົກປ້ອງສິດເສລີພາບສູນ." 

ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ຖ້າທ່ານບໍ່ສາມາດແບ່ງປັນລະຫັດຂອງທ່ານດ້ວຍເຫດຜົນໃດກໍ່ຕາມ, ລະຫັດຂອງທ່ານບໍ່ແມ່ນແຫຼ່ງເປີດຢ່າງແທ້ຈິງ. 

ອີກປະການຫນຶ່ງການໂຕ້ຖຽງ pragmatic ຫຼາຍກ່ຽວກັບການຫ້າມກຸ່ມຫນຶ່ງຈາກການນໍາໃຊ້ຊອບແວ open-source ແມ່ນການສະກັດບາງສິ່ງບາງຢ່າງເຊັ່ນ: ທີ່ຢູ່ IP ເປັນແປງຢ່າງກວ້າງຂວາງຫຼາຍ. ໃນຖານະເປັນ Florian Roth, ບໍລິສັດຄວາມປອດໄພ ລະບົບ Nextronຫົວຫນ້າການຄົ້ນຄວ້າ, ຜູ້ທີ່ພິຈາລະນາ "ປິດການໃຊ້ງານເຄື່ອງມືຟຣີຂອງຂ້ອຍຢູ່ໃນລະບົບ ດ້ວຍການຕັ້ງຄ່າພາສາ ແລະເຂດເວລາທີ່ແນ່ນອນ,” ສຸດທ້າຍໄດ້ຕັດສິນໃຈທີ່ຈະບໍ່. ເປັນຫຍັງ? ເພາະ​ວ່າ​ໂດຍ​ການ​ເຮັດ​ແນວ​ນັ້ນ, "ພວກເຮົາຍັງຈະປິດການນຳໃຊ້ເຄື່ອງມືໃນລະບົບນັກວິຈານ ແລະນັກຄິດອິດສະລະ ທີ່ກ່າວປະນາມການກະ ທຳ ຂອງລັດຖະບານຂອງພວກເຂົາ.” 

ແຕ່ຫນ້າເສຍດາຍ, ມັນບໍ່ແມ່ນພຽງແຕ່ຄົນທີ່ພະຍາຍາມໃຊ້ open-source ສໍາລັບສິ່ງທີ່ພວກເຂົາເຫັນວ່າເປັນຈຸດປະສົງດ້ານຈັນຍາບັນທີ່ສູງກວ່າທີ່ເຮັດໃຫ້ເກີດບັນຫາສໍາລັບຊອບແວ open-source. 

ໃນຕົ້ນປີນີ້, ຜູ້ພັດທະນາ JavaScript Marak Squires ໄດ້ເຈດຕະນາທໍາຮ້າຍຄວາມບໍ່ເຫັນແຈ້ງຂອງລາວ, ແຕ່ຫ້ອງສະຫມຸດ Javascript open-source ທີ່ສໍາຄັນ 'colors.js' ແລະ 'faker.js." ຜົນ? ຫລາຍສິບພັນໂຄງການ JavaScript ໄດ້ລະເບີດຂຶ້ນ.

ເປັນຫຍັງ? ມັນຍັງບໍ່ຊັດເຈນທັງຫມົດ, ແຕ່ໃນຂໍ້ຄວາມ GitHub ທີ່ຖືກລຶບນັບຕັ້ງແຕ່, Squires ຂຽນວ່າ, "ດ້ວຍຄວາມນັບຖື, ຂ້ອຍຈະບໍ່ສະໜັບສະໜູນ Fortune 500s ອີກຕໍ່ໄປ (ແລະບໍລິສັດຂະຫນາດນ້ອຍກວ່າອື່ນໆ) ດ້ວຍວຽກທີ່ບໍ່ເສຍຄ່າຂອງຂ້ອຍ. ບໍ່ມີຫຍັງອີກຫຼາຍທີ່ຈະເວົ້າ. ເອົານີ້ເປັນໂອກາດທີ່ຈະສົ່ງສັນຍາຫົກຕົວເລກຕໍ່ປີໃຫ້ຂ້ອຍຫຼືຕັດໂຄງການແລະໃຫ້ຄົນອື່ນເຮັດວຽກກັບມັນ.” ດັ່ງທີ່ເຈົ້າອາດຈະຈິນຕະນາການ, ຄວາມພະຍາຍາມທີ່ຈະ blackmail ວິທີການຂອງລາວໄປຫາເງິນເດືອນບໍ່ໄດ້ຜົນດີສໍາລັບລາວ. 

ແລະ, ຫຼັງຈາກນັ້ນ, ມີຜູ້ທີ່ຕັ້ງໃຈໃສ່ malware ເຂົ້າໄປໃນລະຫັດແຫຼ່ງເປີດຂອງພວກເຂົາເພື່ອຄວາມມ່ວນແລະກໍາໄລ. ຕົວຢ່າງ, ບໍລິສັດຄວາມປອດໄພ DevOps JFrog ຄົ້ນພົບແພັກເກັດທີ່ເປັນອັນຕະລາຍ JavaScript ໃໝ່ 17 ຊຸດຢູ່ໃນບ່ອນເກັບຂໍ້ມູນ NPM ທີ່ຕັ້ງໃຈໂຈມຕີ ແລະລັກເອົາເຄື່ອງໝາຍ Discord ຂອງຜູ້ໃຊ້. ເຫຼົ່ານີ້ສາມາດຖືກນໍາໃຊ້ໃນ ການ​ສື່​ສານ​ຂັດ​ແຍ່ງ​ແລະ​ເວ​ທີ​ການ​ແຜ່​ກະ​ຈາຍ​ດິ​ຈິ​ຕອນ​.

ນອກຈາກການສ້າງໂປຼແກຼມ open-source ໃໝ່ທີ່ເປັນອັນຕະລາຍທີ່ເບິ່ງຄືຊິບໍ່ມີ ແລະມີປະໂຫຍດແລ້ວ, ຜູ້ໂຈມຕີອື່ນໆຍັງເອົາຊອຟແວເກົ່າ, ທີ່ຖືກປະຖິ້ມໄວ້ ແລະຂຽນຄືນໃຫມ່ເພື່ອລວມເອົາການລັກລອບເງິນ crypto backdoors. ຫນຶ່ງໃນໂຄງການດັ່ງກ່າວແມ່ນເຫດການ-stream. ມັນມີລະຫັດທີ່ເປັນອັນຕະລາຍຖືກໃສ່ເຂົ້າໄປໃນມັນເພື່ອລັກກະເປົາເງິນ bitcoin ແລະໂອນຍອດເງິນຂອງພວກເຂົາໄປຫາເຄື່ອງແມ່ຂ່າຍຂອງ Kuala Lumpur. ມີຕອນທີ່ຄ້າຍຄືກັນຫຼາຍຄັ້ງໃນຊຸມປີທີ່ຜ່ານມາ.

ດ້ວຍ​ການ​ເຄື່ອນ​ໄຫວ​ດັ່ງ​ກ່າວ​ແຕ່​ລະ​ຄົນ, ຄວາມ​ເຊື່ອ​ໃນ​ຊອບ​ແວ​ໂອ​ເພນ​ຊອດ​ຖືກ​ຍຸບ​ລົງ. ເນື່ອງຈາກແຫຼ່ງເປີດແມ່ນມີຄວາມສໍາຄັນຢ່າງແທ້ຈິງຕໍ່ໂລກທີ່ທັນສະໄຫມ, ນີ້ແມ່ນແນວໂນ້ມທີ່ບໍ່ດີ. 

ພວກເຮົາສາມາດເຮັດແນວໃດກ່ຽວກັບມັນ? ດີ, ສໍາລັບສິ່ງຫນຶ່ງ, ພວກເຮົາຄວນຈະພິຈາລະນາຢ່າງລະມັດລະວັງຢ່າງແທ້ຈິງໃນເວລາທີ່, ຖ້າເຄີຍ, ພວກເຮົາຄວນຈະສະກັດກັ້ນການໃຊ້ລະຫັດແຫຼ່ງເປີດ. 

ຫຼາຍພາກປະຕິບັດ, ພວກເຮົາຕ້ອງເລີ່ມຕົ້ນການຮັບຮອງເອົາການນໍາໃຊ້ຂອງ ມູນນິທິ Linux Software Package Data Exchange (SPDX) ແລະ ບັນຊີລາຍການຊອບແວ (SBOM). ຮ່ວມກັນເຫຼົ່ານີ້ຈະບອກພວກເຮົາຢ່າງແນ່ນອນວ່າພວກເຮົາກໍາລັງໃຊ້ລະຫັດໃດໃນໂປຼແກຼມຂອງພວກເຮົາແລະມັນມາຈາກໃສ. ຈາກນັ້ນ, ພວກເຮົາຈະສາມາດຕັດສິນໃຈຢ່າງມີຂໍ້ມູນໄດ້ຫຼາຍຂຶ້ນ.

ໃນມື້ນີ້, ທຸກຄົນມັກຈະໃຊ້ລະຫັດ open-source ໂດຍບໍ່ຮູ້ວ່າພວກເຂົາກໍາລັງແລ່ນຫຼືກວດເບິ່ງມັນສໍາລັບບັນຫາ. ພວກເຂົາເຈົ້າສົມມຸດວ່າທັງຫມົດໄດ້ດີກັບມັນ. ນັ້ນບໍ່ເຄີຍເປັນສົມມຸດຕິຖານທີ່ສະຫຼາດ. ມື້ນີ້, ມັນໂງ່ແທ້ໆ. 

ເຖິງແມ່ນວ່າມີການປ່ຽນແປງທີ່ຜ່ານມາທັງຫມົດເຫຼົ່ານີ້, open-source ຍັງດີກວ່າແລະປອດໄພກວ່າທາງເລືອກຊອຟແວທີ່ເປັນເຈົ້າຂອງກ່ອງດໍາ. ແຕ່, ພວກເຮົາຕ້ອງກວດສອບແລະກວດສອບລະຫັດແທນທີ່ຈະເຊື່ອມັນ blindly. ມັນເປັນສິ່ງດຽວທີ່ສະຫລາດທີ່ຈະເຮັດຕໍ່ໄປ.

Related Stories:



ແຫຼ່ງຂໍ້ມູນ