ഒരു ഓപ്പൺ സോഴ്സ് പ്രോജക്റ്റ് എങ്ങനെ സൃഷ്ടിക്കാം

ഈ ആഴ്ച സെന്റ് പീറ്റേഴ്‌സ്ബർഗിൽ ഒരു ഐടി ഫെസ്റ്റിവൽ നടക്കും ടെക്ട്രെയിൻ. പ്രസംഗകരിൽ ഒരാൾ റിച്ചാർഡ് സ്റ്റാൾമാൻ ആയിരിക്കും. എംബോക്സ് കൂടാതെ ഫെസ്റ്റിവലിൽ പങ്കെടുക്കുന്നു, തീർച്ചയായും നമുക്ക് സ്വതന്ത്ര സോഫ്‌റ്റ്‌വെയർ എന്ന വിഷയം അവഗണിക്കാൻ കഴിഞ്ഞില്ല. അതുകൊണ്ടാണ് ഞങ്ങളുടെ റിപ്പോർട്ടുകളിലൊന്ന് വിളിക്കുന്നത് “വിദ്യാർത്ഥികളുടെ കരകൗശലവസ്തുക്കൾ മുതൽ ഓപ്പൺസോഴ്സ് പ്രോജക്ടുകൾ വരെ. എംബോക്സ് അനുഭവം". ഒരു ഓപ്പൺ സോഴ്‌സ് പ്രോജക്‌റ്റായി എംബോക്‌സിന്റെ വികസനത്തിന്റെ ചരിത്രത്തിനായി ഇത് സമർപ്പിക്കും. ഈ ലേഖനത്തിൽ, എന്റെ അഭിപ്രായത്തിൽ, ഓപ്പൺ സോഴ്‌സ് പ്രോജക്റ്റുകളുടെ വികസനത്തെ സ്വാധീനിക്കുന്ന പ്രധാന ആശയങ്ങളെക്കുറിച്ച് സംസാരിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. ലേഖനം, റിപ്പോർട്ട് പോലെ, വ്യക്തിപരമായ അനുഭവത്തെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്.

ഓപ്പൺ സോഴ്സ് എന്ന പദത്തിന്റെ നിർവചനം ഉപയോഗിച്ച് നമുക്ക് ലളിതമായ എന്തെങ്കിലും ആരംഭിക്കാം. വ്യക്തമായും, ഒരു ഓപ്പൺ സോഴ്സ് പ്രോജക്റ്റ് എന്നത് പ്രോജക്റ്റിന്റെ സോഴ്സ് കോഡിലേക്ക് ആക്സസ് അനുവദിക്കുന്ന ലൈസൻസുകളിലൊന്നാണ്. കൂടാതെ, ഒരു തുറന്ന പ്രോജക്റ്റ് അർത്ഥമാക്കുന്നത് മൂന്നാം കക്ഷി ഡെവലപ്പർമാർക്ക് മാറ്റങ്ങൾ വരുത്താൻ കഴിയും എന്നാണ്. അതായത്, ഏതെങ്കിലും കമ്പനിയോ ഡെവലപ്പറോ അതിന്റെ ഉൽപ്പന്നത്തിന്റെ കോഡ് ഭാഗികമായോ പൂർണ്ണമായോ പ്രസിദ്ധീകരിക്കുകയാണെങ്കിൽ, ഇത് ഇതുവരെ ഈ ഉൽപ്പന്നത്തെ ഒരു ഓപ്പൺ സോഴ്‌സ് പ്രോജക്റ്റ് ആക്കുന്നില്ല. അവസാനമായി, ഏത് പ്രോജക്റ്റ് പ്രവർത്തനവും ഏതെങ്കിലും തരത്തിലുള്ള ഫലത്തിലേക്ക് നയിക്കണം, കൂടാതെ ഈ ഫലം ഡവലപ്പർമാർ മാത്രമല്ല ഉപയോഗിക്കുന്നതെന്ന് പ്രോജക്റ്റിന്റെ തുറന്നത സൂചിപ്പിക്കുന്നു.

ഓപ്പൺ ലൈസൻസുകളുടെ പ്രശ്നങ്ങളിൽ ഞങ്ങൾ സ്പർശിക്കില്ല. ഇത് വളരെ വലുതും സങ്കീർണ്ണവുമായ ഒരു വിഷയമാണ്, അത് ആഴത്തിലുള്ള അന്വേഷണം ആവശ്യമാണ്. ഈ വിഷയത്തിൽ ധാരാളം നല്ല ലേഖനങ്ങളും മെറ്റീരിയലുകളും എഴുതിയിട്ടുണ്ട്. എന്നാൽ ഞാൻ തന്നെ പകർപ്പവകാശ മേഖലയിൽ വിദഗ്ദ്ധനല്ലാത്തതിനാൽ, ലൈസൻസ് പദ്ധതിയുടെ ലക്ഷ്യങ്ങൾ നിറവേറ്റണം എന്ന് മാത്രമേ ഞാൻ പറയൂ. ഉദാഹരണത്തിന്, എംബോക്സിന് GPL ലൈസൻസിന് പകരം ഒരു BSD തിരഞ്ഞെടുക്കുന്നത് ആകസ്മികമായിരുന്നില്ല.

