ઓપન સોર્સ પ્રોજેક્ટ કેવી રીતે બનાવવો

આ અઠવાડિયે સેન્ટ પીટર્સબર્ગમાં આઈટી ફેસ્ટિવલ યોજાશે ટેકટ્રેન. વક્તાઓમાંના એક રિચાર્ડ સ્ટોલમેન હશે. એમ્બોક્સ તહેવારમાં પણ ભાગ લે છે, અને અલબત્ત અમે ફ્રી સોફ્ટવેરના વિષયને અવગણી શકતા નથી. તેથી જ અમારો એક રિપોર્ટ મંગાવવામાં આવ્યો છે "વિદ્યાર્થી હસ્તકલાથી લઈને ઓપનસોર્સ પ્રોજેક્ટ્સ સુધી. Embox અનુભવ". તે ઓપન સોર્સ પ્રોજેક્ટ તરીકે Embox ના વિકાસના ઇતિહાસને સમર્પિત કરવામાં આવશે. આ લેખમાં હું મુખ્ય વિચારો વિશે વાત કરવા માંગુ છું જે, મારા મતે, ઓપનસોર્સ પ્રોજેક્ટ્સના વિકાસને પ્રભાવિત કરે છે. અહેવાલની જેમ લેખ પણ વ્યક્તિગત અનુભવ પર આધારિત છે.

ચાલો ઓપનસોર્સ શબ્દની વ્યાખ્યા સાથે, કંઈક સરળ સાથે પ્રારંભ કરીએ. દેખીતી રીતે, ઓપન સોર્સ પ્રોજેક્ટ એ એવો પ્રોજેક્ટ છે કે જેમાં એક લાયસન્સ હોય છે જે પ્રોજેક્ટના સ્રોત કોડને ઍક્સેસ કરવાની મંજૂરી આપે છે. વધુમાં, ઓપન પ્રોજેક્ટનો અર્થ એ છે કે તૃતીય-પક્ષ વિકાસકર્તાઓ ફેરફારો કરી શકે છે. એટલે કે, જો કોઈ કંપની અથવા ડેવલપર તેના ઉત્પાદનનો કોડ, આંશિક રીતે અથવા સંપૂર્ણ રીતે પ્રકાશિત કરે છે, તો તે હજી સુધી આ ઉત્પાદનને ઓપનસોર્સ પ્રોજેક્ટ બનાવતું નથી. અને અંતે, કોઈપણ પ્રોજેક્ટ પ્રવૃત્તિએ અમુક પ્રકારના પરિણામ તરફ દોરી જવું જોઈએ, અને પ્રોજેક્ટની નિખાલસતા સૂચવે છે કે આ પરિણામનો ઉપયોગ ફક્ત વિકાસકર્તાઓ દ્વારા જ થતો નથી.

અમે ઓપન લાયસન્સની સમસ્યાઓને સ્પર્શ કરીશું નહીં. આ ખૂબ મોટો અને જટિલ વિષય છે જેને ઊંડાણપૂર્વકની તપાસની જરૂર છે. આ વિષય પર ઘણા સારા લેખો અને સામગ્રી લખવામાં આવી છે. પરંતુ હું પોતે કૉપિરાઇટના ક્ષેત્રમાં નિષ્ણાત ન હોવાથી, હું એટલું જ કહીશ કે લાયસન્સ પ્રોજેક્ટના લક્ષ્યોને પૂર્ણ કરે છે. ઉદાહરણ તરીકે, Embox માટે GPL લાયસન્સને બદલે BSD ની પસંદગી આકસ્મિક નહોતી.

