ਬ੍ਰਾਇਨ ਬਹਿਲੇਨਡੌਫ, ਅਪਾਚੀ ਅਤੇ ਖੁੱਲ੍ਹਾ ਵੈੱਬ ਦਾ ਉਭਾਰ

ਰੋਜ਼ਾਨਾ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਵੈੱਬ ਲਈ Apache ਦਾ ਮਹੱਤਵ

1990 ਦੇ ਦਹਾਕੇ ਦੇ ਦਰਮਿਆਨ, ਵੈੱਬ ਅਜੇ ਇਮਤਿਹਾਨੀ ਲੱਗਦੀ ਸੀ—ਅਤੇ ਇਸ ਕਾਬਲ ਸੀ ਕਿ ਇਕ ਹੀ ਸੌਫਟਵੇਅਰ ਚੋਣ ਨੇ ਲੋਕਾਂ ਦਾ ਆਨਲਾਈਨ ਤਜਰਬਾ ਬਦਲ ਸਕਦਾ ਸੀ। ਹਰ ਪੇਜ਼ਵਿਊ ਉਸ ਮਸ਼ੀਨ 'ਤੇ ਨਿਰਭਰ ਸੀ ਜੋ ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰ ਸਕਦੀ ਸੀ, HTTP ਬੇਨਤੀਆਂ ਸਮਝ ਸਕਦੀ ਸੀ ਅਤੇ ਫਾਇਲਾਂ ਤੇਜ਼ੀ ਨਾਲ ਅਤੇ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਭੇਜ ਸਕਦੀ ਸੀ। ਜੇ ਉਹ “ਵੈੱਬ ਸਰਵਰ” ਲੇਅਰ ਫੇਲ ਹੋ ਜਾਂਦੀ, ਤਾਂ ਵੈੱਬ ਦੀ ਹੋਰ ਕੋਈ ਗਾਰੰਟੀ ਮਾਇਨੇ ਨਹੀਂ ਰੱਖਦੀ।

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

ਸ਼ੁਰੂਆਤੀ ਵੈੱਬ ਦਾ ਛੁਪਿਆ ਇੰਜਿਨ: ਸਰਵਰ

ਬ੍ਰਾਊਜ਼ਰ ਧਿਆਨ ਖਿੱਚਦੇ ਸਨ, ਪਰ ਸਰਵਰ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੇ ਸਨ ਕਿ ਵੈੱਬਸਾਈਟਾਂ ਚੱਲਦੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ, ਚੰਗੀ ਪ੍ਰਦਰਸ਼ਨ ਦਿੰਦੀਆਂ ਹਨ ਅਤੇ ਵਧ ਸਕਦੀਆਂ ਹਨ। ਹੋਸਟਿੰਗ ਕੰਪਨੀਆਂ, ਯੂਨੀਵਰਸਿਟੀਆਂ, ਸ਼ੌਕੀਨ ਸਾਈਟਾਂ ਅਤੇ ਨਵੀਆਂ ਕਾਰੋਬਾਰਾਂ ਨੂੰ ਸਾਰੇ ਇੱਕੋ-ਏਹ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਚਾਹੀਦੀਆਂ ਸਨ:

• ਇੱਕ ਐਸਾ ਸਰਵਰ ਜੋ ਲੋਡ 'ਤੇ ਨਾ ਡਿੱਗੇ
• ਬੱਗ ਤੁਰੰਤ ਠੀਕ ਕਰਨ ਦਾ ਤਰੀਕਾ
• ਫੀਚਰਾਂ ਜੋ ਵੈੱਬ ਨਾਲ ਬਦਲ ਸਕਣ

ਜਦੋਂ ਇਹ ਲੋੜਾਂ ਪੂਰੀਆਂ ਨਹੀਂ ਹੁੰਦੀਆਂ, ਨਤੀਜਾ ਧੀਮੇ ਪੇਜ਼, ਡਾਊਨਟਾਈਮ ਅਤੇ ਸੁਰੱਖਿਆ ਖਾਮੀਆਂ ਬਣਦਾ—जेਹੜਾ ਗ੍ਰਹੱਕਤਾ ਘਟਾਉਂਦਾ।

ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ "ਖੁੱਲਾ ਸਰੋਤ ਢਾਂਚਾ"

“ਖੁੱਲਾ ਸਰੋਤ ਢਾਂਚਾ” ਕੋਈ ਫੈਸ਼ਨਾਤਮਕ ਸ਼ਬਦ ਨਹੀਂ—ਇਹ ਇੰਟਰਨੇਟ ਦੀ ਸਾਂਝੀ ਪਾਈਪਿੰਗ ਹੈ: ਉਹ ਸੌਫਟਵੇਅਰ ਜਿਸ 'ਤੇ ਕਈ ਸੰਗਠਨ ਨਿਰਭਰ ਕਰਦੇ ਹਨ, ਜਿਸਦਾ ਸੋਰਸ ਕੋਡ ਖੁੱਲ੍ਹਾ ਹੁੰਦਾ ਅਤੇ ਸੁਧਾਰ ਪ੍ਰਕਾਸ਼ਿਤ ਢੰਗ ਨਾਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।

ਅਮਲੀ ਤੌਰ 'ਤੇ, ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਹੈ:

• ਕੋਈ ਵੀ ਦੇਖ ਸਕਦਾ ਹੈ ਕਿ ਸਰਵਰ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ (ਸੁਰੱਖਿਆ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਲਈ ਲਾਭਦਾਇਕ)
• ਬੱਗ ਉਹ ਲੋਕ ਠੀਕ ਕਰ ਸਕਦੇ ਹਨ ਜੋ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਦਰਦ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ
• ਕੋਈ ਇਕ ਵੈਪਾਰੀ ਰੋਡਮੇਪ ਜਾਂ ਸੌਫਟਵੇਅਰ ਨੂੰ ਇਕੱਲਾ ਨਿਯੰਤਰਿਤ ਨਹੀਂ ਕਰਦਾ

Apache ਸਿਰਫ਼ ਇਕ ਉਤਪਾਦ ਨਹੀਂ ਸੀ; ਇਹ ਫਿਕਸ ਕਰਨ, ਰਿਲੀਜ਼ ਜਾਰੀ ਕਰਨ ਅਤੇ ਭਰੋਸਾ ਬਣਾਉਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵੀ ਸੀ।

ਇਹ ਕਹਾਣੀ ਕਿਹੜਾ ਸਵਾਲ ਜਵਾਬ ਦਿੰਦੀ ਹੈ

Apache ਦਾ ਉਭਾਰ ਲਾਜ਼ਮੀ ਨਹੀਂ ਸੀ। ਇਹ ਕਿਵੇਂ ਹੋਇਆ ਕਿ ਇੱਕ ਕਮਿਊਨਿਟੀ ਪ੍ਰੋਜੈਕਟ—ਪੈਚਾਂ, ਮੈਲਿੰਗ ਲਿਸਟਾਂ ਅਤੇ ਸਾਂਝੇ ਜ਼ਿੰਮੇਵਾਰੀ 'ਤੇ ਬਣਿਆ—ਹੋਸਟਿੰਗ ਲਈ ਡਿਫ਼ਾਲਟ ਚੋਣ ਅਤੇ ਅਸਲ ਵਿੱਚ ਵੈੱਬ ਚਲਾਉਣ ਵਾਲਾ ਪਲੇਟਫਾਰਮ ਬਣ ਗਿਆ? ਅਸੀਂ ਉਹ ਸੂਤਰ ਲੋਕਾਂ, ਤਕਨੀਕੀ ਫੈਸਲਿਆਂ ਅਤੇ ਗਵਰਨੈਂਸ ਮਾਡਲ ਰਾਹੀਂ ਦੇਖਾਂਗੇ ਜਿਸ ਨੇ Apache ਨੂੰ ਕਿਸੇ ਇਕ ਸਰਵਰ ਤੋਂ ਕ jauh 더 ਵੱਡਾ ਮਤਲਬ ਦਿੱਤਾ।

ਬ੍ਰਾਇਨ ਬਹਿਲੇਨਡੌਫ: ਨਿਰਮਾਤਾ ਅਤੇ ਜੋੜਨ ਵਾਲਾ

ਬ੍ਰਾਇਨ ਬਹਿਲੇਨਡੌਫ ਨੂੰ ਅਕਸਰ “Apache ਦੇ ਲੋਕਾਂ ਵਿੱਚੋਂ ਇੱਕ” ਵਜੋਂ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਇਹ ਲੇਬਲ ਉਸਦੀ ਖਾਸ ਕੀਮਤ ਨੂੰ ਘਟਾ ਦਿੰਦਾ ਹੈ: ਉਹ ਸਿਰਫ਼ ਕੋਡ ਨਹੀਂ ਲਿਖਦਾ ਸੀ—ਉਹ ਲੋਕਾਂ ਨੂੰ ਇਕੱਠੇ ਕੰਮ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਸੀ।

Apache ਤੋਂ ਪਹਿਲਾਂ: ਸ਼ੁਰੂਆਤੀ ਵੈੱਬ 'ਤੇ ਅਸਲੀ ਚੀਜ਼ਾਂ ਜਾਰੀ ਕਰਨਾ

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