ഒരു ഓപ്പൺ സോഴ്‌സ് പ്രോജക്‌റ്റ് മാറ്റങ്ങൾ വരുത്താനും ഓപ്പൺ സോഴ്‌സ് പ്രോജക്‌ടിന്റെ വികസനത്തെ സ്വാധീനിക്കാനും ഉള്ള കഴിവ് നൽകണം എന്നത് പ്രോജക്റ്റ് വിതരണം ചെയ്‌തിരിക്കുന്നുവെന്ന് സൂചിപ്പിക്കുന്നു. കേന്ദ്രീകൃത മാനേജുമെന്റുള്ള ഒരു പ്രോജക്റ്റുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ ഇത് കൈകാര്യം ചെയ്യുന്നതും സമഗ്രതയും പ്രകടനവും നിലനിർത്തുന്നത് വളരെ ബുദ്ധിമുട്ടാണ്. ന്യായമായ ഒരു ചോദ്യം ഉയർന്നുവരുന്നു: എന്തുകൊണ്ടാണ് പ്രോജക്റ്റുകൾ തുറക്കുന്നത്? വാണിജ്യ സാധ്യതയുടെ മേഖലയിലാണ് ഉത്തരം സ്ഥിതിചെയ്യുന്നത്; ഒരു പ്രത്യേക ക്ലാസ് പ്രോജക്റ്റുകൾക്ക്, ഈ സമീപനത്തിന്റെ നേട്ടങ്ങൾ ചെലവുകളേക്കാൾ കൂടുതലാണ്. അതായത്, എല്ലാ പദ്ധതികൾക്കും അനുയോജ്യമല്ല, തുറന്ന സമീപനം പൊതുവെ സ്വീകാര്യമാണ്. ഉദാഹരണത്തിന്, ഒരു തുറന്ന തത്വത്തെ അടിസ്ഥാനമാക്കി ഒരു പവർ പ്ലാന്റ് അല്ലെങ്കിൽ ഒരു വിമാനത്തിനുള്ള ഒരു നിയന്ത്രണ സംവിധാനം വികസിപ്പിക്കുന്നത് സങ്കൽപ്പിക്കാൻ പ്രയാസമാണ്. ഇല്ല, തീർച്ചയായും, അത്തരം സിസ്റ്റങ്ങളിൽ ഓപ്പൺ പ്രോജക്റ്റുകളെ അടിസ്ഥാനമാക്കിയുള്ള മൊഡ്യൂളുകൾ ഉൾപ്പെടുത്തണം, കാരണം ഇത് നിരവധി ഗുണങ്ങൾ നൽകും. എന്നാൽ അന്തിമ ഉൽപ്പന്നത്തിന് ആരെങ്കിലും ഉത്തരവാദിയായിരിക്കണം. സിസ്റ്റം പൂർണ്ണമായും ഓപ്പൺ പ്രോജക്റ്റുകളുടെ കോഡിനെ അടിസ്ഥാനമാക്കിയുള്ളതാണെങ്കിലും, ഡവലപ്പർ, എല്ലാം ഒരു സിസ്റ്റത്തിലേക്ക് പാക്കേജുചെയ്‌ത് നിർദ്ദിഷ്ട ബിൽഡുകളും ക്രമീകരണങ്ങളും ഉണ്ടാക്കി, അടിസ്ഥാനപരമായി അത് അടയ്ക്കുന്നു. കോഡ് പൊതുവായി ലഭ്യമായേക്കാം.

ഓപ്പൺ സോഴ്‌സ് പ്രോജക്‌റ്റുകൾ സൃഷ്‌ടിക്കുന്നതിൽ നിന്നോ സംഭാവന ചെയ്യുന്നതിൽ നിന്നോ ഈ സിസ്റ്റങ്ങൾക്ക് ധാരാളം നേട്ടങ്ങളുണ്ട്. ഞാൻ ഇതിനകം പറഞ്ഞതുപോലെ, എൻഡ് സിസ്റ്റം കോഡ് പൊതുവായി ലഭ്യമായേക്കാം. എന്തുകൊണ്ട്, സിസ്റ്റം പരീക്ഷിക്കാൻ ആർക്കെങ്കിലും ഒരേ വിമാനം ഉണ്ടാകാൻ സാധ്യതയില്ല എന്നത് വ്യക്തമാണ്. ഇത് ശരിയാണ്, എന്നാൽ കോഡിന്റെ ചില വിഭാഗങ്ങൾ പരിശോധിക്കാൻ ആഗ്രഹിക്കുന്ന ആരെങ്കിലും ഉണ്ടായിരിക്കാം, അല്ലെങ്കിൽ, ഉദാഹരണത്തിന്, ഉപയോഗിക്കുന്ന ലൈബ്രറി ശരിയായി ക്രമീകരിച്ചിട്ടില്ലെന്ന് ആരെങ്കിലും കണ്ടെത്തിയേക്കാം.