હકીકત એ છે કે ઓપન સોર્સ પ્રોજેક્ટને ફેરફારો કરવાની અને ઓપન સોર્સ પ્રોજેક્ટના વિકાસને પ્રભાવિત કરવાની ક્ષમતા પ્રદાન કરવી જોઈએ તે સૂચવે છે કે પ્રોજેક્ટનું વિતરણ કરવામાં આવ્યું છે. કેન્દ્રિય પ્રબંધન સાથેના પ્રોજેક્ટની સરખામણીમાં તેનું સંચાલન, અખંડિતતા અને કામગીરી જાળવવી વધુ મુશ્કેલ છે. એક વાજબી પ્રશ્ન ઊભો થાય છે: શા માટે બધા પ્રોજેક્ટ્સ ખોલો? જવાબ વાણિજ્યિક સંભવિતતાના ક્ષેત્રમાં રહેલો છે; પ્રોજેક્ટના ચોક્કસ વર્ગ માટે, આ અભિગમના ફાયદા ખર્ચ કરતા વધારે છે. એટલે કે, તે તમામ પ્રોજેક્ટ્સ માટે યોગ્ય નથી અને ખુલ્લો અભિગમ સામાન્ય રીતે સ્વીકાર્ય છે. ઉદાહરણ તરીકે, ખુલ્લા સિદ્ધાંત પર આધારિત પાવર પ્લાન્ટ અથવા એરક્રાફ્ટ માટે કંટ્રોલ સિસ્ટમ વિકસાવવાની કલ્પના કરવી મુશ્કેલ છે. ના, અલબત્ત, આવી સિસ્ટમ્સમાં ખુલ્લા પ્રોજેક્ટ્સ પર આધારિત મોડ્યુલોનો સમાવેશ થવો જોઈએ, કારણ કે આ ઘણા બધા ફાયદા પ્રદાન કરશે. પરંતુ અંતિમ ઉત્પાદન માટે કોઈએ જવાબદાર હોવું જોઈએ. જો સિસ્ટમ સંપૂર્ણપણે ખુલ્લા પ્રોજેક્ટના કોડ પર આધારિત હોય, તો પણ વિકાસકર્તા, દરેક વસ્તુને એક સિસ્ટમમાં પેક કરીને અને ચોક્કસ બિલ્ડ્સ અને સેટિંગ્સ કર્યા પછી, આવશ્યકપણે તેને બંધ કરે છે. કોડ સાર્વજનિક રૂપે ઉપલબ્ધ હોઈ શકે છે.

ઓપન સોર્સ પ્રોજેક્ટ્સ બનાવવા અથવા તેમાં યોગદાન આપવાથી આ સિસ્ટમો માટે ઘણા ફાયદા પણ છે. મેં પહેલેથી જ કહ્યું તેમ, અંતિમ સિસ્ટમ કોડ સાર્વજનિક રૂપે ઉપલબ્ધ રહી શકે છે. શા માટે, કારણ કે તે સ્પષ્ટ છે કે તે અસંભવિત છે કે કોઈની પાસે સિસ્ટમનું પરીક્ષણ કરવા માટે સમાન વિમાન હશે. આ સાચું છે, પરંતુ કોડના અમુક વિભાગો તપાસવા માગતા હોય તેવી કોઈ વ્યક્તિ હોઈ શકે છે, અથવા, ઉદાહરણ તરીકે, કોઈ વ્યક્તિ શોધી શકે છે કે જે લાઈબ્રેરીનો ઉપયોગ થઈ રહ્યો છે તે એકદમ યોગ્ય રીતે ગોઠવાયેલ નથી.

જો કંપની સિસ્ટમના કેટલાક મૂળભૂત ભાગને અલગ પ્રોજેક્ટમાં ફાળવે તો તેનાથી પણ વધુ ફાયદો થાય છે. ઉદાહરણ તરીકે, અમુક પ્રકારના ડેટા એક્સચેન્જ પ્રોટોકોલને સપોર્ટ કરવા માટે લાઇબ્રેરી. આ કિસ્સામાં, જો પ્રોટોકોલ આપેલ વિષય વિસ્તાર માટે વિશિષ્ટ હોય, તો પણ તમે સિસ્ટમના આ ભાગને જાળવવાના ખર્ચને આ ક્ષેત્રની અન્ય કંપનીઓ સાથે શેર કરી શકો છો. વધુમાં, નિષ્ણાતો કે જેઓ પબ્લિક ડોમેનમાં સિસ્ટમના આ ભાગનો અભ્યાસ કરી શકે છે તેઓને તેનો અસરકારક રીતે ઉપયોગ કરવા માટે ઘણો ઓછો સમય લાગે છે. અને અંતે, તૃતીય-પક્ષ વિકાસકર્તાઓ ઉપયોગ કરે છે તે સ્વતંત્ર એન્ટિટીમાં ભાગને અલગ કરવાથી અમને આ ભાગને વધુ સારો બનાવવાની મંજૂરી મળે છે, કારણ કે અમારે અસરકારક API ઓફર કરવાની, દસ્તાવેજીકરણ બનાવવાની જરૂર છે અને હું પરીક્ષણ કવરેજને સુધારવા વિશે પણ વાત કરી રહ્યો નથી.