ਸ਼ੁਰੂਆਤੀ ਵੈੱਬ ਕਮਿਊਨਿਟੀਆਂ ਅਤੇ ਆਨਲਾਈਨ ਸਹਿਯੋਗ

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

ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਉਹ ਸਿਰਫ਼ “ਇੱਕ ਕਮਿਊਨਿਟੀ ਵਿੱਚ” ਨਹੀਂ ਸੀ—ਉਸਨੇ ਕਮਿਊਨਿਟੀ ਨੂੰ ਕਾਮਯਾਬ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕੀਤੀ।

ਉਹ ਸਮੱਸਿਆਵਾਂ ਜਿਨ੍ਹਾਂ 'ਤੇ ਉਹ ਧਿਆਨ ਰੱਖਦਾ ਸੀ

ਬਹਿਲੇਨਡੌਫ ਦੀ ਸ਼ੁਰੂਆਤੀ Apache ਸ਼ਾਮਿਲੀਅਤ ਬਾਰੇ ਵਰਣਨ ਸਧਾਰਨ ਤੌਰ 'ਤੇ ਇੰਜੀਨੀਅਰਿੰਗ ਅਤੇ ਸਮਨਵਯ ਦੇ ਮਿਲੇ-ਜੁਲੇ ਮਾਮਲਿਆਂ ਨੂੰ ਉਜਾਗਰ ਕਰਦਾ ਹੈ। ਉਹਜ਼ਰ ਧਿਆਨ ਕੇਂਦਰਿਤ ਰਹੇ:

• ਤੀਬਰਤਾ: ਪੇਜ਼ ਤੇਜ਼ੀ ਨਾਲ ਲੋਡ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ; ਸਰਵਰ ਸਰੋਤ ਬਰਬਾਦ ਨਾ ਕਰੇ।
• ਭਰੋਸੇਯੋਗਤਾ: ਵੈੱਬ ਸਰਵਰ ਅਸਲੀ ਕਾਰੋਬਾਰ ਅਤੇ ਪ੍ਰਕਾਸ਼ਕਾਂ ਲਈ ਕਾਫ਼ੀ ਸਥਿਰ ਹੋਣਾ ਚਾਹੀਦਾ ਸੀ।
• ਸਮਨਵਯ: ਪੈਚ ਅਤੇ ਵਿਚਾਰਾਂ ਲਈ ਇੱਕ ਸਾਂਝਾ ਪ੍ਰਕਿਰਿਆ ਹੋਣੀ ਚਾਹੀਦੀ ਸੀ, ਬੇਤਰਤੀਬੀ ਨਹੀਂ।

ਯੋਗਦਾਨਕਾਰ, ਆਯੋਜਕ, ਵਕੀਲ

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

ਸ਼ੁਰੂਆਤੀ ਵੈੱਬ ਸਰਵਰ ਸਮੱਸਿਆ (Apache ਤੋਂ ਪਹਿਲਾਂ)

1990 ਦੀਆਂ ਸ਼ੁਰੂਆਤਾਂ ਵਿੱਚ, “ਵੈੱਬ ਹੋਸਟ ਕਰਨਾ” ਅਕਸਰ ਯੂਨੀਵਰਸਿਟੀ ਦੇ ਲੈਬ ਮਸ਼ੀਨ, ਕੰਪਨੀ ਦੇ ਵਰਕਸਟੇਸ਼ਨ ਜਾਂ ਇਕ ਛੋਟੀ ਡੇਡੀਕੇਟਿਡ ਬਾਕਸ 'ਤੇ ਨੈਟਵਰਕ ਲਾਈਨ ਨਾਲ ਕਿਤੇ ਰੱਖਣ ਦਾ ਮਤਲਬ ਸੀ। ਸਾਈਟਾਂ ਸਧਾਰਨ ਸਨ: ਕੁਝ HTML ਪੰਨੇ, ਸ਼ਾਇਦ ਕੁਝ ਚਿੱਤਰ ਅਤੇ ਮੂਲ ਡਾਇਰੈਕਟਰੀ ਬਣਤਰ। ਪਰ ਇਹ ਵੀ ਉਦਿਆਂਗ ਸੀ ਕਿ ਇੱਕ ਐਸਾ ਸੌਫਟਵੇਅਰ ਹੋਵੇ ਜੋ ਬ੍ਰਾਊਜ਼ਰਾਂ ਤੋਂ ਆਉਣ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਜਵਾਬ ਦੇ ਸਕੇ, ਟ੍ਰੈਫਿਕ ਲੌਗ ਕਰ ਸਕੇ ਅਤੇ ਲੰਮ੍ਹੇ ਸਮੇਂ ਤੱਕ ਚੱਲ ਸਕੇ।

ਸਰਵਰ ਵਿਕਲਪ ਅਤੇ ਉਨ੍ਹਾਂ ਦੀਆਂ ਸੀਮਾਵਾਂ

ਕੁਝ ਵੈੱਬ ਸਰਵਰ ਪ੍ਰੋਗਰਾਮ ਮੌਜੂਦ ਸਨ, ਪਰ ਹਰ ਇੱਕ ਦੇ ਆਪਣੇ ਫ਼ਾਇਦੇ-ਨੁਕਸਾਨ ਸਨ। CERN httpd (Tim Berners-Lee ਦੀ ਟੀਮ ਤੋਂ) ਪ੍ਰਭਾਵਸ਼ালী ਸੀ, ਪਰ ਇਹ ਹਰ ਵਾਰੀ ਚਲਾਉਣ ਜਾਂ ਫੈਲਾਉਣ ਲਈ ਸਭ ਤੋਂ ਆਸਾਨ ਨਹੀਂ ਸੀ। ਕੁਝ ਸੰਗਠਨਾਂ ਨੇ ਸ਼ੁਰੂਆਤੀ ਵਪਾਰਕ ਵਿਕਲਪ ਵਰਤੇ, ਪਰ ਉਹ ਮਹਿੰਗੇ, ਕਸਟਮਾਈਜ਼ ਕਰਨ ਵਿੱਚ ਔਖੇ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲ ਰਹੀ ਵੈੱਬ ਦੀਆਂ ਲੋੜਾਂ ਲਈ ਧੀਮੇ ਹੋ ਸਕਦੇ ਸਨ।

ਅਨੇਕ ਪਰਬੰਧਕਾਂ ਲਈ ਪ੍ਰਾਇਕਟਿਕ ਡਿਫਾਲਟ ਬਣਿਆ NCSA httpd, ਜੋ National Center for Supercomputing Applications ਨੇ ਬਣਾਇਆ ਸੀ। ਇਹ ਵਿਆਪਕ ਤੌਰ ਤੇ ਉਪਲਬਧ ਸੀ, ਕਾਫ਼ੀ ਸਿਧਾ ਸੀ ਅਤੇ ਸਹੀ ਸਮੇਂ 'ਤੇ ਆਇਆ—ਜਦੋਂ ਵੈੱਬਸਾਈਟਾਂ ਦੀ ਗਿਣਤੀ ਤੇਜ਼ੀ ਨਾਲ ਵੱਧ ਰਹੀ ਸੀ।

ਪੈਚਾਂ ਦੀ ਮਹੱਤਤਾ

ਵੈੱਬ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਿਆ: ਨਵੇਂ ਬ੍ਰਾਊਜ਼ਰ ਵਰਤਾਰਿਆਂ, ਨਵੀਂਆਂ ਖਾਸੀਅਤਾਂ, ਵਧਦਾ ਟ੍ਰੈਫਿਕ ਅਤੇ ਵੱਧ ਰਹੀਆਂ ਸੁਰੱਖਿਆ ਚਿੰਤਾਵਾਂ। NCSA httpd ਦੀ ਵਿਕਾਸ ਰਫ਼ਤਾਰ ਮੰਦ ਹੋ ਗਈ, ਪਰ ਸੁਧਾਰ ਦੀ ਮੰਗ ਠਹਿਰ ਨਹੀਂ ਗਈ।

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

ਉਹ ਪੈਚ-ਸ਼ੇਅਰਿੰਗ ਸਭਿਆਚਾਰ—ਐਡਮਿਨਾਂ ਦਾ ਮੈਲਿੰਗ ਲਿਸਟਾਂ 'ਤੇ ਫਿਕਸ ਸਾਂਝੇ ਕਰਨਾ ਅਤੇ ਸੌਫਟਵੇਅਰ ਨੂੰ ਸਾਹਮਣੇ ਸੁਧਾਰਨਾ—ਉਸ ਸਟੀਜ ਲਈ ਮੌਕਾ ਬਣਾਉਂਦਾ ਸੀ ਜਿੱਥੇ ਜਲਦੀ ਹੀ Apache ਜਨਮ ਲਿਆ।

ਪੈਚਾਂ ਤੋਂ ਪ੍ਰੋਜੈਕਟ ਤੱਕ: Apache ਦਾ ਜਨਮ