കമ്പനി ഒരു പ്രത്യേക പ്രോജക്റ്റിലേക്ക് സിസ്റ്റത്തിന്റെ ചില അടിസ്ഥാന ഭാഗം അനുവദിക്കുകയാണെങ്കിൽ ഇതിലും വലിയ നേട്ടം ദൃശ്യമാകും. ഉദാഹരണത്തിന്, ഏതെങ്കിലും തരത്തിലുള്ള ഡാറ്റാ എക്സ്ചേഞ്ച് പ്രോട്ടോക്കോൾ പിന്തുണയ്ക്കുന്നതിനുള്ള ഒരു ലൈബ്രറി. ഈ സാഹചര്യത്തിൽ, പ്രോട്ടോക്കോൾ തന്നിരിക്കുന്ന വിഷയ മേഖലയ്ക്ക് പ്രത്യേകമാണെങ്കിലും, ഈ സിസ്റ്റത്തിന്റെ ഈ ഭാഗം പരിപാലിക്കുന്നതിനുള്ള ചെലവ് ഈ ഏരിയയിൽ നിന്നുള്ള മറ്റ് കമ്പനികളുമായി നിങ്ങൾക്ക് പങ്കിടാം. കൂടാതെ, പബ്ലിക് ഡൊമെയ്‌നിലെ സിസ്റ്റത്തിന്റെ ഈ ഭാഗം പഠിക്കാൻ കഴിയുന്ന സ്പെഷ്യലിസ്റ്റുകൾക്ക് ഇത് ഫലപ്രദമായി ഉപയോഗിക്കാൻ വളരെ കുറച്ച് സമയം മാത്രമേ ആവശ്യമുള്ളൂ. അവസാനമായി, മൂന്നാം കക്ഷി ഡെവലപ്പർമാർ ഉപയോഗിക്കുന്ന ഒരു സ്വതന്ത്ര എന്റിറ്റിയായി ഒരു ഭാഗം വേർതിരിക്കുന്നത് ഈ ഭാഗം മികച്ചതാക്കാൻ ഞങ്ങളെ അനുവദിക്കുന്നു, കാരണം ഞങ്ങൾക്ക് ഫലപ്രദമായ API-കൾ വാഗ്ദാനം ചെയ്യേണ്ടതുണ്ട്, ഡോക്യുമെന്റേഷൻ സൃഷ്ടിക്കേണ്ടതുണ്ട്, കൂടാതെ ടെസ്റ്റ് കവറേജ് മെച്ചപ്പെടുത്തുന്നതിനെക്കുറിച്ച് ഞാൻ സംസാരിക്കുന്നില്ല.

ഓപ്പൺ സോഴ്‌സ് പ്രോജക്ടുകൾ സൃഷ്ടിക്കാതെ തന്നെ ഒരു കമ്പനിക്ക് വാണിജ്യ ആനുകൂല്യങ്ങൾ ലഭിക്കും; കമ്പനിയിൽ ഉപയോഗിക്കുന്ന മൂന്നാം കക്ഷി പ്രോജക്റ്റുകളിൽ അതിന്റെ സ്പെഷ്യലിസ്റ്റുകൾ പങ്കെടുത്താൽ മതി. എല്ലാത്തിനുമുപരി, എല്ലാ ആനുകൂല്യങ്ങളും അവശേഷിക്കുന്നു: ജീവനക്കാർക്ക് പ്രോജക്റ്റ് നന്നായി അറിയാം, അതിനാൽ അവർ ഇത് കൂടുതൽ ഫലപ്രദമായി ഉപയോഗിക്കുന്നു, കമ്പനിക്ക് പ്രോജക്റ്റിന്റെ വികസനത്തിന്റെ ദിശയെ സ്വാധീനിക്കാൻ കഴിയും, കൂടാതെ റെഡിമെയ്ഡ്, ഡീബഗ്ഗ് ചെയ്ത കോഡിന്റെ ഉപയോഗം കമ്പനിയുടെ ചെലവ് കുറയ്ക്കുന്നു.