ઓપન-સોર્સ પ્રોજેક્ટ્સ બનાવ્યા વિના કંપની વ્યવસાયિક લાભો મેળવી શકે છે; કંપનીમાં ઉપયોગમાં લેવાતા તૃતીય-પક્ષ પ્રોજેક્ટ્સમાં ભાગ લેવા માટે તેના નિષ્ણાતો માટે તે પૂરતું છે. છેવટે, બધા ફાયદા રહે છે: કર્મચારીઓ પ્રોજેક્ટને વધુ સારી રીતે જાણે છે, તેથી તેઓ તેનો વધુ અસરકારક રીતે ઉપયોગ કરે છે, કંપની પ્રોજેક્ટના વિકાસની દિશાને પ્રભાવિત કરી શકે છે, અને તૈયાર, ડીબગ કરેલા કોડનો ઉપયોગ દેખીતી રીતે કંપનીના ખર્ચમાં ઘટાડો કરે છે.

ઓપનસોર્સ પ્રોજેક્ટ્સ બનાવવાના ફાયદા ત્યાં સમાપ્ત થતા નથી. ચાલો માર્કેટિંગ જેવા વ્યવસાયના આવા મહત્વપૂર્ણ ઘટકને લઈએ. તેના માટે, આ એક ખૂબ જ સારો સેન્ડબોક્સ છે જે તેને બજારની જરૂરિયાતોનું અસરકારક રીતે મૂલ્યાંકન કરવાની મંજૂરી આપે છે.

અને અલબત્ત, આપણે ભૂલવું જોઈએ નહીં કે ઓપનસોર્સ પ્રોજેક્ટ એ તમારી જાતને કોઈપણ વિશેષતાના વાહક તરીકે જાહેર કરવાની અસરકારક રીત છે. કેટલાક કિસ્સાઓમાં, બજારમાં પ્રવેશવાનો આ એકમાત્ર રસ્તો છે. ઉદાહરણ તરીકે, Embox RTOS બનાવવાના પ્રોજેક્ટ તરીકે શરૂ થયું. કદાચ ઘણા બધા સ્પર્ધકો છે તે સમજાવવાની જરૂર નથી. સમુદાય બનાવ્યા વિના, અમારી પાસે પ્રોજેક્ટને અંતિમ વપરાશકર્તા સુધી લાવવા માટે પૂરતા સંસાધનો ન હોત, એટલે કે, તૃતીય-પક્ષ વિકાસકર્તાઓ પ્રોજેક્ટનો ઉપયોગ શરૂ કરી શકે.

ઓપનસોર્સ પ્રોજેક્ટમાં સમુદાય ચાવીરૂપ છે. તે તમને પ્રોજેક્ટ મેનેજમેન્ટ ખર્ચમાં નોંધપાત્ર ઘટાડો કરવા, પ્રોજેક્ટ વિકસાવવા અને સપોર્ટ કરવાની મંજૂરી આપે છે. અમે કહી શકીએ કે સમુદાય વિના કોઈ ઓપનસોર્સ પ્રોજેક્ટ બિલકુલ નથી.

ઓપન સોર્સ પ્રોજેક્ટ સમુદાય કેવી રીતે બનાવવો અને તેનું સંચાલન કેવી રીતે કરવું તે વિશે ઘણી બધી સામગ્રી લખવામાં આવી છે. પહેલેથી જ જાણીતી હકીકતો ફરીથી ન કહેવા માટે, હું Embox ના અનુભવ પર ધ્યાન કેન્દ્રિત કરવાનો પ્રયાસ કરીશ. ઉદાહરણ તરીકે, સમુદાય બનાવવાની પ્રક્રિયા ખૂબ જ રસપ્રદ મુદ્દો છે. એટલે કે, ઘણા લોકો કહે છે કે અસ્તિત્વમાં રહેલા સમુદાયનું સંચાલન કેવી રીતે કરવું, પરંતુ તેની રચનાની ક્ષણોને કેટલીકવાર અવગણવામાં આવે છે, આને ધ્યાનમાં રાખીને.

