ວິທີການສ້າງໂຄງການແຫຼ່ງເປີດ

ງານບຸນ IT ຈະຈັດຂຶ້ນໃນ St. Petersburg ໃນອາທິດນີ້ ເທກໂນໂລຍີ. ຫນຶ່ງໃນລໍາໂພງຈະເປັນ Richard Stallman. Embox ຍັງເຂົ້າຮ່ວມໃນງານບຸນ, ແລະແນ່ນອນວ່າພວກເຮົາບໍ່ສາມາດບໍ່ສົນໃຈຫົວຂໍ້ຂອງຊອບແວຟຣີ. ນັ້ນແມ່ນເຫດຜົນທີ່ວ່າຫນຶ່ງໃນບົດລາຍງານຂອງພວກເຮົາຖືກເອີ້ນວ່າ "ຈາກຫັດຖະກໍາຂອງນັກຮຽນໄປສູ່ໂຄງການ opensource. ປະສົບການ Embox”. ມັນຈະອຸທິດຕົນເພື່ອປະຫວັດການພັດທະນາຂອງ Embox ເປັນໂຄງການແຫຼ່ງເປີດ. ໃນບົດຄວາມນີ້ຂ້ອຍຢາກເວົ້າກ່ຽວກັບແນວຄວາມຄິດຕົ້ນຕໍທີ່, ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ມີອິດທິພົນຕໍ່ການພັດທະນາໂຄງການ opensource. ບົດຄວາມ, ຄືກັບບົດລາຍງານ, ແມ່ນອີງໃສ່ປະສົບການສ່ວນຕົວ.

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

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

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

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

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

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

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

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

ຊຸມຊົນແມ່ນກຸນແຈໃນໂຄງການ opensource. ມັນຊ່ວຍໃຫ້ທ່ານສາມາດຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍໃນການຄຸ້ມຄອງໂຄງການຢ່າງຫຼວງຫຼາຍ, ພັດທະນາແລະສະຫນັບສະຫນູນໂຄງການ. ພວກເຮົາສາມາດເວົ້າໄດ້ວ່າບໍ່ມີຊຸມຊົນບໍ່ມີໂຄງການ opensource ທັງຫມົດ.

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

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

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

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

ຜູ້ໃຊ້ທໍາອິດຂອງ Embox ແມ່ນພະແນກ Cybernetics ທິດສະດີ. ພວກເຂົາເຈົ້າໄດ້ແນະນໍາການສ້າງເຟີມແວທາງເລືອກສໍາລັບ Lego Mindstorm. ແລະເຖິງແມ່ນວ່າເຫຼົ່ານີ້ຍັງເປັນຜູ້ໃຊ້ທ້ອງຖິ່ນ (ພວກເຮົາສາມາດພົບກັບພວກເຂົາດ້ວຍຕົນເອງແລະປຶກສາຫາລືກ່ຽວກັບສິ່ງທີ່ພວກເຂົາຕ້ອງການ). ແຕ່ມັນຍັງເປັນປະສົບການທີ່ດີຫຼາຍ. ຕົວຢ່າງ, ພວກເຮົາພັດທະນາສາທິດທີ່ສາມາດສະແດງໃຫ້ຄົນອື່ນເຫັນ, ເພາະວ່າຫຸ່ນຍົນມີຄວາມມ່ວນ ແລະດຶງດູດຄວາມສົນໃຈ. ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ຮັບຜູ້ໃຊ້ພາກສ່ວນທີສາມຢ່າງແທ້ຈິງທີ່ເລີ່ມຖາມວ່າ Embox ແມ່ນຫຍັງແລະວິທີການນໍາໃຊ້ມັນ.

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

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

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

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