ഓപ്പൺ സോഴ്‌സ് പ്രോജക്ടുകൾ സൃഷ്ടിക്കുന്നതിന്റെ പ്രയോജനങ്ങൾ അവിടെ അവസാനിക്കുന്നില്ല. മാർക്കറ്റിംഗ് പോലെയുള്ള ബിസിനസ്സിന്റെ ഒരു പ്രധാന ഘടകം നമുക്ക് എടുക്കാം. അവനെ സംബന്ധിച്ചിടത്തോളം, മാർക്കറ്റ് ആവശ്യകതകൾ ഫലപ്രദമായി വിലയിരുത്താൻ അനുവദിക്കുന്ന വളരെ നല്ല സാൻഡ്ബോക്സാണിത്.

തീർച്ചയായും, ഏതെങ്കിലും സ്പെഷ്യലൈസേഷന്റെ കാരിയർ ആയി സ്വയം പ്രഖ്യാപിക്കുന്നതിനുള്ള ഫലപ്രദമായ മാർഗമാണ് ഒരു ഓപ്പൺ സോഴ്സ് പ്രോജക്റ്റ് എന്നത് നാം മറക്കരുത്. ചില സന്ദർഭങ്ങളിൽ, വിപണിയിൽ പ്രവേശിക്കാനുള്ള ഒരേയൊരു മാർഗ്ഗമാണിത്. ഉദാഹരണത്തിന്, എംബോക്സ് ഒരു RTOS സൃഷ്ടിക്കുന്നതിനുള്ള ഒരു പ്രോജക്റ്റായി ആരംഭിച്ചു. ധാരാളം മത്സരാർത്ഥികൾ ഉണ്ടെന്ന് വിശദീകരിക്കേണ്ട ആവശ്യമില്ല. ഒരു കമ്മ്യൂണിറ്റി സൃഷ്ടിക്കാതെ, പ്രോജക്റ്റ് അന്തിമ ഉപയോക്താവിലേക്ക് എത്തിക്കുന്നതിന്, അതായത് മൂന്നാം കക്ഷി ഡെവലപ്പർമാർക്ക് പ്രോജക്റ്റ് ഉപയോഗിക്കാൻ തുടങ്ങുന്നതിന് ആവശ്യമായ ഉറവിടങ്ങൾ ഞങ്ങൾക്ക് ഉണ്ടാകുമായിരുന്നില്ല.

ഒരു ഓപ്പൺ സോഴ്സ് പ്രോജക്റ്റിൽ കമ്മ്യൂണിറ്റി പ്രധാനമാണ്. പ്രോജക്റ്റ് മാനേജുമെന്റ് ചെലവ് ഗണ്യമായി കുറയ്ക്കാനും പ്രോജക്റ്റ് വികസിപ്പിക്കാനും പിന്തുണയ്ക്കാനും ഇത് നിങ്ങളെ അനുവദിക്കുന്നു. ഒരു കമ്മ്യൂണിറ്റി ഇല്ലാതെ ഒരു ഓപ്പൺ സോഴ്‌സ് പ്രോജക്റ്റ് ഇല്ലെന്ന് നമുക്ക് പറയാം.

ഒരു ഓപ്പൺ സോഴ്‌സ് പ്രോജക്‌റ്റ് കമ്മ്യൂണിറ്റി എങ്ങനെ സൃഷ്‌ടിക്കാമെന്നും മാനേജുചെയ്യാമെന്നും കുറിച്ച് ധാരാളം മെറ്റീരിയലുകൾ എഴുതിയിട്ടുണ്ട്. ഇതിനകം അറിയപ്പെടുന്ന വസ്‌തുതകൾ വീണ്ടും പറയാതിരിക്കാൻ, എംബോക്‌സിന്റെ അനുഭവത്തിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കാൻ ഞാൻ ശ്രമിക്കും. ഉദാഹരണത്തിന്, ഒരു കമ്മ്യൂണിറ്റി സൃഷ്ടിക്കുന്ന പ്രക്രിയ വളരെ രസകരമായ ഒരു പ്രശ്നമാണ്. അതായത്, നിലവിലുള്ള ഒരു കമ്മ്യൂണിറ്റിയെ എങ്ങനെ കൈകാര്യം ചെയ്യാമെന്ന് പലരും പറയുന്നു, എന്നാൽ ഇത് നൽകിയിട്ടുള്ളതായി കണക്കാക്കി അതിന്റെ സൃഷ്ടിയുടെ നിമിഷങ്ങൾ ചിലപ്പോൾ അവഗണിക്കപ്പെടുന്നു.

