ਇੱਕ ਓਪਨ ਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਕਿਵੇਂ ਬਣਾਇਆ ਜਾਵੇ

ਇਸ ਹਫਤੇ ਸੇਂਟ ਪੀਟਰਸਬਰਗ ਵਿੱਚ ਇੱਕ ਆਈਟੀ ਤਿਉਹਾਰ ਆਯੋਜਿਤ ਕੀਤਾ ਜਾਵੇਗਾ TechTrain. ਬੁਲਾਰਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਰਿਚਰਡ ਸਟਾਲਮੈਨ ਹੋਵੇਗਾ। ਐਮਬਾਕਸ ਤਿਉਹਾਰ ਵਿੱਚ ਵੀ ਹਿੱਸਾ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਬੇਸ਼ੱਕ ਅਸੀਂ ਮੁਫਤ ਸੌਫਟਵੇਅਰ ਦੇ ਵਿਸ਼ੇ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਇਸ ਲਈ ਸਾਡੀ ਰਿਪੋਰਟਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਬੁਲਾਇਆ ਜਾਂਦਾ ਹੈ “ਵਿਦਿਆਰਥੀ ਸ਼ਿਲਪਕਾਰੀ ਤੋਂ ਓਪਨਸੋਰਸ ਪ੍ਰੋਜੈਕਟਾਂ ਤੱਕ। Embox ਅਨੁਭਵ". ਇਹ ਇੱਕ ਓਪਨ ਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਵਜੋਂ Embox ਦੇ ਵਿਕਾਸ ਦੇ ਇਤਿਹਾਸ ਨੂੰ ਸਮਰਪਿਤ ਹੋਵੇਗਾ। ਇਸ ਲੇਖ ਵਿੱਚ ਮੈਂ ਮੁੱਖ ਵਿਚਾਰਾਂ ਬਾਰੇ ਗੱਲ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ ਜੋ, ਮੇਰੇ ਵਿਚਾਰ ਵਿੱਚ, ਓਪਨਸੋਰਸ ਪ੍ਰੋਜੈਕਟਾਂ ਦੇ ਵਿਕਾਸ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦੇ ਹਨ. ਲੇਖ, ਰਿਪੋਰਟ ਵਾਂਗ, ਨਿੱਜੀ ਅਨੁਭਵ 'ਤੇ ਅਧਾਰਤ ਹੈ।

ਆਉ ਓਪਨਸੋਰਸ ਸ਼ਬਦ ਦੀ ਪਰਿਭਾਸ਼ਾ ਦੇ ਨਾਲ, ਕੁਝ ਸਧਾਰਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ। ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਇੱਕ ਓਪਨ ਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਹੈ ਜਿਸ ਵਿੱਚ ਇੱਕ ਲਾਇਸੈਂਸ ਹੈ ਜੋ ਪ੍ਰੋਜੈਕਟ ਦੇ ਸਰੋਤ ਕੋਡ ਤੱਕ ਪਹੁੰਚ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇੱਕ ਓਪਨ ਪ੍ਰੋਜੈਕਟ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੀਜੀ-ਧਿਰ ਦੇ ਡਿਵੈਲਪਰ ਤਬਦੀਲੀਆਂ ਕਰ ਸਕਦੇ ਹਨ. ਭਾਵ, ਜੇਕਰ ਕੋਈ ਕੰਪਨੀ ਜਾਂ ਡਿਵੈਲਪਰ ਆਪਣੇ ਉਤਪਾਦ ਦਾ ਕੋਡ, ਅੰਸ਼ਕ ਜਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਅਜੇ ਤੱਕ ਇਸ ਉਤਪਾਦ ਨੂੰ ਇੱਕ ਓਪਨਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਨਹੀਂ ਬਣਾਉਂਦਾ ਹੈ। ਅਤੇ ਅੰਤ ਵਿੱਚ, ਕਿਸੇ ਵੀ ਪ੍ਰੋਜੈਕਟ ਦੀ ਗਤੀਵਿਧੀ ਨੂੰ ਕਿਸੇ ਕਿਸਮ ਦੇ ਨਤੀਜੇ ਦੀ ਅਗਵਾਈ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਦੇ ਖੁੱਲੇਪਣ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਹ ਨਤੀਜਾ ਨਾ ਸਿਰਫ ਡਿਵੈਲਪਰਾਂ ਦੁਆਰਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ.

ਅਸੀਂ ਓਪਨ ਲਾਇਸੈਂਸਾਂ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਨਹੀਂ ਛੂਹਾਂਗੇ। ਇਹ ਬਹੁਤ ਵੱਡਾ ਅਤੇ ਗੁੰਝਲਦਾਰ ਵਿਸ਼ਾ ਹੈ ਜਿਸਦੀ ਡੂੰਘਾਈ ਨਾਲ ਜਾਂਚ ਦੀ ਲੋੜ ਹੈ। ਇਸ ਵਿਸ਼ੇ 'ਤੇ ਬਹੁਤ ਸਾਰੇ ਵਧੀਆ ਲੇਖ ਅਤੇ ਸਮੱਗਰੀ ਲਿਖੀ ਗਈ ਹੈ। ਪਰ ਕਿਉਂਕਿ ਮੈਂ ਖੁਦ ਕਾਪੀਰਾਈਟ ਦੇ ਖੇਤਰ ਵਿੱਚ ਮਾਹਰ ਨਹੀਂ ਹਾਂ, ਮੈਂ ਸਿਰਫ ਇਹ ਕਹਾਂਗਾ ਕਿ ਲਾਇਸੈਂਸ ਨੂੰ ਪ੍ਰੋਜੈਕਟ ਦੇ ਟੀਚਿਆਂ ਨੂੰ ਪੂਰਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ. ਉਦਾਹਰਨ ਲਈ, Embox ਲਈ GPL ਲਾਇਸੰਸ ਦੀ ਬਜਾਏ BSD ਦੀ ਚੋਣ ਅਚਾਨਕ ਨਹੀਂ ਸੀ।