Apache ਕਿਸੇ ਵੱਡੇ ਯੋਜਨਾ ਦੇ ਤੌਰ 'ਤੇ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋਇਆ। ਇਹ ਇੱਕ ਪਰਸ਼ਾਸਕੀ ਜਵਾਬ ਵਜੋਂ ਸ਼ੁਰੂਆਤ ਸੀ: ਲੋਕ ਇਕੋ ਵੈੱਬ ਸਰਵਰ ਸੌਫਟਵੇਅਰ ਚਲਾ ਰਹੇ ਸਨ, ਉਹੀ ਸੀਮਾਵਾਂ ਆ ਰਹੀਆਂ ਸਨ ਅਤੇ ਬਿਲਕੁਲ ਇੱਕੋ ਹੀ ਬੱਗਾਂ ਲਈ ਅਲੱਗ-ਅਲੱਗ ਹੱਲ ਬਣ ਰਹੇ ਸਨ।

ਪੈਚ-ਸ਼ੇਅਰਿੰਗ ਲੂਪ

ਮਿਡ-1990 ਦੇ ਦਹਾਕੇ ਵਿੱਚ, ਬਹੁਤ ਸਾਈਟਾਂ NCSA httpd 'ਤੇ ਨਿਰਭਰ ਸਨ। ਜਦੋਂ ਵਿਕਾਸ ਰੁਕ ਗਿਆ, ਸਰਵਰ ਇਕਦਮ ਕੰਮ ਕਰਨਾ ਛੱਡਿਆ ਨਹੀਂ—ਪਰ ਵੈੱਬ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲ ਰਿਹਾ ਸੀ ਅਤੇ ਓਪਰੇਟਰਾਂ ਨੂੰ ਸੁਧਾਰਾਂ ਦੀ ਲੋੜ ਸੀ: ਵਧੀਆ ਪ੍ਰਦਰਸ਼ਨ, ਬੱਗ ਫਿਕਸ ਅਤੇ ਅਜਿਹੇ ਫੀਚਰ ਜੋ ਅਸਲੀ ਹੋਸਟਿੰਗ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣ।

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

ਆਖਿਰਕਾਰ, ਪੈਚ-ਸ਼ੇਅਰਿੰਗ ਨੇ ਸਮਨਵਯ ਬਣਾਇਆ। ਲੋਕਾਂ ਨੇ ਫਿਕਸਾਂ ਨੂੰ ਇੱਕ ਸਾਂਝੇ ਕੋਡਬੇਸ ਵਿੱਚ ਮਿਲਾਉਣਾ ਸ਼ੁਰੂ ਕੀਤਾ ਤਾਂ ਜੋ ਹੋਰ ਲੋਕਾਂ ਨੂੰ ਆਪਣੀਆਂ ਵਰਜਨਾਂ ਨੂੰ ਜੋੜਨ ਦੀ ਲੋੜ ਨਾ ਪਏ। ਸ਼ੁਰੂਆਤੀ Apache ਰਿਲੀਜ਼ ਆਸਲ ਵਿੱਚ ਪੈਚਾਂ ਦੇ curated ਬੰਡਲ ਅਤੇ ਨਵੇਂ ਪੈਚਾਂ ਨੂੰ ਸ਼ਾਮਿਲ ਕਰਨ ਦਾ ਇੱਕ ਮਕੈਨਿਜ਼ਮ ਸਨ।

“A patchy server” (ਨਾਮ ਕਿਉਂ ਰਹਿ ਗਿਆ)

ਇਹ ਤਖ਼ਨੀਲਕ ਸ਼ੌਕ ਦਾ ਸੰਜੋਗ ਆਮ ਤੌਰ 'ਤੇ “a patchy server” ਵਜੋਂ ਸਮਝਾਇਆ ਜਾਂਦਾ ਹੈ—ਸਰਵਰ ਜੋ ਕਈ ਛੋਟੇ-ਛੋਟੇ ਫਿਕਸਾਂ ਤੋਂ ਟੁਕੜਿਆਂ ਵਿੱਚ ਬਣਿਆ। ਚਾਹੇ ਹਰ ਇਕ ਉਤਪੱਤੀ ਕਹਾਣੀ ਦਾ ਹਰ ਟੁਕੜਾ ਸਹੀ ਹੋਵੇ ਜਾਂ ਨਹੀਂ, ਇਹ ਨਾਮ ਉਸ ਲਹਜੇ ਨੂੰ ਦਰਸਾਉਂਦਾ ਸੀ: ਤਰੱਕੀ ਕਦਮ-ਕਦਮ ਤੇ ਸਾਂਝੀ ਸੀ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਜ਼ਰੂਰਤਾਂ ਨੇ ਉਹਨੂੰ ਚਲਾਇਆ।

ਸੰਰਚਨਾ ਨੂੰ ਵੀ ਕੋਡ ਦੀ ਤਰ੍ਹਾਂ ਮੌਹਤਾਜ਼ੀ ਸੀ

ਜਿਹੜੇ ਸਮੇਂ 'ਤੇ ਕਈ ਲੋਕ ਇੱਕ ਸਾਂਝੇ ਸਰਵਰ ਨੂੰ ਬਣਾਉਂਦੇ ਸਨ, ਮੁਸ਼ਕਲ ਗੱਲ ਕੇਵਲ ਪੈਚ ਲਿਖਣਾ ਨਹੀਂ ਰਹਿ ਗਈ—ਮੁਸ਼ਕਲ ਇਹ ਸੀ ਕਿ ਕੀ ਕਬ ਆਪਣੀਰਾ(function) ਘੁਸ਼ ਕਰਨਾ ਹੈ, ਕਦੋਂ ਰਿਲੀਜ਼ ਕਰਨੀ ਹੈ ਅਤੇ ਗੈਰ-ਇਹਿਮੀ ਵਿਚਾਰਾਂ ਨੂੰ ਕਿਵੇਂ ਨਿਪਟਾਰਾ ਕਰਨਾ ਹੈ।

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

Apache ਉਸ ਸਮੇਂ ਜਨਮ ਲਿਆ ਜਦੋਂ ਕਮਿਊਨਿਟੀ ਨੇ ਪੈਚਿੰਗ ਨੂੰ ਸਾਂਝੇ ਜ਼ਿੰਮੇਵਾਰੀ ਵਜੋਂ ਲਿਆ ਅਤੇ ਉਸਨੂੰ ਸਸਤੇ ਸਥਾਈ ਰਵੱਈਏ ਬਣਾਏ।