ഒരു ഓപ്പൺ സോഴ്സ് പ്രോജക്റ്റ് കമ്മ്യൂണിറ്റി സൃഷ്ടിക്കുമ്പോൾ പ്രധാന നിയമം നിയമങ്ങളൊന്നുമില്ല എന്നതാണ്. സാർവത്രിക നിയമങ്ങളൊന്നും ഇല്ല എന്നാണ് ഞാൻ അർത്ഥമാക്കുന്നത്, വെള്ളി ബുള്ളറ്റ് ഇല്ലാത്തതുപോലെ, പദ്ധതികൾ വളരെ വ്യത്യസ്തമായതിനാൽ മാത്രം. ഒരു js ലോഗിംഗ് ലൈബ്രറിക്കും ചില പ്രത്യേക ഡ്രൈവറുകൾക്കുമായി ഒരു കമ്മ്യൂണിറ്റി സൃഷ്ടിക്കുമ്പോൾ നിങ്ങൾക്ക് ഇതേ നിയമങ്ങൾ ഉപയോഗിക്കാൻ സാധ്യതയില്ല. മാത്രമല്ല, പദ്ധതിയുടെ വികസനത്തിന്റെ വിവിധ ഘട്ടങ്ങളിൽ (അതിനാൽ സമൂഹം), നിയമങ്ങൾ മാറുന്നു.

എംബോക്‌സ് ഒരു സ്റ്റുഡന്റ് പ്രോജക്‌റ്റായി ആരംഭിച്ചു, കാരണം സിസ്റ്റം പ്രോഗ്രാമിംഗ് ഡിപ്പാർട്ട്‌മെന്റിൽ നിന്നുള്ള വിദ്യാർത്ഥികൾക്ക് ആക്‌സസ് ഉണ്ടായിരുന്നു. വാസ്തവത്തിൽ, ഞങ്ങൾ മറ്റൊരു സമൂഹത്തിലേക്ക് പ്രവേശിക്കുകയായിരുന്നു. ഈ കമ്മ്യൂണിറ്റിയിലെ പങ്കാളികൾ, വിദ്യാർത്ഥികൾ, അവരുടെ സ്പെഷ്യാലിറ്റി, സിസ്റ്റം പ്രോഗ്രാമിംഗ് മേഖലയിലെ ശാസ്ത്രീയ പ്രവർത്തനങ്ങൾ, കോഴ്സ് വർക്ക്, ഡിപ്ലോമകൾ എന്നിവയിൽ നല്ല വ്യാവസായിക പരിശീലനത്തിൽ ഞങ്ങൾക്ക് താൽപ്പര്യമുണ്ടാകാം. അതായത്, ഒരു കമ്മ്യൂണിറ്റി സംഘടിപ്പിക്കുന്നതിനുള്ള അടിസ്ഥാന നിയമങ്ങളിലൊന്ന് ഞങ്ങൾ പിന്തുടർന്നു: കമ്മ്യൂണിറ്റി അംഗങ്ങൾക്ക് എന്തെങ്കിലും ലഭിക്കണം, ഈ വില പങ്കാളിയുടെ സംഭാവനയുമായി പൊരുത്തപ്പെടണം.

മൂന്നാം കക്ഷി ഉപയോക്താക്കൾക്കായുള്ള തിരയലായിരുന്നു എംബോക്സിന്റെ അടുത്ത ഘട്ടം. ഉപയോക്താക്കൾ ഓപ്പൺ സോഴ്‌സ് കമ്മ്യൂണിറ്റിയിൽ പൂർണ്ണ പങ്കാളികളാണെന്ന് മനസ്സിലാക്കേണ്ടത് വളരെ പ്രധാനമാണ്. സാധാരണയായി ഡെവലപ്പർമാരേക്കാൾ കൂടുതൽ ഉപയോക്താക്കളുണ്ട്. ഒരു പ്രോജക്റ്റിലേക്ക് ഒരു സംഭാവകനാകാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, അവർ ആദ്യം അത് ഒരു തരത്തിൽ അല്ലെങ്കിൽ മറ്റൊന്നിൽ ഉപയോഗിക്കാൻ തുടങ്ങുന്നു.

എംബോക്‌സിന്റെ ആദ്യ ഉപയോക്താക്കൾ സൈദ്ധാന്തിക സൈബർനെറ്റിക്‌സ് വകുപ്പാണ്. ലെഗോ മൈൻഡ്‌സ്റ്റോമിനായി ഒരു ബദൽ ഫേംവെയർ സൃഷ്ടിക്കാൻ അവർ നിർദ്ദേശിച്ചു. അവർ ഇപ്പോഴും പ്രാദേശിക ഉപയോക്താക്കൾ ആയിരുന്നെങ്കിലും (ഞങ്ങൾക്ക് അവരെ നേരിട്ട് കാണാനും അവർക്ക് എന്താണ് വേണ്ടതെന്ന് ചർച്ച ചെയ്യാനും കഴിയും). എങ്കിലും അത് വളരെ നല്ല അനുഭവമായിരുന്നു. ഉദാഹരണത്തിന്, റോബോട്ടുകൾ രസകരവും ശ്രദ്ധ ആകർഷിക്കുന്നതുമായതിനാൽ മറ്റുള്ളവർക്ക് കാണിക്കാൻ കഴിയുന്ന ഡെമോകൾ ഞങ്ങൾ വികസിപ്പിച്ചെടുത്തു. തൽഫലമായി, എംബോക്സ് എന്താണെന്നും അത് എങ്ങനെ ഉപയോഗിക്കാമെന്നും ചോദിക്കാൻ തുടങ്ങിയ യഥാർത്ഥ മൂന്നാം കക്ഷി ഉപയോക്താക്കളെ ഞങ്ങൾക്ക് ലഭിച്ചു.