ਇਹ ਤੱਥ ਕਿ ਇੱਕ ਓਪਨ ਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਤਬਦੀਲੀਆਂ ਕਰਨ ਅਤੇ ਓਪਨ ਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਦੇ ਵਿਕਾਸ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਦੀ ਯੋਗਤਾ ਪ੍ਰਦਾਨ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਪ੍ਰੋਜੈਕਟ ਵੰਡਿਆ ਗਿਆ ਹੈ। ਕੇਂਦਰੀਕ੍ਰਿਤ ਪ੍ਰਬੰਧਨ ਵਾਲੇ ਪ੍ਰੋਜੈਕਟ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਇਸਦਾ ਪ੍ਰਬੰਧਨ, ਅਖੰਡਤਾ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਕਾਇਮ ਰੱਖਣਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੈ। ਇੱਕ ਵਾਜਬ ਸਵਾਲ ਉੱਠਦਾ ਹੈ: ਪ੍ਰੋਜੈਕਟ ਕਿਉਂ ਖੁੱਲ੍ਹਦੇ ਹਨ? ਇਸ ਦਾ ਜਵਾਬ ਵਪਾਰਕ ਵਿਵਹਾਰਕਤਾ ਦੇ ਖੇਤਰ ਵਿੱਚ ਹੈ; ਪ੍ਰੋਜੈਕਟਾਂ ਦੀ ਇੱਕ ਖਾਸ ਸ਼੍ਰੇਣੀ ਲਈ, ਇਸ ਪਹੁੰਚ ਦੇ ਲਾਭ ਲਾਗਤਾਂ ਤੋਂ ਵੱਧ ਹਨ। ਭਾਵ, ਇਹ ਸਾਰੇ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ ਢੁਕਵਾਂ ਨਹੀਂ ਹੈ ਅਤੇ ਇੱਕ ਖੁੱਲ੍ਹੀ ਪਹੁੰਚ ਆਮ ਤੌਰ 'ਤੇ ਸਵੀਕਾਰਯੋਗ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਖੁੱਲੇ ਸਿਧਾਂਤ ਦੇ ਅਧਾਰ ਤੇ ਇੱਕ ਪਾਵਰ ਪਲਾਂਟ ਜਾਂ ਇੱਕ ਹਵਾਈ ਜਹਾਜ਼ ਲਈ ਇੱਕ ਨਿਯੰਤਰਣ ਪ੍ਰਣਾਲੀ ਵਿਕਸਿਤ ਕਰਨ ਦੀ ਕਲਪਨਾ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ। ਨਹੀਂ, ਬੇਸ਼ਕ, ਅਜਿਹੇ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਖੁੱਲੇ ਪ੍ਰੋਜੈਕਟਾਂ ਦੇ ਅਧਾਰ ਤੇ ਮੋਡੀਊਲ ਸ਼ਾਮਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਕਿਉਂਕਿ ਇਹ ਬਹੁਤ ਸਾਰੇ ਫਾਇਦੇ ਪ੍ਰਦਾਨ ਕਰੇਗਾ. ਪਰ ਕਿਸੇ ਨੂੰ ਅੰਤਿਮ ਉਤਪਾਦ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ. ਭਾਵੇਂ ਸਿਸਟਮ ਪੂਰੀ ਤਰ੍ਹਾਂ ਓਪਨ ਪ੍ਰੋਜੈਕਟਾਂ ਦੇ ਕੋਡ 'ਤੇ ਅਧਾਰਤ ਹੈ, ਡਿਵੈਲਪਰ, ਹਰ ਚੀਜ਼ ਨੂੰ ਇੱਕ ਸਿਸਟਮ ਵਿੱਚ ਪੈਕ ਕਰਕੇ ਅਤੇ ਖਾਸ ਬਿਲਡ ਅਤੇ ਸੈਟਿੰਗਾਂ ਬਣਾ ਕੇ, ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਇਸਨੂੰ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਕੋਡ ਜਨਤਕ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਹੋ ਸਕਦਾ ਹੈ।

ਓਪਨ ਸੋਰਸ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਬਣਾਉਣ ਜਾਂ ਉਹਨਾਂ ਵਿੱਚ ਯੋਗਦਾਨ ਪਾਉਣ ਤੋਂ ਇਹਨਾਂ ਪ੍ਰਣਾਲੀਆਂ ਲਈ ਬਹੁਤ ਸਾਰੇ ਲਾਭ ਵੀ ਹਨ। ਜਿਵੇਂ ਕਿ ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਕਿਹਾ ਹੈ, ਅੰਤ ਸਿਸਟਮ ਕੋਡ ਜਨਤਕ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਰਹਿ ਸਕਦਾ ਹੈ। ਕਿਉਂ, ਕਿਉਂਕਿ ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਇਹ ਸੰਭਾਵਨਾ ਨਹੀਂ ਹੈ ਕਿ ਸਿਸਟਮ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਕਿਸੇ ਕੋਲ ਵੀ ਉਹੀ ਜਹਾਜ਼ ਹੋਵੇਗਾ. ਇਹ ਸੱਚ ਹੈ, ਪਰ ਕੋਈ ਅਜਿਹਾ ਵਿਅਕਤੀ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਕੋਡ ਦੇ ਕੁਝ ਭਾਗਾਂ ਦੀ ਜਾਂਚ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੋਵੇ, ਜਾਂ, ਉਦਾਹਰਨ ਲਈ, ਕਿਸੇ ਨੂੰ ਪਤਾ ਲੱਗ ਸਕਦਾ ਹੈ ਕਿ ਵਰਤੀ ਜਾ ਰਹੀ ਲਾਇਬ੍ਰੇਰੀ ਨੂੰ ਬਿਲਕੁਲ ਸਹੀ ਢੰਗ ਨਾਲ ਸੰਰਚਿਤ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ।