ઓપનસોર્સ પ્રોજેક્ટ સમુદાય બનાવતી વખતે મુખ્ય નિયમ એ છે કે ત્યાં કોઈ નિયમો નથી. મારો મતલબ છે કે ત્યાં કોઈ સાર્વત્રિક નિયમો નથી, જેમ કે કોઈ સિલ્વર બુલેટ નથી, જો ફક્ત એટલા માટે કે પ્રોજેક્ટ ખૂબ જ અલગ છે. તે અસંભવિત છે કે તમે js લોગીંગ લાઇબ્રેરી અને કેટલાક અત્યંત વિશિષ્ટ ડ્રાઇવર માટે સમુદાય બનાવતી વખતે સમાન નિયમોનો ઉપયોગ કરી શકો. તદુપરાંત, પ્રોજેક્ટના વિકાસના વિવિધ તબક્કે (અને તેથી સમુદાય), નિયમો બદલાય છે.

Embox એક વિદ્યાર્થી પ્રોજેક્ટ તરીકે શરૂ થયો કારણ કે તેમાં સિસ્ટમ પ્રોગ્રામિંગ વિભાગના વિદ્યાર્થીઓની ઍક્સેસ હતી. હકીકતમાં, અમે કોઈ અન્ય સમુદાયમાં પ્રવેશી રહ્યા હતા. અમે આ સમુદાયના સહભાગીઓને, વિદ્યાર્થીઓને, તેમની વિશેષતા, સિસ્ટમ પ્રોગ્રામિંગ, અભ્યાસક્રમ અને ડિપ્લોમાના ક્ષેત્રમાં વૈજ્ઞાનિક કાર્યમાં સારી ઔદ્યોગિક પ્રેક્ટિસમાં રસ લઈ શકીએ છીએ. એટલે કે, અમે સમુદાયને ગોઠવવાના મૂળભૂત નિયમોમાંથી એકનું પાલન કર્યું: સમુદાયના સભ્યોએ કંઈક મેળવવું જોઈએ, અને આ કિંમત સહભાગીના યોગદાનને અનુરૂપ હોવી જોઈએ.

Embox માટે આગળનો તબક્કો તૃતીય-પક્ષ વપરાશકર્તાઓ માટે શોધ હતો. તે સમજવું ખૂબ જ મહત્વપૂર્ણ છે કે વપરાશકર્તાઓ ઓપનસોર્સ સમુદાયમાં સંપૂર્ણ સહભાગીઓ છે. વિકાસકર્તાઓ કરતાં સામાન્ય રીતે વધુ વપરાશકર્તાઓ હોય છે. અને કોઈ પ્રોજેક્ટમાં ફાળો આપનાર બનવાની ઈચ્છા રાખવા માટે, તેઓ સૌ પ્રથમ તેનો એક યા બીજી રીતે ઉપયોગ કરવાનું શરૂ કરે છે.

Embox ના પ્રથમ વપરાશકર્તાઓ સૈદ્ધાંતિક સાયબરનેટિક્સ વિભાગ હતા. તેઓએ Lego Mindstorm માટે વૈકલ્પિક ફર્મવેર બનાવવાનું સૂચન કર્યું. અને તેમ છતાં આ હજી પણ સ્થાનિક વપરાશકર્તાઓ હતા (અમે તેમની સાથે રૂબરૂ મળી શકીએ છીએ અને તેઓ શું ઇચ્છે છે તેની ચર્ચા કરી શકીએ છીએ). પરંતુ તે હજુ પણ ખૂબ જ સારો અનુભવ હતો. ઉદાહરણ તરીકે, અમે ડેમો વિકસાવ્યા છે જે અન્ય લોકોને બતાવી શકાય છે, કારણ કે રોબોટ્સ મનોરંજક છે અને ધ્યાન આકર્ષિત કરે છે. પરિણામે, અમને ખરેખર તૃતીય-પક્ષ વપરાશકર્તાઓ મળ્યા જેમણે પૂછવાનું શરૂ કર્યું કે Embox શું છે અને તેનો ઉપયોગ કેવી રીતે કરવો.