ഈ ഘട്ടത്തിൽ, ഡോക്യുമെന്റേഷനെക്കുറിച്ചും ഉപയോക്താക്കളുമായുള്ള ആശയവിനിമയത്തിനുള്ള മാർഗങ്ങളെക്കുറിച്ചും ഞങ്ങൾ ചിന്തിക്കേണ്ടതുണ്ട്. ഇല്ല, തീർച്ചയായും, ഈ സുപ്രധാന കാര്യങ്ങളെക്കുറിച്ച് ഞങ്ങൾ മുമ്പ് ചിന്തിച്ചു, പക്ഷേ അത് അകാലമായിരുന്നു, നല്ല ഫലം നൽകിയില്ല. പ്രഭാവം വളരെ നെഗറ്റീവ് ആയിരുന്നു. ഒന്നുരണ്ടു ഉദാഹരണങ്ങൾ പറയാം. ഞങ്ങൾ ഗൂഗിൾകോഡ് ഉപയോഗിച്ചു, അതിന്റെ വിക്കി ബഹുഭാഷാവാദത്തെ പിന്തുണയ്ക്കുന്നു. ഇംഗ്ലീഷിലും റഷ്യൻ ഭാഷയിലും മാത്രമല്ല, ജർമ്മൻ, സ്പാനിഷ് എന്നീ ഭാഷകളിലും ഞങ്ങൾ പേജുകൾ സൃഷ്ടിച്ചു. തൽഫലമായി, ഈ ഭാഷകളിൽ ചോദിക്കുമ്പോൾ ഇത് വളരെ പരിഹാസ്യമായി തോന്നുന്നു, പക്ഷേ ഞങ്ങൾക്ക് ഉത്തരം നൽകാൻ കഴിയില്ല. അല്ലെങ്കിൽ അവർ ഡോക്യുമെന്റേഷൻ എഴുതുന്നതിനും അഭിപ്രായമിടുന്നതിനുമുള്ള നിയമങ്ങൾ അവതരിപ്പിച്ചു, എന്നാൽ API പലപ്പോഴും ഗണ്യമായി മാറിയതിനാൽ, ഞങ്ങളുടെ ഡോക്യുമെന്റേഷൻ കാലഹരണപ്പെട്ടതാണെന്നും അത് സഹായിച്ചതിനേക്കാൾ തെറ്റിദ്ധരിപ്പിക്കുന്നതാണെന്നും തെളിഞ്ഞു.

തൽഫലമായി, ഞങ്ങളുടെ എല്ലാ ശ്രമങ്ങളും, തെറ്റായവ പോലും, ബാഹ്യ ഉപയോക്താക്കളുടെ രൂപത്തിലേക്ക് നയിച്ചു. ഒരു വാണിജ്യ ഉപഭോക്താവ് പോലും പ്രത്യക്ഷപ്പെട്ടു, അയാൾക്കായി സ്വന്തം ആർ‌ടി‌ഒഎസ് വികസിപ്പിക്കണമെന്ന് അദ്ദേഹം ആഗ്രഹിച്ചു. ഞങ്ങൾക്ക് അനുഭവപരിചയവും ചില അടിസ്ഥാന പ്രവർത്തനങ്ങളും ഉള്ളതിനാൽ ഞങ്ങൾ അത് വികസിപ്പിച്ചെടുത്തു. ഇവിടെ നിങ്ങൾ നല്ലതും ചീത്തയുമായ നിമിഷങ്ങളെക്കുറിച്ചാണ് സംസാരിക്കേണ്ടത്. ഞാൻ മോശമായവയിൽ നിന്ന് തുടങ്ങും. വാണിജ്യാടിസ്ഥാനത്തിൽ നിരവധി ഡവലപ്പർമാർ ഈ പ്രോജക്റ്റിൽ ഏർപ്പെട്ടിരിക്കുന്നതിനാൽ, കമ്മ്യൂണിറ്റി ഇതിനകം തന്നെ തികച്ചും അസ്ഥിരവും വിഭജിക്കപ്പെട്ടതുമാണ്, ഇത് തീർച്ചയായും പ്രോജക്റ്റിന്റെ വികസനത്തെ ബാധിക്കില്ല. പ്രോജക്റ്റിന്റെ ദിശ ഒരു വാണിജ്യ ഉപഭോക്താവാണ് സജ്ജീകരിച്ചത്, അദ്ദേഹത്തിന്റെ ലക്ഷ്യം പ്രോജക്റ്റിന്റെ കൂടുതൽ വികസനമായിരുന്നില്ല എന്നതാണ് ഒരു അധിക ഘടകം. കുറഞ്ഞത് ഇതായിരുന്നില്ല പ്രധാന ലക്ഷ്യം.