ਇੱਕ ਹੋਰ ਵੀ ਵੱਡਾ ਲਾਭ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਜੇਕਰ ਕੰਪਨੀ ਸਿਸਟਮ ਦੇ ਕੁਝ ਬੁਨਿਆਦੀ ਹਿੱਸੇ ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਕਿਸੇ ਕਿਸਮ ਦੇ ਡੇਟਾ ਐਕਸਚੇਂਜ ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਸਮਰਥਨ ਕਰਨ ਲਈ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਭਾਵੇਂ ਪ੍ਰੋਟੋਕੋਲ ਇੱਕ ਦਿੱਤੇ ਵਿਸ਼ੇ ਖੇਤਰ ਲਈ ਵਿਸ਼ੇਸ਼ ਹੈ, ਤੁਸੀਂ ਇਸ ਖੇਤਰ ਦੀਆਂ ਹੋਰ ਕੰਪਨੀਆਂ ਨਾਲ ਸਿਸਟਮ ਦੇ ਇਸ ਹਿੱਸੇ ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਦੇ ਖਰਚੇ ਸਾਂਝੇ ਕਰ ਸਕਦੇ ਹੋ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਮਾਹਰ ਜੋ ਜਨਤਕ ਡੋਮੇਨ ਵਿੱਚ ਸਿਸਟਮ ਦੇ ਇਸ ਹਿੱਸੇ ਦਾ ਅਧਿਐਨ ਕਰ ਸਕਦੇ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਇਸਦੀ ਪ੍ਰਭਾਵੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਬਹੁਤ ਘੱਟ ਸਮਾਂ ਚਾਹੀਦਾ ਹੈ। ਅਤੇ ਅੰਤ ਵਿੱਚ, ਇੱਕ ਟੁਕੜੇ ਨੂੰ ਇੱਕ ਸੁਤੰਤਰ ਹਸਤੀ ਵਿੱਚ ਵੱਖ ਕਰਨਾ ਜੋ ਤੀਜੀ-ਧਿਰ ਦੇ ਡਿਵੈਲਪਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਸਾਨੂੰ ਇਸ ਹਿੱਸੇ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਸਾਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ API ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਨ, ਦਸਤਾਵੇਜ਼ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਮੈਂ ਟੈਸਟ ਕਵਰੇਜ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਬਾਰੇ ਵੀ ਗੱਲ ਨਹੀਂ ਕਰ ਰਿਹਾ ਹਾਂ।

ਇੱਕ ਕੰਪਨੀ ਓਪਨ-ਸੋਰਸ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਬਣਾਏ ਬਿਨਾਂ ਵਪਾਰਕ ਲਾਭ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੀ ਹੈ; ਕੰਪਨੀ ਵਿੱਚ ਵਰਤੇ ਜਾਂਦੇ ਤੀਜੀ-ਧਿਰ ਦੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਹਿੱਸਾ ਲੈਣ ਲਈ ਇਸਦੇ ਮਾਹਰਾਂ ਲਈ ਇਹ ਕਾਫ਼ੀ ਹੈ। ਆਖ਼ਰਕਾਰ, ਸਾਰੇ ਫਾਇਦੇ ਰਹਿੰਦੇ ਹਨ: ਕਰਮਚਾਰੀ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਬਿਹਤਰ ਜਾਣਦੇ ਹਨ, ਇਸਲਈ ਉਹ ਇਸਦੀ ਵਰਤੋਂ ਵਧੇਰੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਕਰਦੇ ਹਨ, ਕੰਪਨੀ ਪ੍ਰੋਜੈਕਟ ਦੇ ਵਿਕਾਸ ਦੀ ਦਿਸ਼ਾ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰ ਸਕਦੀ ਹੈ, ਅਤੇ ਰੈਡੀਮੇਡ, ਡੀਬੱਗ ਕੋਡ ਦੀ ਵਰਤੋਂ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਕੰਪਨੀ ਦੀਆਂ ਲਾਗਤਾਂ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ।

ਓਪਨਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਬਣਾਉਣ ਦੇ ਫਾਇਦੇ ਇੱਥੇ ਖਤਮ ਨਹੀਂ ਹੁੰਦੇ ਹਨ. ਆਉ ਵਪਾਰ ਦੇ ਅਜਿਹੇ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸੇ ਨੂੰ ਮਾਰਕੀਟਿੰਗ ਦੇ ਰੂਪ ਵਿੱਚ ਲੈਂਦੇ ਹਾਂ. ਉਸਦੇ ਲਈ, ਇਹ ਇੱਕ ਬਹੁਤ ਵਧੀਆ ਸੈਂਡਬੌਕਸ ਹੈ ਜੋ ਉਸਨੂੰ ਮਾਰਕੀਟ ਲੋੜਾਂ ਦਾ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਮੁਲਾਂਕਣ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