આ તબક્કે, અમારે દસ્તાવેજીકરણ વિશે, વપરાશકર્તાઓ સાથે વાતચીતના માધ્યમો વિશે વિચારવું પડ્યું. ના, અલબત્ત, અમે આ મહત્વપૂર્ણ બાબતો વિશે પહેલા વિચાર્યું હતું, પરંતુ તે અકાળ હતું અને સકારાત્મક અસર આપી ન હતી. અસર તદ્દન નકારાત્મક હતી. ચાલો હું તમને થોડા ઉદાહરણો આપું. અમે googlecode નો ઉપયોગ કર્યો, જેની વિકિ બહુભાષીયતાને સમર્થન આપે છે. અમે ઘણી ભાષાઓમાં પૃષ્ઠો બનાવ્યાં છે, માત્ર અંગ્રેજી અને રશિયન જ નહીં, જેમાં અમે ભાગ્યે જ વાતચીત કરી શકીએ છીએ, પણ જર્મન અને સ્પેનિશ પણ. પરિણામે, આ ભાષાઓમાં પૂછવામાં આવે ત્યારે તે ખૂબ જ હાસ્યાસ્પદ લાગે છે, પરંતુ અમે જવાબ આપી શકતા નથી. અથવા તેઓએ દસ્તાવેજો લખવા અને ટિપ્પણી કરવા અંગેના નિયમો રજૂ કર્યા હતા, પરંતુ API ઘણી વાર અને નોંધપાત્ર રીતે બદલાતા હોવાથી, તે બહાર આવ્યું કે અમારું દસ્તાવેજીકરણ જૂનું હતું અને તે મદદ કરતાં વધુ ભ્રામક હતું.

પરિણામે, અમારા બધા પ્રયત્નો, ખોટા પ્રયત્નો પણ, બાહ્ય વપરાશકર્તાઓના દેખાવ તરફ દોરી ગયા. અને એક કોમર્શિયલ ગ્રાહક પણ દેખાયો જે ઇચ્છતો હતો કે તેના માટે પોતાનું RTOS વિકસાવવામાં આવે. અને અમે તેને વિકસાવ્યું છે કારણ કે અમારી પાસે અનુભવ અને કેટલાક પાયાનું કામ છે. અહીં તમારે સારી અને ખરાબ બંને ક્ષણો વિશે વાત કરવાની જરૂર છે. હું ખરાબ લોકોથી શરૂઆત કરીશ. ઘણા વિકાસકર્તાઓ આ પ્રોજેક્ટમાં વ્યાપારી ધોરણે સંકળાયેલા હોવાથી, સમુદાય પહેલેથી જ તદ્દન અસ્થિર અને વિભાજિત હતો, જે અલબત્ત પ્રોજેક્ટના વિકાસને અસર કરી શક્યો ન હતો. એક વધારાનું પરિબળ એ હતું કે પ્રોજેક્ટની દિશા એક વ્યાવસાયિક ગ્રાહક દ્વારા નક્કી કરવામાં આવી હતી, અને તેનો ધ્યેય પ્રોજેક્ટનો વધુ વિકાસ ન હતો. ઓછામાં ઓછું આ મુખ્ય ધ્યેય ન હતું.

બીજી બાજુ, ત્યાં સંખ્યાબંધ હકારાત્મક પાસાઓ હતા. અમને ખરેખર તૃતીય-પક્ષ વપરાશકર્તાઓ મળ્યા છે. તે ફક્ત ગ્રાહક જ નહીં, પણ તે પણ હતા જેમના માટે આ સિસ્ટમનો હેતુ હતો. પ્રોજેક્ટમાં ભાગ લેવાની પ્રેરણા વધી છે. છેવટે, જો તમે કોઈ રસપ્રદ વ્યવસાયમાંથી પણ પૈસા કમાઈ શકો છો, તો તે હંમેશા સરસ છે. અને સૌથી અગત્યનું, અમે ગ્રાહકોની એક ઇચ્છા સાંભળી, જે તે સમયે અમને ઉન્મત્ત લાગતી હતી, પરંતુ જે હવે એમ્બોક્સનો મુખ્ય વિચાર છે, એટલે કે, સિસ્ટમમાં પહેલાથી વિકસિત કોડનો ઉપયોગ કરવો. હવે Embox નો મુખ્ય વિચાર Linux વગર Linux સોફ્ટવેરનો ઉપયોગ કરવાનો છે. એટલે કે, પ્રોજેક્ટના વધુ વિકાસમાં ફાળો આપતું મુખ્ય સકારાત્મક પાસું એ અનુભૂતિ હતી કે પ્રોજેક્ટનો ઉપયોગ તૃતીય-પક્ષ વપરાશકર્તાઓ દ્વારા કરવામાં આવે છે, અને તે તેમની કેટલીક સમસ્યાઓ હલ કરવી જોઈએ.