മറുവശത്ത്, നിരവധി പോസിറ്റീവ് വശങ്ങളും ഉണ്ടായിരുന്നു. ഞങ്ങൾക്ക് ശരിക്കും മൂന്നാം കക്ഷി ഉപയോക്താക്കളെ ലഭിച്ചു. ഇത് ഉപഭോക്താവ് മാത്രമല്ല, ഈ സംവിധാനം ഉദ്ദേശിച്ചിട്ടുള്ളവരും ആയിരുന്നു. പദ്ധതിയിൽ പങ്കെടുക്കാനുള്ള പ്രചോദനം വർദ്ധിച്ചു. എല്ലാത്തിനുമുപരി, നിങ്ങൾക്ക് രസകരമായ ഒരു ബിസിനസ്സിൽ നിന്ന് പണം സമ്പാദിക്കാൻ കഴിയുമെങ്കിൽ, അത് എല്ലായ്പ്പോഴും നല്ലതാണ്. ഏറ്റവും പ്രധാനമായി, ഉപഭോക്താക്കളിൽ നിന്ന് ഒരു ആഗ്രഹം ഞങ്ങൾ കേട്ടു, അത് അക്കാലത്ത് ഞങ്ങൾക്ക് ഭ്രാന്താണെന്ന് തോന്നി, എന്നാൽ ഇപ്പോൾ എംബോക്സിന്റെ പ്രധാന ആശയം ഇതാണ്, അതായത്, സിസ്റ്റത്തിൽ ഇതിനകം വികസിപ്പിച്ച കോഡ് ഉപയോഗിക്കുക. ഇപ്പോൾ എംബോക്സിന്റെ പ്രധാന ആശയം ലിനക്സ് ഇല്ലാതെ ലിനക്സ് സോഫ്റ്റ്വെയർ ഉപയോഗിക്കുക എന്നതാണ്. അതായത്, പ്രോജക്റ്റിന്റെ കൂടുതൽ വികസനത്തിന് സംഭാവന നൽകുന്ന പ്രധാന പോസിറ്റീവ് വശം പ്രോജക്റ്റ് മൂന്നാം കക്ഷി ഉപയോക്താക്കൾ ഉപയോഗിക്കുന്നുവെന്ന തിരിച്ചറിവാണ്, മാത്രമല്ല ഇത് അവരുടെ ചില പ്രശ്നങ്ങൾ പരിഹരിക്കുകയും വേണം.

ആ സമയത്ത്, എംബോക്സ് ഇതിനകം ഒരു വിദ്യാർത്ഥി പ്രോജക്റ്റിന്റെ പരിധിക്കപ്പുറമായിരുന്നു. വിദ്യാർത്ഥി മാതൃക അനുസരിച്ച് പ്രോജക്റ്റ് വികസിപ്പിക്കുന്നതിൽ പ്രധാന പരിമിതപ്പെടുത്തുന്ന ഘടകം പങ്കെടുക്കുന്നവരുടെ പ്രചോദനമാണ്. വിദ്യാർത്ഥികൾ പഠിക്കുമ്പോൾ പങ്കെടുക്കുന്നു, അവർ ബിരുദം നേടുമ്പോൾ, വ്യത്യസ്തമായ പ്രചോദനം ഉണ്ടായിരിക്കണം. പ്രചോദനം ദൃശ്യമാകുന്നില്ലെങ്കിൽ, വിദ്യാർത്ഥി പ്രോജക്റ്റിൽ പങ്കെടുക്കുന്നത് നിർത്തുന്നു. വിദ്യാർത്ഥികൾക്ക് ആദ്യം പരിശീലനം നൽകേണ്ടതുണ്ടെന്ന് ഞങ്ങൾ കണക്കിലെടുക്കുകയാണെങ്കിൽ, അവർ ബിരുദം നേടുമ്പോഴേക്കും അവർ നല്ല സ്പെഷ്യലിസ്റ്റുകളായി മാറുന്നു, പക്ഷേ പരിചയക്കുറവ് കാരണം പ്രോജക്റ്റിലേക്കുള്ള അവരുടെ സംഭാവന വളരെ വലുതല്ല.