ਅਤੇ ਬੇਸ਼ੱਕ, ਸਾਨੂੰ ਇਹ ਨਹੀਂ ਭੁੱਲਣਾ ਚਾਹੀਦਾ ਕਿ ਇੱਕ ਓਪਨਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਆਪਣੇ ਆਪ ਨੂੰ ਕਿਸੇ ਵੀ ਵਿਸ਼ੇਸ਼ਤਾ ਦੇ ਕੈਰੀਅਰ ਵਜੋਂ ਘੋਸ਼ਿਤ ਕਰਨ ਦਾ ਇੱਕ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕਾ ਹੈ। ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਇਹ ਮਾਰਕੀਟ ਵਿੱਚ ਦਾਖਲ ਹੋਣ ਦਾ ਇੱਕੋ ਇੱਕ ਤਰੀਕਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, Embox ਇੱਕ RTOS ਬਣਾਉਣ ਲਈ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਵਜੋਂ ਸ਼ੁਰੂ ਹੋਇਆ। ਸ਼ਾਇਦ ਇਹ ਦੱਸਣ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ ਕਿ ਬਹੁਤ ਸਾਰੇ ਮੁਕਾਬਲੇ ਹਨ. ਇੱਕ ਕਮਿਊਨਿਟੀ ਬਣਾਉਣ ਤੋਂ ਬਿਨਾਂ, ਸਾਡੇ ਕੋਲ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਅੰਤਮ ਉਪਭੋਗਤਾ ਤੱਕ ਲਿਆਉਣ ਲਈ ਲੋੜੀਂਦੇ ਸਰੋਤ ਨਹੀਂ ਹੋਣਗੇ, ਯਾਨੀ ਤੀਜੀ-ਧਿਰ ਦੇ ਵਿਕਾਸਕਾਰਾਂ ਲਈ ਪ੍ਰੋਜੈਕਟ ਦੀ ਵਰਤੋਂ ਸ਼ੁਰੂ ਕਰਨ ਲਈ।

ਇੱਕ ਓਪਨਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਭਾਈਚਾਰਾ ਮੁੱਖ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਪ੍ਰੋਜੈਕਟ ਪ੍ਰਬੰਧਨ ਲਾਗਤਾਂ ਨੂੰ ਮਹੱਤਵਪੂਰਣ ਰੂਪ ਵਿੱਚ ਘਟਾਉਣ, ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਅਤੇ ਸਮਰਥਨ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ. ਅਸੀਂ ਕਹਿ ਸਕਦੇ ਹਾਂ ਕਿ ਕਮਿਊਨਿਟੀ ਤੋਂ ਬਿਨਾਂ ਕੋਈ ਵੀ ਓਪਨਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਨਹੀਂ ਹੈ.

ਇੱਕ ਓਪਨ ਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਕਮਿਊਨਿਟੀ ਨੂੰ ਕਿਵੇਂ ਬਣਾਉਣਾ ਅਤੇ ਪ੍ਰਬੰਧਿਤ ਕਰਨਾ ਹੈ ਇਸ ਬਾਰੇ ਬਹੁਤ ਸਾਰੀ ਸਮੱਗਰੀ ਲਿਖੀ ਗਈ ਹੈ। ਪਹਿਲਾਂ ਤੋਂ ਜਾਣੇ-ਪਛਾਣੇ ਤੱਥਾਂ ਨੂੰ ਦੁਬਾਰਾ ਨਾ ਦੱਸਣ ਲਈ, ਮੈਂ Embox ਦੇ ਅਨੁਭਵ 'ਤੇ ਧਿਆਨ ਦੇਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗਾ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਭਾਈਚਾਰਾ ਬਣਾਉਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਇੱਕ ਬਹੁਤ ਹੀ ਦਿਲਚਸਪ ਮੁੱਦਾ ਹੈ. ਭਾਵ, ਬਹੁਤ ਸਾਰੇ ਦੱਸਦੇ ਹਨ ਕਿ ਇੱਕ ਮੌਜੂਦਾ ਸਮਾਜ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਬੰਧਿਤ ਕਰਨਾ ਹੈ, ਪਰ ਇਸਦੀ ਰਚਨਾ ਦੇ ਪਲਾਂ ਨੂੰ ਕਈ ਵਾਰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਇਸ ਨੂੰ ਇੱਕ ਦਿੱਤਾ ਗਿਆ ਹੈ।

ਇੱਕ ਓਪਨਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਕਮਿਊਨਿਟੀ ਬਣਾਉਣ ਵੇਲੇ ਮੁੱਖ ਨਿਯਮ ਇਹ ਹੈ ਕਿ ਕੋਈ ਨਿਯਮ ਨਹੀਂ ਹਨ. ਮੇਰਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਥੇ ਕੋਈ ਵਿਆਪਕ ਨਿਯਮ ਨਹੀਂ ਹਨ, ਜਿਵੇਂ ਕਿ ਕੋਈ ਸਿਲਵਰ ਬੁਲੇਟ ਨਹੀਂ ਹੈ, ਜੇਕਰ ਸਿਰਫ ਇਸ ਲਈ ਕਿ ਪ੍ਰੋਜੈਕਟ ਬਹੁਤ ਵੱਖਰੇ ਹਨ. ਇਹ ਅਸੰਭਵ ਹੈ ਕਿ ਤੁਸੀਂ js ਲੌਗਿੰਗ ਲਾਇਬ੍ਰੇਰੀ ਅਤੇ ਕੁਝ ਉੱਚ ਵਿਸ਼ੇਸ਼ ਡਰਾਈਵਰ ਲਈ ਕਮਿਊਨਿਟੀ ਬਣਾਉਂਦੇ ਸਮੇਂ ਉਹੀ ਨਿਯਮਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਪ੍ਰੋਜੈਕਟ (ਅਤੇ ਇਸ ਲਈ ਕਮਿਊਨਿਟੀ) ਦੇ ਵਿਕਾਸ ਦੇ ਵੱਖ-ਵੱਖ ਪੜਾਵਾਂ 'ਤੇ, ਨਿਯਮ ਬਦਲਦੇ ਹਨ.