તે સમયે, Embox પહેલાથી જ વિદ્યાર્થી પ્રોજેક્ટના અવકાશની બહાર નીકળી ગયું હતું. વિદ્યાર્થી મોડેલ અનુસાર પ્રોજેક્ટના વિકાસમાં મુખ્ય મર્યાદિત પરિબળ એ સહભાગીઓની પ્રેરણા છે. વિદ્યાર્થીઓ અભ્યાસ કરતા હોય ત્યારે ભાગ લે છે, અને જ્યારે તેઓ સ્નાતક થાય છે, ત્યારે એક અલગ પ્રેરણા હોવી જોઈએ. જો પ્રેરણા દેખાતી નથી, તો વિદ્યાર્થી ફક્ત પ્રોજેક્ટમાં ભાગ લેવાનું બંધ કરે છે. જો આપણે ધ્યાનમાં લઈએ કે વિદ્યાર્થીઓને પ્રથમ તાલીમ આપવાની જરૂર છે, તો તે તારણ આપે છે કે તેઓ સ્નાતક થાય ત્યાં સુધીમાં તેઓ સારા નિષ્ણાત બની જાય છે, પરંતુ બિનઅનુભવીતાને કારણે પ્રોજેક્ટમાં તેમનો ફાળો બહુ મોટો નથી.

સામાન્ય રીતે, અમે મુખ્ય મુદ્દા પર સરળતાથી આગળ વધીએ છીએ જે અમને ઓપનસોર્સ પ્રોજેક્ટ બનાવવા વિશે વાત કરવાની મંજૂરી આપે છે - એક એવું ઉત્પાદન બનાવવું જે તેના વપરાશકર્તાઓની સમસ્યાઓ હલ કરે. મેં ઉપર સમજાવ્યું તેમ, ઓપનસોર્સ પ્રોજેક્ટની મુખ્ય મિલકત તેનો સમુદાય છે. વધુમાં, સમુદાયના સભ્યો મુખ્યત્વે વપરાશકર્તાઓ છે. પરંતુ જ્યારે ઉપયોગ કરવા માટે કંઈ જ ન હોય ત્યારે તેઓ ક્યાંથી આવે છે? તેથી તે તારણ આપે છે કે, બિન-ઓપનસોર્સ પ્રોજેક્ટની જેમ, તમારે MVP (લઘુત્તમ વ્યવહારુ ઉત્પાદન) બનાવવા પર ધ્યાન કેન્દ્રિત કરવાની જરૂર છે, અને જો તે વપરાશકર્તાઓને રસ લે છે, તો પ્રોજેક્ટની આસપાસ સમુદાય દેખાશે. જો તમે માત્ર કોમ્યુનિટી PR દ્વારા સમુદાય બનાવવા માટે, વિશ્વની તમામ ભાષાઓમાં વિકિ લખવામાં અથવા ગીથબ પર ગિટ વર્કફ્લોને સુધારવામાં રોકાયેલા છો, તો પ્રોજેક્ટના પ્રારંભિક તબક્કામાં આ અસંભવિત છે. અલબત્ત, યોગ્ય તબક્કે આ માત્ર મહત્વપૂર્ણ નથી, પણ જરૂરી વસ્તુઓ પણ છે.

નિષ્કર્ષમાં હું નિર્દેશ કરવા માંગુ છું ભાષ્ય, મારા મતે, ઓપનસોર્સ પ્રોજેક્ટમાંથી વપરાશકર્તાની અપેક્ષાઓ પ્રતિબિંબિત કરે છે:

હું આ OS પર સ્વિચ કરવા વિશે ગંભીરતાથી વિચારી રહ્યો છું (ઓછામાં ઓછું પ્રયાસ કરો. તેઓ સક્રિયપણે તેનો પીછો કરી રહ્યાં છે અને સરસ વસ્તુઓ કરી રહ્યાં છે).

પીએસ ચાલુ ટેકટ્રેન અમારી પાસે ત્રણ જેટલા રિપોર્ટ હશે. એક ઓપન સોર્સ વિશે અને બે એમ્બેડેડ વિશે (અને એક વ્યવહારુ છે). સ્ટેન્ડ પર અમે પ્રોગ્રામિંગ માઇક્રોકન્ટ્રોલરનો ઉપયોગ કરીને માસ્ટર ક્લાસ ચલાવીશું એમ્બોક્સ. હંમેશની જેમ, અમે હાર્ડવેર લાવીશું અને તમને પ્રોગ્રામ કરવા દઈશું. ક્વેસ્ટ અને અન્ય પ્રવૃત્તિઓ પણ હશે. તહેવાર અને અમારા સ્ટેન્ડ પર આવો, મજા આવશે.

સોર્સ: www.habr.com