പൊതുവേ, ഒരു ഓപ്പൺ സോഴ്സ് പ്രോജക്റ്റ് സൃഷ്ടിക്കുന്നതിനെക്കുറിച്ച് സംസാരിക്കാൻ ഞങ്ങളെ അനുവദിക്കുന്ന പ്രധാന പോയിന്റിലേക്ക് ഞങ്ങൾ സുഗമമായി നീങ്ങുന്നു - അതിന്റെ ഉപയോക്താക്കളുടെ പ്രശ്നങ്ങൾ പരിഹരിക്കുന്ന ഒരു ഉൽപ്പന്നം സൃഷ്ടിക്കുന്നു. ഞാൻ മുകളിൽ വിശദീകരിച്ചതുപോലെ, ഒരു ഓപ്പൺ സോഴ്സ് പ്രോജക്റ്റിന്റെ പ്രധാന സ്വത്ത് അതിന്റെ കമ്മ്യൂണിറ്റിയാണ്. മാത്രമല്ല, കമ്മ്യൂണിറ്റി അംഗങ്ങൾ പ്രാഥമികമായി ഉപയോക്താക്കളാണ്. എന്നാൽ ഉപയോഗിക്കാൻ ഒന്നുമില്ലാത്തപ്പോൾ അവ എവിടെ നിന്ന് വരുന്നു? അതിനാൽ, ഒരു നോൺ-ഓപ്പൺസോഴ്സ് പ്രോജക്റ്റ് പോലെ, നിങ്ങൾ ഒരു MVP (മിനിമം പ്രാപ്യമായ ഉൽപ്പന്നം) സൃഷ്ടിക്കുന്നതിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കേണ്ടതുണ്ട്, അത് ഉപയോക്താക്കൾക്ക് താൽപ്പര്യമുണ്ടെങ്കിൽ, പ്രോജക്റ്റിന് ചുറ്റും ഒരു കമ്മ്യൂണിറ്റി ദൃശ്യമാകും. കമ്മ്യൂണിറ്റി പിആർ വഴി മാത്രം ഒരു കമ്മ്യൂണിറ്റി സൃഷ്ടിക്കുന്നതിനോ ലോകത്തിലെ എല്ലാ ഭാഷകളിലും ഒരു വിക്കി എഴുതുന്നതിനോ അല്ലെങ്കിൽ ഗിത്തബിൽ ശരിയായ ജിറ്റ് വർക്ക്ഫ്ലോ ചെയ്യുന്നതിനോ നിങ്ങൾ ഏർപ്പെട്ടിരിക്കുകയാണെങ്കിൽ, പ്രോജക്റ്റിന്റെ പ്രാരംഭ ഘട്ടത്തിൽ ഇത് പ്രശ്നമാകാൻ സാധ്യതയില്ല. തീർച്ചയായും, ഉചിതമായ ഘട്ടങ്ങളിൽ ഇവ പ്രധാനമാണ് മാത്രമല്ല, ആവശ്യമായ കാര്യങ്ങളും.

ഉപസംഹാരമായി ഞാൻ ചൂണ്ടിക്കാണിക്കാൻ ആഗ്രഹിക്കുന്നു കമന്ററി, എന്റെ അഭിപ്രായത്തിൽ, ഒരു ഓപ്പൺ സോഴ്സ് പ്രോജക്റ്റിൽ നിന്നുള്ള ഉപയോക്തൃ പ്രതീക്ഷകൾ പ്രതിഫലിപ്പിക്കുന്നു:

ഈ OS-ലേക്ക് മാറുന്നതിനെക്കുറിച്ച് ഞാൻ ഗൗരവമായി ചിന്തിക്കുകയാണ് (കുറഞ്ഞത് ശ്രമിക്കുക. അവർ അത് സജീവമായി പിന്തുടരുകയും രസകരമായ കാര്യങ്ങൾ ചെയ്യുകയും ചെയ്യുന്നു).

പിഎസ് ഓൺ ടെക്ട്രെയിൻ ഞങ്ങൾക്ക് മൂന്ന് റിപ്പോർട്ടുകൾ ഉണ്ടാകും. ഒന്ന് ഓപ്പൺ സോഴ്സിനെ കുറിച്ചും രണ്ട് എംബെഡഡുകളെ കുറിച്ചും (ഒന്ന് പ്രായോഗികമാണ്). സ്റ്റാൻഡിൽ ഞങ്ങൾ പ്രോഗ്രാമിംഗ് മൈക്രോകൺട്രോളറുകൾ ഉപയോഗിച്ച് ഒരു മാസ്റ്റർ ക്ലാസ് നടത്തും എംബോക്സ്. പതിവുപോലെ, ഞങ്ങൾ ഹാർഡ്‌വെയർ കൊണ്ടുവന്ന് അത് പ്രോഗ്രാം ചെയ്യാൻ നിങ്ങളെ അനുവദിക്കും. അന്വേഷണവും മറ്റു പരിപാടികളും ഉണ്ടാകും. ഉത്സവത്തിന് വരൂ, ഞങ്ങളുടെ നിലപാടും, അത് രസകരമായിരിക്കും.

അവലംബം: www.habr.com