Embox ਇੱਕ ਵਿਦਿਆਰਥੀ ਪ੍ਰੋਜੈਕਟ ਦੇ ਰੂਪ ਵਿੱਚ ਸ਼ੁਰੂ ਹੋਇਆ ਕਿਉਂਕਿ ਇਸਦੀ ਸਿਸਟਮ ਪ੍ਰੋਗਰਾਮਿੰਗ ਵਿਭਾਗ ਦੇ ਵਿਦਿਆਰਥੀਆਂ ਤੱਕ ਪਹੁੰਚ ਸੀ। ਅਸਲ ਵਿੱਚ, ਅਸੀਂ ਕਿਸੇ ਹੋਰ ਸਮਾਜ ਵਿੱਚ ਦਾਖਲ ਹੋ ਰਹੇ ਸੀ। ਅਸੀਂ ਇਸ ਭਾਈਚਾਰੇ ਦੇ ਭਾਗੀਦਾਰਾਂ, ਵਿਦਿਆਰਥੀਆਂ, ਉਹਨਾਂ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ, ਸਿਸਟਮ ਪ੍ਰੋਗਰਾਮਿੰਗ, ਕੋਰਸਵਰਕ ਅਤੇ ਡਿਪਲੋਮੇ ਦੇ ਖੇਤਰ ਵਿੱਚ ਵਿਗਿਆਨਕ ਕੰਮ ਵਿੱਚ ਚੰਗੇ ਉਦਯੋਗਿਕ ਅਭਿਆਸ ਵਿੱਚ ਦਿਲਚਸਪੀ ਲੈ ਸਕਦੇ ਹਾਂ। ਭਾਵ, ਅਸੀਂ ਇੱਕ ਕਮਿਊਨਿਟੀ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਦੇ ਇੱਕ ਬੁਨਿਆਦੀ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕੀਤੀ ਹੈ: ਕਮਿਊਨਿਟੀ ਦੇ ਮੈਂਬਰਾਂ ਨੂੰ ਕੁਝ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਹ ਕੀਮਤ ਭਾਗੀਦਾਰ ਦੇ ਯੋਗਦਾਨ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।

Embox ਲਈ ਅਗਲਾ ਪੜਾਅ ਤੀਜੀ-ਧਿਰ ਦੇ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਖੋਜ ਸੀ। ਇਹ ਸਮਝਣਾ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਉਪਭੋਗਤਾ ਓਪਨਸੋਰਸ ਕਮਿਊਨਿਟੀ ਵਿੱਚ ਪੂਰੇ ਭਾਗੀਦਾਰ ਹਨ। ਆਮ ਤੌਰ 'ਤੇ ਡਿਵੈਲਪਰਾਂ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਉਪਭੋਗਤਾ ਹੁੰਦੇ ਹਨ. ਅਤੇ ਕਿਸੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਯੋਗਦਾਨ ਪਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋਣ ਲਈ, ਉਹ ਪਹਿਲਾਂ ਇਸਨੂੰ ਕਿਸੇ ਨਾ ਕਿਸੇ ਤਰੀਕੇ ਨਾਲ ਵਰਤਣਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ।