ໂດຍທົ່ວໄປ, ພວກເຮົາກ້າວໄປຢ່າງລຽບງ່າຍໃນຈຸດຕົ້ນຕໍທີ່ອະນຸຍາດໃຫ້ພວກເຮົາເວົ້າກ່ຽວກັບການສ້າງໂຄງການ opensource - ການສ້າງຜະລິດຕະພັນທີ່ຈະແກ້ໄຂບັນຫາຂອງຜູ້ໃຊ້. ດັ່ງທີ່ຂ້ອຍໄດ້ອະທິບາຍຂ້າງເທິງ, ຊັບສິນຕົ້ນຕໍຂອງໂຄງການ opensource ແມ່ນຊຸມຊົນຂອງມັນ. ຍິ່ງໄປກວ່ານັ້ນ, ສະມາຊິກຊຸມຊົນແມ່ນຜູ້ໃຊ້ຕົ້ນຕໍ. ແຕ່ພວກເຂົາມາຈາກໃສໃນເວລາທີ່ບໍ່ມີຫຍັງທີ່ຈະໃຊ້? ດັ່ງນັ້ນ, ຄືກັນກັບໂຄງການທີ່ບໍ່ແມ່ນ opensource, ທ່ານຈໍາເປັນຕ້ອງໄດ້ສຸມໃສ່ການສ້າງ MVP (ຜະລິດຕະພັນທີ່ມີປະໂຫຍດສູງສຸດ), ແລະຖ້າມັນສົນໃຈຜູ້ໃຊ້, ຫຼັງຈາກນັ້ນຊຸມຊົນຈະປາກົດຢູ່ທົ່ວໂຄງການ. ຖ້າທ່ານມີສ່ວນຮ່ວມໃນການສ້າງຊຸມຊົນພຽງແຕ່ຜ່ານ PR ຊຸມຊົນ, ການຂຽນ wiki ໃນທຸກພາສາຂອງໂລກ, ຫຼືແກ້ໄຂ git workflow ໃນ github, ມັນບໍ່ຫນ້າຈະເປັນບັນຫາໃນຂັ້ນຕອນທໍາອິດຂອງໂຄງການ. ແນ່ນອນ, ໃນຂັ້ນຕອນທີ່ເຫມາະສົມ, ເຫຼົ່ານີ້ບໍ່ພຽງແຕ່ມີຄວາມສໍາຄັນ, ແຕ່ຍັງມີຄວາມຈໍາເປັນ.

ສະຫຼຸບ, ຂ້າພະເຈົ້າຢາກຊີ້ໃຫ້ເຫັນ commentary, ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ສະທ້ອນໃຫ້ເຫັນຄວາມຄາດຫວັງຂອງຜູ້ໃຊ້ຈາກໂຄງການ opensource:

ຂ້າ​ພະ​ເຈົ້າ​ຄິດ​ຢ່າງ​ຈິງ​ຈັງ​ກ່ຽວ​ກັບ​ການ​ສະ​ຫຼັບ​ກັບ OS ນີ້ (ຢ່າງ​ຫນ້ອຍ​ພະ​ຍາ​ຍາມ. ພວກ​ເຂົາ​ເຈົ້າ​ກໍາ​ລັງ​ຫ້າວ​ຫັນ​ຊອກ​ຫາ​ມັນ​ແລະ​ເຮັດ​ສິ່ງ​ທີ່​ເຢັນ).

PS On ເທກໂນໂລຍີ ພວກເຮົາຈະມີສາມບົດລາຍງານ. ຫນຶ່ງກ່ຽວກັບແຫຼ່ງເປີດແລະສອງກ່ຽວກັບການຝັງ (ແລະຫນຶ່ງແມ່ນປະຕິບັດໄດ້). ຢູ່ທີ່ຢືນພວກເຮົາຈະດໍາເນີນຫ້ອງຮຽນຕົ້ນສະບັບກ່ຽວກັບ microcontrollers ການຂຽນໂປລແກລມໂດຍໃຊ້ Embox. ຕາມປົກກະຕິ, ພວກເຮົາຈະເອົາຮາດແວແລະໃຫ້ທ່ານຂຽນໂປຼແກຼມ. ນອກ​ນັ້ນ​ຍັງ​ຈະ​ມີ​ການ​ຊອກ​ຫາ​ແລະ​ກິດ​ຈະ​ກໍາ​ອື່ນໆ​. ມາງານບຸນແລະຈຸດຢືນຂອງພວກເຮົາ, ມັນຈະມ່ວນ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com