01 ਮਾਰਚ 2025·8 ਮਿੰਟ
ਬ੍ਰਾਇਨ ਬਹਿਲੇਨਡੌਫ, ਅਪਾਚੀ ਅਤੇ ਖੁੱਲ੍ਹਾ ਵੈੱਬ ਦਾ ਉਭਾਰ
ਸਧਾਰਨ ਅੰਗਰੇਜ਼ੀ ਵਿੱਚ ਦੇਖੋ ਕਿ ਕਿਵੇਂ Brian Behlendorf ਨੇ Apache HTTP Server ਵਿੱਚ ਰੋਲ ਨਿਭਾਇਆ ਅਤੇ ਖੁੱਲ੍ਹੇ ਸਰੋਤ ਦੇ ਸਹਿਯੋਗ ਨੇ ਇੰਟਰਨੇਟ ਦੀ ਸਾਂਝੀ ਬੁਨਿਆਦ ਬਣਾਈ।
ਸਧਾਰਨ ਅੰਗਰੇਜ਼ੀ ਵਿੱਚ ਦੇਖੋ ਕਿ ਕਿਵੇਂ Brian Behlendorf ਨੇ Apache HTTP Server ਵਿੱਚ ਰੋਲ ਨਿਭਾਇਆ ਅਤੇ ਖੁੱਲ੍ਹੇ ਸਰੋਤ ਦੇ ਸਹਿਯੋਗ ਨੇ ਇੰਟਰਨੇਟ ਦੀ ਸਾਂਝੀ ਬੁਨਿਆਦ ਬਣਾਈ।
1990 ਦੇ ਦਹਾਕੇ ਦੇ ਦਰਮਿਆਨ, ਵੈੱਬ ਅਜੇ ਇਮਤਿਹਾਨੀ ਲੱਗਦੀ ਸੀ—ਅਤੇ ਇਸ ਕਾਬਲ ਸੀ ਕਿ ਇਕ ਹੀ ਸੌਫਟਵੇਅਰ ਚੋਣ ਨੇ ਲੋਕਾਂ ਦਾ ਆਨਲਾਈਨ ਤਜਰਬਾ ਬਦਲ ਸਕਦਾ ਸੀ। ਹਰ ਪੇਜ਼ਵਿਊ ਉਸ ਮਸ਼ੀਨ 'ਤੇ ਨਿਰਭਰ ਸੀ ਜੋ ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰ ਸਕਦੀ ਸੀ, HTTP ਬੇਨਤੀਆਂ ਸਮਝ ਸਕਦੀ ਸੀ ਅਤੇ ਫਾਇਲਾਂ ਤੇਜ਼ੀ ਨਾਲ ਅਤੇ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਭੇਜ ਸਕਦੀ ਸੀ। ਜੇ ਉਹ “ਵੈੱਬ ਸਰਵਰ” ਲੇਅਰ ਫੇਲ ਹੋ ਜਾਂਦੀ, ਤਾਂ ਵੈੱਬ ਦੀ ਹੋਰ ਕੋਈ ਗਾਰੰਟੀ ਮਾਇਨੇ ਨਹੀਂ ਰੱਖਦੀ।
Apache HTTP Server ਉਹਨਾਂ ਮੁਸ਼ਕਲਾਂ ਵਿਚੋਂ ਇਕ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਜਵਾਬ ਬਣਿਆ। ਅਤੇ ਇਸਦੇ ਸ਼ੁਰੂਆਤੀ ਗਤੀਵਿਧੀ ਵਿੱਚ ਨਜ਼ਦੀਕੀ ਜੁੜੇ ਲੋਕਾਂ ਵਿੱਚ ਇਕ ਸੀ ਬ੍ਰਾਇਨ ਬਹਿਲੇਨਡੌਫ: ਇੱਕ ਨਿਰਮਾਤਾ ਜਿਸ ਨੇ ਅਸਲੀ ਵੈੱਬਸਾਈਟਾਂ 'ਤੇ ਕੰਮ ਕੀਤਾ, ਓਪਰੇਟਰਾਂ ਦੀਆਂ ਲੋੜਾਂ ਨੂੰ ਦੇਖਿਆ ਅਤੇ ਖੁੱਲੇ ਤੌਰ 'ਤੇ ਵੰਡੀਆਂ ਸੁਧਾਰਾਂ ਨੂੰ ਇੱਕ ਸਾਂਝੇ ਯਤਨ ਵਿੱਚ ਬਦਲਣ ਵਿੱਚ ਮਦਦ ਕੀਤੀ, ਜਿਸ 'ਤੇ ਹੋਰ ਲੋਕ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਸਨ।
ਬ੍ਰਾਊਜ਼ਰ ਧਿਆਨ ਖਿੱਚਦੇ ਸਨ, ਪਰ ਸਰਵਰ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੇ ਸਨ ਕਿ ਵੈੱਬਸਾਈਟਾਂ ਚੱਲਦੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ, ਚੰਗੀ ਪ੍ਰਦਰਸ਼ਨ ਦਿੰਦੀਆਂ ਹਨ ਅਤੇ ਵਧ ਸਕਦੀਆਂ ਹਨ। ਹੋਸਟਿੰਗ ਕੰਪਨੀਆਂ, ਯੂਨੀਵਰਸਿਟੀਆਂ, ਸ਼ੌਕੀਨ ਸਾਈਟਾਂ ਅਤੇ ਨਵੀਆਂ ਕਾਰੋਬਾਰਾਂ ਨੂੰ ਸਾਰੇ ਇੱਕੋ-ਏਹ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਚਾਹੀਦੀਆਂ ਸਨ:
ਜਦੋਂ ਇਹ ਲੋੜਾਂ ਪੂਰੀਆਂ ਨਹੀਂ ਹੁੰਦੀਆਂ, ਨਤੀਜਾ ਧੀਮੇ ਪੇਜ਼, ਡਾਊਨਟਾਈਮ ਅਤੇ ਸੁਰੱਖਿਆ ਖਾਮੀਆਂ ਬਣਦਾ—जेਹੜਾ ਗ੍ਰਹੱਕਤਾ ਘਟਾਉਂਦਾ।
“ਖੁੱਲਾ ਸਰੋਤ ਢਾਂਚਾ” ਕੋਈ ਫੈਸ਼ਨਾਤਮਕ ਸ਼ਬਦ ਨਹੀਂ—ਇਹ ਇੰਟਰਨੇਟ ਦੀ ਸਾਂਝੀ ਪਾਈਪਿੰਗ ਹੈ: ਉਹ ਸੌਫਟਵੇਅਰ ਜਿਸ 'ਤੇ ਕਈ ਸੰਗਠਨ ਨਿਰਭਰ ਕਰਦੇ ਹਨ, ਜਿਸਦਾ ਸੋਰਸ ਕੋਡ ਖੁੱਲ੍ਹਾ ਹੁੰਦਾ ਅਤੇ ਸੁਧਾਰ ਪ੍ਰਕਾਸ਼ਿਤ ਢੰਗ ਨਾਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।
ਅਮਲੀ ਤੌਰ 'ਤੇ, ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਹੈ:
Apache ਸਿਰਫ਼ ਇਕ ਉਤਪਾਦ ਨਹੀਂ ਸੀ; ਇਹ ਫਿਕਸ ਕਰਨ, ਰਿਲੀਜ਼ ਜਾਰੀ ਕਰਨ ਅਤੇ ਭਰੋਸਾ ਬਣਾਉਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵੀ ਸੀ।
Apache ਦਾ ਉਭਾਰ ਲਾਜ਼ਮੀ ਨਹੀਂ ਸੀ। ਇਹ ਕਿਵੇਂ ਹੋਇਆ ਕਿ ਇੱਕ ਕਮਿਊਨਿਟੀ ਪ੍ਰੋਜੈਕਟ—ਪੈਚਾਂ, ਮੈਲਿੰਗ ਲਿਸਟਾਂ ਅਤੇ ਸਾਂਝੇ ਜ਼ਿੰਮੇਵਾਰੀ 'ਤੇ ਬਣਿਆ—ਹੋਸਟਿੰਗ ਲਈ ਡਿਫ਼ਾਲਟ ਚੋਣ ਅਤੇ ਅਸਲ ਵਿੱਚ ਵੈੱਬ ਚਲਾਉਣ ਵਾਲਾ ਪਲੇਟਫਾਰਮ ਬਣ ਗਿਆ? ਅਸੀਂ ਉਹ ਸੂਤਰ ਲੋਕਾਂ, ਤਕਨੀਕੀ ਫੈਸਲਿਆਂ ਅਤੇ ਗਵਰਨੈਂਸ ਮਾਡਲ ਰਾਹੀਂ ਦੇਖਾਂਗੇ ਜਿਸ ਨੇ Apache ਨੂੰ ਕਿਸੇ ਇਕ ਸਰਵਰ ਤੋਂ ਕ jauh 더 ਵੱਡਾ ਮਤਲਬ ਦਿੱਤਾ।
ਬ੍ਰਾਇਨ ਬਹਿਲੇਨਡੌਫ ਨੂੰ ਅਕਸਰ “Apache ਦੇ ਲੋਕਾਂ ਵਿੱਚੋਂ ਇੱਕ” ਵਜੋਂ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਇਹ ਲੇਬਲ ਉਸਦੀ ਖਾਸ ਕੀਮਤ ਨੂੰ ਘਟਾ ਦਿੰਦਾ ਹੈ: ਉਹ ਸਿਰਫ਼ ਕੋਡ ਨਹੀਂ ਲਿਖਦਾ ਸੀ—ਉਹ ਲੋਕਾਂ ਨੂੰ ਇਕੱਠੇ ਕੰਮ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਸੀ।
Apache ਨਾਮ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਬਹਿਲੇਨਡੌਫ ਸ਼ੁਰੂਆਤੀ ਵੈੱਬ ਪ੍ਰਕਾਸ਼ਨ ਅਤੇ ਹੋਸਟਿੰਗ ਦੀ ਗੁੰਝਲਦਾਰ ਹਕੀਕਤ ਵਿੱਚ ਲਿਫ਼ਟ ਹੋ ਚੁੱਕੇ ਸਨ। ਉਹ ਐਸੀਆਂ ਵੈੱਬਸਾਈਟਾਂ 'ਤੇ ਕੰਮ ਕਰਦੇ ਸਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਆਨਲਾਈਨ ਰਹਿਣਾ, ਤੇਜ਼ ਜਵਾਬ ਦੇਣਾ ਅਤੇ ਸੀਮਤ ਉਪਕਰਨਾਂ ਨਾਲ ਵੱਧ ਰਹੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਸੰਭਾਲਣਾ ਪੈਂਦਾ ਸੀ। ਇਹ ਅਨੁਭਵ ਇੱਕ ਪ੍ਰੈਗਮੈਟਿਕ ਸੋਚ ਬਣਾਉਂਦਾ ਸੀ: ਪ੍ਰਦਰਸ਼ਨ ਮਹੱਤਵਪੂਰਨ ਸੀ, ਭਰੋਸੇਯੋਗਤਾ ਮਹੱਤਵਪੂਰਨ ਸੀ, ਅਤੇ ਛੋਟੀ ਓਪਰੇਸ਼ਨਲ ਸਮੱਸਿਆਵਾਂ ਜਲਦੀ ਵੱਡੀਆਂ ਬਣ ਜਾਂਦੀਆਂ।
ਬਹਿਲੇਨਡੌਫ ਨੇ ਉਹਨਾਂ ਆਨਲਾਈਨ ਕਮਿਊਨਿਟੀਆਂ ਵਿੱਚ ਵੀ ਸਮਾਂ ਗੁਜ਼ਾਰਿਆ ਜਿੱਥੇ ਸ਼ੁਰੂਆਤੀ ਵੈੱਬ ਦੇ ਆਚਰਣ ਬਣੇ—ਮੈਲਿੰਗ ਲਿਸਟਾਂ, ਸਾਂਝੇ ਕੋਡ ਆਰਕਾਈਵ ਅਤੇ ਵਿਸ਼ਵ ਦੇ ਕੋਨੇ-ਕੋਨੇ 'ਚ ਫੈਲੇ ਸੇਵਾ-ਸੁਚਕ ਪ੍ਰੋਜੈਕਟ। ਇਹ ਮਾਹੌਲ ਉਹਨਾਂ ਲੋਕਾਂ ਨੂੰ ਇਨਾਮ ਦੇਂਦਾ ਸੀ ਜੋ ਸਾਫ਼-ਸੁਥਰੀ ਤਰ੍ਹਾਂ ਸੰਚਾਰ ਕਰ ਸਕਦੇ, ਭਰੋਸਾ ਕਮਾ ਸਕਦੇ ਅਤੇ ਬਿਨਾਂ ਉਪਰੀੱਧਾਰਨਾ ਦੇ ਗਤੀਸ਼ੀਲਤਾ ਬਰਕਰਾਰ ਰੱਖ ਸਕਦੇ।
ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਉਹ ਸਿਰਫ਼ “ਇੱਕ ਕਮਿਊਨਿਟੀ ਵਿੱਚ” ਨਹੀਂ ਸੀ—ਉਸਨੇ ਕਮਿਊਨਿਟੀ ਨੂੰ ਕਾਮਯਾਬ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕੀਤੀ।
ਬਹਿਲੇਨਡੌਫ ਦੀ ਸ਼ੁਰੂਆਤੀ Apache ਸ਼ਾਮਿਲੀਅਤ ਬਾਰੇ ਵਰਣਨ ਸਧਾਰਨ ਤੌਰ 'ਤੇ ਇੰਜੀਨੀਅਰਿੰਗ ਅਤੇ ਸਮਨਵਯ ਦੇ ਮਿਲੇ-ਜੁਲੇ ਮਾਮਲਿਆਂ ਨੂੰ ਉਜਾਗਰ ਕਰਦਾ ਹੈ। ਉਹਜ਼ਰ ਧਿਆਨ ਕੇਂਦਰਿਤ ਰਹੇ:
ਬਹਿਲੇਨਡੌਫ ਨੇ ਇੱਕ ਸਮੇਂ ਕਈ ਹੈਟ ਪਹਿਨੀਆਂ। ਇੱਕ ਯੋਗਦਾਨਕਾਰ ਵਜੋਂ ਉਸਨੇ ਸਰਵਰ ਨੂੰ ਸੁਧਾਰਨ 'ਚ ਮਦਦ ਕੀਤੀ। ਇੱਕ ਆਯੋਜਕ ਵਜੋਂ ਉਸਨੇ ਵੰਡੇ ਹੋਏ ਪੈਚਾਂ ਨੂੰ ਇਕ ਰੁਪ ਵਿੱਚ ਲਿਆਉਣ ਵਿੱਚ ਮਦਦ ਕੀਤੀ। ਅਤੇ ਇੱਕ ਵਕੀਲ ਵਜੋਂ ਉਸਨੇ ਸਮਝਾਇਆ ਕਿ ਖੁੱਲਾ, ਕਮਿਊਨਿਟੀ-ਨਿਰਮਿਤ ਵੈੱਬ ਸਰਵਰ ਕਿਉਂ ਭਰੋਸੇਯੋਗ ਹੋ ਸਕਦਾ—ਇਸ ਨਾਲ Apache ਇੱਕ ਸ਼ੌਂਕੀ ਪ੍ਰੋਜੈਕਟ ਤੋਂ ਭਰੋਸੇਯੋਗ ਢਾਂਚੇ ਵਾਂਗ ਮਹਿਸੂਸ ਹੋਣਾ ਸ਼ੁਰੂ ਹੋਇਆ।
1990 ਦੀਆਂ ਸ਼ੁਰੂਆਤਾਂ ਵਿੱਚ, “ਵੈੱਬ ਹੋਸਟ ਕਰਨਾ” ਅਕਸਰ ਯੂਨੀਵਰਸਿਟੀ ਦੇ ਲੈਬ ਮਸ਼ੀਨ, ਕੰਪਨੀ ਦੇ ਵਰਕਸਟੇਸ਼ਨ ਜਾਂ ਇਕ ਛੋਟੀ ਡੇਡੀਕੇਟਿਡ ਬਾਕਸ 'ਤੇ ਨੈਟਵਰਕ ਲਾਈਨ ਨਾਲ ਕਿਤੇ ਰੱਖਣ ਦਾ ਮਤਲਬ ਸੀ। ਸਾਈਟਾਂ ਸਧਾਰਨ ਸਨ: ਕੁਝ HTML ਪੰਨੇ, ਸ਼ਾਇਦ ਕੁਝ ਚਿੱਤਰ ਅਤੇ ਮੂਲ ਡਾਇਰੈਕਟਰੀ ਬਣਤਰ। ਪਰ ਇਹ ਵੀ ਉਦਿਆਂਗ ਸੀ ਕਿ ਇੱਕ ਐਸਾ ਸੌਫਟਵੇਅਰ ਹੋਵੇ ਜੋ ਬ੍ਰਾਊਜ਼ਰਾਂ ਤੋਂ ਆਉਣ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਜਵਾਬ ਦੇ ਸਕੇ, ਟ੍ਰੈਫਿਕ ਲੌਗ ਕਰ ਸਕੇ ਅਤੇ ਲੰਮ੍ਹੇ ਸਮੇਂ ਤੱਕ ਚੱਲ ਸਕੇ।
ਕੁਝ ਵੈੱਬ ਸਰਵਰ ਪ੍ਰੋਗਰਾਮ ਮੌਜੂਦ ਸਨ, ਪਰ ਹਰ ਇੱਕ ਦੇ ਆਪਣੇ ਫ਼ਾਇਦੇ-ਨੁਕਸਾਨ ਸਨ। CERN httpd (Tim Berners-Lee ਦੀ ਟੀਮ ਤੋਂ) ਪ੍ਰਭਾਵਸ਼ালী ਸੀ, ਪਰ ਇਹ ਹਰ ਵਾਰੀ ਚਲਾਉਣ ਜਾਂ ਫੈਲਾਉਣ ਲਈ ਸਭ ਤੋਂ ਆਸਾਨ ਨਹੀਂ ਸੀ। ਕੁਝ ਸੰਗਠਨਾਂ ਨੇ ਸ਼ੁਰੂਆਤੀ ਵਪਾਰਕ ਵਿਕਲਪ ਵਰਤੇ, ਪਰ ਉਹ ਮਹਿੰਗੇ, ਕਸਟਮਾਈਜ਼ ਕਰਨ ਵਿੱਚ ਔਖੇ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲ ਰਹੀ ਵੈੱਬ ਦੀਆਂ ਲੋੜਾਂ ਲਈ ਧੀਮੇ ਹੋ ਸਕਦੇ ਸਨ।
ਅਨੇਕ ਪਰਬੰਧਕਾਂ ਲਈ ਪ੍ਰਾਇਕਟਿਕ ਡਿਫਾਲਟ ਬਣਿਆ NCSA httpd, ਜੋ National Center for Supercomputing Applications ਨੇ ਬਣਾਇਆ ਸੀ। ਇਹ ਵਿਆਪਕ ਤੌਰ ਤੇ ਉਪਲਬਧ ਸੀ, ਕਾਫ਼ੀ ਸਿਧਾ ਸੀ ਅਤੇ ਸਹੀ ਸਮੇਂ 'ਤੇ ਆਇਆ—ਜਦੋਂ ਵੈੱਬਸਾਈਟਾਂ ਦੀ ਗਿਣਤੀ ਤੇਜ਼ੀ ਨਾਲ ਵੱਧ ਰਹੀ ਸੀ।
ਵੈੱਬ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਿਆ: ਨਵੇਂ ਬ੍ਰਾਊਜ਼ਰ ਵਰਤਾਰਿਆਂ, ਨਵੀਂਆਂ ਖਾਸੀਅਤਾਂ, ਵਧਦਾ ਟ੍ਰੈਫਿਕ ਅਤੇ ਵੱਧ ਰਹੀਆਂ ਸੁਰੱਖਿਆ ਚਿੰਤਾਵਾਂ। NCSA httpd ਦੀ ਵਿਕਾਸ ਰਫ਼ਤਾਰ ਮੰਦ ਹੋ ਗਈ, ਪਰ ਸੁਧਾਰ ਦੀ ਮੰਗ ਠਹਿਰ ਨਹੀਂ ਗਈ।
ਇੱਕ ਪੈਚ ਇੱਕ ਛੋਟਾ ਕੋਡ ਟੁਕੜਾ ਹੁੰਦਾ ਹੈ ਜੋ ਮੌਜੂਦਾ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਸਵਾਲ-ਜਵਾਬ ਜਾਂ ਫੀਚਰ ਜੋੜਨ ਲਈ ਬਦਲਦਾ ਹੈ। ਜਦੋਂ ਸੈਂਕੜੇ (ਫਿਰ ਹਜ਼ਾਰ) ਸਾਈਟ ਓਪਰੇਟਰ ਇੱਕੋ ਸਰਵਰ ਚਲਾ ਰਹੇ ਹਨ, ਤਾਂ ਪੈਚਾਂ ਨੂੰ ਸਾਂਝਾ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੋ ਜਾਂਦਾ ਹੈ। ਨਹੀਂ ਤਾਂ ਹਰ ਕੋਈ ਇੱਕੋ ਹੀ ਸਮੱਸਿਆਵਾਂ ਅਲੱਗ-ਅਲੱਗ ਹੱਲ ਕਰਦਾ, ਆਪਣੀ ਪ੍ਰਾਈਵੇਟ ਵਰਜਨ ਰੱਖਦਾ ਅਤੇ ਆਸ ਕਰਦਾ ਕਿ ਕੁਝ ਨਹੀਂ ਟੁਟੇਗਾ।
ਉਹ ਪੈਚ-ਸ਼ੇਅਰਿੰਗ ਸਭਿਆਚਾਰ—ਐਡਮਿਨਾਂ ਦਾ ਮੈਲਿੰਗ ਲਿਸਟਾਂ 'ਤੇ ਫਿਕਸ ਸਾਂਝੇ ਕਰਨਾ ਅਤੇ ਸੌਫਟਵੇਅਰ ਨੂੰ ਸਾਹਮਣੇ ਸੁਧਾਰਨਾ—ਉਸ ਸਟੀਜ ਲਈ ਮੌਕਾ ਬਣਾਉਂਦਾ ਸੀ ਜਿੱਥੇ ਜਲਦੀ ਹੀ Apache ਜਨਮ ਲਿਆ।
Apache ਕਿਸੇ ਵੱਡੇ ਯੋਜਨਾ ਦੇ ਤੌਰ 'ਤੇ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋਇਆ। ਇਹ ਇੱਕ ਪਰਸ਼ਾਸਕੀ ਜਵਾਬ ਵਜੋਂ ਸ਼ੁਰੂਆਤ ਸੀ: ਲੋਕ ਇਕੋ ਵੈੱਬ ਸਰਵਰ ਸੌਫਟਵੇਅਰ ਚਲਾ ਰਹੇ ਸਨ, ਉਹੀ ਸੀਮਾਵਾਂ ਆ ਰਹੀਆਂ ਸਨ ਅਤੇ ਬਿਲਕੁਲ ਇੱਕੋ ਹੀ ਬੱਗਾਂ ਲਈ ਅਲੱਗ-ਅਲੱਗ ਹੱਲ ਬਣ ਰਹੇ ਸਨ।
ਮਿਡ-1990 ਦੇ ਦਹਾਕੇ ਵਿੱਚ, ਬਹੁਤ ਸਾਈਟਾਂ NCSA httpd 'ਤੇ ਨਿਰਭਰ ਸਨ। ਜਦੋਂ ਵਿਕਾਸ ਰੁਕ ਗਿਆ, ਸਰਵਰ ਇਕਦਮ ਕੰਮ ਕਰਨਾ ਛੱਡਿਆ ਨਹੀਂ—ਪਰ ਵੈੱਬ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲ ਰਿਹਾ ਸੀ ਅਤੇ ਓਪਰੇਟਰਾਂ ਨੂੰ ਸੁਧਾਰਾਂ ਦੀ ਲੋੜ ਸੀ: ਵਧੀਆ ਪ੍ਰਦਰਸ਼ਨ, ਬੱਗ ਫਿਕਸ ਅਤੇ ਅਜਿਹੇ ਫੀਚਰ ਜੋ ਅਸਲੀ ਹੋਸਟਿੰਗ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣ।
ਡਿਵੈਲਪਰ ਅਤੇ ਪ੍ਰਬੰਧਕ ਪੈਚਾਂ ਦਾ ਲੇਨ-ਦੇਨ ਮੈਲਿੰਗ ਲਿਸਟਾਂ ਅਤੇ ਨਿੱਜੀ ਸੰਪਰਕਾਂ ਰਾਹੀਂ ਸ਼ੁਰੂ ਕਰਦੇ। ਸ਼ੁਰੂ ਵਿੱਚ ਇਹ ਅਨੌਪਚਾਰਿਕ ਸੀ: ਇੱਕ ਵਿਅਕਤੀ ਇੱਕ ਫਿਕਸ ਪੋਸਟ ਕਰਦਾ, ਹੋਰ ਲੋਕ ਓਸ ਨੂੰ ਲੋਕਲ ਲਗਾਉਂਦੇ ਅਤੇ ਕੁਝ ਵਾਪਸ ਰਿਪੋਰਟ ਕਰਦੇ। ਪਰ ਜਿਵੇਂ ਜ਼ਿਆਦਾ ਪੈਚਾਂ ਘੁੰਮਣ ਲੱਗੇ, ‘ਸਰਵਰ ਦੀ ਸਭ ਤੋਂ ਵਧੀਆ ਵਰਜਨ’ ਇੱਥੇ ਉਸ ਤੇ ਨਿਰਭਰ ਹੋਣ ਲੱਗੀ ਕਿ ਤੁਸੀਂ ਕਿਸਨੂੰ ਜਾਣਦੇ ਹੋ ਅਤੇ ਕਿਹੜੇ ਬਦਲਾਅ ਤੁਹਾਡੇ ਕੋਲ ਹਨ।
ਆਖਿਰਕਾਰ, ਪੈਚ-ਸ਼ੇਅਰਿੰਗ ਨੇ ਸਮਨਵਯ ਬਣਾਇਆ। ਲੋਕਾਂ ਨੇ ਫਿਕਸਾਂ ਨੂੰ ਇੱਕ ਸਾਂਝੇ ਕੋਡਬੇਸ ਵਿੱਚ ਮਿਲਾਉਣਾ ਸ਼ੁਰੂ ਕੀਤਾ ਤਾਂ ਜੋ ਹੋਰ ਲੋਕਾਂ ਨੂੰ ਆਪਣੀਆਂ ਵਰਜਨਾਂ ਨੂੰ ਜੋੜਨ ਦੀ ਲੋੜ ਨਾ ਪਏ। ਸ਼ੁਰੂਆਤੀ Apache ਰਿਲੀਜ਼ ਆਸਲ ਵਿੱਚ ਪੈਚਾਂ ਦੇ curated ਬੰਡਲ ਅਤੇ ਨਵੇਂ ਪੈਚਾਂ ਨੂੰ ਸ਼ਾਮਿਲ ਕਰਨ ਦਾ ਇੱਕ ਮਕੈਨਿਜ਼ਮ ਸਨ।
ਇਹ ਤਖ਼ਨੀਲਕ ਸ਼ੌਕ ਦਾ ਸੰਜੋਗ ਆਮ ਤੌਰ 'ਤੇ “a patchy server” ਵਜੋਂ ਸਮਝਾਇਆ ਜਾਂਦਾ ਹੈ—ਸਰਵਰ ਜੋ ਕਈ ਛੋਟੇ-ਛੋਟੇ ਫਿਕਸਾਂ ਤੋਂ ਟੁਕੜਿਆਂ ਵਿੱਚ ਬਣਿਆ। ਚਾਹੇ ਹਰ ਇਕ ਉਤਪੱਤੀ ਕਹਾਣੀ ਦਾ ਹਰ ਟੁਕੜਾ ਸਹੀ ਹੋਵੇ ਜਾਂ ਨਹੀਂ, ਇਹ ਨਾਮ ਉਸ ਲਹਜੇ ਨੂੰ ਦਰਸਾਉਂਦਾ ਸੀ: ਤਰੱਕੀ ਕਦਮ-ਕਦਮ ਤੇ ਸਾਂਝੀ ਸੀ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਜ਼ਰੂਰਤਾਂ ਨੇ ਉਹਨੂੰ ਚਲਾਇਆ।
ਜਿਹੜੇ ਸਮੇਂ 'ਤੇ ਕਈ ਲੋਕ ਇੱਕ ਸਾਂਝੇ ਸਰਵਰ ਨੂੰ ਬਣਾਉਂਦੇ ਸਨ, ਮੁਸ਼ਕਲ ਗੱਲ ਕੇਵਲ ਪੈਚ ਲਿਖਣਾ ਨਹੀਂ ਰਹਿ ਗਈ—ਮੁਸ਼ਕਲ ਇਹ ਸੀ ਕਿ ਕੀ ਕਬ ਆਪਣੀਰਾ(function) ਘੁਸ਼ ਕਰਨਾ ਹੈ, ਕਦੋਂ ਰਿਲੀਜ਼ ਕਰਨੀ ਹੈ ਅਤੇ ਗੈਰ-ਇਹਿਮੀ ਵਿਚਾਰਾਂ ਨੂੰ ਕਿਵੇਂ ਨਿਪਟਾਰਾ ਕਰਨਾ ਹੈ।
Apache ਦਾ ਢੁਕਵਾਂ ਢੰਗ ਸਿਰਫ਼ ਅਨੌਪਚਾਰਿਕ ਪੈਚ ਮੁਲ-ਲਣ-ਦੇਣ ਤੋਂ ਪ੍ਰੋਜੈਕਟ ਬਣਨ ਵਿੱਚ ਲਾਈਟਵੇਟ ਪਰ ਅਸਲ ਪ੍ਰਕਿਰਿਆ ਦਵਾਈ: ਸਾਂਝੀ ਸੰਚਾਰ ਚੈਨਲ, manteiners ਦੀ ਸਹਿਮਤੀ, ਬਦਲਾਵਾਂ ਦੀ ਸਮੀਖਿਆ ਦਾ ਤਰੀਕਾ ਅਤੇ ਰਿਲੀਜ਼ ਰਿਦਮ। ਇਹ ਸੰਰਚਨਾ ਕੰਮ ਨੂੰ ਟੁਕੜਿਆਂ ਵਿੱਚ ਵੰਡਣ ਤੋਂ ਰੁਕਾਉਂਦੀ ਅਤੇ ਨਵੇਂ ਯੋਗਦਾਨਕਾਰਾਂ ਨੂੰ ਬਿਨਾਂ ਭਰੋਸਾ ਟੁਟੇ ਯੋਗਦਾਨ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦੀ।
Apache ਉਸ ਸਮੇਂ ਜਨਮ ਲਿਆ ਜਦੋਂ ਕਮਿਊਨਿਟੀ ਨੇ ਪੈਚਿੰਗ ਨੂੰ ਸਾਂਝੇ ਜ਼ਿੰਮੇਵਾਰੀ ਵਜੋਂ ਲਿਆ ਅਤੇ ਉਸਨੂੰ ਸਸਤੇ ਸਥਾਈ ਰਵੱਈਏ ਬਣਾਏ।
Apache ਇਸ ਲਈ ਨਹੀਂ ਵਧਿਆ ਕਿ ਇੱਕ ਵਿਅਕਤੀ ਸਾਰਾ ਕੰਮ ਲਿਖਾ। ਇਹ ਵਧਿਆ ਕਿਉਂਕਿ ਇਕ ਛੋਟੀ ਕੋਰ ਟੀਮ ਨੇ ਬਹੁਤ ਸਾਰੇ ਲੋਕਾਂ ਲਈ ਬਿਨਾਂ ਹੰਗਾਮੇ ਯੋਗਦਾਨ ਕਰਨ ਦਾ ਤਰੀਕਾ ਬਣਾਇਆ।
Apache Group ਨੇ “ਛੋਟੀ ਕੋਰ, ਵਿਆਪਕ ਕਮਿਊਨਿਟੀ” ਮਾਡਲ ਅਪਣਾਇਆ। ਇਕ ਸਬੰਧਤ ਛੋਟੀ ਗਿਣਤੀ ਵਾਲੇ ਲੋਕਾਂ ਕੋਲ commit access ਸੀ (ਜੋ ਬਦਲਾਅ ਮਿਲਾਉਂਦੇ), ਪਰ ਕੋਈ ਵੀ ਫਿਕਸ ਸੁਝਾ ਸਕਦਾ, ਬੱਗ ਰਿਪੋਰਟ ਕਰ ਸਕਦਾ ਜਾਂ ਸੁਧਾਰ ਪ੍ਰਸਤਾਵਿਤ ਕਰ ਸਕਦਾ।
ਕੋਰ ਟੀਮ ਨੇ ਇੱਕ ਹੀ ਵਿਅਕਤੀ 'ਤੇ ਨਿਰਭਰਤਾ ਘਟਾਈ। ਵੱਖ-ਵੱਖ ਲੋਕ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਖੇਤਰਾਂ (ਪ੍ਰਦਰਸ਼ਨ, ਮੋਡੀਊਲ, ਦਸਤਾਵੇਜ਼, ਪਲੇਟਫਾਰਮ ਸਹਾਰਾ) ਦੇ ਮਾਲਕ ਬਣ ਗਏ। ਜਦੋਂ ਇਕ ਵਿਅਕਤੀ ਵਿਅਸਤ ਹੋ ਜਾਂਦਾ, ਹੋਰ ਲੋਗ ਕੰਮ ਨੂੰ ਉੱਠਾ ਲੈਂਦੇ, ਕਿਉਂਕਿ ਕੰਮ ਜਨਤਕ ਅਤੇ ਚਰਚਿਤ ਸੀ।
ਬੰਦ ਮੀਟਿੰਗਾਂ ਦੀ ਥਾਂ, ਕੇਸਰੇ ਫੈਸਲੇ ਜ਼ਿਆਦਾਤਰ ਮੈਲਿੰਗ ਲਿਸਟਾਂ 'ਤੇ ਹੁੰਦੇ। ਇਸਦਾ ਮਤਲਬ:
ਸਹਿਮਤੀ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਹਰ ਕੋਈ ਖੁਸ਼ ਹੋਵੇ; ਮਤਲਬ ਇਹ ਸੀ ਕਿ ਗਰੁੱਪ ਵਿਆਪਕ ਸਹਿਮਤੀ ਲਈ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ, ਇਤਰਾਜ਼ ਖੁੱਲ੍ਹੇ ਤੌਰ 'ਤੇ ਨਿਪਟਾਏ ਜਾਂਦੇ ਅਤੇ ਅਚਾਨਕ ਬਦਲਾਵ ਜੋ ਹੋਰਾਂ ਦਾ ਕੰਮ ਤੋੜ ਸਕਦੇ ਹਨ, ਰੋਕੇ ਜਾਂਦੇ।
ਖੁੱਲ੍ਹੀ ਚਰਚਾ ਇੱਕ ਮੁੜ-ਸਮੀਖਿਆ ਲੂਪ ਬਣਾਉਂਦੀ। ਬੱਗ ਤੇਜ਼ੀ ਨਾਲ ਮਿਲਦੇ, ਫਿਕਸ ਚੁਣੌਤੀ ਦੇ ਨਾਲ ਆਉਂਦੇ (ਸਿਹਤਮੰਦ ਢੰਗ ਨਾਲ), ਅਤੇ ਜੋਖ਼ਮ ਭਰੇ ਬਦਲਾਅ ਨੂੰ ਵਧੇਰੇ ਨਿਗਰਾਨੀ ਮਿਲਦੀ। ਕਾਰੋਬਾਰਾਂ ਲਈ ਇਹ ਪਾਰਦਰਸ਼ਤਾ ਭਰੋਸਾ ਬਣਾਉਂਦੀ: ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਕਿਵੇਂ ਨਿਪਟਾਇਆ ਗਿਆ ਅਤੇ ਸਥਿਰਤਾ ਨੂੰ ਕਿੰਨੀ ਗੰਭੀਰਤਾ ਨਾਲ ਲਿਆ ਗਿਆ।
“ਰਿਲੀਜ਼ ਪ੍ਰਬੰਧਨ” ਉਹ ਪ੍ਰਕਿਰਿਆ ਹੈ ਜੋ ਬਹੁਤ ਸਾਰੇ ਛੋਟੇ ਯੋਗਦਾਨਾਂ ਨੂੰ ਉਸ ਵਰਜ਼ਨ ਵਿੱਚ ਬਦਲਦੀ ਹੈ ਜੋ ਅਸਲ ਉਪਭੋਗਤਿਆਂ ਦੁਆਰਾ ਸੇਟਿੰਗ 'ਤੇ ਸੁਰੱਖਿਅਤ ਤੌਰ 'ਤੇ ਇੰਸਟਾਲ ਕੀਤੀ ਜਾ ਸਕੇ। ਰਿਲੀਜ਼ ਮੈਨੇਜਰ ਇਹ ਨਿਸ਼ਚਿਤ ਕਰਨ ਵਿੱਚ ਸਹਾਇਤਾ ਕਰਦੇ ਹਨ ਕਿ ਕੀ ਸ਼ਾਮਿਲ ਹੋਵੇ, ਕੀ ਬਾਹਰ ਰਹੇ, ਬਦਲਾਵ ਪਰੀਖਿਆ ਹੋਏ ਹਨ, ਸਪਸ਼ਟ ਨੋਟ ਲਿਖੇ ਗਏ ਹਨ ਅਤੇ ਇੱਕ ਪੂਰੇ ਰਹਿਤ-ਰਿਵਾਜ਼ ਨੂੰ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਇਹ ਕੰਟਰੋਲ ਤੋਂ ਵੱਧ ਉਸ ਗੱਲ ਬਾਰੇ ਹੈ ਕਿ ਕਮਿਊਨਿਟੀ ਦੇ ਕੰਮ ਨੂੰ ਭਰੋਸੇਯੋਗ ਚੀਜ਼ ਵਿੱਚ ਕਿਵੇਂ ਬਦਲਿਆ ਜਾਵੇ।
Apache ਮੁਫ਼ਤ ਹੋਣ ਦੇ ਕਾਰਨ ਹੀ ਲੋਕਾਂ ਦਾ ਮਨ ਜਿੱਤਿਆ ਨਹੀਂ। ਇਸਨੇ ਦਿਨ-ਪ੍ਰਤੀ ਦਿਨ ਦੇ ਡਿਜ਼ਾਇਨ ਨਾਲ ਅਸਲੀ ਲੋਕਾਂ ਵਾਲੀਆਂ ਵੈੱਬਸਾਈਟਾਂ ਲਈ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਬਣਨ ਦਾ ਰਾਸ਼ਤਾ ਚੁਣਿਆ।
ਇੱਕ ਵੱਡੇ, ਫਿਕਸ ਪ੍ਰੋਗਰਾਮ ਦੀ ਥਾਂ, Apache ਐਡ-ਓਨਸ (ਮੋਡੀਊਲ) ਸਵੀਕਾਰ ਕਰਨ ਲਈ ਬਣਾਇਆ ਗਿਆ। ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ: ਕੋਰ ਵੈੱਬ ਸਰਵਰ ਬੁਨਿਆਦੀ ਕੰਮ (ਬੇਨਤੀਆਂ ਪ੍ਰਾਪਤ ਕਰਨ ਅਤੇ ਪੰਨਿਆਂ ਭੇਜਣ) ਸੰਭਾਲਦਾ ਹੈ, ਅਤੇ ਮੋਡੀਊਲ ਤੁਹਾਨੂੰ ਹੋਰ ਖਾਸੀਅਤਾਂ ਚਾਲੂ ਕਰਨ ਦਿੰਦੇ—ਜਿਵੇਂ ਬਰਾਊਜ਼ਰ ਪਲੱਗਇਨ।
ਇਸਦਾ ਮਤਲਬ ਇਹ ਸੀ ਕਿ ਇਕ ਸੰਗਠਨ ਸਰਲਤਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਸੀ ਅਤੇ ਫਿਰ ਫੀਚਰ ਜੋੜ ਸਕਦਾ ਸੀ ਜਿਵੇਂ URL rewriting, authentication, compression ਜਾਂ ਵੱਖ-ਵੱਖ ਸਕ੍ਰਿਪਟਿੰਗ ਸੈਟਅੱਪ ਬਿਨਾਂ ਪੂਰੇ ਸਰਵਰ ਨੂੰ ਬਦਲੇ।
Apache ਦੀ ਸੰਰਚਨਾ ਫਾਈਲਾਂ ਨੇ ਇਸਨੂੰ ਅਨੁਕੂਲ ਬਣਾਇਆ। ਹੋਸਟਿੰਗ ਪ੍ਰਦਾਤਾ ਇੱਕ ਮਸ਼ੀਨ 'ਤੇ ਕਈ ਸਾਈਟਾਂ ਚਲਾ ਸਕਦੇ ਸਨ, ਹਰ ਇੱਕ ਦੀਆਂ ਆਪਣੀਆਂ ਸੈਟਿੰਗਾਂ ਨਾਲ। ਛੋਟੀ ਸਾਈਟਾਂ ਘੱਟ ਰੱਖ ਸਕਦੀਆਂ ਸਨ। ਵੱਡੀਆਂ ਸੰਥਾਵਾਂ caching, ਸੁਰੱਖਿਆ ਨਿਯਮ ਅਤੇ ਡਾਇਰੈਕਟਰੀ-ਸਤਰ ਪਰਮਿਸ਼ਨਾਂ ਲਈ ਟਿਊਨ ਕਰ ਸਕਦੀਆਂ ਸਨ।
ਇਹ ਕੰਫਿਗਰੇਬਿਲਟੀ ਮਹੱਤਵਪੂਰਨ ਸੀ ਕਿਉਂਕਿ ਸ਼ੁਰੂਆਤੀ ਵੈੱਬ ਅਮਲ ਵਿੱਚ ਇੱਕ-ਰੂਪਤ ਨਹੀਂ ਸੀ। ਲੋਕਾਂ ਕੋਲ ਵੱਖ-ਵੱਖ ਹਾਰਡਵੇਅਰ, ਵੱਖ-ਵੱਖ ਟ੍ਰੈਫਿਕ ਨਮੂਨੇ ਅਤੇ ਵੱਖ-ਵੱਖ ਉਮੀਦਾਂ ਸਨ। Apache ਨੂੰ ਉਸੇ ਰੂਪ ਵਿੱਚ ਰੱਖਣ ਦੀ ਬਜਾਏ ਫਿਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਸੀ।
Apache ਨੇ ਬੁਨਿਆਦੀ ਪਰ ਜਰੂਰੀ ਭਰੋਸੇਯੋਗਤਾ ਅਭਿਆਸਾਂ ਤੋਂ ਵੀ ਲਾਭ ਲਿਆ:
ਨਤੀਜਾ ਪੇਸ਼ਗੋਈਯੋਗ ਵਿਹਾਰ ਸੀ—ਜਦੋਂ ਤੁਹਾਡੀ ਵੈੱਬਸਾਈਟ ਤੁਹਾਡਾ ਕਾਰੋਬਾਰ ਹੁੰਦੀ ਹੈ, ਇਹ ਇੱਕ ਘੱਟ-ਅੰਕਿਤ ਫੀਚਰ ਨਹੀਂ।
ਐਡਮਿਨਾਂ ਨੂੰ Apache ਇਸ ਲਈ ਪਸੰਦ ਆਇਆ ਕਿ ਇਸਦੀ ਦਸਤਾਵੇਜ਼ੀ, ਜਵਾਬਦੇਹ ਮੈਲਿੰਗ ਲਿਸਟਾਂ ਅਤੇ ਇੱਕੋ ਜਿਹੀ ਢੰਗ ਨਾਲ ਕੰਫਿਗਰੇਸ਼ਨ ਵਰਤੀ ਜਾਂਦੀ। ਜਦੋਂ ਕੁਝ ਟੁੱਟਦਾ, ਆਮ ਤੌਰ 'ਤੇ ਡਾਇਗਨੋਜ਼ ਕਰਨ ਦਾ ਜਾਣਿਆ ਹੋਇਆ ਤਰੀਕਾ ਹੁੰਦਾ, ਪੁੱਛਣ ਲਈ ਥਾਂ ਹੁੰਦੀ ਅਤੇ ਇੱਕ ਫਿਕਸ ਜੋ ਪੂਰੇ ਸਟੈਕ ਨੂੰ ਮੁੜ-ਬਨਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਨਾ ਪਵੇ।
ਖੁੱਲ੍ਹਾ ਸਰੋਤ ਸਿਰਫ਼ ਇਹ ਨਹੀਂ ਕਿ “ਕੋਡ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ।” ਕੰਪਨੀਆਂ ਲਈ ਜਿਹੜੀਆਂ ਐਕਰੀਟਿਕ ਸਰਵਰਾਂ 'ਤੇ ਚੱਲਦੀ ਹਨ, ਲਾਇਸੈਂਸ ਉਹ ਕਾਨੂੰਨੀ ਨਿਯਮਾਂ ਦੀ ਕਾਪੀ ਹੈ ਜੋ ਅਮਲੀ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ: ਮੈਂ ਕੀ ਕਰ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ? ਮੈਨੂੰ ਕੀ ਕਰਨਾ ਜਰੂਰੀ ਹੈ? ਮੈਂ ਕਿਹੜਾ ਜੋਖ਼ਮ ਲੈ ਰਹਾ/ਰਹੀ ਹਾਂ?
ਕੋਈ ਸਪਸ਼ਟ ਖੁੱਲ੍ਹੀ ਲਾਇਸੈਂਸ ਆਮ ਤੌਰ 'ਤੇ ਤਿੰਨ ਚੀਜ਼ਾਂ ਕਵਰ ਕਰਦੀ ਹੈ:
Apache ਲਈ ਇਹ ਸਪਸ਼ਟਤਾ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਬਰਾਬਰ ਮਹੱਤਵਪੂਰਨ ਸੀ। ਜਦੋਂ ਸ਼ਰਤਾਂ ਸਮਝਣ ਯੋਗ ਅਤੇ ਲਗਾਤਾਰ ਹੁੰਦੀਆਂ ਹਨ, ਕਾਨੂੰਨੀ ਅਤੇ ਪ੍ਰੋਕਿਊਰਮੈਂਟ ਟੀਮਾਂ ਤੇਜ਼ੀ ਨਾਲ ਮਨਜ਼ੂਰੀ ਦੇ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਇੰਜਨੀਅਰਿੰਗ ਟੀਮਾਂ ਘੱਟ ਅਚਾਨਕੀ ਨਾਲ ਯੋਜਨਾ ਬਣਾ ਸਕਦੀਆਂ ਹਨ।
ਕਾਰੋਬਾਰਾਂ ਨੇ Apache ਨੂੰ ਇਸ ਲਈ ਅਪਣਾਇਆ ਕਿ ਲਾਇਸੈਂਸ ਅਣਿਸ਼ਚਿਤਤਾ ਘਟਾਉਂਦਾ ਸੀ। ਸਪਸ਼ਟ ਸ਼ਰਤਾਂ ਨੇ ਸਹਾਇਤਾ ਕੀਤੀ:
ਇਹ ਭਰੋਸਾ Apache ਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਹੋਬੀ ਪ੍ਰੋਜੈਕਟ ਤੋਂ ਢਾਂਚਾ ਬਣਾ ਗਿਆ।
ਖੁੱਲ੍ਹੇ ਲਾਇਸੈਂਸ ਵੈਂਡਰ ਲਾਕ-ਇਨ ਘਟਾ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਕੰਪਨੀ ਖ਼ਾਸ ਮਾਲਕਾਨੀ ਦੇ ਬੰਨ੍ਹਣ ਵਿੱਚ ਫਸਦੀ ਨਹੀਂ। ਜੇ ਲੋੜ ਬਦਲੇ, ਤੁਸੀਂ ਹੋਰ ਟੀਮ ਨਿਯੁਕਤ ਕਰ ਸਕਦੇ ਹੋ, ਕੰਮ ਘਰ ਵਿੱਚ ਲਿਆ ਸਕਦੇ ਹੋ ਜਾਂ ਹੋਸਟਿੰਗ ਪ੍ਰੋਵਾਈਡਰ ਬਦਲ ਸਕਦੇ ਹੋ ਅਤੇ ਇੱਕੋ ਕੋਰ ਸੌਫਟਵੇਅਰ ਰੱਖ ਸਕਦੇ ਹੋ।
ਟ੍ਰੇਡ-ਆਫ ਅਮਲੀ ਹੈ: “ਮੁਫ਼ਤ” ਦਾ ਮਤਲਬ ਦਿਲਚਸਪ ਨਹੀਂ; ਸਹਾਇਤਾ ਫਿਰ ਵੀ ਸਮਾਂ, ਹੁਨਰ, ਨਿਗਰਾਨੀ ਅਤੇ ਅੱਪਡੇਟ ਯੋਜਨਾ ਲੈਂਦੀ ਹੈ—ਚਾਹੇ ਤੁਸੀਂ ਆਪਣੇ ਆਪ ਕਰੋ ਜਾਂ ਕਿਸੇ ਪ੍ਰੋਵਾਈਡਰ ਨੂੰ ਭੁਗਤਾਨ ਕਰੋ।
Apache ਦੀ ਕਾਮਯਾਬੀ ਸਿਰਫ਼ ਚੰਗੇ ਕੋਡ ਅਤੇ ਸਮੇਂ-ਉਪਯੋਗ ਪੈਚਾਂ ਬਾਰੇ ਨਹੀਂ ਸੀ—ਇਹ ਇੱਕ ਢਾਂਚੇਦਾਰ ਤਰੀਕੇ ਨਾਲ ਇਕ ਛੋਟੀ ਗਰੁੱਪ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਬਣਾਉਣ ਬਾਰੇ ਸੀ ਜੋ ਕਿਸੇ ਵੀ ਵਿਅਕਤੀ ਤੋਂ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਟਿਕ ਸਕੇ।
ਕਮਿਊਨਿਟੀ ਨੂੰ Apache Software Foundation (ASF) ਵਿੱਚ ਰੂਪਾਂਤਰਨ ਕਰਨ ਨਾਲ ਫੈਸਲਿਆਂ ਦਾ ਤਰੀਕਾ, ਨਵੇਂ ਪ੍ਰੋਜੈਕਟਾਂ ਨਾਲ ਸ਼ਾਮਿਲ ਹੋਣ ਦਾ ਤਰੀਕਾ ਅਤੇ “Apache ਦਾ ਹਿੱਸਾ ਹੋਣ” ਦੀਆਂ ਜ਼ਰੂਰੀਆਂ ਸ਼ਰਤਾਂ ਨਿਰਧਾਰਤ ਹੋ ਗਈਆਂ। ਇਹ ਬਦਲਾਅ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਗੈਰ-ਅਨੌਪਚਾਰਿਕ ਟੀਮਾਂ ਅਕਸਰ ਕੁਝ ਜ਼ੋਰਦਾਰ ਲੋਕਾਂ 'ਤੇ ਨਿਰਭਰ ਰਹਿੰਦੀਆਂ ਹਨ; ਜਦੋਂ ਉਹ ਲੋਕ ਨੌਕਰੀ ਬਦਲਦੇ ਜਾਂ ਥੱਕ ਜਾਂਦੇ ਹਨ, ਤਰੱਕੀ ਰੁਕ ਸਕਦੀ ਹੈ।
ਇੱਕ ਫਾਊਂਡੇਸ਼ਨ ਨਾਲ, ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਲਗਾਤਾਰ ਰੱਖਣ ਲਈ ਇੱਕ ਘਰ ਮਿਲਦਾ ਹੈ। ਉਹ ਸਥਿਰ ਮੇਜ਼ਬਾਨੀ, ਦਸਤਾਵੇਜ਼, ਰਿਲੀਜ਼ ਅਤੇ ਕਮਿュਨਿਟੀ ਨਿਯਮਾਂ ਲਈ ਇੱਕ ਥਾਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ—ਭਾਵੇਂ ਇਨ੍ਹੇ ਵਿੱਚੂਕ ਵਿੱਚ maintainers ਬਦਲਦੇ ਰਹਿਣ।
ਗਵਰਨੈਂਸ ਬਿਊਰੋਕਰੇਸੀ ਜਾਪਦੀ ਹੈ, ਪਰ ਇਹ ਅਮਲੀ ਮੁੱਦੇ ਹੱਲ ਕਰਦੀ ਹੈ:
ਬ੍ਰਾਇਨ ਬਹਿਲੇਨਡੌਫ Apache ਦੀ ਉਤਪੱਤੀ ਦਾ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਹਿਸ्सा ਹਨ, ਪਰ ਪਛਾਣਨ ਯੋਗ ਹੈ ਕਿ ਸਥਾਈ ਖੁੱਲਾ ਸਰੋਤ ਆਮ ਤੌਰ 'ਤੇ ਇਕਲ-ਕਿਸਾਨੀ ਕਹਾਣੀ ਨਹੀਂ ਹੁੰਦੀ। ASF ਮਾਡਲ ਨੇ ਇਹ ਸੁਨਿਸ਼ਚਤ ਕੀਤਾ ਕਿ:
ਇਹ ਪੈਟਰਨ ਖੁੱਲ੍ਹੇ ਸਰੋਤ ਢਾਂਚਿਆਂ ਵਿੱਚ ਦੋਹਰਾਇਆ ਜਾਂਦਾ ਹੈ: ਤਕਨਾਲੋਜੀ “ਡਿਫਾਲਟ” ਬਣਦੀ ਹੈ ਜਦੋਂ ਲੋਕ ਨਾ ਸਿਰਫ਼ ਸੌਫਟਵੇਅਰ 'ਤੇ ਭਰੋਸਾ ਕਰਨ, ਸਗੋਂ ਉਸ ਗੱਲ 'ਤੇ ਵੀ ਕਿ ਕੱਲ੍ਹ ਨੂੰ ਕੀ ਹੋਵੇਗਾ।
ਜਦੋਂ ਲੋਕ ਕਹਿੰਦੇ ਹਨ ਕਿ Apache “ਡਿਫਾਲਟ” ਵੈੱਬ ਸਰਵਰ ਬਣ ਗਿਆ, ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਮਤਲਬ ਰੱਖਦੇ ਹਨ: ਇਹ ਉਹ ਚੋਣ ਸੀ ਜੋ ਬਿਨਾ ਪੁੱਛੇ ਹੀ ਮਿਲ ਜਾਂਦੀ। ਇਹ ਹੋਸਟਿੰਗ ਕੰਪਨੀਆਂ ਦੁਆਰਾ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਡਿਪਲੋਇ ਕੀਤੀ ਜਾਂਦੀ, ਆਪਰੇਟਿੰਗ ਸਿਸਟਮਾਂ ਵਿੱਚ ਪੈਕੇਜ ਹੋ ਕੇ ਆਉਂਦੀ, ਅਤੇ ਟਿਊਟੋਰੀਅਲਾਂ ਅਤੇ ਕਿਤਾਬਾਂ ਵਿੱਚ ਸਿਖਾਈ ਜਾਂਦੀ—ਇਸ ਲਈ Apache ਚੁਣਨਾ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਆਸਾਨ ਰਸਤਾ ਲੱਗਦਾ ਸੀ।
Apache ਨੇ ਇਸ ਲਈ ਜਿੱਤਿਆ ਨਹੀਂ ਕਿ ਹਰ ਉਪਭੋਗਤਾ ਹਰ ਫੀਚਰ ਦੀ ਤੁਲਨਾ ਕਰਦਾ। ਇਹ ਇਸ ਲਈ ਜਿੱਤਿਆ ਕਿ ਇਹ ਪਹਿਲਾਂ ਹੀ ਇੰਸਟਾਲ ਹੋ ਕੇ ਜਾਂ ਇੱਕ ਕਮਾਂਡ ਦੂਰ ਸੀ, ਕਾਫ਼ੀ ਦਸਤਾਵੇਜ਼ ਅਤੇ ਕਮਿਊਨਿਟੀ ਸਹਿਯੋਗ ਨਾਲ ਤਾਂ ਕਿ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਸਾਈਟ ਚਾਲੂ ਕਰ ਸਕੋ।
ਜੇ ਤੁਸੀਂ 1990 ਦੇ ਅੰਤ ਅਤੇ 2000 ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਵੈੱਬ ਹੋਸਟਿੰਗ ਸਿੱਖ ਰਹੇ ਸੀ, ਤਾਂ ਜੋ ਉਦਾਹਰਣ ਤੁਸੀਂ ਲੱਭਦੇ—ਮੈਲਿੰਗ ਲਿਸਟਾਂ, ਸਰਵਰ ਐਡਮਿਨ ਗਾਈਡਾਂ ਅਤੇ ਸ਼ੁਰੂਆਤੀ ਹੋਸਟਿੰਗ ਪੈਨਲ—ਅਕਸਰ Apache ਨੂੰ ਮੰਨ ਕੇ ਤਿਆਰ ਕੀਤੇ ਗਏ ਸਨ। ਇਹ ਸਾਂਝਾ ਆਧਾਰ ਘਟਾਓ ਰੋਕਦਾ: ਡਿਵੈਲਪਰ ਇੱਕ ਵਾਰੀ ਹਦਾਇਤਾਂ ਲਿਖਦੇ, ਅਤੇ ਪਾਠਕ ਉਹਨਾਂ ਨੂੰ ਜ਼ਿਆਦਾਤਰ ਮਸ਼ੀਨਾਂ 'ਤੇ ਅਸਾਨੀ ਨਾਲ ਅਪਲਾਈ ਕਰ ਸਕਦੇ।
Linux ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨਾਂ ਨੇ Apache ਨੂੰ ਆਪਣੇ ਰਿਪੋਜ਼ਟਰੀਜ਼ ਅਤੇ ਇੰਸਟਾਲੇਸ਼ਨ ਟੂਲਾਂ ਵਿੱਚ ਸ਼ਾਮਿਲ ਕਰਕੇ ਵੱਡੀ ਮਦਦ ਕੀਤੀ। ਐਡਮਿਨਾਂ ਲਈ ਇਸਦਾ ਮਤਲਬ ਸੀ συνεਹਤ ਅਪਡੇਟ, ਜਾਣ پہچਾਣ ਵਾਲੀ ਫਾਈਲ ਸਥਿਤੀ ਅਤੇ ਨਾਰਮਲ ਸਿਸਟਮ ਰਖ-ਰਖਾਅ ਦੇ ਅਨੁਕੂਲ ਅਪਗਰੇਡ ਪਾਥ।
ਹੋਸਟਿੰਗ ਪ੍ਰੋਵਾਈਡਰਾਂ ਨੇ ਇਸ ਲੂਪ ਨੂੰ ਮਜ਼ਬੂਤ ਕੀਤਾ। ਸ਼ੇਅਰਡ ਹੋਸਟਿੰਗ ਕਾਰੋਬਾਰ ਨੂੰ ਕੁਝ ਸਥਿਰ, ਸੰਰਚਨੀਯੋਗ ਅਤੇ ਵਿਸ਼ਾਲ ਐਡਮਿਨ ਟੈਲੈਂਟ ਪੁਲ ਦੁਆਰਾ ਆਮ ਤੌਰ 'ਤੇ ਸਮਝਿਆ ਜਾਣ ਵਾਲੀ ਚੀਜ਼ ਦੀ ਲੋੜ ਹੁੰਦੀ ਸੀ। Apache ਉੱਤੇ ਮਿਆਰੀਕਰਨ ਕਰਨ ਨਾਲ ਸਟਾਫਿੰਗ ਆਸਾਨ ਹੋ ਗਈ, ਸਪੋਰਟ ਟਿਕਟ ਤੇਜ਼ੀ ਨਾਲ ਹੱਲ ਹੋਏ, ਅਤੇ ਪ੍ਰੋਵਾਈਡਰ ਆਮ ਫੀਚਰ (ਜਿਵੇਂ ਪ੍ਰਤੀ-ਡਾਇਰੈਕਟਰੀ ਸੰਰਚਨਾ ਅਤੇ ਵਰਚੁਅਲ ਹੋਸਟਿੰਗ) ਇੱਕ ਨਿਰਵਚਿਤ ਢੰਗ ਨਾਲ ਪੇਸ਼ ਕਰ ਸਕੇ।
ਸ਼ੁਰੂਆਤੀ ਇੰਟਰਨੇਟ ਵਾਧਾ ਕਿਸੇ ਇੱਕ ਆਪਰੇਟਿੰਗ ਸਿਸਟਮ 'ਤੇ ਨਹੀਂ ਹੋਇਆ। ਯੂਨੀਵਰਸਿਟੀਆਂ, ਸਟਾਰਟਅਪ, ਉਦਯੋਗ ਅਤੇ ਸ਼ੌਕੀਨ ਲੋਕ ਵੱਖ-ਵੱਖ ਯੂਨੀਕਸ ਵੈਰੀਅਂਟ, ਸ਼ੁਰੂਆਤੀ Linux ਡਿਸਟ੍ਰੋ ਅਤੇ Windows ਸਰਵਰ ਚਲਾ ਰਹੇ ਸਨ। Apache ਦੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਵਾਤਾਵਰਨਾਂ 'ਤੇ ਚੱਲਣ ਅਤੇ ਇੱਕ ਵਾਰੀ ਇੰਸਟਾਲ ਹੋਣ 'ਤੇ ਇੱਕੋ ਜਿਹੀ ਵਿਵਹਾਰ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਇਸਨੂੰ ਵੱਧ ਫੈਲਣ ਯੋਗ ਬਣਾਉਂਦੀ ਸੀ।
ਇਹ ਪોર્ટੇਬਿਲਿਟੀ ਸ਼ਾਇਦ ਰੋਮਾਂਚਕ ਨਹੀਂ ਸੀ, ਪਰ ਫ਼ੈਸਲਾਕਾਰੀ ਸੀ: ਜੇ ਜ਼ਿਆਦਾ ਥਾਵਾਂ ਤੇ Apache ਚੱਲ ਸਕੇ, ਤਾਂ ਇਹ ਹੋਰਾਂ ਦੁਆਰਾ ਲਿਖੀਆਂ ਟੂਲਜ਼, ਡੌਕਸ ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ ਚੈਕਲਿਸਟਾਂ ਵਿੱਚ ਵਧੇਰੇ ਉਮੀਦਯੋਗ ਸਰਵਰ ਬਣ ਗਿਆ।
Apache ਸਿਰਫ਼ ਮੁਫ਼ਤ ਅਤੇ ਯੋਗ ਨਹੀਂ ਸੀ—ਇਹ ਇਸ ਲਈ ਫੈਲਿਆ ਕਿਉਂਕਿ ਹਜ਼ਾਰਾਂ ਲੋਕਾਂ ਨੇ ਇਸਨੂੰ ਚਲਾਉਣਾ ਸਿੱਖਿਆ। ਇਸ ਅਸਲੀ ਦਿਖਾਈ ਪਰਛਾਈ ਨੇ Apache HTTP Server ਨੂੰ ਸ਼ੁਰੂਆਤੀ ਵੈੱਬ ਤੇ ਕਾਰਯਕਸ਼ਮਤਾ ਅਤੇ ਸੁਰੱਖਿਆ ਲਈ ਇੱਕ ਪ੍ਰਸ਼িক্ষਣ ਮੈਦਾਨ ਬਣਾਇਆ।
ਇੱਕ ਵਾਰੀ Apache ਆਮ ਹੋ ਗਿਆ, ਇਹ ਵੱਡਾ ਨਿਸ਼ਾਨਾ ਬਣ ਗਿਆ। ਹਮਲਾਵਰ ਸਾਂਝੇ ਬੁਨਿਆਦੀਆਂ 'ਤੇ ਧਿਆਨ ਦੇਂਦੇ ਹਨ ਕਿਉਂਕਿ ਇਕ ਹੀ ਕਮੀ ਸਾਰਿਆਂ 'ਤੇ ਲਾਗੂ ਹੋ ਸਕਦੀ ਹੈ। ਇਹ ਸੁਰੱਖਿਆ ਦਾ ਇੱਕ ਮੁਢਲਾ ਅਤੇ ਅਸੁਖਾਵਾਰ ਨਿਯਮ ਹੈ: ਕਾਮਯਾਬੀ ਨਿਗਰਾਨੀ ਵਧਾਉਂਦੀ ਹੈ।
ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵਰਤੀ ਜਾਣ ਵਾਲੀ ਸੌਫਟਵੇਅਰ ਨੂੰ ਬਚਾਉਣ ਵਾਲੇ ਅਤੇ ਹਮਲਾਵਰ ਦੋਹਾਂ ਦਾ ਟੈਸਟ ਮਿਲਦਾ—ਇਸ ਲਈ ਮੁੱਦੇ ਜ਼ਿਆਦਾ ਸੰਭਾਵਨਾ ਨਾਲ ਲੱਭੇ ਅਤੇ ਠੀਕ ਹੋ ਜਾਂਦੇ ਹਨ।
Apache ਦੀ ਖੁੱਲ੍ਹੀ ਵਿਕਾਸ ਮਾਡਲ ਨੇ ਸੁਰੱਖਿਆ ਲਈ ਇੱਕ ਸਿਹਤਮੰਦ ਰਿਥਮ ਸਧਾਰਨ ਕੀਤਾ: ਮੁੱਦੇ ਰਿਪੋਰਟ ਕਰੋ, ਜਿੱਥੇ ਉਪਯੁਕਤ ਹੋ ਖੁੱਲ੍ਹੇ ਤੌਰ 'ਤੇ ਚਰਚਾ ਕਰੋ, ਫਿਕਸ ਜਾਰੀ ਕਰੋ ਅਤੇ ਸਪਸ਼ਟ ਢੰਗ ਨਾਲ ਸੰਚਾਰ ਕਰੋ ਤਾਂ ਕਿ ਐਡਮਿਨ ਤੁਰੰਤ ਪੈਚ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕਰ ਸਕਣ। ਜਦੋਂ ਰਿਲੀਜ਼ ਨੋਟ ਅਤੇ ਸਲਾਹ-ਮਸ਼ਵਰੇ ਸਪਸ਼ਟ ਹੁੰਦੇ, ਸਾਈਟ ਮਾਲਕ ਤੇਜ਼ੀ ਨਾਲ ਫੈਸਲਾ ਕਰ ਸਕਦੇ ਕਿ ਕੀ ਪ੍ਰਭਾਵਿਤ ਹੈ, ਕੀ ਨਹੀਂ, ਅਤੇ ਅਪਡੇਟ ਕਿੰਨੀ ਤੁਰੰਤ ਜਰੂਰੀ ਹੈ।
ਇਸ ਨਾਲ ਇੱਕ ਓਪਰੇਸ਼ਨਲ ਸਬਕ ਵੀ ਮਿਲਿਆ ਜੋ ਹੁਣ ਉਦਯੋਗ ਮੰਨਦਾ ਹੈ: ਸੁਰੱਖਿਆ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਹੈ, ਇੱਕ ਏਕ-ਵਾਰ ਆਡਿਟ ਨਹੀਂ।
Apache ਚਲਾਉਣ ਨੇ ਐਡਮਿਨਾਂ ਨੂੰ ਮੁੜ-ਉਪਯੋਗ ਰੂਟਿਨਾਂ ਵੱਲ ਧੱਕਿਆ:
ਇਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੇ ਅਭਿਆਸ ਆਧੁਨਿਕ ਟੀਮਾਂ ਲਈ ਵੀ ਲਾਗੂ ਹੁੰਦੇ ਹਨ—ਚਾਹੇ ਉਹ "ਕਲਾਸਿਕ" ਸਰਵਰ ਚਲਾ ਰਹੀਆਂ ਹੋਣ ਜਾਂ ਕਲਾਉਡ-ਨੇਟਿਵ ਐਪਸ।
Apache ਅਚ్ఛੀ ਤਰ੍ਹਾਂ ਬਣਿਆ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਗਲਤ ਢੰਗ ਨਾਲ ਚਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਕਮਜ਼ੋਰ ਪਾਸਵਰਡ, ਬਹੁਤ ਖੁੱਲ੍ਹੀਆਂ ਫਾਇਲ ਪਰਮਿਸ਼ਨ, ਪੁੁਰਾਣੇ ਮੋਡੀਊਲ ਅਤੇ ਗਲਤ TLS ਸੰਰਚਨਾ ਵਧੀਆ ਸੌਫਟਵੇਅਰ ਨੂੰ ਵੀ ਅਣ-ਸੁਰੱਖਿਅਤ ਕਰ ਸਕਦੇ ਹਨ। Apache ਦੀ ਇਤਿਹਾਸ ਨੇ ਇੱਕ ਲੰਮੇ ਸਮੇਂ ਵਾਲੀ ਸਚਾਈ ਰੋਸ਼ਨ ਕੀਤੀ: ਸੁਰੱਖਿਆ ਇੱਕ ਸਾਂਝੀ ਜ਼ਿੰਮੇਵਾਰੀ ਹੈ—ਸੌਫਟਵੇਅਰ ਲੇਖਕ ਜੋਖ਼ਮ ਘਟਾ ਸਕਦੇ ਹਨ, ਪਰ ਓਪਰੇਟਰ ਫੈਸਲਾ ਕਰਦੇ ਹਨ ਕਿ ਇਹ ਕਿੰਨੀ ਸੁਰੱਖਿਅਤ ਚਲਾਈ ਜਾਏ।
Apache ਦੀ ਲੰਮੀ ਦੌੜ ਇਕ ਦੁਰਘਟਨਾ ਨਹੀਂ ਸੀ। ਬਹਿਲੇਨਡੌਫ ਅਤੇ ਸ਼ੁਰੂਆਤੀ Apache Group ਨੇ ਦਿਖਾਇਆ ਕਿ ਜਦੋਂ ਪ੍ਰਕਿਰਿਆ ਇੰਜੀਨੀਅਰਿੰਗ ਜਿੰਨੀ ਸੋਚ-ਵਿਚਾਰ ਨਾਲ ਬਣਾਈ ਜਾਏ, ਤਾਂ ਖੁੱਲ੍ਹਾ ਸਰੋਤ ਪ੍ਰਾਪਤੀਕ ਤੌਰ 'ਤੇ ਪ੍ਰਾਪਤੀ ਲੈ ਸਕਦਾ ਹੈ।
Apache ਨੇ ਉਹਨਾਂ ਅਭਿਆਸਾਂ ਨੂੰ ਆਮ ਕਰ ਦਿੱਤਾ ਜੋ ਬਾਅਦ ਵਿੱਚ “ਖੁੱਲ੍ਹੇ ਸਰੋਤ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ” ਬਣੇ: ਜਨਤਕ ਚਰਚਾ, ਸਮੀਖਿਆ ਕੀਤੇ ਪੈਚ, ਸਪਸ਼ਟ maintainers ਅਤੇ ਫੈਸਲੇ ਜਨਤਕ ਰਿਕਾਰਡ ਕੀਤਾ ਜਾਣਾ। ਇਸ ਪਾਰਦਰਸ਼ਤਾ ਨੇ ਲਗਾਤਾਰਤਾ ਬਣਾਈ—ਪਰੋਜੈਕਟ ਨੌਕਰੀ ਬਦਲਣ, ਸਪਾਂਸਰ ਬਦਲਣ ਅਤੇ ਨਵੇਂ ਯੋਗਦਾਨਕਾਰਾਂ ਦੇ ਆਉਣ-ਜਾਣ ਤੋਂ ਬਾਅਦ ਵੀ ਜਾਰੀ ਰਹਿ ਸਕਦਾ।
ਗੈਰ-ਅਨੌਪਚਾਰਿਕ ਸਮੂਹ ਤੋਂ ASF ਵੱਲ ਦਾ ਰੁਖ ਸਹਿਯੋਗ ਨੂੰ ਠੋਸ ਬਣਾਉਦਾ: ਨਿਰਧਾਰਿਤ ਭੂਮਿਕਾਵਾਂ, ਵੋਟਿੰਗ, IP ਹाइजੀਨ ਅਤੇ ਨਿਰਪੱਖ ਘਰ ਜੋ ਕਿਸੇ ਇਕ ਵੈਂਡਰ ਦਾ ਨਹੀਂ। ਇਹ ਢਾਂਚਾ ਕਾਰੋਬਾਰਾਂ ਨੂੰ Apache ਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਪਰੋਜੈਕਟ ਨਾ ਸਮਝਣ ਲਈ ਮਦਦ ਕਰਦਾ—ਇੱਕ ਸੰਸਥਾ ਜੋ ਭਰੋਸੇਯੋਗ ਇੰਫਰਾਸਟਰੱਕਚਰ ਪ੍ਰਦਾਨ ਕਰ ਸਕਦੀ।
Apache ਨੇ ਓਪਰੇਟਰਾਂ ਦੀ ਮੌਜੂਦਾ ਸਥਿਤੀ ਪਾਸੋਂ ਮਿਲ ਕੇ ਸਫਲਤਾ ਹਾਸਲ ਕੀਤੀ: ਸਥਿਰ ਰਿਲੀਜ਼, ਸਮਝਦਾਰ ਡਿਫ਼ਾਲਟ, ਮਾਡਿਊਲਰ ਐਕਸਟੈਂਡਬਿਲਟੀ ਅਤੇ ਸਥਿਰ ਅੱਗੇ ਵਧਾਈ। ਵੱਡੀ ਸੋਚ ਨਹੀਂ; ਬਜਾਏ ਇਸਦੇ, ਮਕਸਦ ਇਹ ਸੀ ਕਿ ਵੈੱਬ ਸਰਵਰ ਸਥਿਰ, ਸਮਰੱਥ ਤੇ ਸੰਭਾਲਯੋਗ ਹੋਵੇ।
ਉਹ ਉਮੀਦਾਂ ਜੋ Apache ਨੇ ਸੈੱਟ ਕੀਤੀਆਂ—ਮੈਰਿਟ-ਅਧਾਰਿਤ ਯੋਗਦਾਨ, “ਕਮਿਊਨਿਟੀ ਕੋਡ ਤੋਂ ਉਪਰ”, ਪੇਸ਼ਗੀ ਰਿਲੀਜ਼ ਅਤੇ ਫਾਊਂਡੇਸ਼ਨ-ਸਮਰਥਿਤ ਗਵਰਨੈਂਸ—ਅਨੇਕ ਵੱਡੇ ਖੁੱਲ੍ਹੇ ਸਰੋਤ ਪ੍ਰੋਜੈਕਟਾਂ 'ਚ ਵੀ ਦਿੱਖਾਈ ਦੇਂਦੀਆਂ ਹਨ। ਭਾਵੇਂ ਪ੍ਰੋਜੈਕਟ Apache ਦੇ ਮਾਡਲ ਨੂੰ ਸੀਧਾ ਨਕਲ ਨਾ ਕਰਦੇ ਹੋਣ, ਉਹਨਾਂ ਨੇ ਕਈ ਸਮਾਜਿਕ ਸਮਝੌਤੀਆਂ ਲੈ ਲੀੀਆਂ: ਯੋਗਦਾਨ ਦਿਓ, ਸਾਂਝੀ ਮਾਲਕੀ, ਅਤੇ ਜਨਤਕ ਜਵਾਬਦੇਹੀ।
ਆਧੁਨਿਕ ਢਾਂਚਾ ਹੋਰ ਜ਼ਿਆਦਾ ਜਟਿਲ ਹੈ, ਪਰ ਮੁਢਲੇ ਸਮੱਸਿਆਵਾਂ ਇੱਕੋ-ਇਕੋ ਹਨ: ਰੱਖ-ਰਖਾਅ, ਸੁਰੱਖਿਆ ਅਪਡੇਟ, ਅਤੇ ਉਹ ਸਾਂਝੇ ਮਿਆਰ ਜੋ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਇੰਟਰੋਪਰੇਬਲ ਰੱਖਦੇ ਹਨ। Apache ਦੀ ਕਹਾਣੀ ਇੱਕ ਯਾਦ ਹੈ ਕਿ “ਖੁੱਲ੍ਹਾ” ਦੇਣ ਨਾਲ ਸਿਰਫ਼ ਕੋਡ ਛਪਾਉਣਾ ਨਹੀਂ—ਸੰਭਾਲ ਜਾਰੀ ਰੱਖਣਾ ਸਭ ਤੋਂ ਮੁਸ਼ਕਲ ਕੰਮ ਹੈ।
ਇਸੇ ਲਈ ਆਧੁਨਿਕ ਬਿਲਡ ਟੂਲ ਮਹੱਤਵਪੂਰਨ ਹਨ: ਟੀਮਾਂ ਤੇਜ਼ੀ ਨਾਲ ਜਾਰੀ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਨ ਬਿਨਾਂ ਉਨ੍ਹਾਂ ਅਭਿਆਸਾਂ ਨੂੰ ਖੋਵਾਏ ਜੋ Apache ਨੇ ਲੋਕਾਂ ਨੂੰ ਸਿਖਾਉਂਦੇ ਰਹੇ। ਉਦਾਹਰਨ ਲਈ, Koder.ai ਐਪ ਬਣਾਉਣ ਨੂੰ ਇੱਕ ਗੱਲ-ਬਾਤ ਵੰਜੋਂ ਦੇਖਦਾ ਹੈ—React ਫਰੰਟਐਂਡ, Go ਬੈਕਐਂਡ ਅਤੇ PostgreSQL ਡੇਟਾ ਲੇਅਰਾਂ ਸਿਰਜਦਾ ਏਜੈਂਟ-ਅਧਾਰਿਤ ਵਰਕਫਲੋ ਦੇ ਨਾਲ—ਫਿਰ ਵੀ ਟੀਮਾਂ ਨੂੰ ਸੋర్స్ ਕੋਡ ਨਿਰਯਾਤ, ਡਿਪਲੋਇ ਅਤੇ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਦੇ ਨਾਲ ਦੁਹਰਾਉਣ ਦੀ ਆਜ਼ਾਦੀ ਦਿੰਦਾ ਹੈ। ਤਕਨਾਲੋਜੀ ਨਵੀਂ ਹੈ, ਪਰ ਆਧਾਰਭੂਤ ਸਬਕ ਵਾਂਗ: ਗਤੀ ਤਾਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ ਪਰ ਉਹ ਮੁਲਾਂਕਣ, ਰਿਵਿਊ ਅਤੇ ਜ਼ਿੰਮੇਵਾਰੀ ਵਾਲੇ ਪ੍ਰਕਿਰਿਆ ਬਿਨਾਂ ਲੰਮੇ ਸਮੇਂ ਤੱਕ ਘਟਦੀ ਹੈ।
Apache HTTP Server ਨੇ उस ਸਮੇਂ ਜਦੋਂ ਵੈੱਬ ਅਜੇ ਅਸਥਿਰ ਸੀ, ਵੈੱਬਸਾਈਟਾਂ ਨੂੰ ਸਥਿਰ, ਤੇਜ਼ ਤੇ ਸਕੇਲਯੋਗ ਬਣਾਉਣ ਵਿੱਚ ਮੱਦਦ ਕੀਤੀ।
ਇਸ ਦਾ ਵੱਡਾ ਪ੍ਰਭਾਵ ਤਕਨੀਕੀ ਤੋਂ ਜ਼ਿਆਦਾ ਸਾਮਾਜਿਕ ਸੀ: ਇਸ ਨੇ ਫਿਕਸ ਸ਼ੇਅਰ ਕਰਨ, ਬਦਲਾਵਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰਨ ਅਤੇ ਭਰੋਸੇਯੋਗ ਰਿਲੀਜ਼ ਜਾਰੀ ਕਰਨ ਦਾ ਇੱਕ ਮੁੜ-ਪ੍ਰਯੋਗਯੋਗ ਤਰੀਕਾ ਬਣਾਇਆ, ਜਿਸ ਨਾਲ ਵੈੱਬ ਸਰਵਰ ਇੱਕ ਭਰੋਸੇਯੋਗ ਢਾਂਚਾ ਬਣ ਗਿਆ।
ਇੱਕ ਵੈੱਬ ਸਰਵਰ ਉਹ ਸੌਫਟਵੇਅਰ ਹੈ ਜੋ ਬ੍ਰਾਊਜ਼ਰਾਂ ਤੋਂ ਆਉਣ ਵਾਲੀਆਂ HTTP ਬੇਨਤੀਆਂ ਸਵੀਕਾਰ ਕਰਦਾ ਅਤੇ ਪੰਨੇ, ਚਿੱਤਰ ਅਤੇ ਹੋਰ ਫਾਇਲਾਂ ਵਾਪਸ ਕਰਦਾ ਹੈ।
ਜੇ ਸਰਵਰ ਠੱਗ ਜਾਂ ਧੀਮਾ ਹੋ ਜਾਂਦਾ ਹੈ ਜਾਂ ਘਾਤਕ ਸੁਰੱਖਿਆ ਦੀਆਂ ਖਾਮੀਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਸਾਈਟ ਫੇਲ ਹੋ ਜਾਂਦੀ ਹੈ—ਚਾਹੇ ਸਮੱਗਰੀ ਜਾਂ ਬ੍ਰਾਊਜ਼ਰ ਕਿੰਨੇ ਹੀ ਚੰਗੇ ਹੋਣ।
“ਖੁੱਲਾ ਸਰੋਤ ਢਾਂਚਾ” ਉਹ ਹੈ ਜੋ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵਰਤੀ ਜਾਣ ਵਾਲੀ ਸੌਫਟਵੇਅਰ ਹੈ ਜਿਸਦਾ ਸੋורס ਕੋਡ ਸਰਵਜਨਿਕ ਹੁੰਦਾ ਹੈ ਅਤੇ ਸੁਧਾਰ ਖੁੱਲੇ ਪ੍ਰਕਿਰਿਆ ਰਾਹੀਂ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।
ਅਮਲ ਵਿੱਚ, ਇਸਦਾ ਮਤਲਬ ਹੈ:
ਪੈਚ ਇੱਕ ਛੋਟਾ ਕੋਡ ਬਦਲਾਅ ਹੁੰਦਾ ਹੈ ਜੋ ਕਿਸੇ ਬੱਗ ਨੂੰ ਠੀਕ, ਪ੍ਰਦਰਸ਼ਨ ਸੁਧਾਰਣ ਜਾਂ ਫੀਚਰ ਜੋੜਨ ਲਈ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
Apache ਇੱਕ ਸਮਨਵਿਤ ਪ੍ਰੋਜੈਕਟ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ, ਕਈ ਐਡਮਿੰਸ ਵੱਖ-ਵੱਖ ਪੈਚ ਸੈਟ ਲਗਾ ਰਹੇ ਸਨ, ਜਿਸ ਨਾਲ ਸਫਟਵੇਅਰ ਵਿੱਚ ਟੁੱਟ-ਫੁੱਟ ਹੋ ਰਹੀ ਸੀ। Apache ਨੇ ਪੈਚਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਕੇ ਇੱਕ ਸਾਂਝਾ, ਰੱਖ-ਰਖਾਅ ਵਾਲਾ ਕੋਡਬੇਸ ਬਣਾਉਣ ਦਾ ਮੁੱਖ ਕਦਮ ਚੁੱਕਿਆ, ਤਾਂ ਜੋ ਹਰ ਕੋਈ ਫਾਇਦਾ ਉਠਾ ਸਕੇ।
ਉਹ ਨਿੱਕ-ਨਾਂਵੇਂ ਨਾਮ ਆਮ ਤੌਰ 'ਤੇ “a patchy server” ਵਜੋਂ ਸਮਝਾਇਆ ਜਾਂਦਾ ਹੈ, ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ ਸ਼ੁਰੂਆਤੀ Apache ਰਿਲੀਜ਼ ਕਈ ਕਮਿਊਨਿਟੀ ਫਿਕਸਾਂ ਤੋਂ ਜੋੜ ਕੇ ਬਣੇ ਸਨ।
ਚਾਹੇ ਹਰ ਇਕ ਵੇਰਵਾ ਬਿਲਕੁਲ ਸਹੀ ਹੋਵੇ ਜਾਂ ਨਾ, ਇਹ ਨਾਂ ਰਹਿ ਗਿਆ ਕਿਉਂਕਿ ਇਹ ਸੱਚ ਬਿਆਨ ਕਰਦਾ ਸੀ: Apache ਹੌਲੀ-ਹੌਲੀ, ਸਾਂਝੇ ਢੰਗ ਨਾਲ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਜ਼ਰੂਰਤਾਂ ਤੋਂ ਪ੍ਰੇਰਿਤ ਸੁਧਾਰਾਂ ਰਾਹੀਂ ਅੱਗੇ ਵਧਿਆ।
Brian Behlendorf ਇੱਕ ਯੋਗਦਾਨਕਾਰ, ਆਯੋਜਕ ਅਤੇ ਵਕੀਲ ਵਜੋਂ ਵੇਖਿਆ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਉਹ ਇੰਜੀਨੀਅਰਿੰਗ ਅਤੇ ਸਮਨਵਯ ਦੋਹਾਂ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਸੀ।
ਉਹ ਦੀਆਂ ਤਰਜੀਹਾਂ ਪ੍ਰਯੋਗਿਕ ਸਨ—ਤੀਬਰਤਾ, ਭਰੋਸੇਯੋਗਤਾ ਅਤੇ ਬਦਲਾਵਾਂ ਨੂੰ ਇਕਠੇ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ—ਅਤੇ ਉਸ ਨੇ ਫੈਲੀਆਂ ਹੋਈਆਂ ਫਿਕਸਾਂ ਨੂੰ ਇੱਕ ਐਸੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਬਦਲਣ ਵਿੱਚ ਸਹਾਇਤਾ ਕੀਤੀ ਜੋ ਅਸਲੀ ਸਾਈਟਾਂ ਚਲਾ ਸਕੇ।
Apache ਗਰੁੱਪ ਨੇ “ਛੋਟੀ ਕੋਰ, ਚੌੜੀ ਕਮਿਊਨਿਟੀ” ਮਾਡਲ ਵਰਤਿਆ।
ਆਮ ਤਰੀਕਾ:
Apache ਦੀ ਮਾਡਿਊਲਰ ਡਿਜ਼ਾਇਨ ਨੇ ਐਡਮਿਨ ਨੂੰ ਸਿਰਫ਼ ਉਹ ਚੀਜ਼ਾਂ ਚਾਲੂ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਦਿਤੀ ਜੋ ਉਹਨਾਂ ਨੂੰ ਚਾਹੀਦੀਆਂ ਸਨ, नਾਂ ਕਿ ਇਕ-ਸਾਈਜ਼-ਸਭ ਲਈ ਸਰਵਰ ਲੈਣੀ ਪਈ।
ਇਸ ਨਾਲ ਆਸਾਨੀ ਹੋਈ:
ਲਾਇਸੈਂਸਿੰਗ ਬਿਜ਼ਨਸ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ—ਤੁਸੀਂ ਕੀ ਕਰ ਸਕਦੇ ਹੋ, ਕਿਹੜੀਆਂ ਨੋਟਿਸਾਂ ਰੱਖਣੀਆਂ ਨੇ, ਅਤੇ ਦੁਬਾਰਾ ਵਰਤੋਂ ਕਿਵੇਂ ਹੋ ਸਕਦੀ ਹੈ।
ਸਪਸ਼ਟ ਲਾਇਸੈਂਸ ਨੇ ਅਣਿਸ਼ਚਿਤਤਾ ਘਟਾਈ ਅਤੇ ਕੰਪਨੀਆਂ ਨੂੰ Apache 'ਤੇ ਮਿਆਰੀਕਰਨ ਕਰਨ ਵਿੱਚ ਅਸਾਨੀ ਦਿੱਤੀ—ਇੱਕ ਕਾਰਨ ਇਹ ਕਿ ਇਹ ਸਾਡਾ ਭਰੋਸੇਯੋਗ ਢਾਂਚਾ ਬਣਿਆ।
Apache “ਡਿਫ਼ਾਲਟ” ਬਣ ਗਿਆ ਕਿਉਂਕਿ ਇਹ ਪੈਕੇਜਡ, ਦਸਤਾਵੇਜ਼ੀਕ੍ਰਿਤ ਅਤੇ ਹਰ ਜਗ੍ਹਾ ਉਪਲਬਧ ਸੀ।
Linux ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਅਤੇ ਹੋਸਟਿੰਗ ਪ੍ਰੋਵਾਈਡਰਾਂ ਨੇ ਇਸਨੂੰ ਵਿਆਪਕ ਰੂਪ ਵਿੱਚ ਸ਼ਪਿੰਗ ਅਤੇ ਸਹਿਯੋਗ ਦੇ ਕੇ ਅਨੁਕੂਲਤਾ ਵਧਾਈ—ਇਸਕਰ ਕੇ ਇੰਸਟਾਲੇਸ਼ਨ ਤੇ ਰੱਖ-ਰਖਾਅ ਆਸਾਨ ਹੋ ਗਏ ਅਤੇ ਸਿਖਲਾਈ ਸਮੱਗਰੀ ਇੱਕ ਹੀ ਆਧਾਰ ਮੰਨ ਕੇ ਤਿਆਰ ਕੀਤੀ ਜਾ ਸਕੀ।