Embox ਦੇ ਪਹਿਲੇ ਉਪਭੋਗਤਾ ਸਿਧਾਂਤਕ ਸਾਈਬਰਨੇਟਿਕਸ ਵਿਭਾਗ ਸਨ। ਉਹਨਾਂ ਨੇ Lego Mindstorm ਲਈ ਇੱਕ ਵਿਕਲਪਿਕ ਫਰਮਵੇਅਰ ਬਣਾਉਣ ਦਾ ਸੁਝਾਅ ਦਿੱਤਾ। ਅਤੇ ਹਾਲਾਂਕਿ ਇਹ ਅਜੇ ਵੀ ਸਥਾਨਕ ਉਪਭੋਗਤਾ ਸਨ (ਅਸੀਂ ਉਹਨਾਂ ਨਾਲ ਵਿਅਕਤੀਗਤ ਤੌਰ 'ਤੇ ਮਿਲ ਸਕਦੇ ਹਾਂ ਅਤੇ ਚਰਚਾ ਕਰ ਸਕਦੇ ਹਾਂ ਕਿ ਉਹ ਕੀ ਚਾਹੁੰਦੇ ਹਨ)। ਪਰ ਇਹ ਅਜੇ ਵੀ ਬਹੁਤ ਵਧੀਆ ਅਨੁਭਵ ਸੀ। ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਅਜਿਹੇ ਡੈਮੋ ਵਿਕਸਿਤ ਕੀਤੇ ਹਨ ਜੋ ਦੂਜਿਆਂ ਨੂੰ ਦਿਖਾਏ ਜਾ ਸਕਦੇ ਹਨ, ਕਿਉਂਕਿ ਰੋਬੋਟ ਮਜ਼ੇਦਾਰ ਹੁੰਦੇ ਹਨ ਅਤੇ ਧਿਆਨ ਖਿੱਚਦੇ ਹਨ। ਨਤੀਜੇ ਵਜੋਂ, ਸਾਨੂੰ ਸੱਚਮੁੱਚ ਤੀਜੀ-ਧਿਰ ਦੇ ਉਪਭੋਗਤਾ ਮਿਲੇ ਜਿਨ੍ਹਾਂ ਨੇ ਪੁੱਛਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ ਕਿ Embox ਕੀ ਹੈ ਅਤੇ ਇਸਨੂੰ ਕਿਵੇਂ ਵਰਤਣਾ ਹੈ।

ਇਸ ਪੜਾਅ 'ਤੇ, ਸਾਨੂੰ ਦਸਤਾਵੇਜ਼ਾਂ ਬਾਰੇ, ਉਪਭੋਗਤਾਵਾਂ ਨਾਲ ਸੰਚਾਰ ਦੇ ਸਾਧਨਾਂ ਬਾਰੇ ਸੋਚਣਾ ਪਿਆ। ਨਹੀਂ, ਬੇਸ਼ੱਕ, ਅਸੀਂ ਪਹਿਲਾਂ ਇਹਨਾਂ ਮਹੱਤਵਪੂਰਨ ਚੀਜ਼ਾਂ ਬਾਰੇ ਸੋਚਿਆ ਸੀ, ਪਰ ਇਹ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਸੀ ਅਤੇ ਸਕਾਰਾਤਮਕ ਪ੍ਰਭਾਵ ਨਹੀਂ ਦਿੰਦਾ ਸੀ. ਪ੍ਰਭਾਵ ਕਾਫ਼ੀ ਨਕਾਰਾਤਮਕ ਸੀ. ਮੈਂ ਤੁਹਾਨੂੰ ਕੁਝ ਉਦਾਹਰਣਾਂ ਦਿੰਦਾ ਹਾਂ। ਅਸੀਂ ਗੂਗਲਕੋਡ ਦੀ ਵਰਤੋਂ ਕੀਤੀ, ਜਿਸਦਾ ਵਿਕੀ ਬਹੁ-ਭਾਸ਼ਾਈਵਾਦ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਅਸੀਂ ਕਈ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਪੰਨੇ ਬਣਾਏ, ਨਾ ਸਿਰਫ਼ ਅੰਗਰੇਜ਼ੀ ਅਤੇ ਰੂਸੀ, ਜਿਸ ਵਿੱਚ ਅਸੀਂ ਮੁਸ਼ਕਿਲ ਨਾਲ ਸੰਚਾਰ ਕਰ ਸਕਦੇ ਸੀ, ਸਗੋਂ ਜਰਮਨ ਅਤੇ ਸਪੈਨਿਸ਼ ਵੀ। ਨਤੀਜੇ ਵਜੋਂ, ਇਹਨਾਂ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਪੁੱਛੇ ਜਾਣ 'ਤੇ ਇਹ ਬਹੁਤ ਹਾਸੋਹੀਣੀ ਲੱਗਦੀ ਹੈ, ਪਰ ਅਸੀਂ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦੇ। ਜਾਂ ਉਹਨਾਂ ਨੇ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਲਿਖਣ ਅਤੇ ਟਿੱਪਣੀ ਕਰਨ ਬਾਰੇ ਨਿਯਮ ਪੇਸ਼ ਕੀਤੇ, ਪਰ ਕਿਉਂਕਿ API ਅਕਸਰ ਅਤੇ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਬਦਲਦਾ ਹੈ, ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਸਾਡੇ ਦਸਤਾਵੇਜ਼ ਪੁਰਾਣੇ ਸਨ ਅਤੇ ਇਸਦੀ ਮਦਦ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਗੁੰਮਰਾਹਕੁੰਨ ਸਨ।

ਨਤੀਜੇ ਵਜੋਂ, ਸਾਡੇ ਸਾਰੇ ਯਤਨ, ਇੱਥੋਂ ਤੱਕ ਕਿ ਗਲਤ ਵੀ, ਬਾਹਰੀ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਦਿੱਖ ਵੱਲ ਲੈ ਗਏ। ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਇੱਕ ਵਪਾਰਕ ਗਾਹਕ ਵੀ ਪ੍ਰਗਟ ਹੋਇਆ ਜੋ ਚਾਹੁੰਦਾ ਸੀ ਕਿ ਉਸਦਾ ਆਪਣਾ RTOS ਉਸਦੇ ਲਈ ਵਿਕਸਤ ਕੀਤਾ ਜਾਵੇ। ਅਤੇ ਅਸੀਂ ਇਸਨੂੰ ਵਿਕਸਿਤ ਕੀਤਾ ਹੈ ਕਿਉਂਕਿ ਸਾਡੇ ਕੋਲ ਤਜਰਬਾ ਹੈ ਅਤੇ ਕੁਝ ਆਧਾਰ ਹੈ। ਇੱਥੇ ਤੁਹਾਨੂੰ ਚੰਗੇ ਪਲ ਅਤੇ ਮਾੜੇ ਦੋਵਾਂ ਬਾਰੇ ਗੱਲ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਮੈਂ ਬੁਰੇ ਲੋਕਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰਾਂਗਾ। ਕਿਉਂਕਿ ਬਹੁਤ ਸਾਰੇ ਡਿਵੈਲਪਰ ਇੱਕ ਵਪਾਰਕ ਆਧਾਰ 'ਤੇ ਇਸ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਸ਼ਾਮਲ ਸਨ, ਭਾਈਚਾਰਾ ਪਹਿਲਾਂ ਹੀ ਕਾਫ਼ੀ ਅਸਥਿਰ ਅਤੇ ਵੰਡਿਆ ਹੋਇਆ ਸੀ, ਜੋ ਬੇਸ਼ਕ ਪ੍ਰੋਜੈਕਟ ਦੇ ਵਿਕਾਸ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰ ਸਕਦਾ ਸੀ। ਇੱਕ ਵਾਧੂ ਕਾਰਕ ਇਹ ਸੀ ਕਿ ਪ੍ਰੋਜੈਕਟ ਦੀ ਦਿਸ਼ਾ ਇੱਕ ਵਪਾਰਕ ਗਾਹਕ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਕੀਤੀ ਗਈ ਸੀ, ਅਤੇ ਉਸਦਾ ਟੀਚਾ ਪ੍ਰੋਜੈਕਟ ਦਾ ਹੋਰ ਵਿਕਾਸ ਨਹੀਂ ਸੀ। ਘੱਟੋ-ਘੱਟ ਇਹ ਮੁੱਖ ਟੀਚਾ ਨਹੀਂ ਸੀ।

ਦੂਜੇ ਪਾਸੇ, ਕਈ ਸਕਾਰਾਤਮਕ ਪਹਿਲੂ ਸਨ. ਸਾਨੂੰ ਸੱਚਮੁੱਚ ਤੀਜੀ-ਧਿਰ ਦੇ ਉਪਭੋਗਤਾ ਮਿਲੇ ਹਨ। ਇਹ ਸਿਰਫ਼ ਗਾਹਕ ਹੀ ਨਹੀਂ ਸੀ, ਸਗੋਂ ਉਹ ਵੀ ਸਨ ਜਿਨ੍ਹਾਂ ਲਈ ਇਹ ਸਿਸਟਮ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ। ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਹਿੱਸਾ ਲੈਣ ਦੀ ਪ੍ਰੇਰਣਾ ਵਧੀ ਹੈ। ਆਖਰਕਾਰ, ਜੇ ਤੁਸੀਂ ਇੱਕ ਦਿਲਚਸਪ ਕਾਰੋਬਾਰ ਤੋਂ ਵੀ ਪੈਸਾ ਕਮਾ ਸਕਦੇ ਹੋ, ਤਾਂ ਇਹ ਹਮੇਸ਼ਾ ਵਧੀਆ ਹੁੰਦਾ ਹੈ. ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ, ਅਸੀਂ ਗਾਹਕਾਂ ਤੋਂ ਇੱਕ ਇੱਛਾ ਸੁਣੀ, ਜੋ ਉਸ ਸਮੇਂ ਸਾਡੇ ਲਈ ਪਾਗਲ ਲੱਗਦੀ ਸੀ, ਪਰ ਜੋ ਕਿ ਹੁਣ Embox ਦਾ ਮੁੱਖ ਵਿਚਾਰ ਹੈ, ਅਰਥਾਤ, ਸਿਸਟਮ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਵਿਕਸਤ ਕੋਡ ਦੀ ਵਰਤੋਂ ਕਰਨਾ. ਹੁਣ Embox ਦਾ ਮੁੱਖ ਵਿਚਾਰ ਲੀਨਕਸ ਤੋਂ ਬਿਨਾਂ ਲੀਨਕਸ ਸੌਫਟਵੇਅਰ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਹੈ। ਭਾਵ, ਪ੍ਰੋਜੈਕਟ ਦੇ ਹੋਰ ਵਿਕਾਸ ਵਿੱਚ ਯੋਗਦਾਨ ਪਾਉਣ ਵਾਲਾ ਮੁੱਖ ਸਕਾਰਾਤਮਕ ਪਹਿਲੂ ਇਹ ਅਹਿਸਾਸ ਸੀ ਕਿ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਤੀਜੀ-ਧਿਰ ਦੇ ਉਪਭੋਗਤਾਵਾਂ ਦੁਆਰਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਉਹਨਾਂ ਦੀਆਂ ਕੁਝ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ.

ਉਸ ਸਮੇਂ, Embox ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਵਿਦਿਆਰਥੀ ਪ੍ਰੋਜੈਕਟ ਦੇ ਦਾਇਰੇ ਤੋਂ ਪਰੇ ਚਲਾ ਗਿਆ ਸੀ। ਵਿਦਿਆਰਥੀ ਮਾਡਲ ਦੇ ਅਨੁਸਾਰ ਪ੍ਰੋਜੈਕਟ ਦੇ ਵਿਕਾਸ ਵਿੱਚ ਮੁੱਖ ਸੀਮਤ ਕਾਰਕ ਭਾਗੀਦਾਰਾਂ ਦੀ ਪ੍ਰੇਰਣਾ ਹੈ। ਵਿਦਿਆਰਥੀ ਪੜ੍ਹਦੇ ਸਮੇਂ ਹਿੱਸਾ ਲੈਂਦੇ ਹਨ, ਅਤੇ ਜਦੋਂ ਉਹ ਗ੍ਰੈਜੂਏਟ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਇੱਕ ਵੱਖਰੀ ਪ੍ਰੇਰਣਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਜੇਕਰ ਪ੍ਰੇਰਣਾ ਦਿਖਾਈ ਨਹੀਂ ਦਿੰਦੀ, ਤਾਂ ਵਿਦਿਆਰਥੀ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਹਿੱਸਾ ਲੈਣਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਜੇਕਰ ਅਸੀਂ ਇਸ ਗੱਲ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹਾਂ ਕਿ ਵਿਦਿਆਰਥੀਆਂ ਨੂੰ ਪਹਿਲਾਂ ਸਿਖਲਾਈ ਦੇਣ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਉਹ ਗ੍ਰੈਜੂਏਟ ਹੋਣ ਦੇ ਸਮੇਂ ਤੱਕ ਚੰਗੇ ਮਾਹਰ ਬਣ ਜਾਂਦੇ ਹਨ, ਪਰ ਤਜਰਬੇਕਾਰਤਾ ਦੇ ਕਾਰਨ, ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਉਹਨਾਂ ਦਾ ਯੋਗਦਾਨ ਬਹੁਤ ਵੱਡਾ ਨਹੀਂ ਹੈ।

ਆਮ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਆਸਾਨੀ ਨਾਲ ਮੁੱਖ ਬਿੰਦੂ ਵੱਲ ਵਧਦੇ ਹਾਂ ਜੋ ਸਾਨੂੰ ਇੱਕ ਓਪਨਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਬਣਾਉਣ ਬਾਰੇ ਗੱਲ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ - ਇੱਕ ਉਤਪਾਦ ਬਣਾਉਣਾ ਜੋ ਇਸਦੇ ਉਪਭੋਗਤਾਵਾਂ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰੇਗਾ। ਜਿਵੇਂ ਕਿ ਮੈਂ ਉੱਪਰ ਦੱਸਿਆ ਹੈ, ਇੱਕ ਓਪਨਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਦੀ ਮੁੱਖ ਸੰਪਤੀ ਇਸਦਾ ਭਾਈਚਾਰਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਕਮਿਊਨਿਟੀ ਮੈਂਬਰ ਮੁੱਖ ਤੌਰ 'ਤੇ ਉਪਭੋਗਤਾ ਹਨ। ਪਰ ਜਦੋਂ ਵਰਤਣ ਲਈ ਕੁਝ ਨਹੀਂ ਹੈ ਤਾਂ ਉਹ ਕਿੱਥੋਂ ਆਉਂਦੇ ਹਨ? ਇਸ ਲਈ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ, ਜਿਵੇਂ ਕਿ ਇੱਕ ਗੈਰ-ਓਪਨਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਦੇ ਨਾਲ, ਤੁਹਾਨੂੰ ਇੱਕ MVP (ਘੱਟੋ-ਘੱਟ ਵਿਹਾਰਕ ਉਤਪਾਦ) ਬਣਾਉਣ 'ਤੇ ਧਿਆਨ ਦੇਣ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਜੇਕਰ ਇਹ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਦਿਲਚਸਪੀ ਰੱਖਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਕਮਿਊਨਿਟੀ ਪ੍ਰੋਜੈਕਟ ਦੇ ਆਲੇ ਦੁਆਲੇ ਦਿਖਾਈ ਦੇਵੇਗੀ. ਜੇਕਰ ਤੁਸੀਂ ਸਿਰਫ਼ ਕਮਿਊਨਿਟੀ ਪੀਆਰ ਦੁਆਰਾ ਇੱਕ ਕਮਿਊਨਿਟੀ ਬਣਾਉਣ ਵਿੱਚ ਰੁੱਝੇ ਹੋਏ ਹੋ, ਦੁਨੀਆ ਦੀਆਂ ਸਾਰੀਆਂ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਇੱਕ ਵਿਕੀ ਲਿਖ ਰਹੇ ਹੋ, ਜਾਂ github ਉੱਤੇ git ਵਰਕਫਲੋ ਨੂੰ ਠੀਕ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਪ੍ਰੋਜੈਕਟ ਦੇ ਸ਼ੁਰੂਆਤੀ ਪੜਾਵਾਂ ਵਿੱਚ ਮਾਇਨੇ ਰੱਖਣ ਦੀ ਸੰਭਾਵਨਾ ਨਹੀਂ ਹੈ। ਬੇਸ਼ੱਕ, ਢੁਕਵੇਂ ਪੜਾਅ 'ਤੇ ਇਹ ਨਾ ਸਿਰਫ਼ ਜ਼ਰੂਰੀ ਹਨ, ਸਗੋਂ ਜ਼ਰੂਰੀ ਚੀਜ਼ਾਂ ਵੀ ਹਨ.

ਸਿੱਟਾ ਵਿੱਚ ਮੈਂ ਦੱਸਣਾ ਚਾਹਾਂਗਾ ਟਿੱਪਣੀ, ਮੇਰੀ ਰਾਏ ਵਿੱਚ, ਇੱਕ ਓਪਨਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਤੋਂ ਉਪਭੋਗਤਾ ਦੀਆਂ ਉਮੀਦਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ:

ਮੈਂ ਇਸ OS 'ਤੇ ਸਵਿਚ ਕਰਨ ਬਾਰੇ ਗੰਭੀਰਤਾ ਨਾਲ ਸੋਚ ਰਿਹਾ ਹਾਂ (ਘੱਟੋ-ਘੱਟ ਕੋਸ਼ਿਸ਼ ਕਰੋ। ਉਹ ਸਰਗਰਮੀ ਨਾਲ ਇਸਦਾ ਪਿੱਛਾ ਕਰ ਰਹੇ ਹਨ ਅਤੇ ਵਧੀਆ ਚੀਜ਼ਾਂ ਕਰ ਰਹੇ ਹਨ).

'ਤੇ ਪੀ.ਐਸ TechTrain ਸਾਡੇ ਕੋਲ ਵੱਧ ਤੋਂ ਵੱਧ ਤਿੰਨ ਰਿਪੋਰਟਾਂ ਹੋਣਗੀਆਂ। ਇੱਕ ਓਪਨ ਸੋਰਸ ਬਾਰੇ ਅਤੇ ਦੋ ਏਮਬੈਡਡ ਬਾਰੇ (ਅਤੇ ਇੱਕ ਵਿਹਾਰਕ ਹੈ)। ਸਟੈਂਡ 'ਤੇ ਅਸੀਂ ਪ੍ਰੋਗਰਾਮਿੰਗ ਮਾਈਕ੍ਰੋਕੰਟਰੋਲਰ ਦੀ ਵਰਤੋਂ ਕਰਨ 'ਤੇ ਇੱਕ ਮਾਸਟਰ ਕਲਾਸ ਦਾ ਆਯੋਜਨ ਕਰਾਂਗੇ ਐਮਬਾਕਸ. ਆਮ ਵਾਂਗ, ਅਸੀਂ ਹਾਰਡਵੇਅਰ ਲਿਆਵਾਂਗੇ ਅਤੇ ਤੁਹਾਨੂੰ ਇਸ ਨੂੰ ਪ੍ਰੋਗਰਾਮ ਕਰਨ ਦੇਵਾਂਗੇ। ਖੋਜ ਅਤੇ ਹੋਰ ਗਤੀਵਿਧੀਆਂ ਵੀ ਹੋਣਗੀਆਂ। ਤਿਉਹਾਰ ਤੇ ਸਾਡਾ ਸਟੈਂਡ ਆ, ਮਜ਼ਾ ਆਵੇਗਾ।

ਸਰੋਤ: www.habr.com