ਕਿਵੇਂ Bill Gates ਦੇ PC-ਯੁੱਗ ਵਾਲੇ ਸਾਫਟਵੇਅਰ ਮਾਡਲ ਨੇ ਟੂਲ, ਪਲੇਟਫਾਰਮ ਅਤੇ ਵੰਡ ਨੂੰ ਜੋੜਿਆ—ਜੋ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਐਪ ਰਿਲੀਜ਼ ਕਰਨ ਯੋਗ ਬਣਾਉਂਦਾ ਅਤੇ ਆਧੁਨਿਕ ਇਕੋਸਿਸਟਮਾਂ ਨੂੰ ਰੂਪ ਦਿੰਦਾ।
“PC ਸਾਫਟਵੇਅਰ ਮਾਡਲ” ਕੋਈ ਇਕ ਉਤਪਾਦ ਜਾਂ ਕੋਸੀ ਲਾਇਸੈਂਸਿੰਗ ਚਾਲ ਨਹੀਂ ਸੀ। ਇਹ ਇੱਕ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲਾ ਤਰੀਕਾ ਸੀ ਜਿਸ ਨਾਲ ਪੂਰਾ ਬਜ਼ਾਰ ਚਲਿਆ: ਵਿਕਾਸਕਾਰ ਸਾਫਟਵੇਅਰ ਕਿਵੇਂ ਬਣਾਉਂਦੇ ਸਨ, ਇਹ_users ਤੱਕ ਕਿਵੇਂ ਭੇਜਿਆ ਜਾਂਦਾ ਸੀ, ਅਤੇ ਇਸ ਤੋਂ ਕਿਵੇਂ ਪੈਸਾ ਬਣਾਇਆ ਜਾਂਦਾ ਸੀ।
ਇਹ ਸਾਦਾ ਲੱਗਦਾ ਹੈ—ਪਰ ਸ਼ੁਰੂਆਤੀ ਨਿੱਜੀ ਕੰਪਿਊਟਿੰਗ ਵਿੱਚ ਇਹ ਕਿੰਨਾ ਅਸਆਮਾਨ ਸੀ, ਇਹ ਯਾਦ ਰੱਖੋ। ਪਹਿਲੇ ਕੰਪਿਊਟਰ ਅਕਸਰ Proprietary ਹਾਰਡਵੇਅਰ ਦੇ ਨਾਲ ਵੇਚੇ ਜਾਂਦੇ ਸਨ, ਇਕ-ਵਾਰ ਲਈ ਓਪਰੇਟਿੰਗ ਮਾਹੌਲ ਹੁੰਦਾ ਸੀ, ਅਤੇ ਤੀਜੀ-ਪੱਖੀ ਵਿਕਾਸਕਾਰਾਂ ਲਈ ਰਸਤੇ ਅਸਪਸ਼ਟ ਹੁੰਦੇ ਸਨ। PC ਦੌਰ ਨੇ ਸਾਫਟਵੇਅਰ ਨੂੰ ਐਸਾ ਬਣਾ ਦਿੱਤਾ ਜੋ ਕਿਸੇ ਇਕ ਮਸ਼ੀਨ ਜਾਂ ਕੰਪਨੀ ਤੋਂ ਪਰੇ ਸਕੇ।
ਵਿਆਵਹਾਰਿਕ ਤੌਰ 'ਤੇ, ਸਾਫਟਵੇਅਰ ਮਾਡਲ ਉਹ ਧਾਰਣਾ-ਸੈੱਟ ਹੈ ਜੋ ਪ੍ਰਸ਼ਨ ਦੇ ਜਵਾਬ ਦਿੰਦੀ ਹੈ:
ਜਦ ਇਹ ਜਵਾਬ ਪੂਰਵਾਨੁਮਾਨਯੋਗ ਹੁੰਦੇ ਹਨ, ਵਿਕਾਸਕਾਰ ਨਿਵੇਸ਼ ਕਰਦੇ ਹਨ। ਜਦ ਉਹ ਨਹੀਂ ਹੁੰਦੇ, ਉਹ ਹਿਚਕਦੇ ਹਨ।
PC ਸਾਫਟਵੇਅਰ ਮਾਡਲ ਇਸ ਲਈ ਕੰਮ ਕਰਦਾ ਸੀ ਕਿਉਂਕਿ ਇਸ ਨੇ ਤਿੰਨ ਖੰਭਿਆਂ ਨੂੰ ਇਕ ਫਲਾਈਵ੍ਹੀਲ ਵਿੱਚ ਜੋੜਿਆ:
ਇੱਕਠੇ, ਇਹ PC ਨੂੰ ਇੱਕ ਭਰੋਸੇਯੋਗ "ਬਣਾਉਣ ਦੀ ਜਗ੍ਹਾ" ਬਣਾਉਂਦੇ। ਉਹ ਭਰੋਸਾ ਨਿੱਜੀ ਕੰਪਿਊਟਿੰਗ ਨੂੰ ਮੀਨਸਟ੍ਰੀਮ ਡਿਵੈਲਪਰ ਇਕੋਸਿਸਟਮ ਵਿੱਚ ਬਦਲ ਗਿਆ—ਸਿਰਫ਼ ਸ਼ੌੱਕੀਆ ਸਕੀਨ ਤੋਂ ਬਾਹਰ।
ਬਾਜ਼ਾਰ-ਪੱਧਰ ਦੇ PCs ਤੋਂ ਪਹਿਲਾਂ, "ਕੰਪਿਊਟਿੰਗ" ਅਕਸਰ ਮੈਨਫ੍ਰੇਮ ਅਤੇ ਮਿਨੀਕੰਪਿਊਟਰਾਂ ਦਾ ਮਤਲਬ ਸੀ, ਜੋ ਸਰਕਾਰਾਂ, ਵਿਸ਼ਵਵਿਦਿਆ ਲਿਆਈਂ ਅਤੇ ਵੱਡੀਆਂ ਕੰਪਨੀਾਂ ਦੇ ਸੰਜੈ ਹੋਂਦੇ ਸਨ। ਪਹੁੰਚ ਘੱਟ ਸੀ, ਮਹਿੰਗੀ ਸੀ, ਅਤੇ ਅਕਸਰ IT ਵਿਭਾਗਾਂ ਰਾਹੀਂ ਮਧਿਅਸਥ ਹੋਂਦੀ ਸੀ। ਜੇ ਤੁਸੀਂ ਵਿਕਾਸਕਾਰ ਸੀ, ਤਾਂ ਤੁਸੀਂ ਕਿਸੇ ਵਿਸ਼ੇਸ਼ ਸੰਗਠਨ ਲਈ ਸਾਫਟਵੇਅਰ ਲਿਖਦੇ—ਸਾਰਵਜਨਿਕ ਬਜ਼ਾਰ ਲਈ ਨਹੀਂ।
ਸ਼ੁਰੂਆਤੀ ਨਿੱਜੀ ਅਤੇ ਸ਼ੌਕੀਨ ਪ੍ਰਣਾਲੀਆਂ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਉਹ ਇਕ ਸਿੰਗਲ ਭਰੋਸੇਯੋਗ ਬਜ਼ਾਰ ਨਹੀਂ ਬਣ ਪਾਈਆਂ। ਹਾਰਡਵੇਅਰ ਬਹੁਤ ਵੱਖ-ਵੱਖ ਸੀ (CPU ਪਰਿਵਾਰ, ਡਿਸਕ ਫਾਰਮੇਟ, ਗ੍ਰਾਫਿਕਸ, ਪੈਰੀਫੇਰਲ), ਅਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਅਸਮੇਲ ਜਾਂ proprietary ਸਨ। ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਜੋ ਇਕ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲਦਾ ਸੀ, ਦੂਜੇ 'ਤੇ ਚੱਲਾਉਣ ਲਈ ਮੁੜ-ਲਿਖਣਾ ਪੈਂਦਾ ਸੀ।
ਇਹ ਖੰਡਿਤਤਾ ਨੇ ਸਾਫਟਵੇਅਰ ਆਰਥਿਕਤਾ ਨੂੰ ਆਕਾਰ ਦਿੱਤਾ:
ਕਿਸੇ ਇਕ ਸੰਰਚਨਾ ਲਈ ਲਕੜ੍ਹੀ ਦਰਸ਼ਕ ਛੋਟੀ ਹੋਣ ਕਰਕੇ, ਸੁਤੰਤਰ ਵਿਕਾਸਕਾਰਾਂ ਲਈ ਪੋਲਿਸ਼ ਕੀਤੇ, ਵਿਸ਼ਤ੍ਰਿਤ ਤੌਰ 'ਤੇ ਸਹਿਯੋਗਤ ਉਤਪਾਦ ਬਣਾਉਣ ਦਾ ਸਮਾਂ ਤੇ ਲਾਗਤ ਜਾਇਜ਼ ਨਹੀਂ ਰਹਿੰਦੀ। ਵੰਡ ਵੀ ਸੀਮਤ ਸੀ: ਤੁਸੀਂ ਟੇਪ ਜਾਂ ਡਿਸਕ ਭੇਜ ਸਕਦੇ, ਯੂਜ਼ਰ ਗਰੂਪਾਂ 'ਤੇ ਨਿਰਭਰ ਹੋ ਸਕਦੇ, ਜਾਂ ਕੋਡ ਅਨੌਪਚਾਰਿਕ ਤੌਰ 'ਤੇ ਸਾਂਝਾ ਕਰਦੇ। ਇਹਨਾਂ ਚੀਜਾਂ ਨਾਲ ਕਾਰੋਬਾਰ ਕਦੇ ਆਪਣਾ ਪੈਰ ਨਹੀਂ ਫੈਲਾਉਂਦਾ ਦਿੱਸਦਾ।
ਜਦ PCs ਸਧਾਰਣ ਗ੍ਰਾਹਕ ਅਤੇ ਦਫ਼ਤਰੀ ਉਤਪਾਦ ਬਣ ਗਏ, ਤਾਂ ਕੀਮਤ ਇੱਕ-ਵਾਰ ਡਿਪਲੋਇਮੈਂਟ ਤੋਂ ਦੋਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੀਆਂ ਸਾਫਟਵੇਅਰ ਵਿਕਰੀਆਂ ਵੱਲ ਸਿੱਧੀ ਹੋ ਗਈ। ਮੁੱਖ ਵਿਚਾਰ ਸੀ ਇੱਕ ਮਿਆਰੀ ਟਾਰਗੇਟ: ਹਾਰਡਵੇਅਰ ਉਮੀਦਾਂ, ਓਐਸ ਰੀਤੀਆਂ ਅਤੇ ਵੰਡ ਰਾਹ ਜੋ ਵਿਕਾਸਕਾਰਾਂ ਲਈ ਪੂਰਵਾਨੁਮਾਨਯੋਗ ਹੋਵੇ।
ਜਦ ਇਕ ਆਲੋਚਨਾਤਮਕ ਮਾਤਰਾ ਖਰੀਦਦਾਰਾਂ ਅਤੇ ਅਨੁਕੂਲ ਮਸ਼ੀਨਾਂ ਦੀ ਉਪਲਬਧ ਹੋ ਗਈ, ਤਾਂ ਸਾਫਟਵੇਅਰ ਲਿਖਣ ਦਾ ਸਵਾਲ "ਇਹ ਹੋਰ ਕਿੱਥੇ ਚੱਲੇਗਾ?" ਤੋਂ ਬਦਲ ਕੇ "ਅਸੀਂ ਇਸ ਮਿਆਰ 'ਤੇ ਸਭ ਤੱਕ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਪਹੁੰਚ ਸਕਦੇ ਹਾਂ?" ਹੋ ਗਿਆ।
Microsoft ਓਐਸ ਨਾਲ ਫੈਮਸ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਭਾਸ਼ਾਵਾਂ—ਖਾਸ ਕਰਕੇ BASIC—ਨਾਲ ਜਾਣੀ ਜਾਂਦੀ ਸੀ। ਇਹ ਚੋਣ ਆਕਸਮਾਤ ਨਹੀਂ ਸੀ। ਜੇ ਤੁਸੀਂ ਇਕ ਇਕੋਸਿਸਟਮ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਤੁਹਾਨੂੰ ਉਹ ਲੋਕ ਚਾਹੀਦੇ ਜੋ ਚੀਜ਼ਾਂ ਬਣਾਉਣ ਜਾਣ। ਭਾਸ਼ਾਵਾਂ ਇਹ ਘੱਟ-ਘਰੈਨੀ ਰਾਹ ਹਨ।
ਸ਼ੁਰੂਆਤੀ ਮਾਈਕ੍ਰੋਕੰਪਿਊਟਰ ਅਕਸਰ ROM ਵਿੱਚ BASIC ਨਾਲ ਆਉਂਦੇ ਸਨ, ਅਤੇ Microsoft ਦੀਆਂ ਵਰਜਨਾਂ ਕਈ ਮਸ਼ੀਨਾਂ 'ਤੇ ਜਾਣਿਆ-ਪਛਾਣਿਆ ਦਰਵਾਜ਼ਾ ਬਣ ਗਈਆਂ। ਵਿਦਿਆਰਥੀ, ਸ਼ੌਕੀਨ, ਜਾਂ ਛੋਟੇ ਕਾਰੋਬਾਰੀ ਲਈ ਰਾਹ ਸਧਾਰਣ ਸੀ: ਮਸ਼ੀਨ ਚਾਲੂ ਕਰੋ, ਪ੍ਰਾਂਪਟ ਤੇ ਲਿਖੋ, ਨਤੀਜੇ ਦੇਖੋ। ਇਹ ਤੁਰੰਤਤਾ ਸ਼ਾਨਦਾਰਤਾ ਤੋਂ ਵੱਧ ਮਹੱਤਵ ਦੀ ਸੀ। ਇਹ ਪ੍ਰੋਗਰਾਮਿੰਗ ਨੂੰ ਕੰਪਿਊਟਰ ਦੀ ਇਕ ਸਧਾਰਣ ਵਰਤੋਂ ਬਣਾਉਂਦੀ ਸੀ, ਕਿਸੇ ਵਿਸ਼ੇਸ਼ ਪੇਸ਼ੇ ਦਾ ਹਿੱਸਾ ਨਹੀਂ।
ਸੌਖੇ ਟੂਲਾਂ 'ਤੇ ਧਿਆਨ ਦੇ ਕੇ, Microsoft ਨੇ ਸੰਭਾਵੀ ਵਿਕਾਸਕਾਰਾਂ ਦੀ ਨਦੀ ਨੂੰ ਵਧਾਇਆ। ਹੋਰ ਲੋਕ ਛੋਟੇ ਪ੍ਰੋਗਰਾਮ ਲਿਖਣ ਲੱਗੇ, ਹੋਰ ਪ੍ਰਯੋਗ ਹੋਏ, ਹੋਰ "ਲੋਕਲ ਐਪ" ਬਣੇ, ਅਤੇ ਬੇਹਤਰ ਟੂਲਾਂ ਦੀ ਮੰਗ ਵਧੀ। ਇਹ ਡਿਵੈਲਪਰ ਮਨਸ਼ਾ-ਬਾਜ਼ੀ ਦੀ ਪਹਿਲੀ ਉਦਾਹਰਨ ਹੈ: ਜਦ ਇੱਕ ਪੀੜ੍ਹੀ ਤੁਹਾਡੀ ਭਾਸ਼ਾ ਅਤੇ ਟੂਲਿੰਗ 'ਤੇ ਸਿੱਖਦੀ ਹੈ, ਉਹ ਅਕਸਰ ਉਸੀ ਪ੍ਰਣਾਲੀ 'ਚ ਹੀ ਬਣਾਉਂਦੀ ਅਤੇ ਖਰੀਦਦੀ ਰਹਿੰਦੀ ਹੈ।
ਮਾਈਕ੍ਰੋਕੰਪਿਊਟਰ ਯੁੱਗ ਖੰਡਿਤ ਸੀ, ਪਰ Microsoft ਨੇ ਪਲੇਟਫਾਰਮ ਤੋਂ ਪਲੇਟਫਾਰਮ ਸਮਾਨ ਵਿਚਾਰ ਲਿਆਏ: ਸਮਾਨ ਭਾਸ਼ਾ ਸਿੰਟੈਕਸ, ਸਮਾਨ ਟੂਲਿੰਗ ਉਮੀਦਾਂ, ਅਤੇ ਇਹ ਹਿਸਾਸ ਕਿ "ਜੇ ਤੁਸੀਂ ਇੱਥੇ ਕੋਡ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਸ਼ਾਇਦ ਤੁਸੀਂ ਉੱਥੇ ਵੀ ਕਰ ਸਕਦੇ ਹੋ।" ਇਹ ਪੂਰਵਾਨੁਮਾਨਤਾ ਸਿੱਖਣ ਦੇ ਜੋਖਮ ਨੂੰ ਘਟਾਉਂਦੀ ਸੀ।
रणਨੀਤਿਕ ਸਬਕ ਸਪਸ਼ਟ ਹੈ: ਪਲੇਟਫਾਰਮ ਬਜ਼ਾਰਾਂ ਜਾਂ ਮਨਟਾਈਜ਼ੇਸ਼ਨ ਨਾਲ ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦੇ। ਉਹ ਟੂਲਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ ਜੋ ਬਣਾਉਣਾ ਸੰਭਵ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੇ—ਫਿਰ ਵਫ਼ਾਦਾਰੀ ਕਮਾਉਂਦੇ ਹਨ ਜੇ ਇਹ ਤਜ਼ਰਬਾ ਦੁਹਰਾਏ ਜਾ ਸਕੇ।
ਸ਼ੁਰੂਆਤੀ ਨਿੱਜੀ ਕੰਪਿਊਟਿੰਗ ਵਿੱਚ ਇਕ ਵੱਡੀ ਖੋਲ੍ਹ ਸੀ: "ਸਟੈਂਡਰਡ OS ਲੇਅਰ" ਦੀ ਸੋਚ—ਇਸ ਦੇ ਬਜਾਏ ਕਿ ਹਰ ਹਾਰਡਵੇਅਰ ਲਈ ਆਪਣੀ ਵੱਖਰੀ ਐਪ ਬਣਾਈ ਜਾਵੇ, ਤੁਸੀਂ ਇੱਕ ਆਮ ਇੰਟਰਫੇਸ ਨੂੰ ਟਾਰਗੇਟ ਕਰ ਸਕਦੇ। ਵਿਕਾਸਕਾਰਾਂ ਲਈ ਇਹ ਘੱਟ ਪੋਰਟਾਂ, ਘੱਟ ਸਪੋਰਟ ਕਾਲਾਂ, ਅਤੇ ਇੱਕ ਸੁਝਾ ਰਾਹ ਸੀ ਜੋ ਬਹੁਤ ਸਾਰੇ ਗ੍ਰਾਹਕਾਂ ਲਈ ਕੰਮ ਕਰਦਾ।
MS-DOS ਐਪਲੀਕੇਸ਼ਨਾਂ ਅਤੇ ਅਹਿਮ ਤਰ੍ਹਾਂ ਦੇ ਹਾਰਡਵੇਅਰ ਦੇ ਵਿਚਕਾਰ ਬੈਠਦਾ ਸੀ। ਫਿਰ ਵੀ ਵੱਖ-ਵੱਖ ਗ੍ਰਾਫਿਕਸ ਕਾਰਡ, ਪ੍ਰਿੰਟਰ, ਡਿਸਕ ਕੰਟਰੋਲਰ ਅਤੇ ਮੈਮੋਰੀ ਸੰਰਚਨਾਵਾਂ ਸਨ—ਪਰ MS-DOS ਫਾਇਲ ਪਹੁੰਚ, ਪ੍ਰੋਗ੍ਰਾਮ ਲੋਡਿੰਗ ਅਤੇ ਬੁਨਿਆਦੀ ਡਿਵਾਈਸ ਇੰਟਰਐਕਸ਼ਨ ਲਈ ਇੱਕ ਸਾਂਝਾ ਬੇਸਲਾਈਨ ਦਿੰਦਾ ਸੀ। ਉਹ ਆਮ ਪਰਤ "PC" ਨੂੰ ਇੱਕ ਪਹੁੰਚਯੋਗ ਬਜ਼ਾਰ ਬਣਾ ਦਿੰਦੀ ਸੀ ਨਾ ਕਿ ਲਗਭਗ-ਮੈਚਿੰਗ ਮਸ਼ੀਨਾਂ ਦਾ ਇਕ ਗਠਜੋੜ।
ਗ੍ਰਾਹਕਾਂ ਲਈ, ਕੰਪੈਟਬਿਲਿਟੀ ਭਰੋਸਾ ਸੀ: ਜੇ ਕੋਈ ਪ੍ਰੋਗਰਾਮ ਕਹਿੰਦਾ ਸੀ ਕਿ ਇਹ MS-DOS 'ਤੇ ਚੱਲਦਾ ਹੈ (ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ, IBM PC compatibles), ਤਾਂ ਉਹ ਸੰਭਵਤ: ਤੁਹਾਡੀ ਮਸ਼ੀਨ 'ਤੇ ਵੀ ਚਲਿਆ। ਵਿਕਾਸਕਾਰਾਂ ਲਈ, ਕੰਪੈਟਬਿਲਿਟੀ ਦਾ ਮਤਲਬ ਸੀ ਪੂਰਵਾਨੁਮਾਨਯੋਗ ਵਿਹਾਰ—ਦਸਤਾਵੇਜ਼ੀ ਕੰਟ੍ਰੋਲ, ਸਥਿਰ ਐਕਸਿਕਿਊਸ਼ਨ ਮਾਡਲ, ਅਤੇ ਇੰਸਟਾਲ ਅਤੇ ਲਾਂਚ ਕਰਨ ਦੀਆਂ ਰੀਤੀਆਂ।
ਇਹ ਪੂਰਵਾਨੁਮਾਨਤਾ ਪੋਲਿਸ਼, ਦਸਤਾਵੇਜ਼ ਅਤੇ ਲਗਾਤਾਰ ਅਪਡੇਟਾਂ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰਨਾ ਵਾਜਬ ਬਣਾਉਂਦੀ ਸੀ, ਕਿਉਂਕਿ ਦਰਸ਼ਕ ਕਿਸੇ ਇੱਕ ਹਾਰਡਵੇਅਰ ਵੇਂਡਰ ਦੀ ਹੱਦ ਵਿੱਚ ਸੀਮਿਤ ਨਹੀਂ ਰਹਿੰਦਾ ਸੀ।
ਮਿਆਰੀਕਰਨ ਨੇ ਇੱਕ ਸੀਮਾਬੱਦੀ ਵੀ ਪੈਦਾ ਕੀਤੀ: ਪੁਰਾਣੇ ਸਾਫਟਵੇਅਰ ਨੂੰ ਚਲਾਉਣਾ ਪ੍ਰਾਥਮਿਕਤਾ ਬਣ ਗਈ। ਉਹ ਬੈਕਵਰਡ-ਕੰਪੇਟਬਿਲਿਟੀ ਦਬਾਅ ਵੱਡੇ ਬਦਲਾਅ ਨੂੰ धीਮਾ ਕਰ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਲੋਕਪ੍ਰਿਯ ਪਰੋਗਰਾਮ ਤੋੜਨਾ ਪਲੇਟਫਾਰਮ 'ਤੇ ਭਰੋਸਾ ਤੋੜ ਦਿੰਦਾ ਹੈ। ਉੱਤਮ ਪਾਸਾ ਇੱਕ ਬਢ਼ਦੀ ਹੋਈ ਸਾਫਟਵੇਅਰ ਲਾਇਬ੍ਰੇਰੀ ਹੈ; ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਰੈਡੀਕਲ OS-ਸਤਰ ਦੀ ਨਵੀਨਤਾ ਲਈ ਰਸਤਾ ਤੰਗ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦ ਤੱਕ ਸਾਵਧਾਨ ਮਾਈਗ੍ਰੇਸ਼ਨ ਯੋਜਨਾਵਾਂ ਨਹੀਂ ਹੁੰਦੀਆਂ।
Windows ਸਿਰਫ MS-DOS 'ਤੇ ਬੈਠਦਾ ਨਹੀਂ ਸੀ—ਇਸ ਨੇ ਵਿਕਾਸਕਾਰਾਂ ਲਈ ਮਸ਼ੀਨ ਬਾਰੇ ਜੋ ਧਾਰਨਾਵਾਂ ਹੋ ਸਕਦੀਆਂ ਸਨ, ਉਹ ਬਦਲ ਦਿੱਤੀਆਂ। ਹਰ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਆਪਣਾ ਢੰਗ ਖੁਦ ਬਣਾਉਣ ਦੀ ਥਾਂ, Windows ਨੇ ਸਾਂਝਾ UI ਮਾਡਲ ਅਤੇ ਵੱਧਦੇ ਹੋਏ ਸਿਸਟਮ ਸਰਵਿਸز ਦਿੱਤੀਆਂ।
ਸਿਰਲੇਖੀ ਤਬਦੀਲੀ ਗ੍ਰਾਫਿਕਲ ਯੂਜ਼ਰ ਇੰਟਰਫੇਸ ਸੀ: ਵਿੰਡੋਜ਼, ਮੀਨੂ, ਡਾਇਲਾਗ ਅਤੇ ਫੋਂਟ ਜੋ ਐਪਾਂ ਵਿਚ ਇੱਕਸਾਰ ਦਿਖਦੇ ਅਤੇ ਵਰਤੋਂ ਵਿੱਚ ਆਉਂਦੇ। ਇਸ ਦੀ ਮਹੱਤਤਾ ਇਸ ਲਈ ਸੀ ਕਿ ਇਕਸਾਰਤਾ ਨੇ "ਮੂਢੀਆਂ ਚੀਜ਼ਾਂ ਦੁਬਾਰਾ ਬਣਾਉਣ" ਦਾ ਵਜਨ ਘਟਾਇਆ। ਵਿਕਾਸਕਾਰ ਉਹ ਸਮਾਂ ਉਪਭੋਗ-ਕੇਂਦਰਤ ਫੀਚਰਾਂ 'ਤੇ ਖਰਚ ਸਕਦੇ ਸਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਉਪਭੋਗਤਾ ਚਾਹੁੰਦੇ ਸਨ।
Windows ਨੇ DOS ਯੁੱਗ ਵਿੱਚ ਦੱਖਲਦਾਰ ਸੇਵਾਵਾਂ ਵੀ ਫੈਲਾਈਆਂ:
Windows ਰੀਤੀਆਂ—ਜਿਵੇਂ ਕiি ਕੀ-ਬੋਰਡ ਸ਼ਾਰਟਕਟ, ਡਾਇਲਾਗ ਲੇਆਊਟ, ਅਤੇ ਆਮ ਕੰਟਰੋਲ (ਬਟਨ, ਸੂਚੀ, ਟੈਕਸਟ ਬਾਕਸ)—ਨਿਰਮਾਣ ਝੰਝਟ ਅਤੇ ਉਪਭੋਗਤਾ ਟਰੇਨਿੰਗ ਦੋਹਾਂ ਘਟਾਉਂਦੀਆਂ। ਸਾਂਝੇ ਕੰਪੋਨੇਟਾਂ ਨਾਲ ਘੱਟ bespoke ਹੱਲ ਅਤੇ ਹਾਰਡਵੇਅਰ ਬਦਲਣ 'ਤੇ ਘੱਟ ਅਚੰਭੇ ਹੁੰਦੇ।
ਜਿਵੇਂ ਜਿਵੇਂ Windows ਵਿਕਸਿਤ ਹੋਇਆ, ਵਿਕਾਸਕਾਰਾਂ ਨੂੰ ਫੈਸਲਾ ਕਰਨਾ ਪਿਆ: ਪੁੰਗੇ ਵਰਜ਼ਨਾਂ ਨੂੰ ਸਹਿਯੋਗ ਦੇ ਕੇ ਪਹੁੰਚ ਵਧਾਈਏ, ਜਾਂ ਨਵੇਂ APIs ਅਪਣਾਓ ਤਾਂ ਕਿ ਵਧੀਆ ਸਮਰੱਥਾ ਮਿਲੇ। ਇਹ ਯੋਜਨਾ-ਕਾਰਜ਼ੀਆਂ, ਟੈਸਟਿੰਗ ਅਤੇ ਮਾਰਕੀਟਿੰਗ ਨੂੰ ਰੂਪ ਦਿੰਦਾ।
ਕਈ ਸਮੇਂ, ਟੂਲ, ਦਸਤਾਵੇਜ਼, ਤੀਜੀ-ਪੱਖੀ ਲਾਇਬ੍ਰੇਰੀਆਂ, ਅਤੇ ਉਪਭੋਗਤਾ ਉਮੀਦਾਂ Windows ਨੂੰ ਡਿਫੌਲਟ ਟਾਰਗੇਟ ਵਜੋਂ ਕੇਂਦਰਿਤ ਕਰਨ ਲੱਗੀਆਂ—ਸਿਰਫ਼ ਇੱਕ ਓਐਸ ਨਹੀਂ, ਬਲਕਿ ਰਿਵਾਜਾਂ ਅਤੇ ਗਤੀਵਿੱਧੀ ਵਾਲਾ ਪਲੇਟਫਾਰਮ।
ਇੱਕ ਪਲੇਟਫਾਰਮ ਵਿਕਾਸਕਾਰਾਂ ਲਈ ਤਦ ਤੱਕ "ਅਸਲ" ਨਹੀਂ ਲੱਗਦਾ ਜਦ ਤੱਕ ਉੱਤੇ ਆਸਾਨੀ ਨਾਲ ਸਾਫਟਵੇਅਰ ਰਿਲੀਜ਼ ਨਹੀਂ ਹੋ ਸਕਦਾ। PC ਯੁੱਗ ਵਿੱਚ, ਇਹ ਆਸਾਨੀ ਵੱਧਤੋਂ ਵੱਧ ਦਿਨ-ਪ੍ਰਤੀਦਿਨ ਲਿਖਣ, ਬਿਲਡ ਕਰਨ, ਡੀਬੱਗ ਕਰਨ ਅਤੇ ਪੈਕੇਜ ਕਰਨ ਦੇ ਤਜ਼ਰਬੇ ਦੁਆਰਾ ਬਣੀ।
ਕੰਪਾਇਲਰ, ਲਿੰਕਰ, ਡੀਬੱਗਰ, ਅਤੇ ਬਿਲਡ ਸਿਸਟਮ ਇਕੋਸਿਸਟਮ ਦੀ ਗਤੀ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ। ਜਦ ਕੰਪਾਇਲ ਸਮਾਂ ਘੱਟ ਹੁੰਦਾ, ਐਰਰ ਸੁਨੇਹੇ ਸੁਧਰਦੇ, ਅਤੇ ਡੀਬੱਗਿੰਗ ਭਰੋਸੇਯੋਗ ਹੋਂਦੀ, ਵਿਕਾਸਕਾਰ ਤੇਜ਼ੀ ਨਾਲ ਇਟਰੇਟ ਕਰ ਸਕਦੇ ਹਨ—ਅਤੇ ਇਟਰੇਸ਼ਨ ਹੀ ਆਧਾ-ਕੰਮ ਤੋਂ ਪੂਰੇ ਉਤਪਾਦ ਤੱਕ ਲੈ ਜਾਂਦੀ ਹੈ।
IDEs ਨੇ ਇਹ ਹੋਰ ਅੱਗੇ ਵਧਾਇਆ, ਸੰਪਾਦਨ, ਬਿਲਡ, ਡੀਬੱਗ ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਮੈਨੇਜਮੈਂਟ ਨੂੰ ਇਕ ਵਰਕਫਲੋ ਵਿੱਚ ਬੰਦ ਕਰ ਕੇ। ਚੰਗਾ IDE "ਗਲੂ ਵਰਕ" ਘਟਾਉਂਦਾ ਜੋ ਨਹੀਂ ਹੋਵੇ ਤਾਂ ਘੰਟਿਆਂ ਕੱਟ ਜਾਂਦੇ: ਇੰਕਲੂਡ ਪਾਥ ਸੈਟ ਕਰਨਾ, ਲਾਇਬ੍ਰੇਰੀਆਂ ਮੈਨੇਜ ਕਰਨਾ, ਬਿਲਡ ਸਥਿਰ ਰੱਖਣਾ, ਅਤੇ ਰਨਟਾਈਮ ਕ੍ਰੈਸ਼ ਧੁੰਢਣਾ।
ਵਧੀਆ ਟੂਲ ਸਿਰਫ਼ "ਚੰਗੀਆਂ" ਚੀਜ਼ਾਂ ਨਹੀਂ—ਇਹ ਛੋਟੀਆਂ ਟੀਮਾਂ ਲਈ ਅਰਥ ਵਿਵਸਥਾ ਬਦਲ ਦਿੰਦੇ ਹਨ। ਜੇ ਇਕ-ਦੋ ਵਿਕਾਸਕਾਰ ਭਰੋਸੇ ਨਾਲ ਬਣਾਉਣ ਅਤੇ ਟੈਸਟ ਕਰਨ ਸਕਦੇ ਹਨ, ਤਾਂ ਉਹ ਉਹ ਪ੍ਰੋਜੈਕਟ ਲੈ ਸਕਦੇ ਹਨ ਜੋ ਪਹਿਲਾਂ ਵੱਡੀ ਟੀਮ ਲੈਂਦੇ। ਇਹ ਲਾਗਤ ਘਟਾਉਂਦਾ, ਸਮਾਂ ਘਟਾਉਂਦਾ, ਅਤੇ ਨਵੇਂ ISV ਲਈ ਨਿਵੇਸ਼ ਘੱਟ ਖਤਰਨਾਕ ਬਣਾਉਂਦਾ।
ਦਸਤਾਵੇਜ਼ ਅਤੇ ਚਲਦੇ ਉਦਾਹਰਨ ਇੱਕ ਦੂਜੇ ਉਤਪਾਦ ਵਾਂਗ ਕੰਮ ਕਰਦੇ ਹਨ: ਉਹ ਮਾਨਸਿਕ ਮਾਡਲ ਸਿਖਾਉਂਦੇ, ਸਰੋਤ-ਚਰਚਾ ਦਿਖਾਉਂਦੇ, ਅਤੇ ਆਮ ਗਲਤੀਆਂ ਤੋਂ ਬਚਾਉਂਦੇ। ਕਈ ਵਿਕਾਸਕਾਰ ਕਿਸੇ API ਨੂੰ ਇਸ ਲਈ ਨਹੀਂ ਅਪਣਾਉਂਦੇ ਕਿ ਉਹ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੈ—ਉਹ ਇਸ ਲਈ ਅਪਣਾਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਇਕ ਸਪਸ਼ਟ ਉਦਾਹਰਨ ਦਿਨ-1 'ਤੇ ਕੰਮ ਕਰਦੀ ਹੈ।
ਟੂਲ ਵੇਂਡਰ ਕਿਸ ਤਰ੍ਹਾਂ ਦੇ ਪ੍ਰੋਗਰਾਮਿੰਗ ਮਾਡਲ ਜਿੱਤਦੇ ਹਨ, ਇਸ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦੇ ਹਨ—ਉਹ ਕਿਸੇ ਵਿਸ਼ੇਸ਼ ਰਾਹ ਨੂੰ ਘਰੈਣੀ-ਰਹਿਤ ਬਣਾਕੇ। ਜੇ ਟੈਂਪਲੇਟ, ਵਿਜ਼ਾਰਡ, ਲਾਇਬ੍ਰੇਰੀਆਂ, ਅਤੇ ਡੀਬੱਗ ਵਿਊ ਕਿਸੇ ਅੰਦਾਜ਼ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ, ਤਾਂ ਉਹ ਅੰਦਾਜ਼ ਡਿਫੌਲਟ ਬਣ ਜਾਂਦਾ—ਨਾ ਕਿ ਕਿਉਂਕਿ ਉਹ ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ ਬਿਹਤਰ ਹੈ, ਪਰ ਕਿਉਂਕਿ ਉਹ ਸਿੱਖਣ ਵਿੱਚ ਤੇਜ਼ ਅਤੇ ਸ਼ਿਪ ਕਰਨ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਹੈ।
ਇੱਕ ਓਐਸ ਆਪਣੇ ਆਪ 'ਤੇ ਪਲੇਟਫਾਰਮ ਨਹੀਂ ਬਣ ਜਾਂਦਾ। ਉਹ ਉਸ ਵੇਲੇ ਬਣਦਾ ਹੈ ਜਦ ਬਾਹਰੀ ਵਿਕਾਸਕਾਰ ਉਸ 'ਤੇ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਰਚਨਾ ਕਰ ਸਕਦੇ ਹਨ। ਇੱਥੇ PC ਯੁੱਗ ਵਿੱਚ APIs ਅਤੇ SDKs ਦੀ ਅਹਿਮੀਅਤ ਸੀ।
API ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ ਉਹ ਫੀਚਰ ਹਨ ਜੋ ਐਪ ਵਰਤ ਸਕਦੀ ਹੈ: ਇਕ ਵਿੰਡੋ ਦਿਖਾਉਣ, ਦਸਤਾਵੇਜ਼ ਪ੍ਰਿੰਟ ਕਰਨ, ਫਾਇਲ ਸੇਵ ਕਰਨ, ਹਾਰਡਵੇਅਰ ਨਾਲ ਗੱਲ ਕਰਨ, ਆਵਾਜ਼ ਚਲਾਉਣ। ਹਰ ਵਿਕਾਸਕਾਰ ਆਪਣੀ ਢੰਗ ਨਾਲ ਇਹ ਚੀਜ਼ਾਂ ਨਹੀਂ ਬਣਾਉਂਦਾ—ਪਲੇਟਫਾਰਮ ਸਾਂਝੇ ਇਮਾਰਤੀ ਬਲਾਕ ਦਿੰਦਾ ਹੈ।
SDK ਉਹ ਬੰਡਲ ਹੈ ਜੋ ਉਹਨਾਂ ਇਮਾਰਤੀ ਬਲਾਕਾਂ ਨੂੰ ਵਰਤਣਾ ਯੋਗ ਬਣਾਉਂਦਾ: ਲਾਇਬ੍ਰੇਰੀਆਂ, ਹੈਡਰ, ਟੂਲ, ਦਸਤਾਵੇਜ਼, ਅਤੇ ਉਦਾਹਰਨ ਕੋਡ ਜੋ ਦਿਖਾਉਂਦੇ ਕਿ ਮੇਨੂ ਤੋਂ ਕਿਵੇਂ ਚੁਣਨਾ ਹੈ।
ਵਿਕਾਸਕਾਰ ਜਦ ਸਾਫਟਵੇਅਰ ਬਣਾਉਂਦੇ ਹਨ, ਉਹ ਸਮਾਂ, ਭਰਤੀ, ਸਪੋਰਟ, ਮਾਰਕੀਟਿੰਗ ਅਤੇ ਲਗਾਤਾਰ ਅਪਡੇਟ ਲਈ ਲਾਗਤ ਉਠਾਉਂਦੇ ਹਨ। ਸਥਿਰ APIs ਇਸ ਖਤਰੇ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ ਕਿ ਇੱਕ ਅਪਡੇਟ ਅਚਾਨਕ ਮੁੱਖ ਕਾਰਜ ਨੂੰ ਤੋੜ ਦੇਵੇ।
ਜਦ ਨਿਯਮ ਲਗਾਤਾਰ ਰਹਿੰਦੇ—ਫਾਇਲ ਡਾਇਲਾਗ ਇਕੋ ਜਿਹੇ ਰਹਿੰਦੇ, ਪ੍ਰਿੰਟਿੰਗ ਇਕੋ ਜਿਹੀ ਰਹਿੰਦੀ, ਵਿੰਡੋ ਕੰਟਰੋਲਾਂ ਇਕੋ ਜਿਹੀਆਂ ਮਾਡਲ ਦੀ ਪਾਲਨਾ ਕਰਦੀਆਂ—ਤਾਂ ਤੀਜੀ-ਪੱਖੀ ਕੰਪਨੀਆਂ ਕਈ ਸਾਲਾਂ ਦੇ ਰੋਡਮੇਪ ਆਜ਼ਾਦੀ ਨਾਲ ਤਿਆਰ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਇਸ ਪੂਰਵਾਨੁਮਾਨਯੋਗਤਾ ਨੇ Windows ਡਿਵੈਲਪਰ ਮਾਡਲ ਨੂੰ ਗੰਭੀਰ ISV ਆਕਰਸ਼ਿਤ ਕੀਤਾ।
ਪਲੇਟਫਾਰਮ ਟੀਮਾਂ ਸਿਰਫ APIs ਪ੍ਰਕਾਸ਼ਿਤ ਨਹੀਂ ਕਰਦੀਆਂ; ਉਹ ਅਪਣਾਉਣ ਨੂੰ ਪਾਲਦੀ ਵੀ ਕਰਨ। ਡਿਵੈਲਪਰ ਪ੍ਰੋਗਰਾਮ, ਪਹਿਲੇ ਦਸਤਾਵੇਜ਼, ਬੇਟਾ ਅਤੇ ਪ੍ਰੀਵਿਊ ਰੀਲੀਜ਼ ਵਿਕਾਸਕਾਰਾਂ ਨੂੰ ਪੂਰੀ ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਅਨੁਕੂਲਤਾ ਟੇਸਟ ਕਰਨ ਦਿੰਦੇ।
ਇਸ ਨਾਲ ਇੱਕ ਲੂਪ ਬਣਦਾ: ਵਿਕਾਸਕਾਰ ਐਜ ਕੇਸ ਲੱਭਦੇ ਹਨ, ਪਲੇਟਫਾਰਮ ਉਹਨੂੰ ਠੀਕ ਕਰਦਾ ਹੈ, ਅਤੇ ਅਗਲੀ ਲਹਿਰ ਦੀਆਂ ਐਪਾਂ ਘੱਟ ਹੈਰਾਨੀਆਂ ਨਾਲ ਸ਼ਿਪ ਹੁੰਦੀਆਂ ਹਨ। ਸਮੇਂ-ਦੇ ਨਾਲ, ਇਹ ਉਪਭੋਗਤਿਆਂ ਲਈ ਗੁਣਵੱਤਾ ਸੁਧਾਰਦਾ ਅਤੇ ਹਰ ਕਿਸੇ ਲਈ ਸਪੋਰਟ ਲਾਗਤ ਘਟਾਉਂਦਾ ਹੈ।
APIs ਵੀ LIABILITY ਬਣ ਸਕਦੇ ਹਨ। ਤੋੜ-ਫੋੜ ਮਹਿੰਗੀਆਂ ਰੀ-ਰਾਈਟਾਂ ਨੂੰ ਮਜਬੂਰ ਕਰ ਦਿੰਦਾ। ਅਸਪਸ਼ਟ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ (ਸਿਸਟਮ ਐਪਾਂ ਵਿੱਚ ਵੱਖ-ਵੱਖ UI ਰੀਤੀਆਂ) ਤੀਜੀ-ਪੱਖੀ ਐਪਾਂ ਨੂੰ "ਗਲਤ" ਮਹਿਸੂਸ ਕਰਾਂਦੀਆਂ ਭਾਵੇਂ ਉਹ ਕੰਮ ਕਰ ਰਹੀਆਂ ਹੋਣ। ਅਤੇ ਖੰਡਿਤਤਾ—ਕਈ ਓਵਰਲੈਪਿੰਗ APIs—ਧਿਆਨ ਵੰਡਦੀ ਹੈ ਅਤੇ ਇਕੋਸਿਸਟਮ ਦੀ ਗਤੀ ਨੂੰ ਸੁਸਤ ਕਰਦੀ ਹੈ।
ਮਿਆਰ 'ਤੇ ਪਹੁੰਚ ਹੋਣ 'ਤੇ, ਸਭ ਤੋਂ ਵਧੀਆ ਪਲੇਟਫਾਰਮ ਰਣਨੀਤੀ ਅਕਸਰ ਨਿਰੀਖਣਯੋਗ ਹੁੰਦੀ ਹੈ: ਸਪਸ਼ਟ ਵਾਅਦੇ, ਧੀਰੇ-ਧੀਰੇ ਡੀਪ੍ਰੇਕੇਸ਼ਨ, ਅਤੇ ਦਸਤਾਵੇਜ਼ ਜੋ ਅਪ-ਟੂ-ਡੇਟ ਰਿਹਾ।
ਇੱਕ ਪਲੇਟਫਾਰਮ ਸਿਰਫ APIs ਅਤੇ ਟੂਲ ਨਹੀਂ—ਇਹ ਇਹ ਵੀ ਹੈ ਕਿ ਸਾਫਟਵੇਅਰ ਲੋਕਾਂ ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚਦਾ ਹੈ। PC ਯੁੱਗ ਵਿੱਚ, ਵੰਡ ਨੇ ਇਹ ਫੈਸਲਾ ਕੀਤਾ ਕਿ ਕਿਹੜੇ ਉਤਪਾਦ " ਡਿਫੌਲਟ" ਬਣਦੇ, ਕਿਹੜੇ ਦਰਸ਼ਕ ਲੱਭਦੇ, ਅਤੇ ਕਿਹੜੇ ਸੁਪਟ-ਸਾਫ਼ ਹੋ ਗਏ।
ਜਦ PC ਨਿਰਮਾਤਾ ਸਾਫਟਵੇਅਰ ਪ੍ਰੀਇੰਸਟਾਲ ਕਰਦੇ (ਜਾਂ ਬਾਂਡਲ ਕਰਦੇ), ਉਹ ਉਪਭੋਗਤਾ ਉਮੀਦਾਂ ਨੂੰ ਰੂਪ ਦਿੰਦੇ। ਜੇ ਇੱਕ spreadsheet, word processor, ਜਾਂ runtime ਮਸ਼ੀਨ ਨਾਲ ਆ ਜਾਂਦਾ, ਤਾਂ ਉਹ ਸਿਰਫ ਸਹੂਲਤ ਨਹੀਂ—ਉਹ ਸ਼ੁਰੂਆਤੀ ਪੁਆਇੰਟ ਬਣ ਜਾਂਦਾ। OEM ਭਾਈਚਾਰੇ ਵਿਕਾਸਕਾਰਾਂ ਨੂੰ ਇੱਕ ਚੀਜ਼ ਦਿੰਦੇ ਸੀ ਜੋ ਮਾਰਕੀਟਿੰਗ ਤੋਂ ਵੀ ਵਧ ਕੇ ਕੀਮਤੀ ਸੀ: ਪੂਰਵਾਨੁਮਾਨਯੋਗ ਆਮਦਨੀ। ਕਿਸੇ ਪ੍ਰਸਿੱਧ ਹਾਰਡਵੇਅਰ ਲਾਈਨ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਦਾ ਮਤਲਬ ਢੀਠ, ਅੰਦਾਜ਼ਿਤ ਵਿਕਰੀ ਹੋ ਸਕਦੀ—ਜੋ ਸਮਰਥਨ, ਅਪਡੇਟ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਲਈ ਟੀਮ ਨੂੰ ਫੰਡ ਕਰਨ ਲਈ ਜਰੂਰੀ ਸੀ।
ਰਿਟੇਲ ਸਾਫਟਵੇਅਰ ਬਾਕਸ, ਮੇਲ-ਆਰਡਰ ਕੈਟਲੋਗ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਵੱਡੇ-ਬਾਕਸ ਕੰਪਿਊਟਰ ਸਟੋਰਾਂ ਨੇ "ਸ਼ੈਲਫ ਸਪੇਸ ਲਈ ਮੁਕਾਬਲਾ" ਬਣਾਇਆ। ਪੈਕਜਿੰਗ, ਬ੍ਰਾਂਡ ਪਛਾਣ ਅਤੇ ਵੰਡ ਬਜਟ ਮੈਟਰ ਕਰਦੇ। ਇੱਕ ਚੰਗਾ ਉਤਪਾਦ ਹਾਰ ਜਾਂ ਸਕਦਾ ਸੀ ਇਕ ਹੋਰ ਜ਼ਿਆਦਾ ਵਿਜ਼ਿਬਲ ਉਤਪਾਦ ਦੇ ਮੁਕਾਬਲੇ ਵਿੱਚ।
ਇਹ ਵਿਜੀਬਿਲਟੀ ਇੱਕ ਫੀਡਬੈਕ ਲੂਪ ਚਲਾਉਂਦੀ: ਮਜ਼ਬੂਤ ਵਿਕਰੀ ਹੋਰ ਸ਼ੈਲਫ ਪ੍ਰਜੰਟੇਸ਼ਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੀ, ਜੋ ਹੋਰ ਵਿਕਰੀ ਲਿਆਉਂਦੀ। ਵਿਕਾਸਕਾਰਾਂ ਨੇ ਸਿੱਖਿਆ ਕਿ ਚੈਨਲ ਨਿਰਪੱਖ ਨਹੀਂ—ਉਹ ਉਹ ਉਤਪਾਦਾਂ ਨੂੰ ਇਨਾਮ ਦਿੰਦਾ ਹੈ ਜੋ ਪ੍ਰੋਮੋਸ਼ਨ ਅਤੇ ਸਮਰਥਨ ਵਿੱਚ ਸਕੇਲ ਕਰ ਸਕਦੇ।
ਸ਼ੇਅਰਵੇਅਰ (ਅਕਸਰ ਡਿਸਕਾਂ ਰਾਹੀਂ ਯੂਜ਼ਰ ਗਰੂਪਾਂ, ਮੈਗਜ਼ੀਨ ਅਤੇ BBS ਨੈੱਟਵਰਕਾਂ 'ਤੇ ਵੰਡਿਆ) ਨਵੇਂ ਦਾਖਲਿਆਂ ਲਈ ਰੁਕਾਵਟ ਘਟਾਉਂਦਾ। ਉਪਭੋਗਤਾ ਅਜ਼ਮਾਈਸ਼ ਤੋਂ ਬਾਅਦ ਭੁਗਤਾਨ ਕਰ ਸਕਦਾ, ਅਤੇ ਛੋਟੇ ਵਿਕਾਸਕਾਰ ਨਿਸ਼ ਦਰਸ਼ਕਾਂ ਤੱਕ ਰਿਟੇਲ ਡੀਲਸ ਤੋਂ ਬਿਨਾ ਪਹੁੰਚ ਸਕਦੇ।
ਇਹਨਾਂ ਸਾਰੇ ਚੈਨਲਾਂ ਵਿੱਚ ਸਾਂਝੀ ਧਾਰਨਾ ਪਹੁੰਚ ਅਤੇ ਪੂਰਵਾਨੁਮਾਨਯੋਗਤਾ ਸੀ। ਜਦ ਵਿਕਾਸਕਾਰ ਗ੍ਰਾਹਕਾਂ ਦੇ ਪਤਾ ਲਗਣ, ਟੈਸਟ ਹੋਣ, ਅਤੇ ਭੁਗਤਾਨ ਕਰਨ ਦੇ ਤਰੀਕਿਆਂ ਦੀ ਭਵਿੱਖਵਾਣੀ ਕਰ ਸਕਦੇ, ਉਹ ਸਟਾਫਿੰਗ, ਕੀਮਤ, ਅਪਡੇਟ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਦੇ ਉਤਪਾਦ ਨਿਰਣਯ ਕਰ ਸਕਦੇ।
PC ਯੁੱਗ ਨੇ ਮੀਨਸਟਰੀਮ ਵਿਕਾਸਕਾਰਾਂ ਨੂੰ ਖਿੱਚਣ ਦਾ ਇਕ ਵੱਡਾ ਕਾਰਨ ਸਿਰਫ ਤਕਨੀਕੀ ਸੰਭਾਵਨਾ ਨਹੀਂ ਸੀ—ਇਹ ਪੂਰਵਾਨੁਮਾਨਯੋਗ ਆਰਥਿਕਤਾ ਸੀ। "PC ਸਾਫਟਵੇਅਰ ਮਾਡਲ" ਨੇ ਰੈਵੇਨਿਊ ਦਾ ਅਨੁਮਾਨ ਲਗਾਉਣਾ, ਲਗਾਤਾਰ ਸੁਧਾਰਾਂ ਲਈ ਫੰਡ ਮਿਲਣਾ, ਅਤੇ ਸਾਫਟਵੇਅਰ ਦੇ ਆਧਾਰ 'ਤੇ ਕਾਰੋਬਾਰ ਬਣਾਉਣਾ ਆਸਾਨ ਕੀਤਾ—ਸੇਵਾਵਾਂ 'ਤੇ ਨਹੀਂ।
ਪੈਕੇਜਡ ਸਾਫਟਵੇਅਰ ਮੁੱਲ (ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਪਰ-ਸੀਟ ਲਾਇਸੈਂਸਿੰਗ) ਨੇ ਸਪਸ਼ਟ ਰੈਵੇਨਿਊ ਉਮੀਦਾਂ ਬਣਾਈਆਂ: ਦੀਆਂ ਨਕਲ ਵੇਚੋ, ਮਾਰਜਿਨ ਪ੍ਰਾਪਤ ਕਰੋ, ਦੁਹਰਾਓ। ਨਿਯਤ ਅੱਪਗਰੇਡ (12–24 ਮਹੀਨਿਆਂ) ਨੇ "ਮਂਟੇਨੈਂਸ" ਨੂੰ ਕਾਰੋਬਾਰ ਮਾਡਲ ਬਣਾਇਆ—ਵਿਕਾਸਕਾਰ ਨਵੀਂ ਵਰਜ਼ਨ हर 12–24 ਮਹੀਨੇ ਵਿੱਚ ਆਉਣ ਦੀ ਯੋਜਨਾ ਕਰ ਸਕਦੇ, ਮਾਰਕੀਟਿੰਗ ਰਿਲੀਜ਼ ਨਾਲ ਸੰਰਚਿਤ।
ਛੋਟੀਆਂ ਟੀਮਾਂ ਲਈ ਇਹ ਵੱਡੀ ਗੱਲ ਸੀ: ਹਰ ਗਾਹਕ ਲਈ ਕਸਟਮ ਕੰਟਰੈਕਟ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਇੱਕ ਪ੍ਰੋਡਕਟ ਸਕੇਲ ਕਰ ਸਕਦਾ ਸੀ।
ਜਦ ਇੱਕ ਪਲੇਟਫਾਰਮ ਵੱਡੇ ਇੰਸਟਾਲਡ ਬੇਸ ਨੂੰ ਲੱਭ ਲੈਂਦਾ, ਤਾਂ ਇਹ ਬਦਲ ਦਿੰਦਾ ਕਿ ਕਿਹੜੀਆਂ ਐਪ ਬਣਾਉਣ ਯੋਗ ਹਨ। ਨਿਸ਼ "ਵਰਟਿਕਲ" ਸਾਫਟਵੇਅਰ (ਦੰਤ ਚਿਕਿਤਸਕਾਂ ਲਈ ਇਕਾਉਂਟਿੰਗ, ਆਟੋ ਸ਼ਾਪਾਂ ਲਈ ਇਨਵੈਂਟਰੀ), ਛੋਟੇ ਉਪਯੋਗਿਤਾਵਾਂ, ਅਤੇ ਖੇਡਾਂ viable ਹੋ ਗਏ ਕਿਉਂਕਿ ਵੱਡੇ ਬਜ਼ਾਰ ਦੇ ਥੋੜੇ ਪ੍ਰਤੀਸ਼ਤ ਵੀ ਕਾਰੋਬਾਰ ਬਣ ਸਕਦੇ।
ਵਿਕਾਸਕਾਰ ਵੀ ਵੰਡ-ਮਿੱਤਰ ਉਤਪਾਦਾਂ ਦੀ ਅਨੁਕੂਲਤਾ ਵਾਲੇ ਉਤਪਾਦਾਂ ਲਈ ਅਪਟਿਮਾਈਜ਼ ਕਰਨ ਲੱਗੇ: ਉਹ ਚੀਜ਼ਾਂ ਜੋ ਢੁਕਵਾਂ ਤਰੀਕੇ ਨਾਲ ਡੈਮੋ ਹੁੰਦੀਆਂ, ਸ਼ੈਲਫ 'ਤੇ ਫਿੱਟ ਹੁੰਦੀਆਂ, ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਇੱਕ ਮੁਸ਼ਕਲ ਨੂੰ ਹੱਲ ਕਰਦੀਆਂ।
ਛੋਟੇ ਕਾਰੋਬਾਰ ਖਰੀਦਦਾਰ ਨੋਵੇਂਪਨ ਦੇ ਮੁਕਾਬਲੇ ਵਿਚ ਸਥਿਰਤਾ ਨੂੰ ਜ਼ਿਆਦਾ ਮਹੱਤਵ ਦਿੰਦੇ। ਮੌਜੂਦਾ ਫਾਇਲਾਂ, ਪ੍ਰਿੰਟਰਾਂ, ਅਤੇ ਵਰਕਫਲੋ ਨਾਲ ਕੰਪੈਟਬਿਲਿਟੀ ਸਪੋਰਟ ਕਾਲਾਂ ਨੂੰ ਘਟਾਉਂਦੀ—ਅਕਸਰ PC ਸਾਫਟਵੇਅਰ ਵੇਂਡਰਾਂ ਲਈ ਸਭ ਤੋਂ ਵੱਡੀ ਛੁਪੀ ਲਾਗਤ। ਪਲੇਟਫਾਰਮ ਜੋ ਪੁਰਾਣੇ ਐਪ ਨੂੰ ਚਲਾਉਂਦੇ ਰਹਿੰਦੇ ਹਨ, ਗਾਹਕਾਂ ਅਤੇ ਵਿਕਾਸਕਾਰਾਂ ਦੋਹਾਂ ਲਈ ਜੋਖਮ ਘਟਾਉਂਦੇ ਹਨ।
ISV ਉਹ ਕੰਪਨੀ ਸੀ ਜਿਸਦਾ ਉਤਪਾਦ ਕਿਸੇ ਹੋਰ ਦੇ ਪਲੇਟਫਾਰਮ 'ਤੇ ਨਿਰਭਰ ਸੀ। ਟਰੇਡ-ਆਫ ਸادہ ਸੀ: ਤੁਸੀਂ ਪਹੁੰਚ ਅਤੇ ਵੰਡ ਲੈ ਲੈਂਦੇ, ਪਰ ਪਲੇਟਫਾਰਮ ਦੇ ਨਿਯਮਾਂ, ਵਰਜ਼ਨ ਬਦਲਾਂ ਅਤੇ ਸਹਿਯੋਗ ਦੀਆਂ ਉਮੀਦਾਂ ਨਾਲ ਜੀਉਂਦੇ।
ਨੈੱਟਵਰਕ ਪ੍ਰਭਾਵ ਸਧਾਰਣ ਹਨ: ਜਦ ਇੱਕ ਪਲੇਟਫਾਰਮ ਦੇ ਜ਼ਿਆਦਾ ਉਪਭੋਗਤਾ ਹਨ, ਵਿਕਾਸਕਾਰਾਂ ਲਈ ਉਸ 'ਤੇ ਐਪ ਬਣਾਉਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ। ਅਤੇ ਜਦ ਉਹਦੇ ਕੋਲ ਜ਼ਿਆਦਾ ਐਪ ਹਨ, ਉਪਭੋਗਤਾ ਲਈ ਉਹ ਹੋਰ ਕੀਮਤੀ ਬਣ ਜਾਂਦਾ ਹੈ। ਇਹੀ ਲੂਪ "ਕਾਫੀ ਅੱਚਾ" ਪਲੇਟਫਾਰਮਾਂ ਨੂੰ ਡਿਫੌਲਟ ਬਣਾਉਂਦਾ ਹੈ।
PC ਯੁੱਗ ਵਿੱਚ, ਟਿਕਾਣਾ ਚੁਣਨਾ ਸਿਰਫ ਤਕਨੀਕੀ ਸੁੰਦਰਤਾ ਦੇ ਬਾਰੇ ਨਹੀਂ ਸੀ। ਇਹ ਸਭ ਤੋਂ ਵੱਡੇ ਪਹੁੰਚਯੋਗ ਬਜ਼ਾਰ ਤੱਕ ਘੱਟ ਰੁਕਾਵਟ ਨਾਲ ਪਹੁੰਚ ਬਣਾਉਣ ਬਾਰੇ ਸੀ। ਜਦ MS‑DOS ਅਤੇ ਬਾਅਦ ਵਿੱਚ Windows ਆਮ ਟਾਰਗੇਟ ਬਣੇ, ਵਿਕਾਸਕਾਰ ਇੱਕ ਉਤਪਾਦ ਭੇਜ ਸਕਦੇ ਅਤੇ ਉਮੀਦ ਕਰ ਸਕਦੇ ਕਿ ਉਹ ਬਹੁਤ ਸਾਰੇ ਗ੍ਰਾਹਕਾਂ ਲਈ ਚੱਲੇਗਾ।
ਉਪਭੋਗਤਾ ਉਹ ਸਾਫਟਵੇਅਰ ਫਾਲੋ ਕਰਦੇ ਜੋ ਉਹ ਚਾਹੁੰਦੇ—ਸਪ੍ਰੈਡਸ਼ੀਟ, ਵਰਡ ਪ੍ਰੋਸੈਸਰ, ਖੇਡਾਂ—ਅਤੇ ਕੰਪਨੀਆਂ ਟੈਲੇਂਟ ਪੂਲ ਦੇ ਪਿੱਛੇ ਗਈਆਂ। ਸਮੇਂ ਦੇ ਨਾਲ, ਜਿਸ ਪਲੇਟਫਾਰਮ ਕੋਲ ਸਭ ਤੋਂ ਡੂੰਘਾ ਕੈਟਾਲੌਗ ਸੀ ਉਹ ਸੁਰੱਖਿਅਤ ਮਹਿਸੂਸ ਹੋਇਆ: ਵਧੀਆ ਨੌਕਰੀ, ਵਧੇਰੇ ਟਰੇਨਿੰਗ ਸਾਮੱਗਰੀ, ਵਧੇਰੇ ਤੀਜੀ-ਪੱਖੀ ਇੰਟੀਗ੍ਰੇਸ਼ਨ, ਅਤੇ ਘੱਟ "ਕੀ ਇਹ ਚੱਲੇਗਾ?" ਵਾਲੀਆਂ ਚਿੰਤਾਵਾਂ।
ਨੈੱਟਵਰਕ ਪ੍ਰਭਾਵ ਸਿਰਫ ਐਪ ਗਿਣਤੀ ਬਾਰੇ ਨਹੀਂ ਸੀ। ਸਟੈਂਡਰਡਸ ਨੇ ਲੂਪ ਨੂੰ ਤੰਗ ਕੀਤਾ:
ਹਰ ਇੱਕ ਮਿਆਰ ਉਪਭੋਗਤਿਆਂ ਲਈ ਸਵਿੱਚ ਕਰਨ ਦੀ ਲਾਗਤ ਘਟਾਉਂਦਾ—ਅਤੇ ਵਿਕਾਸਕਾਰਾਂ ਲਈ ਸਪੋਰਟ ਲਾਗਤ ਘਟਾਉਂਦਾ—ਜਿਸ ਨਾਲ ਡਿਫੌਲਟ ਚੋਣ ਹੋਰ ਸਟਿੱਕੀ ਬਣਦੀ ਹੈ।
ਫਲਾਈਵ੍ਹੀਲ ਤਬ ਟੁਟਦਾ ਹੈ ਜਦ ਵਿਕਾਸਕਾਰ ਕਾਮਯਾਬ ਨਹੀਂ ਹੋ ਸਕਦੇ:
ਇੱਕ ਪਲੇਟਫਾਰਮ ਕੋਲ ਉਪਭੋਗਤਾ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਜੇ ਕਿਸੇ ਵਿਸ਼ਵਾਸਯੋਗ ਰਾਹ ਨਹੀਂ ਹੈ ਕਿ ਵਿਕਾਸਕਾਰ ਬਣਾਉਣ, ਭੇਜਣ, ਅਤੇ ਭੁਗਤਾਨ ਲੈਣਗੇ, ਤਾਂ ਐਪ ਇਕੋਸਿਸਟਮ ਹੋਲਟ ਕਰ ਜਾਂਦਾ—ਅਤੇ ਲੂਪ ਉਲਟ ਜਾ ਸਕਦਾ ਹੈ।
PC ਸਾਫਟਵੇਅਰ ਮਾਡਲ ਜਿਸ ਨੂੰ ਡਿਫੌਲਟ ਬਣਾਉਂਦਾ ਉਸ ਲਈ ਵੱਡਾ ਫਾਇਦਾ ਬਨਾਉਂਦਾ—ਪਰ ਇਹ ਕਦੇ ਵੀ ਪੂਰਾ ਨਿਯੰਤਰਣ ਨਹੀਂ ਸੀ। Microsoft ਦੀ ਉੱਥੀ ਹੋਈ ਸਫਲਤਾ ਇੱਕ ਮੁਕਾਬਲਤਮਕ, ਕਈ ਵਾਰ ਅਸਥਿਰ ਬਜ਼ਾਰ ਵਿੱਚ ਹੋਈ ਜਿੱਥੇ ਹੋਰ ਕੰਪਨੀਆਂ ਨਿਯਮ ਬਦਲ ਸਕਦੀਆਂ ਸਨ।
Apple ਨੇ ਇਕ ਤੰਗ ਇੰਟੀਗ੍ਰੇਟਡ ਵਿਕਲਪ ਦਿੱਤਾ: ਘੱਟ ਹਾਰਡਵੇਅਰ ਕਾਂਬੀਨੇਸ਼ਨ, ਜਿਆਦਾ ਨਿਯੰਤਰਿਤ ਉਪਭੋਗਤਾ ਅਨੁਭਵ, ਅਤੇ ਵੱਖਰਾ ਵਿਕਾਸਕ ਝੰਗ। ਦੂਜੇ ਪਾਸੇ, "IBM-compatible" ਇਕ ਇਕੱਲਾ ਮੁਕਾਬਲਾਈ ਨਹੀਂ ਸੀ ਪਰ ਕਲੋਨ ਨਿਰਮਾਤਾ, ਚਿਪ ਵੇਂਡਰ, ਅਤੇ ਸਾਫਟਵੇਅਰ ਪ੍ਰਕਾਸ਼ਕਾਂ ਦੀ ਇੱਕ ਵਿਸ਼ਾਲ ਕੋ-ਆਲਿਸ਼ਨ ਸੀ—ਜੋ ਕਿਸੇ ਵੀ ਵੇਲੇ ਮਿਆਰ ਜਾਂ ਬਹਾਲੀ ਦੀ ਤਾਕਤ ਬਦਲ ਸਕਦੀ ਸੀ।
IBM ਘੇਰਾਬੰਦ ਵਿੱਚ ਵੀ ਪਲੇਟਫਾਰਮ ਦਿਸ਼ਾ ਵਿਰੋਧੀ ਸੀ। OS/2 ਇੱਕ ਗੰਭੀਰ ਕੋਸ਼ਿਸ਼ ਸੀ ਅਗਲੇ ਮੁੱਖ PC ਓਐਸ ਵਾਤਾਵਰਨ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਦੀ, ਅਤੇ ਉਸਦੀ ਕਿਸਮਤ ਨੇ ਦਿਖਾਇਆ ਕਿ ਮੌਜੂਦਾ ਟਾਰਗੇਟ (MS-DOS, ਫਿਰ Windows) ਨੂੰ ਮਾਈਗਰੇਟ ਕਰਨਾ ਕਿੰਨਾ ਮੁਸ਼ਕਲ ਹੈ ਜਦ ਉਹ ਪਹਿਲਾਂ ਹੀ ਮੋਮੈਂਟਮ ਰੱਖਦਾ ਹੈ।
ਬਾਅਦ ਵਿੱਚ, ਬ੍ਰਾਉਜ਼ਰ ਯੁੱਗ ਨੇ OS ਤੋਂ ਉਪਰ ਇੱਕ ਨਵਾਂ ਸੰਭਾਵਤ ਪਲੇਟਫਾਰਮ-ਲੱਯਰ ਪੈਦਾ ਕੀਤਾ, ਮੁਕਾਬਲੇ ਨੂੰ defaults, ਵੰਡ, ਅਤੇ ਕਿਸੇ runtime 'ਤੇ ਨਿਰਭਰਤਾ ਦੇ ਆਸਰੇ ਦੁਬਾਰਾ ਤਰਜੀਹ ਦਿੱਤੀ।
ਐਂਟੀਟ੍ਰਸਟ ਨਿਗਰਾਨੀ—ਕਾਨੂੰਨੀ ਨਤੀਜਿਆਂ 'ਤੇ ਨਾ ਜਾਉ—ਇੱਕ ਮੁੜ-ਉਠਣ ਵਾਲੀ ਪਲੇਟਫਾਰਮ ਤਣਾਅ ਨੂੰ ਰੋਸ਼ਨ ਕਰਦੀ ਹੈ: ਉਹੀ ਚੱਲਾਂ ਜੋ ਉਪਭੋਗਤਿਆ ਲਈ ਜੀਵਨ ਆਸਾਨ ਬਣਾਉਂਦੀਆਂ ਹਨ (ਬੰਡਲ ਕੀਤੀਆਂ ਫੀਚਰ, ਪ੍ਰੀਇੰਸਟਾਲ, ਡਿਫੌਲਟ ਸੈੱਟਿੰਗ) ਉਹ ਵਿਕਾਸਕਾਰਾਂ ਅਤੇ ਮੁਕਾਬਲਿਆਂ ਲਈ ਅਸਲ ਚੋਣਾਂ ਘੱਟ ਕਰ ਸਕਦੀਆਂ ਹਨ।
ਜਦ ਕੋਈ ਬੰਡਲ ਕੀਤੀ ਹਿੱਸਾ ਡਿਫੌਲਟ ਬਣ ਜਾਂਦੀ ਹੈ, ਵਿਕਾਸਕਾਰ ਅਕਸਰ ਇੰਸਟਾਲਡ ਬੇਸ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ ਨਾ ਕਿ ਆਪਣੇ-ਸਰਵੋਤਮ ਵਿਕਲਪ ਦੀ। ਇਹ ਸਟੈਂਡਰਡਾਈਜੇਸ਼ਨ ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਵਿਕਲਪਾਂ ਨੂੰ ਵੀ ਬੰਨ੍ਹ ਸਕਦਾ ਹੈ ਅਤੇ ਪ੍ਰਯੋਗ ਨੂੰ ਘਟਾ ਸਕਦਾ ਹੈ।
ਪਲੇਟਫਾਰਮ ਵਿਕਾਸ ਰਣਨੀਤੀਆਂ ਇਕੋਸਿਸਟਮ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਡਿਫੌਲਟ ਹੋ ਕੇ ਲਾਭ ਕਮਾ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਮਾਰਕੀਟ ਦੇ ਮੌਕੇ-ਸਤਰ ਨੂੰ ਵੀ ਆਕਾਰ ਦੇ ਰਹੇ ਹੋ—ਕੌਣ ਉਪਭੋਗਤਿਆਂ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ, ਕਿਹੜੀਆਂ ਚੀਜ਼ਾਂ ਫੰਡ ਹੋਦੀਆਂ ਹਨ, ਅਤੇ ਨਵੀਂ ਚੀਜ਼ ਬਣਾਉਣਾ ਕਿੰਨਾ ਆਸਾਨ ਹੈ। ਜਿੰਨਾ ਸਿਹਤਮੰਦ ਪਲੇਟਫਾਰਮ ਦੇ ਨਿਯਮ ਅਤੇ ਪਾਰਦਰਸ਼ਤਾ ਹੋਵੇਗੀ, ਉਤਨਾ ਹੀ ਟਿਕਾਊ ਉਹ ਵਿਕਾਸਕਾਰ ਭਰੋਸਾ ਹੋਵੇਗਾ ਜੋ ਆਖ਼ਿਰਕਾਰ ਉਸਨੂੰ ਸਹਾਰੇਗਾ।
PC ਯੁੱਗ ਨੇ ਸਰਲ ਨਿਯਮ ਸਿਖਾਇਆ: ਪਲੇਟਫਾਰਮ ਜਿੱਤਦੇ ਹਨ ਜਦ ਉਹ ਵਿਕਾਸਕਾਰਾਂ ਲਈ ਬਹੁਤ ਸਾਰੇ ਉਪਭੋਗਤਿਆ ਤੱਕ ਪਹੁੰਚ ਸੌਖੀ ਬਣਾਉਂਦੇ ਹਨ। ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ ਨੇ ਉਹ ਨਿਯਮ ਮਿਟਾਇਆ ਨਹੀਂ—ਉਹ "ਕਿਵੇਂ" ਨੂੰ ਦੁਬਾਰਾ ਪਰਿਭਾਸ਼ਿਤ ਕਰ ਗਏ।
ਵੰਡ, ਅਪਡੇਟ ਅਤੇ ਖੋਜ ਆਨਲਾਈਨ ਹੋ ਗਏ। ਡਿਸਕਾਂ ਜਾਂ ਰਿਟੇਲ ਬਾਕਸ ਭੇਜਣ ਦੀ ਥਾਂ, ਸਾਫਟਵੇਅਰ ਡਾਊਨਲੋਡ ਬਣ ਗਿਆ। ਇਸ ਨਾਲ ਰੁਕਾਵਟ ਘੱਟ ਹੋਈ, ਤਤੇਕ ਅਪਡੇਟ ਆਸਾਨ ਹੋਏ, ਅਤੇ ਨਵੀਆਂ ਖੋਜ ਤਰੀਕਾਂ ਆਈਆਂ: ਖੋਜ, ਲਿੰਕ, ਸੋਸ਼ਲ ਸ਼ੇਅਰਿੰਗ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਐਲਗੋਰਿਦਮਿਕ ਫੀਡ।
ਮੋਬਾਈਲ 'ਤੇ, ਐਪ ਸਟੋਰ ਡਿਫੌਲਟ ਚੈਨਲ ਬਣ ਗਏ। ਉਨ੍ਹਾਂ ਨੇ ਇੰਸਟਾਲ ਅਤੇ ਭੁਗਤਾਨ ਸਧਾਰਨ ਕੀਤੇ, ਪਰ ਨਵੇਂ ਗੇਟਕੀਪਰ ਵੀ ਪੈਦਾ ਹੋਏ: ਸਮੀਖਿਆ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼, ਰੈਂਕਿੰਗ ਸਿਸਟਮ, ਅਤੇ ਰੈਵਨਿਊ ਸ਼ੇਅਰ। ਇਹਨਾਂ ਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਵੰਡ ਆਸਾਨ ਹੋਈ ਪਰ ਕੇਂਦਰੀਕ੍ਰਿਤ ਵੀ ਹੋ ਗਈ।
ਓਪਨ ਸੋਰਸ ਅਤੇ ਕ੍ਰਾਸ-ਪਲੇਟਫਾਰਮ ਟੂਲਿੰਗ ਲਾਕ-ਇਨ ਘਟਾਇਆ। ਵਿਕਾਸਕਾਰ macOS ਜਾਂ Linux 'ਤੇ ਕੰਮ ਕਰ ਸਕਦੇ, ਮੁਫ਼ਤ ਟੂਲਚੇਨ ਵਰਤ ਸਕਦੇ, ਅਤੇ ਕਈ ਵਾਤਾਵਰਨਾਂ ਵਿੱਚ ਰਿਲੀਜ਼ ਕਰ ਸਕਦੇ। ਬ੍ਰਾਊਜ਼ਰ, JavaScript, ਅਤੇ ਆਮ ਫ੍ਰੇਮਵਰਕਸ ਨੇ ਬਹੁਤ ਸਾਰੀਆਂ ਐਪ ਵਰਗੀਆਂ ਸ਼੍ਰੇਣੀਆਂ ਲਈ "ਕਹਿਣਾ—ਕਿਂਚੇ ਚੱਲਦਾ ਹੈ" ਨੂੰ ਯਥਾਰਥਿਕ ਬਣਾਈਆ।
ਵਿਕਾਸਕਾਰ ਅਜੇ ਵੀ ਉਹ ਆਸਾਨ ਰਾਹ ਫੋਲੋ ਕਰਦੇ ਹਨ ਜੋ ਉਪਭੋਗਤਿਆਂ ਤੱਕ ਲੈ ਜਾਂਦਾ ਹੈ।
ਉਹ ਰਾਹ ਕੇਹੜੇ ਹਿੱਸੇ ਪ੍ਰੇਰਿਤ ਕਰਦੇ ਹਨ:
ਜਦ ਇਹ ਹਿੱਸੇ ਇਕਠੇ ਹੋਂਦੇ ਹਨ, ਇਕੋਸਿਸਟਮ ਵਧਦੇ ਹਨ—ਭਾਵੇਂ "ਪਲੇਟਫਾਰਮ" Windows ਹੋਵੇ, ਇੱਕ ਬ੍ਰਾਊਜ਼ਰ, ਇਕ ਐਪ ਸਟੋਰ, ਜਾਂ ਇੱਕ AI-ਨੈਟਿਵ ਬਿਲਡਰ।
ਤੁਹਾਨੂੰ PC ਯੁੱਗ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ ਕਿ ਉਸਦੀ ਨੀਤੀ ਤੋਂ ਲਾਭ ਲਿਆ ਜਾਵੇ। ਥੜ੍ਹਾ ਸਬਕ ਇਹ ਹੈ ਕਿ ਪਲੇਟਫਾਰਮ ਉਹਨਾਂ ਤੀਜੀ-ਪੱਖੀ ਨਿਰਮਾਤਿਆਂ ਲਈ ਅਣਿਸ਼ਚਿਤਤਾ ਘਟਾਉਂਦੀਆਂ ਹਨ—ਤਕਨੀਕੀ, ਵਪਾਰਕ, ਅਤੇ ਓਪਰੇਸ਼ਨਲ।
ਆਪਣੇ ਮੁੱਖਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਟੀਮਾਂ ਨੂੰ ਤੁਹਾਡੀ ਰੋਡਮੇਪ 'ਤੇ ਸ਼ਰਤ ਲਾਉਣ ਦਾ ਆਸਰਾ ਦਿੰਦੇ ਹਨ:
ਵਿਕਾਸਕਾਰਾਂ ਨੂੰ ਇੱਕ ਮੁੱਖ ਗ੍ਰਾਹਕ ਵਭਾਗ ਵਜੋਂ ਮੰਨੋ। ਇਸਦਾ ਮਤਲਬ ਹੈ:
ਜੇ ਤੁਸੀਂ ਉਦਾਹਰਨਾਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਕਾਰੋਬਾਰੀ ਮਾਡਲ ਚੋਣਾਂ ਭਾਈਦਾਰਾਂ ਦੇ ਵਿਹਾਰ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਤ ਕਰਦੀਆਂ ਹਨ, ਤਾਂ /blog ਅਤੇ /pricing ਵਿੱਚ ਭਿੰਨ-ਭਿੰਨ ਦ੍ਰਿਸ਼ਟਾਂਤਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ।
ਇਕ ਕਾਰਨ ਜਿਸ ਕਰਕੇ PC ਮਾਡਲ ਲਾਭਕਾਰੀ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਰਹਿ ਜਾਂਦਾ ਹੈ, ਉਹ ਇਹ ਹੈ ਕਿ ਇਹ ਨਵੇਂ "vibe-coding" ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਸਾਫ਼ ਚੀਜ਼ਾਂ ਨਾਲ ਮੇਚ ਕਰਦਾ ਹੈ।
ਉਦਾਹਰਨ ਲਈ, Koder.ai ਉਹੀ ਤਿੰਨ ਖੰਭਿਆਂ 'ਤੇ ਭਾਰੀ ਦਾਅ ਕੀਤਾ ਹੈ:
ਪਲੇਟਫਾਰਮ PC-ਯੁੱਗ ਦੀ ਆਰਥਿਕਤਾ ਦੀ ਨਵੀਂ ਰੂਪ-ਰੇਖਾ ਵੀ ਦਰਸਾਉਂਦਾ ਹੈ: ਟਿਯਰਡ ਪ੍ਰਾਈਸਿੰਗ (ਫ੍ਰੀ, ਪ੍ਰੋ, ਬਿਜ਼ਨਸ, ਐਂਟਰਪ੍ਰਾਈਜ਼), ਸੋਰਸ ਕੋਡ ਐਕਸਪੋਰਟ, ਅਤੇ ਪ੍ਰੇਰਕਾਂ ਜਿਵੇਂ ਪ੍ਰਕਾਸ਼ਿਤ ਸਮੱਗਰੀ ਜਾਂ ਰੈਫ਼ਰਲ ਲਈ ਕਰੈਡਿਟ—ਵਹ ਨਿਰਧਾਰਤ ਤਰੀਕੇ ਜੋ ਬਣਾਉਣਾ (ਅਤੇ ਜਾਰੀ ਰੱਖਣਾ) ਵਿੱਤੀ ਤੌਰ 'ਤੇ ਠੀਕ ਬਣਾਉਂਦੇ ਹਨ।
ਛੋਟੀ-ਮਿਆਦ ਦਾ ਨਿਯੰਤਰਣ ਲੰਬੇ ਸਮੇਂ ਦੀ ਹਿਚਕ ਨੂੰ ਜਨਮ ਦੇ ਸਕਦਾ ਹੈ। ਉਹ ਪੈਟਰਨ ਦੇਖੋ ਜੋ ਭਾਈਦਾਰਾਂ ਨੂੰ ਬਦਲਯੋਗ ਮਹਿਸੂਸ ਕਰਾਉਂਦੇ ਹਨ: ਕਾਮਯਾਬ ਐਪਾਂ ਦੀ ਨਕਲ, ਅਚਾਨਕ ਨੀਤੀਆਂ ਵਿਚ ਬਦਲਾਅ, ਜਾਂ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਬਿਨਾਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਰਸਤੇ ਤੋੜਨਾ।
ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ ਲੰਬੀ-ਅਵਧੀ ਦੀ ਯੋਗਤਾ ਲਈ ਕੋਸ਼ਿਸ਼ ਕਰੋ। ਜਦ ਤੋੜ-ਫੋੜ ਲਾਜ਼ਮੀ ਹੋਵੇ, ਤਤਕਾਲ ਟੂਲਿੰਗ, ਸਮਾਂ-ਸੂਚੀਆਂ, ਅਤੇ ਪ੍ਰੇਰਕ ਦਿਓ—ਤਾਂ ਜੋ ਵਿਕਾਸਕਾਰ ਸੁਰੱਖਿਅਤ ਮਹਿਸੂਸ ਕਰਨ, ਸਜ਼ਾ ਨਹੀਂ।
ਇਹ ਇੱਕ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲਾ ਸੈੱਟ ਹੈ ਜੋ ਪਲੇਟਫਾਰਮ ਤੇ ਸਾਫਟਵੇਅਰ ਨੂੰ ਵਪਾਰਯੋਗ ਬਣਾਉਂਦਾ ਹੈ: ਬਣਾਉਣ ਲਈ ਇੱਕ ਸਥਿਰ ਟਾਰਗੇਟ, ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਣ ਲਈ ਭਰੋਸੇਯੋਗ ਟੂਲ ਤੇ ਦਸਤਾਵੇਜ਼, ਅਤੇ ਵੰਡਣ ਅਤੇ ਭੁਗਤਾਨ ਲੈਣ ਦੇ ਪਾਲਣਯੋਗ ਤਰੀਕੇ।
ਜਦ ਤੱਕ ਇਹ ਤਿੰਨ ਚੀਜ਼ਾਂ ਸਮੇਂ ਦੇ ਨਾਲ ਲਗਾਤਾਰ ਸਥਿਰ ਰਹਿੰਦੀਆਂ ਹਨ, ਵਿਕਾਸਕਾਰ ਪੋਲਿਸ਼, ਸਹਾਇਤਾ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਦੀਆਂ ਯੋਜ਼ਨਾਵਾਂ 'ਤੇ ਨਿਵੇਸ਼ ਕਰਨ ਦੀ ਹਿੰमत ਕਰਦੇ ਹਨ।
ਕਿਉਂਕਿ ਫਰਕ-ਫਰਕ ਕੰਫਿਗਰੇਸ਼ਨਾਂ ਲਈ ਬਣਾਉਣਾ ਮਹਿੰਗਾ ਪੈਂਦਾ ਹੈ: ਹੋਰ ਬੰਦਰਗਾਹਾਂ, ਹੋਰ QA ਮੈਟ੍ਰਿਕਸ, ਹੋਰ ਸਪੋਰਟ ਮੁੱਦੇ, ਅਤੇ ਹਰ ਬਿਲਡ ਲਈ ਛੋਟੀ ਪਹੁੰਚਯੋਗ ਦਰ।
ਜਦ MS‑DOS/IBM-compatible PCs ਇੱਕ ਆਮ ਟਾਰਗੇਟ ਬਣੇ, ਤਾਂ ਵਿਕਾਸਕਾਰ ਇੱਕ ਉਤਪਾਦ ਇਕੱਠਾ ਭੇਜ ਸਕਦੇ ਸਨ ਜੋ ਕਾਫੀ ਵੱਡੇ ਇੰਸਟਾਲਡ ਬੇਸ ਲਈ ਕੰਮ ਕਰਦਾ—ਜਿਸ ਨਾਲ "ਪ੍ਰੋਡਕਟ ਸਾਫਟਵੇਅਰ" ਦੀਆਂ ਆਰਥਿਕਤਾਵਾਂ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਨ ਲੱਗੀਆਂ।
ਟੂਲ ਇਟਰੇਸ਼ਨ ਗਤੀ ਅਤੇ ਭਰੋਸੇ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ। ਬਿਹਤਰ ਕੰਪਾਇਲਰ, ਡੀਬੱਗਰ, IDEs, ਦਸਤਾਵੇਜ਼ ਅਤੇ ਉਦਾਹਰਨ-ਕੋਡ ਵਿਚਾਰ ਨੂੰ ਕੰਮ ਕਰਨ ਵਾਲੇ ਨਿਰਭ ਜਾਣ ਤੋਂ ਜਲਦੀ ਸ਼ਿਪ ਕਰਨ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।
ਵਾਸਤਵਿਕ ਤੌਰ 'ਤੇ, ਇਸਦਾ ਮਤਲਬ ਹੈ:
BASIC ਨੇ ਪ੍ਰੋਗਰਾਮਿੰਗ ਨੂੰ ਤੁਰੰਤ ਬਣਾਇਆ: ਕੰਪਿਊਟਰ ਓਨ ਕਰੋ, ਪ੍ਰਾਂਪਟ ਮਿਲੇ, ਕੋਡ ਲਿਖੋ, ਨਤੀਜੇ ਵੇਖੋ।
ਉਸ ਘੱਟ-ਘਰੈਨੀ ਰਾਹ ਨੇ ਰਚਿਆ-ਨਿਰਮਾਤਾ ਦੀ ਗਿਣਤੀ ਵਧਾਈ (ਵਿਦਿਆਰਥੀ, ਸ਼ੌਕੀਨ, ਛੋਟੇ ਕਾਰੋਬਾਰ)। ਵੱਧ ਰਚਿਆ-ਨਿਰਮਾਤਿਆਂ ਨਾਲ ਟੂਲ, ਲਾਇਬਰੇਰੀਆਂ ਅਤੇ ਪਲੇਟਫਾਰਮ ਖਪਤ ਦੀ ਮਾਂਗ ਵਧਦੀ—ਜੋ ਇਕ ਇਕੋਸਿਸਟਮ ਨੂੰ ਉਮੀਦ ਮਿਲਦੀ ਹੈ।
MS‑DOS ਨੇ ਪ੍ਰੋਗਰਾਮ ਲੋਡ ਕਰਨ ਅਤੇ ਫਾਇਲ ਪਹੁੰਚ ਵਰਗੀਆਂ ਮੁੱਖ ਪਜ਼ਾਰਤਾਂ ਲਈ ਇੱਕ ਸਾਂਝਾ ਬੇਸਲਾਈਨ ਦਿੱਤੀ, ਇਸ ਕਰਕੇ "MS‑DOS 'ਤੇ ਚੱਲਦਾ ਹੈ" ਇਕ ਮਾਣਯੋਗ ਮਿਲਾਪ ਦਾ ਵਾਅਦਾ ਬਣ ਗਿਆ।
ਹਾਲਾਂਕਿ ਹਾਰਡਵੇਅਰ ਵੱਖ-ਵੱਖ ਸੀ, ਉਹ ਸਾਂਝੀ OS ਪਰਤ ਪੋਰਟਿੰਗ ਦਾ ਕੰਮ ਘਟਾ ਦਿੰਦੀ ਅਤੇ ਗ੍ਰਾਹਕਾਂ ਨੂੰ ਭਰੋਸਾ ਦਿੰਦੀ ਕਿ ਸਾਫਟਵੇਅਰ ਸੰਭਵਤ: ਉਨ੍ਹਾਂ ਦੀ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲੇਗਾ।
Windows ਨੇ UI ਨੂੰ ਸਥਿਰ ਕੀਤਾ ਅਤੇ ਸਿਸਟਮ ਸਰਵਿਸز ਵਧਾਈਆਂ ਤਾਂ ਕਿ ਹਰ ਐਪ ਨੂੰ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਫਿਰ ਤੋਂ ਬਣਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਨਾ ਪਏ।
ਵਹ ਅਮਲ ਵਿੱਚ ਵਿਕਾਸਕਾਰ ਇਹਨਾਂ 'ਤੇ ਨਿਰਭਰ ਹੋ ਸਕਦੇ ਸਨ:
APIs ਉਹ ਸਮਰੱਥਾਵਾਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਐਪ ਕਾਲ ਕਰਦੇ ਹਨ (UI, ਫਾਇਲ, ਪ੍ਰਿੰਟਿੰਗ, ਨੈੱਟਵਰਕ)। SDKs ਉਹ ਪੈਕੇਜ ਹਨ ਜੋ ਵਿਕਾਸਕਾਰਾਂ ਨੂੰ ਉਹਨਾਂ APIs ਵਰਤਣਾ ਆਸਾਨ ਬਣਾਉਂਦੇ (ਹੈਡਰ/ਲਾਇਬਰੇਰੀਆਂ, ਟੂਲ, ਦਸਤਾਵੇਜ਼, ਉਦਾਹਰਨ)।
ਸਤਤ APIs ਰੁਚੀ ਨੂੰ ਨਿਵੇਸ਼ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਇਸ ਖਤਰੇ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ ਕਿ OS ਅੱਪਡੇਟ ਅਚਾਨਕ ਮੁੱਖ ਕਰਿਆਨੂੰ ਤੋੜ ਦੇਵੇਗਾ।
ਬੈਕਵਰਡ ਕੰਪੇਟਬਿਲਿਟੀ ਪੁਰਾਣੇ ਸਾਫਟਵੇਅਰ ਨੂੰ ਚਲਦਾ ਰਖਦੀ ਹੈ, ਜੋ ਭਰੋਸਾ ਬਚਾਉਂਦਾ ਹੈ ਅਤੇ ਮੌਜੂਦਾ ਸਾਫਟਵੇਅਰ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਕੀਮਤ ਨੂੰ ਸੰਰੱਖਣ ਕਰਦਾ ਹੈ।
ਟ੍ਰੇਡ-ਆਫ ਇਹ ਹੈ ਕਿ ਪਲੇਟਫਾਰਮ ਬਦਲਾਅ ਧੀਰੇ ਹੋ ਸਕਦਾ ਹੈ। ਜੇ ਤੋੜ-ਫੋੜ ਆਵਸ਼ਯਕ ਹੋਵੇ, ਤਾਂ ਪ੍ਰਯੋਗਿਕ ਸੋਝ-ਵਿਚਾਰ ਦੇ ਨਾਲ ਡੀਪ੍ਰੇਕੇਸ਼ਨ ਨੀਤੀਆਂ, ਮਾਈਗ੍ਰੇਸ਼ਨ ਟੂਲਿੰਗ ਅਤੇ ਸਮਾਂ-ਸੂਚੀਆਂ ਦੇਣੀਆਂ ਬਿਹਤਰ ਪ੍ਰੈਕਟਿਸ ਹਨ ਤਾਂ ਕਿ ਵਿਕਾਸਕਾਰ ਯੋਜਨਾ ਬਣਾ ਸਕਣ।
ਹਰ ਚੈਨਲ ਆਪਣਾ ਅਸਰ ਰੱਖਦਾ ਸੀ:
ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਹੈ ਪੂਰਵਾਨੁਮਾਨਯੋਗਤਾ—ਜਦੋਂ ਵਿਕਾਸਕਾਰ ਗਾਹਕਾਂ ਦੇ ਲੱਭਣ, ਇੰਸਟਾਲ ਕਰਨ ਅਤੇ ਭੁਗਤਾਨ ਕਰਨ ਦੇ ਤਰੀਕੇ ਦੀ ਭਵਿੱਖਵਾਣੀ ਕਰ ਸਕਦੇ ਹਨ, ਉਹ ਕਾਰੋਬਾਰ ਦੀ ਯੋਜਨਾ ਬਣਾ ਸਕਦੇ ਹਨ।
ISV (Independent Software Vendor) ਉਹ ਕੰਪਨੀ ਹੈ ਜੋ ਕਿਸੇ ਹੋਰ ਦੇ ਪਲੇਟਫਾਰਮ 'ਤੇ ਨਿਰਭਰ ਉਤਪਾਦ ਵੇਚਦੀ ਹੈ.
ਤੁਹਾਨੂੰ ਪਹੁੰਚ ਮਿਲਦੀ ਹੈ (ਵੱਡਾ ਇੰਸਟਾਲਡ ਬੇਸ, ਪਛਾਣਯੋਗ ਵੰਡ) ਪਰ ਪਲੇਟਫਾਰਮ ਖਤਰੇ ਸਹਿਣੇ ਪੈਂਦੇ ਹਨ:
ਨਿਬਟਣ ਲਈ ਆਮ ਤੌਰ 'ਤੇ ਵਰਜ਼ਨਾਂ 'ਤੇ ਟੈਸਟਿੰਗ, ਪਲੇਟਫਾਰਮ ਰੋਡਮੇਪਾਂ 'ਤੇ ਨਜ਼ਰ ਅਤੇ ਅਸਥਿਰ ਇੰਟਰਫੇਸਾਂ 'ਤੇ ਜ਼ਿਆਦਾ ਨਿਰਭਰ ਨਾ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਈ ਜਾਂਦੀ ਹੈ।