Apache Group ਦਾ ਕੰਮ ਕਰਨ ਦਾ ਢੰਗ (ਅਤੇ ਇਹ ਕਿਵੇਂ ਪੈਮਾਨੇ 'ਤੇ ਵਧਿਆ)

Apache ਇਸ ਲਈ ਨਹੀਂ ਵਧਿਆ ਕਿ ਇੱਕ ਵਿਅਕਤੀ ਸਾਰਾ ਕੰਮ ਲਿਖਾ। ਇਹ ਵਧਿਆ ਕਿਉਂਕਿ ਇਕ ਛੋਟੀ ਕੋਰ ਟੀਮ ਨੇ ਬਹੁਤ ਸਾਰੇ ਲੋਕਾਂ ਲਈ ਬਿਨਾਂ ਹੰਗਾਮੇ ਯੋਗਦਾਨ ਕਰਨ ਦਾ ਤਰੀਕਾ ਬਣਾਇਆ।

ਛੋਟੀ ਕੋਰ ਟੀਮ, ਸਾਂਝੀ ਜ਼ਿੰਮੇਵਾਰੀ

Apache Group ਨੇ “ਛੋਟੀ ਕੋਰ, ਵਿਆਪਕ ਕਮਿਊਨਿਟੀ” ਮਾਡਲ ਅਪਣਾਇਆ। ਇਕ ਸਬੰਧਤ ਛੋਟੀ ਗਿਣਤੀ ਵਾਲੇ ਲੋਕਾਂ ਕੋਲ commit access ਸੀ (ਜੋ ਬਦਲਾਅ ਮਿਲਾਉਂਦੇ), ਪਰ ਕੋਈ ਵੀ ਫਿਕਸ ਸੁਝਾ ਸਕਦਾ, ਬੱਗ ਰਿਪੋਰਟ ਕਰ ਸਕਦਾ ਜਾਂ ਸੁਧਾਰ ਪ੍ਰਸਤਾਵਿਤ ਕਰ ਸਕਦਾ।

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

ਚਰਚਾ ਅਤੇ ਸਹਿਮਤੀ ਨਾਲ ਫੈਸਲੇ

ਬੰਦ ਮੀਟਿੰਗਾਂ ਦੀ ਥਾਂ, ਕੇਸਰੇ ਫੈਸਲੇ ਜ਼ਿਆਦਾਤਰ ਮੈਲਿੰਗ ਲਿਸਟਾਂ 'ਤੇ ਹੁੰਦੇ। ਇਸਦਾ ਮਤਲਬ:

• ਵੱਖ-ਵੱਖ ਟਾਈਮਜ਼ੋਨਾਂ ਦੇ ਲੋਕ ਹਿੱਸਾ ਲੈ ਸਕਦੇ ਸਨ
• ਕਿਸੇ ਬਦਲਾਅ ਦੇ ਪਿੱਛੇ ਤਰਕ ਦਰਜ ਰਹਿੰਦਾ
• ਨਵੇਂ ਯੋਗਦਾਨਕਾਰ ਪਿਛਲੇ ਥ੍ਰੈਡ ਪੜ੍ਹਕੇ ਸਿੱਖ ਸਕਦੇ ਸਨ

ਸਹਿਮਤੀ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਹਰ ਕੋਈ ਖੁਸ਼ ਹੋਵੇ; ਮਤਲਬ ਇਹ ਸੀ ਕਿ ਗਰੁੱਪ ਵਿਆਪਕ ਸਹਿਮਤੀ ਲਈ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ, ਇਤਰਾਜ਼ ਖੁੱਲ੍ਹੇ ਤੌਰ 'ਤੇ ਨਿਪਟਾਏ ਜਾਂਦੇ ਅਤੇ ਅਚਾਨਕ ਬਦਲਾਵ ਜੋ ਹੋਰਾਂ ਦਾ ਕੰਮ ਤੋੜ ਸਕਦੇ ਹਨ, ਰੋਕੇ ਜਾਂਦੇ।

ਖੁੱਲ੍ਹਾਪਣ ਨੇ ਗੁਣਵੱਤਾ ਅਤੇ ਭਰੋਸਾ ਕਿਵੇਂ ਵਧਾਇਆ

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

ਰਿਲੀਜ਼ ਪ੍ਰਬੰਧਨ ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ

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

ਉਹ ਡਿਜ਼ਾਇਨ ਚੋਣ ਜੋ Apache ਦੀ ਕਬੂਲਤਾ ਨੂੰ ਮਦਦ ਕੀਤੀਆਂ

Apache ਮੁਫ਼ਤ ਹੋਣ ਦੇ ਕਾਰਨ ਹੀ ਲੋਕਾਂ ਦਾ ਮਨ ਜਿੱਤਿਆ ਨਹੀਂ। ਇਸਨੇ ਦਿਨ-ਪ੍ਰਤੀ ਦਿਨ ਦੇ ਡਿਜ਼ਾਇਨ ਨਾਲ ਅਸਲੀ ਲੋਕਾਂ ਵਾਲੀਆਂ ਵੈੱਬਸਾਈਟਾਂ ਲਈ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਬਣਨ ਦਾ ਰਾਸ਼ਤਾ ਚੁਣਿਆ।

ਮਾਡਿਊਲ ਪਹੁੰਚ — ਪਲੱਗਇਨ ਵਰਗੀ ਸੁਵਿਧਾ

ਇੱਕ ਵੱਡੇ, ਫਿਕਸ ਪ੍ਰੋਗਰਾਮ ਦੀ ਥਾਂ, Apache ਐਡ-ਓਨਸ (ਮੋਡੀਊਲ) ਸਵੀਕਾਰ ਕਰਨ ਲਈ ਬਣਾਇਆ ਗਿਆ। ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ: ਕੋਰ ਵੈੱਬ ਸਰਵਰ ਬੁਨਿਆਦੀ ਕੰਮ (ਬੇਨਤੀਆਂ ਪ੍ਰਾਪਤ ਕਰਨ ਅਤੇ ਪੰਨਿਆਂ ਭੇਜਣ) ਸੰਭਾਲਦਾ ਹੈ, ਅਤੇ ਮੋਡੀਊਲ ਤੁਹਾਨੂੰ ਹੋਰ ਖਾਸੀਅਤਾਂ ਚਾਲੂ ਕਰਨ ਦਿੰਦੇ—ਜਿਵੇਂ ਬਰਾਊਜ਼ਰ ਪਲੱਗਇਨ।

ਇਸਦਾ ਮਤਲਬ ਇਹ ਸੀ ਕਿ ਇਕ ਸੰਗਠਨ ਸਰਲਤਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਸੀ ਅਤੇ ਫਿਰ ਫੀਚਰ ਜੋੜ ਸਕਦਾ ਸੀ ਜਿਵੇਂ URL rewriting, authentication, compression ਜਾਂ ਵੱਖ-ਵੱਖ ਸਕ੍ਰਿਪਟਿੰਗ ਸੈਟਅੱਪ ਬਿਨਾਂ ਪੂਰੇ ਸਰਵਰ ਨੂੰ ਬਦਲੇ।

ਸੰਰਚਨਾ ਫ਼ਾਇਦਾ

Apache ਦੀ ਸੰਰਚਨਾ ਫਾਈਲਾਂ ਨੇ ਇਸਨੂੰ ਅਨੁਕੂਲ ਬਣਾਇਆ। ਹੋਸਟਿੰਗ ਪ੍ਰਦਾਤਾ ਇੱਕ ਮਸ਼ੀਨ 'ਤੇ ਕਈ ਸਾਈਟਾਂ ਚਲਾ ਸਕਦੇ ਸਨ, ਹਰ ਇੱਕ ਦੀਆਂ ਆਪਣੀਆਂ ਸੈਟਿੰਗਾਂ ਨਾਲ। ਛੋਟੀ ਸਾਈਟਾਂ ਘੱਟ ਰੱਖ ਸਕਦੀਆਂ ਸਨ। ਵੱਡੀਆਂ ਸੰਥਾਵਾਂ caching, ਸੁਰੱਖਿਆ ਨਿਯਮ ਅਤੇ ਡਾਇਰੈਕਟਰੀ-ਸਤਰ ਪਰਮਿਸ਼ਨਾਂ ਲਈ ਟਿਊਨ ਕਰ ਸਕਦੀਆਂ ਸਨ।

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

ਭਰੋਸਾ ਪੈਦਾ ਕਰਨ ਵਾਲੀਆਂ ਵਿਹਾਰੀਆਂ

Apache ਨੇ ਬੁਨਿਆਦੀ ਪਰ ਜਰੂਰੀ ਭਰੋਸੇਯੋਗਤਾ ਅਭਿਆਸਾਂ ਤੋਂ ਵੀ ਲਾਭ ਲਿਆ:

• ਸਥਿਰ ਰਿਲੀਜ਼: ਐਡਮਿਨ ਪ੍ਰੋਡਕਸ਼ਨ ਲਈ ਉਪਯੋਗ ਵਰਜ਼ਨ ਚੁਣ ਸਕਦੇ ਸਨ
• ਸਮੀਖਿਆ ਕੀਤੇ ਬਦਲਾਅ: ਪੈਚ ਸਿਰਫ਼ ਇਕੱਠੇ ਨਹੀਂ ਹੋਏ; ਉਨ੍ਹਾਂ 'ਤੇ ਚਰਚਾ ਅਤੇ ਟੈਸਟ ਹੋਇਆ
• ਸਪਸ਼ਟ ਜ਼ਿੰਮੇਵਾਰੀ: ਸਰਵਰ ਦੇ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਦੇ ਲੋਕ ਉਨ੍ਹਾਂ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਰਹੇ

ਨਤੀਜਾ ਪੇਸ਼ਗੋਈਯੋਗ ਵਿਹਾਰ ਸੀ—ਜਦੋਂ ਤੁਹਾਡੀ ਵੈੱਬਸਾਈਟ ਤੁਹਾਡਾ ਕਾਰੋਬਾਰ ਹੁੰਦੀ ਹੈ, ਇਹ ਇੱਕ ਘੱਟ-ਅੰਕਿਤ ਫੀਚਰ ਨਹੀਂ।

ਐਡਮਿਨਾਂ ਨੂੰ ਕੀ ਪਸੰਦ ਆਇਆ

ਐਡਮਿਨਾਂ ਨੂੰ Apache ਇਸ ਲਈ ਪਸੰਦ ਆਇਆ ਕਿ ਇਸਦੀ ਦਸਤਾਵੇਜ਼ੀ, ਜਵਾਬਦੇਹ ਮੈਲਿੰਗ ਲਿਸਟਾਂ ਅਤੇ ਇੱਕੋ ਜਿਹੀ ਢੰਗ ਨਾਲ ਕੰਫਿਗਰੇਸ਼ਨ ਵਰਤੀ ਜਾਂਦੀ। ਜਦੋਂ ਕੁਝ ਟੁੱਟਦਾ, ਆਮ ਤੌਰ 'ਤੇ ਡਾਇਗਨੋਜ਼ ਕਰਨ ਦਾ ਜਾਣਿਆ ਹੋਇਆ ਤਰੀਕਾ ਹੁੰਦਾ, ਪੁੱਛਣ ਲਈ ਥਾਂ ਹੁੰਦੀ ਅਤੇ ਇੱਕ ਫਿਕਸ ਜੋ ਪੂਰੇ ਸਟੈਕ ਨੂੰ ਮੁੜ-ਬਨਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਨਾ ਪਵੇ।

ਕਾਰੋਬਾਰਾਂ ਲਈ ਖੁੱਲ੍ਹੀ ਸਰੋਤ ਲਾਇਸੈਂਸਿੰਗ ਅਤੇ ਭਰੋਸਾ

ਖੁੱਲ੍ਹਾ ਸਰੋਤ ਸਿਰਫ਼ ਇਹ ਨਹੀਂ ਕਿ “ਕੋਡ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ।” ਕੰਪਨੀਆਂ ਲਈ ਜਿਹੜੀਆਂ ਐਕਰੀਟਿਕ ਸਰਵਰਾਂ 'ਤੇ ਚੱਲਦੀ ਹਨ, ਲਾਇਸੈਂਸ ਉਹ ਕਾਨੂੰਨੀ ਨਿਯਮਾਂ ਦੀ ਕਾਪੀ ਹੈ ਜੋ ਅਮਲੀ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ: ਮੈਂ ਕੀ ਕਰ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ? ਮੈਨੂੰ ਕੀ ਕਰਨਾ ਜਰੂਰੀ ਹੈ? ਮੈਂ ਕਿਹੜਾ ਜੋਖ਼ਮ ਲੈ ਰਹਾ/ਰਹੀ ਹਾਂ?

ਲਾਇਸੈਂਸਿੰਗ ਦਾ ਸਧਾਰਨ ਸਿੱਧਾਂਤ

ਕੋਈ ਸਪਸ਼ਟ ਖੁੱਲ੍ਹੀ ਲਾਇਸੈਂਸ ਆਮ ਤੌਰ 'ਤੇ ਤਿੰਨ ਚੀਜ਼ਾਂ ਕਵਰ ਕਰਦੀ ਹੈ:

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

Apache ਲਈ ਇਹ ਸਪਸ਼ਟਤਾ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਬਰਾਬਰ ਮਹੱਤਵਪੂਰਨ ਸੀ। ਜਦੋਂ ਸ਼ਰਤਾਂ ਸਮਝਣ ਯੋਗ ਅਤੇ ਲਗਾਤਾਰ ਹੁੰਦੀਆਂ ਹਨ, ਕਾਨੂੰਨੀ ਅਤੇ ਪ੍ਰੋਕਿਊਰਮੈਂਟ ਟੀਮਾਂ ਤੇਜ਼ੀ ਨਾਲ ਮਨਜ਼ੂਰੀ ਦੇ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਇੰਜਨੀਅਰਿੰਗ ਟੀਮਾਂ ਘੱਟ ਅਚਾਨਕੀ ਨਾਲ ਯੋਜਨਾ ਬਣਾ ਸਕਦੀਆਂ ਹਨ।

ਕਾਰੋਬਾਰਾਂ ਨੇ ਇਸ 'ਤੇ ਕਿਉਂ ਭਰੋਸਾ ਕੀਤਾ

ਕਾਰੋਬਾਰਾਂ ਨੇ Apache ਨੂੰ ਇਸ ਲਈ ਅਪਣਾਇਆ ਕਿ ਲਾਇਸੈਂਸ ਅਣਿਸ਼ਚਿਤਤਾ ਘਟਾਉਂਦਾ ਸੀ। ਸਪਸ਼ਟ ਸ਼ਰਤਾਂ ਨੇ ਸਹਾਇਤਾ ਕੀਤੀ:

• ਕਈ ਪ੍ਰੋਜੈਕਟਾਂ 'ਤੇ ਇੱਕੋ ਵੈੱਬ ਸਰਵਰ ਮਿਆਰੀਕਰਨ ਕਰਨ
• ਅਨੁਕੂਲਤਾ ਦੀ ਜਾਂਚ ਤੇਜ਼ੀ ਨਾਲ ਕਰਨ (ਕਿਹੜੀਆਂ ਨੋਟਿਸਾਂ ਰੱਖਣੀਆਂ ਹਨ, ਕਿਹੜੀਆਂ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਨੇ)
• ਇੱਕ ਹੱਥ ਜਾਂ ਇਕ ਵੈਪਾਰੀ ਦੀ ਬਦਲਦੀਆਂ ਨੀਤੀਆਂ 'ਤੇ ਕੰਪਨੀ ਦਾ ਦਾਊ ਉੱਪਰ ਨਾ ਲਗੇ

ਇਹ ਭਰੋਸਾ Apache ਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਹੋਬੀ ਪ੍ਰੋਜੈਕਟ ਤੋਂ ਢਾਂਚਾ ਬਣਾ ਗਿਆ।

ਵੈਂਡਰ ਲਾਕ-ਇਨ ਘਟਦਾ—ਪਰ ਜਾਦੂ ਨਹੀਂ

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

ਟ੍ਰੇਡ-ਆਫ ਅਮਲੀ ਹੈ: “ਮੁਫ਼ਤ” ਦਾ ਮਤਲਬ ਦਿਲਚਸਪ ਨਹੀਂ; ਸਹਾਇਤਾ ਫਿਰ ਵੀ ਸਮਾਂ, ਹੁਨਰ, ਨਿਗਰਾਨੀ ਅਤੇ ਅੱਪਡੇਟ ਯੋਜਨਾ ਲੈਂਦੀ ਹੈ—ਚਾਹੇ ਤੁਸੀਂ ਆਪਣੇ ਆਪ ਕਰੋ ਜਾਂ ਕਿਸੇ ਪ੍ਰੋਵਾਈਡਰ ਨੂੰ ਭੁਗਤਾਨ ਕਰੋ।

Apache Software Foundation ਅਤੇ ਠੋਸ ਗਵਰਨੈਂਸ

Apache ਦੀ ਕਾਮਯਾਬੀ ਸਿਰਫ਼ ਚੰਗੇ ਕੋਡ ਅਤੇ ਸਮੇਂ-ਉਪਯੋਗ ਪੈਚਾਂ ਬਾਰੇ ਨਹੀਂ ਸੀ—ਇਹ ਇੱਕ ਢਾਂਚੇਦਾਰ ਤਰੀਕੇ ਨਾਲ ਇਕ ਛੋਟੀ ਗਰੁੱਪ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਬਣਾਉਣ ਬਾਰੇ ਸੀ ਜੋ ਕਿਸੇ ਵੀ ਵਿਅਕਤੀ ਤੋਂ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਟਿਕ ਸਕੇ।

ਗੈਰ-ਅਨੌਪਚਾਰਿਕ ਟੀਮ ਤੋਂ ਇੱਕ ਸੰਸਥਾ ਤੱਕ

ਕਮਿਊਨਿਟੀ ਨੂੰ Apache Software Foundation (ASF) ਵਿੱਚ ਰੂਪਾਂਤਰਨ ਕਰਨ ਨਾਲ ਫੈਸਲਿਆਂ ਦਾ ਤਰੀਕਾ, ਨਵੇਂ ਪ੍ਰੋਜੈਕਟਾਂ ਨਾਲ ਸ਼ਾਮਿਲ ਹੋਣ ਦਾ ਤਰੀਕਾ ਅਤੇ “Apache ਦਾ ਹਿੱਸਾ ਹੋਣ” ਦੀਆਂ ਜ਼ਰੂਰੀਆਂ ਸ਼ਰਤਾਂ ਨਿਰਧਾਰਤ ਹੋ ਗਈਆਂ। ਇਹ ਬਦਲਾਅ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਗੈਰ-ਅਨੌਪਚਾਰਿਕ ਟੀਮਾਂ ਅਕਸਰ ਕੁਝ ਜ਼ੋਰਦਾਰ ਲੋਕਾਂ 'ਤੇ ਨਿਰਭਰ ਰਹਿੰਦੀਆਂ ਹਨ; ਜਦੋਂ ਉਹ ਲੋਕ ਨੌਕਰੀ ਬਦਲਦੇ ਜਾਂ ਥੱਕ ਜਾਂਦੇ ਹਨ, ਤਰੱਕੀ ਰੁਕ ਸਕਦੀ ਹੈ।

ਇੱਕ ਫਾਊਂਡੇਸ਼ਨ ਨਾਲ, ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਲਗਾਤਾਰ ਰੱਖਣ ਲਈ ਇੱਕ ਘਰ ਮਿਲਦਾ ਹੈ। ਉਹ ਸਥਿਰ ਮੇਜ਼ਬਾਨੀ, ਦਸਤਾਵੇਜ਼, ਰਿਲੀਜ਼ ਅਤੇ ਕਮਿュਨਿਟੀ ਨਿਯਮਾਂ ਲਈ ਇੱਕ ਥਾਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ—ਭਾਵੇਂ ਇਨ੍ਹੇ ਵਿੱਚੂਕ ਵਿੱਚ maintainers ਬਦਲਦੇ ਰਹਿਣ।

ਗਵਰਨੈਂਸ ਦੀ ਮਹੱਤਤਾ (ਭਾਵੇਂ ਤੁਸੀਂ ਬਾਇਲਾਜ਼ ਨਾ ਪੜ੍ਹੋ)

ਗਵਰਨੈਂਸ ਬਿਊਰੋਕਰੇਸੀ ਜਾਪਦੀ ਹੈ, ਪਰ ਇਹ ਅਮਲੀ ਮੁੱਦੇ ਹੱਲ ਕਰਦੀ ਹੈ:

• ਟ੍ਰੇਡਮਾਰਕ ਅਤੇ ਨਾਮਕਰਨ: “Apache” ਸਿਰਫ਼ ਇਕ ਲੇਬਲ ਨਹੀਂ; ਫਾਊਂਡੇਸ਼ਨ ਨਾਮ ਦੀ ਰੱਖਿਆ ਕਰ ਸਕਦੀ ਹੈ ਤਾਂ ਕਿ ਉਪਭੋਗਤਾ ਜਾਣ ਸਕਣ ਕਿ ਕੀ ਅਧਿਕਾਰਿਕ ਹੈ
• ਸੰਭਾਲ ਅਤੇ ਨੈਤ੍ਰਿਤਵ ਦੀ ਨਿਊਟਰਲ ਜਗ੍ਹਾ: ਫਾਊਂਡੇਸ਼ਨ ਮੁਕਾਬਲੇ ਕਰਨ ਵਾਲੀਆਂ ਕੰਪਨੀਆਂ ਨੂੰ ਇੱਕ ਨਿਰਪੱਖ ਜਗ੍ਹਾ ਦਿੰਦੀ ਹੈ ਜਿੱਥੇ ਉਹ ਸਾਥ-ਕਾਰਜ ਕਰ ਸਕਦੀਆਂ ਹਨ
• ਸਪਸ਼ਟ ਫੈਸਲਾ-ਗ੍ਰਹਣ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ: ASF ਦਾ ਜ਼ੋਰ ਮੇਰਿਟ-ਅਧਾਰਿਤ ਭਾਗੀਦਾਰੀ ਅਤੇ ਪਾਰਦਰਸ਼ੀ ਪ੍ਰਕਿਰਿਆ 'ਤੇ ਹੈ, ਜੋ ਤਕਨੀਕੀ ਚੋਣਾਂ ਨੂੰ ਸਮਝਣਯੋਗ ਅਤੇ ਸਮੀਖਿਆਯੋਗ ਬਣਾਉਂਦਾ ਹੈ

ਫਾਊਂਡੇਸ਼ਨ ਨਾਲ ਸੰਭਾਲ-ਕਾਮ founder ਤੋਂ ਅੱਗੇ

ਬ੍ਰਾਇਨ ਬਹਿਲੇਨਡੌਫ Apache ਦੀ ਉਤਪੱਤੀ ਦਾ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਹਿਸ्सा ਹਨ, ਪਰ ਪਛਾਣਨ ਯੋਗ ਹੈ ਕਿ ਸਥਾਈ ਖੁੱਲਾ ਸਰੋਤ ਆਮ ਤੌਰ 'ਤੇ ਇਕਲ-ਕਿਸਾਨੀ ਕਹਾਣੀ ਨਹੀਂ ਹੁੰਦੀ। ASF ਮਾਡਲ ਨੇ ਇਹ ਸੁਨਿਸ਼ਚਤ ਕੀਤਾ ਕਿ:

• ਰੱਖ-ਰਖਾਅ ਵਾਲਾ ਕੰਮ (ਰੁਚੀ ਵਾਲੇ, ਸੁਰੱਖਿਆ ਅੱਪਡੇਟ ਅਤੇ ਰਿਲੀਜ਼) ਮੁੱਲਵਰ ਹੋਵੇ,
• ਯੋਗਦਾਨਕਾਰ ਬਿਨਾ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਫੇਲ ਕੀਤੇ ਘੁੰਮ ਸਕਣ,
• ਉਪਭੋਗਤਾ—ਖ਼ਾਸ ਕਰਕੇ ਕਾਰੋਬਾਰ—ਲੰਮੇ ਸਮੇਂ ਤੱਕ Apache 'ਤੇ ਨਿਰਭਰ ਰਹਿ ਸਕਣ

ਇਹ ਪੈਟਰਨ ਖੁੱਲ੍ਹੇ ਸਰੋਤ ਢਾਂਚਿਆਂ ਵਿੱਚ ਦੋਹਰਾਇਆ ਜਾਂਦਾ ਹੈ: ਤਕਨਾਲੋਜੀ “ਡਿਫਾਲਟ” ਬਣਦੀ ਹੈ ਜਦੋਂ ਲੋਕ ਨਾ ਸਿਰਫ਼ ਸੌਫਟਵੇਅਰ 'ਤੇ ਭਰੋਸਾ ਕਰਨ, ਸਗੋਂ ਉਸ ਗੱਲ 'ਤੇ ਵੀ ਕਿ ਕੱਲ੍ਹ ਨੂੰ ਕੀ ਹੋਵੇਗਾ।

Apache ਕਿਵੇਂ ਹੋਸਟਿੰਗ ਲਈ ਡਿਫਾਲਟ ਚੋਣ ਬਣਿਆ

ਜਦੋਂ ਲੋਕ ਕਹਿੰਦੇ ਹਨ ਕਿ Apache “ਡਿਫਾਲਟ” ਵੈੱਬ ਸਰਵਰ ਬਣ ਗਿਆ, ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਮਤਲਬ ਰੱਖਦੇ ਹਨ: ਇਹ ਉਹ ਚੋਣ ਸੀ ਜੋ ਬਿਨਾ ਪੁੱਛੇ ਹੀ ਮਿਲ ਜਾਂਦੀ। ਇਹ ਹੋਸਟਿੰਗ ਕੰਪਨੀਆਂ ਦੁਆਰਾ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਡਿਪਲੋਇ ਕੀਤੀ ਜਾਂਦੀ, ਆਪਰੇਟਿੰਗ ਸਿਸਟਮਾਂ ਵਿੱਚ ਪੈਕੇਜ ਹੋ ਕੇ ਆਉਂਦੀ, ਅਤੇ ਟਿਊਟੋਰੀਅਲਾਂ ਅਤੇ ਕਿਤਾਬਾਂ ਵਿੱਚ ਸਿਖਾਈ ਜਾਂਦੀ—ਇਸ ਲਈ Apache ਚੁਣਨਾ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਆਸਾਨ ਰਸਤਾ ਲੱਗਦਾ ਸੀ।

“ਡਿਫਾਲਟ” ਦਾ ਮਤਲਬ: ਪੈਕੇਜਡ, ਦਸਤਾਵੇਜ਼ੀ ਅਤੇ ਹਰ ਜਗ੍ਹਾ

Apache ਨੇ ਇਸ ਲਈ ਜਿੱਤਿਆ ਨਹੀਂ ਕਿ ਹਰ ਉਪਭੋਗਤਾ ਹਰ ਫੀਚਰ ਦੀ ਤੁਲਨਾ ਕਰਦਾ। ਇਹ ਇਸ ਲਈ ਜਿੱਤਿਆ ਕਿ ਇਹ ਪਹਿਲਾਂ ਹੀ ਇੰਸਟਾਲ ਹੋ ਕੇ ਜਾਂ ਇੱਕ ਕਮਾਂਡ ਦੂਰ ਸੀ, ਕਾਫ਼ੀ ਦਸਤਾਵੇਜ਼ ਅਤੇ ਕਮਿਊਨਿਟੀ ਸਹਿਯੋਗ ਨਾਲ ਤਾਂ ਕਿ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਸਾਈਟ ਚਾਲੂ ਕਰ ਸਕੋ।

ਜੇ ਤੁਸੀਂ 1990 ਦੇ ਅੰਤ ਅਤੇ 2000 ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਵੈੱਬ ਹੋਸਟਿੰਗ ਸਿੱਖ ਰਹੇ ਸੀ, ਤਾਂ ਜੋ ਉਦਾਹਰਣ ਤੁਸੀਂ ਲੱਭਦੇ—ਮੈਲਿੰਗ ਲਿਸਟਾਂ, ਸਰਵਰ ਐਡਮਿਨ ਗਾਈਡਾਂ ਅਤੇ ਸ਼ੁਰੂਆਤੀ ਹੋਸਟਿੰਗ ਪੈਨਲ—ਅਕਸਰ Apache ਨੂੰ ਮੰਨ ਕੇ ਤਿਆਰ ਕੀਤੇ ਗਏ ਸਨ। ਇਹ ਸਾਂਝਾ ਆਧਾਰ ਘਟਾਓ ਰੋਕਦਾ: ਡਿਵੈਲਪਰ ਇੱਕ ਵਾਰੀ ਹਦਾਇਤਾਂ ਲਿਖਦੇ, ਅਤੇ ਪਾਠਕ ਉਹਨਾਂ ਨੂੰ ਜ਼ਿਆਦਾਤਰ ਮਸ਼ੀਨਾਂ 'ਤੇ ਅਸਾਨੀ ਨਾਲ ਅਪਲਾਈ ਕਰ ਸਕਦੇ।

Linux ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਅਤੇ ਹੋਸਟਿੰਗ ਪ੍ਰੋਵਾਈਡਰਾਂ ਦਾ ਭੂਮਿਕਾ

Linux ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨਾਂ ਨੇ Apache ਨੂੰ ਆਪਣੇ ਰਿਪੋਜ਼ਟਰੀਜ਼ ਅਤੇ ਇੰਸਟਾਲੇਸ਼ਨ ਟੂਲਾਂ ਵਿੱਚ ਸ਼ਾਮਿਲ ਕਰਕੇ ਵੱਡੀ ਮਦਦ ਕੀਤੀ। ਐਡਮਿਨਾਂ ਲਈ ਇਸਦਾ ਮਤਲਬ ਸੀ συνεਹਤ ਅਪਡੇਟ, ਜਾਣ پہچਾਣ ਵਾਲੀ ਫਾਈਲ ਸਥਿਤੀ ਅਤੇ ਨਾਰਮਲ ਸਿਸਟਮ ਰਖ-ਰਖਾਅ ਦੇ ਅਨੁਕੂਲ ਅਪਗਰੇਡ ਪਾਥ।

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

ਕਈ ਸਿਸਟਮਾਂ 'ਤੇ ਕੰਮ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਸੀ

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

ਇਹ ਪોર્ટੇਬਿਲਿਟੀ ਸ਼ਾਇਦ ਰੋਮਾਂਚਕ ਨਹੀਂ ਸੀ, ਪਰ ਫ਼ੈਸਲਾਕਾਰੀ ਸੀ: ਜੇ ਜ਼ਿਆਦਾ ਥਾਵਾਂ ਤੇ Apache ਚੱਲ ਸਕੇ, ਤਾਂ ਇਹ ਹੋਰਾਂ ਦੁਆਰਾ ਲਿਖੀਆਂ ਟੂਲਜ਼, ਡੌਕਸ ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ ਚੈਕਲਿਸਟਾਂ ਵਿੱਚ ਵਧੇਰੇ ਉਮੀਦਯੋਗ ਸਰਵਰ ਬਣ ਗਿਆ।

ਸੁਰੱਖਿਆ ਅਤੇ ਓਪਰੇਸ਼ਨ: Apache ਚਲਾਉਣ ਨੇ ਇੰਟਰਨੈੱਟ ਨੂੰ ਕੀ ਸਿਖਾਇਆ

Apache ਸਿਰਫ਼ ਮੁਫ਼ਤ ਅਤੇ ਯੋਗ ਨਹੀਂ ਸੀ—ਇਹ ਇਸ ਲਈ ਫੈਲਿਆ ਕਿਉਂਕਿ ਹਜ਼ਾਰਾਂ ਲੋਕਾਂ ਨੇ ਇਸਨੂੰ ਚਲਾਉਣਾ ਸਿੱਖਿਆ। ਇਸ ਅਸਲੀ ਦਿਖਾਈ ਪਰਛਾਈ ਨੇ Apache HTTP Server ਨੂੰ ਸ਼ੁਰੂਆਤੀ ਵੈੱਬ ਤੇ ਕਾਰਯਕਸ਼ਮਤਾ ਅਤੇ ਸੁਰੱਖਿਆ ਲਈ ਇੱਕ ਪ੍ਰਸ਼িক্ষਣ ਮੈਦਾਨ ਬਣਾਇਆ।

ਪਸੰਦੀਦਾ ਢਾਂਚਾ ਧਿਆਨ ਖਿੱਚਦਾ ਹੈ

ਇੱਕ ਵਾਰੀ Apache ਆਮ ਹੋ ਗਿਆ, ਇਹ ਵੱਡਾ ਨਿਸ਼ਾਨਾ ਬਣ ਗਿਆ। ਹਮਲਾਵਰ ਸਾਂਝੇ ਬੁਨਿਆਦੀਆਂ 'ਤੇ ਧਿਆਨ ਦੇਂਦੇ ਹਨ ਕਿਉਂਕਿ ਇਕ ਹੀ ਕਮੀ ਸਾਰਿਆਂ 'ਤੇ ਲਾਗੂ ਹੋ ਸਕਦੀ ਹੈ। ਇਹ ਸੁਰੱਖਿਆ ਦਾ ਇੱਕ ਮੁਢਲਾ ਅਤੇ ਅਸੁਖਾਵਾਰ ਨਿਯਮ ਹੈ: ਕਾਮਯਾਬੀ ਨਿਗਰਾਨੀ ਵਧਾਉਂਦੀ ਹੈ।

ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵਰਤੀ ਜਾਣ ਵਾਲੀ ਸੌਫਟਵੇਅਰ ਨੂੰ ਬਚਾਉਣ ਵਾਲੇ ਅਤੇ ਹਮਲਾਵਰ ਦੋਹਾਂ ਦਾ ਟੈਸਟ ਮਿਲਦਾ—ਇਸ ਲਈ ਮੁੱਦੇ ਜ਼ਿਆਦਾ ਸੰਭਾਵਨਾ ਨਾਲ ਲੱਭੇ ਅਤੇ ਠੀਕ ਹੋ ਜਾਂਦੇ ਹਨ।

ਖੁੱਲ੍ਹੀ ਰਿਪੋਰਟਿੰਗ ਨਾਲ ਫਿਕਸ ਤੇਜ਼ ਫੈਲਦੇ

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

ਇਸ ਨਾਲ ਇੱਕ ਓਪਰੇਸ਼ਨਲ ਸਬਕ ਵੀ ਮਿਲਿਆ ਜੋ ਹੁਣ ਉਦਯੋਗ ਮੰਨਦਾ ਹੈ: ਸੁਰੱਖਿਆ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਹੈ, ਇੱਕ ਏਕ-ਵਾਰ ਆਡਿਟ ਨਹੀਂ।

Apache ਚਲਾਉਣ ਨੇ ਪ੍ਰਚਲਿਤ ਅਭਿਆਸ ਪ੍ਰੋਤਸਾਹਿਤ ਕੀਤੇ

Apache ਚਲਾਉਣ ਨੇ ਐਡਮਿਨਾਂ ਨੂੰ ਮੁੜ-ਉਪਯੋਗ ਰੂਟਿਨਾਂ ਵੱਲ ਧੱਕਿਆ:

• ਕੰਫਿਗਰੇਸ਼ਨ ਹਾਈਜੀਨ: ਸੈਟਿੰਗਾਂ ਪੜ੍ਹਨੀਏ ਅਤੇ ਸੰਖੇਪ, ਘੱਟ-ਕਾਪੀ-পੇਸਟ ਡਾਇਰੈਕਟਿਵ ਅਤੇ ਵੱਲ-ਕੋਈ ਟਿੱਪਣੀ।
• ਲੌਗਿੰਗ ਅਤੇ ਮਾਨੀਟਰਿੰਗ: ਐਕਸੈਸ ਅਤੇ ERRROR ਲੌਗਾਂ ਨੂੰ ਪਹਿਲ-ਕਲਾਸ ਸਿਗਨਲ ਮੰਨਣਾ।
• ਨਿਯਮਤ ਅਪਡੇਟ: ਪੈਚ ਵਿਂਡੋ ਯੋਜਨਾ, ਬਦਲਾਵ ਟੈਸਟ ਕਰਨਾ ਅਤੇ ਸਰਵਰਾਂ 'ਤੇ ਵਰਜ਼ਨਾਂ ਦਾ ਟ੍ਰੈਕ ਰੱਖਣਾ।

ਇਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੇ ਅਭਿਆਸ ਆਧੁਨਿਕ ਟੀਮਾਂ ਲਈ ਵੀ ਲਾਗੂ ਹੁੰਦੇ ਹਨ—ਚਾਹੇ ਉਹ "ਕਲਾਸਿਕ" ਸਰਵਰ ਚਲਾ ਰਹੀਆਂ ਹੋਣ ਜਾਂ ਕਲਾਉਡ-ਨੇਟਿਵ ਐਪਸ।

ਸੁਰੱਖਿਆ ਨਿਰਭਰ ਹੈ ਤੈਨਾਤੀ 'ਤੇ, ਸਿਰਫ਼ ਸੌਫਟਵੇਅਰ 'ਤੇ ਨਹੀਂ

Apache ਅਚ్ఛੀ ਤਰ੍ਹਾਂ ਬਣਿਆ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਗਲਤ ਢੰਗ ਨਾਲ ਚਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਕਮਜ਼ੋਰ ਪਾਸਵਰਡ, ਬਹੁਤ ਖੁੱਲ੍ਹੀਆਂ ਫਾਇਲ ਪਰਮਿਸ਼ਨ, ਪੁੁਰਾਣੇ ਮੋਡੀਊਲ ਅਤੇ ਗਲਤ TLS ਸੰਰਚਨਾ ਵਧੀਆ ਸੌਫਟਵੇਅਰ ਨੂੰ ਵੀ ਅਣ-ਸੁਰੱਖਿਅਤ ਕਰ ਸਕਦੇ ਹਨ। Apache ਦੀ ਇਤਿਹਾਸ ਨੇ ਇੱਕ ਲੰਮੇ ਸਮੇਂ ਵਾਲੀ ਸਚਾਈ ਰੋਸ਼ਨ ਕੀਤੀ: ਸੁਰੱਖਿਆ ਇੱਕ ਸਾਂਝੀ ਜ਼ਿੰਮੇਵਾਰੀ ਹੈ—ਸੌਫਟਵੇਅਰ ਲੇਖਕ ਜੋਖ਼ਮ ਘਟਾ ਸਕਦੇ ਹਨ, ਪਰ ਓਪਰੇਟਰ ਫੈਸਲਾ ਕਰਦੇ ਹਨ ਕਿ ਇਹ ਕਿੰਨੀ ਸੁਰੱਖਿਅਤ ਚਲਾਈ ਜਾਏ।

ਵਿਰਾਸਤ: Apache ਅਤੇ ਬਹਿਲੇਨਡੌਫ ਦੇ ਕੰਮ ਤੋਂ ਅਜੇ ਵੀ ਕੀ ਸਿੱਖਣ ਯੋਗ ਹੈ

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

ਸਬਕ 1: ਕਮਿਊਨਿਟੀ ਇੱਕ ਵਰਕਫਲੋ ਹੈ, ਇਕ ਅਹਿਸਾਸ ਨਹੀਂ

Apache ਨੇ ਉਹਨਾਂ ਅਭਿਆਸਾਂ ਨੂੰ ਆਮ ਕਰ ਦਿੱਤਾ ਜੋ ਬਾਅਦ ਵਿੱਚ “ਖੁੱਲ੍ਹੇ ਸਰੋਤ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ” ਬਣੇ: ਜਨਤਕ ਚਰਚਾ, ਸਮੀਖਿਆ ਕੀਤੇ ਪੈਚ, ਸਪਸ਼ਟ maintainers ਅਤੇ ਫੈਸਲੇ ਜਨਤਕ ਰਿਕਾਰਡ ਕੀਤਾ ਜਾਣਾ। ਇਸ ਪਾਰਦਰਸ਼ਤਾ ਨੇ ਲਗਾਤਾਰਤਾ ਬਣਾਈ—ਪਰੋਜੈਕਟ ਨੌਕਰੀ ਬਦਲਣ, ਸਪਾਂਸਰ ਬਦਲਣ ਅਤੇ ਨਵੇਂ ਯੋਗਦਾਨਕਾਰਾਂ ਦੇ ਆਉਣ-ਜਾਣ ਤੋਂ ਬਾਅਦ ਵੀ ਜਾਰੀ ਰਹਿ ਸਕਦਾ।

ਸਬਕ 2: ਗਵਰਨੈਂਸ ਇੰਜੀਨੀਅਰਿੰਗ ਜਿੰਨੀ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ

ਗੈਰ-ਅਨੌਪਚਾਰਿਕ ਸਮੂਹ ਤੋਂ ASF ਵੱਲ ਦਾ ਰੁਖ ਸਹਿਯੋਗ ਨੂੰ ਠੋਸ ਬਣਾਉਦਾ: ਨਿਰਧਾਰਿਤ ਭੂਮਿਕਾਵਾਂ, ਵੋਟਿੰਗ, IP ਹाइजੀਨ ਅਤੇ ਨਿਰਪੱਖ ਘਰ ਜੋ ਕਿਸੇ ਇਕ ਵੈਂਡਰ ਦਾ ਨਹੀਂ। ਇਹ ਢਾਂਚਾ ਕਾਰੋਬਾਰਾਂ ਨੂੰ Apache ਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਪਰੋਜੈਕਟ ਨਾ ਸਮਝਣ ਲਈ ਮਦਦ ਕਰਦਾ—ਇੱਕ ਸੰਸਥਾ ਜੋ ਭਰੋਸੇਯੋਗ ਇੰਫਰਾਸਟਰੱਕਚਰ ਪ੍ਰਦਾਨ ਕਰ ਸਕਦੀ।

ਸਬਕ 3: ਪ੍ਰਯੋਗਿਕ ਇੰਜੀਨੀਅਰਿੰਗ ਆਪਣੀ ਠੀਕ ਢੰਗ ਨਾਲ ਅਪਣਾਈ ਜਾਵੇ ਤਾਂ ਗ੍ਰਹਿ ਪ੍ਰਾਪਤ ਹੁੰਦੀ ਹੈ

Apache ਨੇ ਓਪਰੇਟਰਾਂ ਦੀ ਮੌਜੂਦਾ ਸਥਿਤੀ ਪਾਸੋਂ ਮਿਲ ਕੇ ਸਫਲਤਾ ਹਾਸਲ ਕੀਤੀ: ਸਥਿਰ ਰਿਲੀਜ਼, ਸਮਝਦਾਰ ਡਿਫ਼ਾਲਟ, ਮਾਡਿਊਲਰ ਐਕਸਟੈਂਡਬਿਲਟੀ ਅਤੇ ਸਥਿਰ ਅੱਗੇ ਵਧਾਈ। ਵੱਡੀ ਸੋਚ ਨਹੀਂ; ਬਜਾਏ ਇਸਦੇ, ਮਕਸਦ ਇਹ ਸੀ ਕਿ ਵੈੱਬ ਸਰਵਰ ਸਥਿਰ, ਸਮਰੱਥ ਤੇ ਸੰਭਾਲਯੋਗ ਹੋਵੇ।

ਆਉਣ ਵਾਲੇ ਸਨਮਾਨ ਤੇ ਪ੍ਰਭਾਵ

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

ਅੱਜ ਵੀ ਕੀ ਮਹੱਤਵਪੂਰਨ ਹੈ

ਆਧੁਨਿਕ ਢਾਂਚਾ ਹੋਰ ਜ਼ਿਆਦਾ ਜਟਿਲ ਹੈ, ਪਰ ਮੁਢਲੇ ਸਮੱਸਿਆਵਾਂ ਇੱਕੋ-ਇਕੋ ਹਨ: ਰੱਖ-ਰਖਾਅ, ਸੁਰੱਖਿਆ ਅਪਡੇਟ, ਅਤੇ ਉਹ ਸਾਂਝੇ ਮਿਆਰ ਜੋ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਇੰਟਰੋਪਰੇਬਲ ਰੱਖਦੇ ਹਨ। Apache ਦੀ ਕਹਾਣੀ ਇੱਕ ਯਾਦ ਹੈ ਕਿ “ਖੁੱਲ੍ਹਾ” ਦੇਣ ਨਾਲ ਸਿਰਫ਼ ਕੋਡ ਛਪਾਉਣਾ ਨਹੀਂ—ਸੰਭਾਲ ਜਾਰੀ ਰੱਖਣਾ ਸਭ ਤੋਂ ਮੁਸ਼ਕਲ ਕੰਮ ਹੈ।

ਇਸੇ ਲਈ ਆਧੁਨਿਕ ਬਿਲਡ ਟੂਲ ਮਹੱਤਵਪੂਰਨ ਹਨ: ਟੀਮਾਂ ਤੇਜ਼ੀ ਨਾਲ ਜਾਰੀ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਨ ਬਿਨਾਂ ਉਨ੍ਹਾਂ ਅਭਿਆਸਾਂ ਨੂੰ ਖੋਵਾਏ ਜੋ Apache ਨੇ ਲੋਕਾਂ ਨੂੰ ਸਿਖਾਉਂਦੇ ਰਹੇ। ਉਦਾਹਰਨ ਲਈ, Koder.ai ਐਪ ਬਣਾਉਣ ਨੂੰ ਇੱਕ ਗੱਲ-ਬਾਤ ਵੰਜੋਂ ਦੇਖਦਾ ਹੈ—React ਫਰੰਟਐਂਡ, Go ਬੈਕਐਂਡ ਅਤੇ PostgreSQL ਡੇਟਾ ਲੇਅਰਾਂ ਸਿਰਜਦਾ ਏਜੈਂਟ-ਅਧਾਰਿਤ ਵਰਕਫਲੋ ਦੇ ਨਾਲ—ਫਿਰ ਵੀ ਟੀਮਾਂ ਨੂੰ ਸੋర్స్ ਕੋਡ ਨਿਰਯਾਤ, ਡਿਪਲੋਇ ਅਤੇ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਦੇ ਨਾਲ ਦੁਹਰਾਉਣ ਦੀ ਆਜ਼ਾਦੀ ਦਿੰਦਾ ਹੈ। ਤਕਨਾਲੋਜੀ ਨਵੀਂ ਹੈ, ਪਰ ਆਧਾਰਭੂਤ ਸਬਕ ਵਾਂਗ: ਗਤੀ ਤਾਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ ਪਰ ਉਹ ਮੁਲਾਂਕਣ, ਰਿਵਿਊ ਅਤੇ ਜ਼ਿੰਮੇਵਾਰੀ ਵਾਲੇ ਪ੍ਰਕਿਰਿਆ ਬਿਨਾਂ ਲੰਮੇ ਸਮੇਂ ਤੱਕ ਘਟਦੀ ਹੈ।

ਅੱਗੇ ਪੜ੍ਹੋ

• ਇਕ ਗਹਿਰਾਈ ਨਾਲ ਸ਼ੁਰੂਆਤੀ ਵੈੱਬ ਇੰਫਰਾਸਟਰੱਕਚਰ ਦਾ ਇਤਿਹਾਸ
• ਢਾਂਚੇ ਅਤੇ ਲਾਇਸੈਂਸਿੰਗ ਬਿਜ਼ਨਸ ਜੋਖ਼ਮ ਘਟਾਉਂਦੇ ਹਨ
• ਨਜ਼ਦੀਕੀ ਨਿਰਭਰਤਾਵਾਂ ਦਾ ਮูลਾਂਕਣ ਅਤੇ ਫੰਡ ਕਰਨ ਲਈ ਵਿਹਾਰਕ ਰਹਿਨੁਮਾ