ਆਪਣੇ ਡਿਵੈਲਪਰਾਂ ਦੁਆਰਾ ਬੰਧਕ ਬਣਨ ਤੋਂ ਪਰਹੇਜ਼ ਕਰੋ

ਹੋਸਟੇਜ 100107ਇਸ ਹਫਤੇ ਦੇ ਅੰਤ ਵਿੱਚ ਮੈਂ ਇੱਕ ਸਥਾਨਕ ਕਲਾਕਾਰ ਨਾਲ ਗੱਲਬਾਤ ਸ਼ੁਰੂ ਕੀਤੀ ਜੋ ਉਸਦੇ ਬੌਸ ਦੇ ਕੋਲ ਕੁਝ ਵੈਬ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਪ੍ਰਬੰਧਨ ਵਿੱਚ ਉਸਦੇ ਬੌਸ ਦੀ ਸਹਾਇਤਾ ਕਰ ਰਹੀ ਹੈ.

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

ਡਿਵੈਲਪਰ ਨੇ ਡੋਮੇਨ ਨਾਮ ਤਬਦੀਲ ਕੀਤੇ ਤਾਂ ਜੋ ਉਹ ਉਹਨਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰ ਸਕੇ. ਡਿਵੈਲਪਰ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਆਪਣੇ ਹੋਸਟਿੰਗ ਖਾਤੇ 'ਤੇ ਵੀ ਰੱਖਦਾ ਹੈ. ਸੰਖੇਪ ਵਿੱਚ, ਵਿਕਾਸਕਾਰ ਹੁਣ ਉਹਨਾਂ ਨੂੰ ਬੰਧਕ ਬਣਾ ਰਿਹਾ ਹੈ.

ਸ਼ੁਕਰ ਹੈ, ਜਿਸ I'mਰਤ ਨਾਲ ਮੈਂ ਕੰਮ ਕਰ ਰਿਹਾ ਹਾਂ, ਨੇ ਸਾਈਟ ਲਈ ਕੁਝ ਨਮੂਨੇ ਫਾਈਲਾਂ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਨ ਲਈ ਪਿਛਲੇ ਸਮੇਂ ਵਿੱਚ ਪ੍ਰਬੰਧਕੀ ਪਹੁੰਚ ਦੀ ਮੰਗ ਕੀਤੀ. ਡਿਵੈਲਪਰ ਉਸ ਨੂੰ ਸੀਮਤ ਪਹੁੰਚ ਪ੍ਰਦਾਨ ਕਰ ਸਕਦਾ ਸੀ ਪਰ ਉਸਨੇ ਨਹੀਂ ਕੀਤਾ. ਉਸਨੇ (ਆਰਾਮ ਨਾਲ) ਉਸਨੂੰ ਸਾਈਟ ਤੇ ਪ੍ਰਬੰਧਕੀ ਲੌਗਇਨ ਪ੍ਰਦਾਨ ਕੀਤਾ. ਅੱਜ ਰਾਤ ਮੈਂ ਉਹ ਵਰਤੋਂ ਸਾਈਟ ਦੇ ਸਾਰੇ ਕੋਡਾਂ ਦਾ ਬੈਕਅਪ ਲੈਣ ਲਈ ਕੀਤੀ. ਮੈਂ ਇਹ ਵੀ ਪਤਾ ਲਗਾ ਲਿਆ ਕਿ ਉਹ ਕਿਹੜਾ ਪ੍ਰਬੰਧਨ ਸਾੱਫਟਵੇਅਰ ਵਰਤ ਰਿਹਾ ਹੈ ਅਤੇ ਮੇਰੇ ਦੁਆਰਾ ਡੇਟਾਬੇਸ ਪ੍ਰਸ਼ਾਸਨ ਤੱਕ ਪਹੁੰਚਾਇਆ ਜਿਥੇ ਮੈਂ ਦੋਵੇਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਡੇਟਾ ਅਤੇ ਟੇਬਲ structuresਾਂਚੇ ਨੂੰ ਨਿਰਯਾਤ ਕਰਨ ਦੇ ਯੋਗ ਸੀ. Whew.

ਇੱਕ ਵਾਰ ਵਿਕਾਸ ਪੂਰਾ ਹੋ ਜਾਣ 'ਤੇ ਮਾਲਕ ਸਾਈਟਾਂ ਨੂੰ ਨਵੇਂ ਡੋਮੇਨ ਨਾਮਾਂ' ਤੇ ਲਿਜਾਣ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਿਹਾ ਸੀ. ਇਹ ਬਹੁਤ ਵੱਡਾ ਹੈ ਕਿਉਂਕਿ ਇਸਦਾ ਅਰਥ ਹੈ ਕਿ ਮੌਜੂਦਾ ਡੋਮੇਨਾਂ ਦੀ ਅਵਸਥਾ ਦੀ ਮਿਆਦ ਖਤਮ ਹੋ ਸਕਦੀ ਹੈ ਜਦੋਂ ਡਿਵੈਲਪਰ ਅਤੇ ਕੰਪਨੀ ਦੇ ਵਿਚਕਾਰ ਗੁੱਸੇ ਤੋਂ ਵੱਖ ਹੋਣਾ ਹੈ. ਮੈਂ ਪਹਿਲਾਂ ਅਜਿਹਾ ਹੁੰਦਾ ਵੇਖਿਆ ਹੈ.

ਕੁਝ ਸੁਝਾਅ ਜੇ ਤੁਸੀਂ ਆ outsਟਸੋਰਸ ਵਿਕਾਸ ਟੀਮ ਪ੍ਰਾਪਤ ਕਰਨ ਜਾ ਰਹੇ ਹੋ:

  1. ਡੋਮੇਨ ਰਜਿਸਟਰੇਸ਼ਨ

    ਆਪਣੀ ਡੋਮੇਨ ਨਾਮ ਆਪਣੀ ਕੰਪਨੀ ਦੇ ਨਾਮ ਤੇ ਰਜਿਸਟਰ ਕਰੋ. ਤੁਹਾਡੇ ਡਿਵੈਲਪਰ ਨੂੰ ਖਾਤੇ ਤੇ ਤਕਨੀਕੀ ਸੰਪਰਕ ਵਜੋਂ ਰੱਖਣਾ ਬੁਰਾ ਨਹੀਂ ਹੈ, ਪਰ ਕਦੇ ਵੀ ਡੋਮੇਨ ਦੀ ਮਾਲਕੀਅਤ ਆਪਣੀ ਕੰਪਨੀ ਤੋਂ ਬਾਹਰ ਕਿਸੇ ਨੂੰ ਵੀ ਤਬਦੀਲ ਕਰੋ.

  2. ਆਪਣੀ ਐਪਲੀਕੇਸ਼ਨ ਜਾਂ ਸਾਈਟ ਦੀ ਮੇਜ਼ਬਾਨੀ ਕਰਨਾ

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

  3. ਕੋਡ ਦਾ ਮਾਲਕ ਹੈ

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

  4. ਇੱਕ ਦੂਜੀ ਰਾਏ ਲਓ!

    ਇਹ ਮੇਰੀ ਭਾਵਨਾਵਾਂ ਨੂੰ ਠੇਸ ਨਹੀਂ ਪਹੁੰਚਾਉਂਦਾ ਜਦੋਂ ਲੋਕ ਮੈਨੂੰ ਦੱਸਦੇ ਹਨ ਕਿ ਉਹ ਬੋਲੀ ਲੈ ਰਹੇ ਹਨ ਜਾਂ ਦੂਜੇ ਪੇਸ਼ੇਵਰਾਂ ਨਾਲ ਸਲਾਹ-ਮਸ਼ਵਰਾ ਕਰ ਰਹੇ ਹਨ. ਅਸਲ ਵਿਚ, ਮੈਂ ਇਸ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹਾਂ!

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

6 Comments

  1. 1

    ਮੈਂ ਇੱਕ ਵੈਬ ਐਪ ਡਿਵੈਲਪਰ ਹਾਂ ਅਤੇ ਮੈਂ ਤੁਹਾਡੇ ਜ਼ਿਆਦਾਤਰ ਬਿੰਦੂਆਂ (ਸ਼ਾਇਦ ਸਾਰੇ) ਨਾਲ ਸਹਿਮਤ ਹਾਂ ਪਰ ਮੈਨੂੰ # 3 'ਤੇ ਸਪਸ਼ਟੀਕਰਨ ਚਾਹੀਦਾ ਹੈ.

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

    ਉਦਾਹਰਨ:
    ਕਲਾਇੰਟ ਪੇਜ ਲੈਵਲ ਅਤੇ ਫੀਲਡ ਲੈਵਲ ਕੰਟਰੋਲ ਨੂੰ ਯੂਜ਼ਰ ਰੋਲ ਨਾਲ ਬੰਨ੍ਹਣਾ ਚਾਹੁੰਦਾ ਸੀ. ASP.Net ਲਈ "ਬਾਕਸ ਤੋਂ ਬਾਹਰ" ਕਾਰਜਕੁਸ਼ਲਤਾ ਫੋਲਡਰ ਪੱਧਰ ਦੀਆਂ ਆਗਿਆ ਦਿੰਦੀ ਹੈ. ਇਸ ਲਈ ਮੈਂ. ਨੈੱਟ ਲਈ ਦੇਸੀ ਅਧਿਕਾਰਾਂ ਨੂੰ ਵਧਾ ਦਿੱਤਾ ਅਤੇ ਸਮੁੱਚੇ ਵੈਬ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਹੱਲ ਕੱ theਿਆ.

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

    ਇਕ ਹੋਰ ਝੁਰੜੀ:
    ਮੈਂ ਇਹ ਇਕ ਸਲਾਹਕਾਰ ਕੰਪਨੀ ਦੁਆਰਾ ਬਾਹਰ ਕੱ whileੇ ਜਾਣ ਸਮੇਂ ਕੀਤਾ. ਕੀ ਸਲਾਹ ਮਸ਼ਵਰਾ ਕਰਨ ਵਾਲੀ ਕੰਪਨੀ ਨੂੰ ਵਾਪਸ ਜਾ ਕੇ ਉਸ ਹੱਲ ਦੀ ਨਕਲ ਕਰਨ, ਇਸ ਨੂੰ ਆਪਣੇ ਖੁਦ ਦੇ ਤੌਰ ਤੇ ਮਾਰਕੀਟਿੰਗ ਕਰਨ ਦਾ ਅਧਿਕਾਰ ਹੈ?

    • 2

      ਸਚ ਵਿੱਚ ਨਹੀ,

      ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਅਸੀਂ ਸਹਿਮਤ ਹਾਂ ਇਸ ਵਿਚ ਮੇਰਾ ਨੁਕਤਾ ਇਹ ਸੁਨਿਸ਼ਚਿਤ ਕਰਨਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਕੋਡ ਹੈ ਅਤੇ ਇਸ ਨਾਲ ਦਰਵਾਜ਼ੇ ਨੂੰ ਬਾਹਰ ਕੱ can ਸਕਦੇ ਹੋ. ਜੇ ਤੁਹਾਡਾ ਵਿਕਾਸਕਰਤਾ ਤੁਹਾਡੇ ਲਈ ਕੋਡ ਕੰਪਾਇਲ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਆਪਣੀ ਸਾਈਟ ਤੇ ਬਾਹਰ ਭੇਜ ਰਿਹਾ ਹੈ - ਤੁਹਾਡੇ ਕੋਲ ਕੋਡ ਨਹੀਂ ਹੈ. ਮੈਂ ਗਰਾਫਿਕਸ, ਫਲੈਸ਼,. ਐਨ.ਈ.ਟੀ., ਜਾਵਾ… ਹਰ ਚੀਜ ਨਾਲ ਅਜਿਹਾ ਹੁੰਦਾ ਵੇਖਿਆ ਹੈ ਜਿਸ ਲਈ ਕਿਸੇ ਸਰੋਤ ਫਾਈਲ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਅਤੇ ਆਉਟਪੁੱਟ ਹੈ.

      ਡਗ

  2. 3

    ਮੈਂ ਵੇਖਦਾ ਹਾਂ ਕਿ ਤੁਸੀਂ ਕਿੱਥੋਂ ਆ ਰਹੇ ਹੋ ਅਤੇ ਜਦੋਂ ਕਿ ਮੈਂ ਹਰ ਚੀਜ਼ ਨਾਲ ਸਹਿਮਤ ਨਹੀਂ ਹਾਂ 100% (ਮੇਰੇ ਕੋਲ ਚੇਤਾਵਨੀ ਹੈ), ਕੰਪਨੀਆਂ ਨੂੰ ਹਮੇਸ਼ਾਂ ਇਸ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ.

    1. ਬਿਲਕੁਲ. ਇਸ ਨੂੰ ਕਾਫ਼ੀ ਤਣਾਅ ਨਹੀ ਕਰ ਸਕਦਾ. ਮੈਂ ਇਕ ਛੋਟੀ ਜਿਹੀ ਕੰਪਨੀ ਲਈ ਕੰਮ ਕੀਤਾ ਹੈ ਜਿਸ ਨੇ ਇਹ ਕੀਤਾ ਅਤੇ ਮੈਂ ਮਹਿਸੂਸ ਕੀਤਾ ਕਿ ਇਸ ਵਿਚ ਸ਼ਾਮਲ ਹੋਣ 'ਤੇ ਦੋਸ਼ ਨੂੰ ਕੁਚਲਿਆ ਜਾ ਰਿਹਾ ਹਾਂ. ਮੈਂ ਬਹੁਤ ਖੁਸ਼ ਹਾਂ ਕਿ ਮੈਂ ਉੱਥੋਂ ਨਿਕਲਣ ਦੇ ਯੋਗ ਹੋ ਗਿਆ. ਗ੍ਰਾਹਕਾਂ ਨੂੰ ਆਪਣੇ ਡੋਮੇਨਾਂ ਦਾ ਨਿਯੰਤਰਣ ਬਿਲਕੁਲ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ. ਜੇ ਉਨ੍ਹਾਂ ਕੋਲ ਕਿਸੇ ਕੋਲ ਕਾਫ਼ੀ ਜਾਣੂ ਹੈ, ਤਾਂ ਡਿਵੈਲਪਰ ਨੂੰ ਇਸ ਤੱਕ ਪਹੁੰਚ ਨਾ ਦਿਓ. ਜੇ ਨਹੀਂ, ਤਾਂ ਇਹ ਸੁਨਿਸ਼ਚਿਤ ਕਰੋ ਕਿ ਡਿਵੈਲਪਰ ਕੋਲ ਤੁਹਾਡੇ ਕੋਲ ਜਾਣਕਾਰੀ ਨੂੰ ਬਦਲਣਾ / ਡੋਮੇਨ ਨੂੰ ਬਹੁਤ ਘੱਟ ਵਿੱਚ ਕਿਸੇ ਕਿਸਮ ਦੇ ਇੱਕ ਰੈਸਲਰ ਇੰਟਰਫੇਸ ਦੁਆਰਾ ਤਬਦੀਲ ਕਰਨਾ ਹੈ.

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

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

    4. ਹਮੇਸ਼ਾਂ. ਹਮੇਸ਼ਾ. ਹਮੇਸ਼ਾ.

  3. 4

    ਵਧੀਆ ਪੋਸਟ ... ਵਧੀਆ ਹੋ ਗਿਆ ਹੈ ਹਾਲਾਂਕਿ ਮੈਂ ਇਕ ਚੀਜ਼ ਨਾਲ ਸਹਿਮਤ ਨਹੀਂ ਹਾਂ (# 2):

    "ਇਹ ਬਹੁਤ ਵਧੀਆ ਹੈ ਕਿ ਤੁਹਾਡੇ ਡਿਵੈਲਪਰ ਦੀ ਹੋਸਟਿੰਗ ਕੰਪਨੀ ਹੋ ਸਕਦੀ ਹੈ ਅਤੇ ਤੁਹਾਡੀ ਸਾਈਟ ਤੁਹਾਡੇ ਲਈ ਹੋਸਟ ਕਰ ਸਕਦੀ ਹੈ, ਪਰ ਅਜਿਹਾ ਨਹੀਂ ਕਰੋ."

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

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

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

    ਦੁਬਾਰਾ, ਚੰਗੀ ਪੋਸਟ ਅਤੇ ਬਹੁਤ ਲਾਭਦਾਇਕ ਜਾਣਕਾਰੀ.

    ਧੰਨਵਾਦ ਹੈ!
    ਮਾਈਕਲ ਰੇਨੋਲਡਸ

    • 5

      ਹਾਇ ਮਾਈਕਲ,

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

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

      ਮੈਂ ਵਕਾਲਤ ਕਰ ਰਿਹਾ ਹਾਂ ਕਿ ਤੁਸੀਂ ਆਪਣੇ ਹੋਸਟਿੰਗ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰੋ ਅਤੇ ਜ਼ਿੰਮੇਵਾਰ ਹੋਵੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਆਪਣੇ ਡਿਵੈਲਪਰ 'ਤੇ ਨਿਰਭਰ ਕਰ ਸਕੋ ਕਿ ਉਹ ਕੀ ਕਰ ਰਿਹਾ ਹੈ - ਵਿਕਾਸਸ਼ੀਲ!

      ਮੈਂ ਪੁਸ਼-ਬੈਕ, ਮਾਈਕਲ ਦੀ ਪ੍ਰਸ਼ੰਸਾ ਕਰਦਾ ਹਾਂ.

  4. 6

    ਮੈਂ ਇੱਕ ਵੈਬ ਐਪ ਡਿਵੈਲਪਰ ਵੀ ਹਾਂ, ਅਤੇ ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਸਿਰ ਤੇ ਨਹੁੰ ਮਾਰਿਆ ਹੈ. ਕੁਝ ਵਿਚਾਰ:

    ਮੇਰਾ ਖਿਆਲ ਹੈ ਕਿ ਬਹੁਤੇ ਲੋਕ ਸਹਿਮਤ ਹੋਣਗੇ (ਅਤੇ ਹੇਠਾਂ ਦਿੱਤੀ ਟਿੱਪਣੀਆਂ 'ਤੇ ਅਧਾਰਤ ਹਨ) # 1 ਇਕ ਪੂਰਨ ਹੈ. ਕਦੇ ਨਹੀਂ, ਕਦੇ ਵੀ ਨਾ ਕਰੋ. ਕਦੇ. ਕਿਸੇ ਵੀ ਸਥਿਤੀ ਵਿਚ.

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

    # 3 ਲਈ, ਸਾਡੇ ਕਲਾਇੰਟ ਇੱਕ ਕੈਵੇਟ ਦੇ ਨਾਲ ਅੰਤਮ ਉਤਪਾਦ ਦਾ ਸਾਰਾ ਸਰੋਤ ਕੋਡ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ: ਤੀਜੀ ਧਿਰ ਦੇ ਉਤਪਾਦਾਂ ਲਈ ਜੋ ਹੱਲ ਵਿੱਚ ਵਰਤੇ ਜਾਂਦੇ ਹਨ (ਜਿਵੇਂ ਕਿ ਟੈਲੀਰੀਕ ਜਾਂ ਕੰਪੋਨੈਂਟ ਵਨ ਤੋਂ ਵੈੱਬ ਨਿਯੰਤਰਣ), ਅਸੀਂ ਕਲਾਇੰਟ ਨੂੰ ਕੰਪਾਈਲਡ ਡੀਐਲ ਦੇ ਸਕਦੇ ਹਾਂ. ਤੀਜੀ ਧਿਰ ਦਾ ਨਿਯੰਤਰਣ (ਇਕ ਗਰਿੱਡ ਕਹੋ). ਉਨ੍ਹਾਂ ਤੀਸਰੀ ਧਿਰ ਦੀਆਂ ਕੰਪਨੀਆਂ (ਜੋ ਅਸੀਂ ਕਲਾਇੰਟ ਨੂੰ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਾਂ) ਨਾਲ ਸਾਡੇ ਲਾਇਸੈਂਸ ਸਮਝੌਤੇ ਸਾਨੂੰ ਉਨ੍ਹਾਂ ਕਿਸਮਾਂ ਦੇ ਨਿਯਮਾਂ ਲਈ ਸਰੋਤ ਕੋਡ ਨੂੰ ਦੁਬਾਰਾ ਵੰਡਣ ਤੋਂ ਵਰਜਦੇ ਹਨ, ਕਿਉਂਕਿ ਇਹ ਤੀਜੀ ਧਿਰ ਦੀ ਬੌਧਿਕ ਜਾਇਦਾਦ ਹੈ, ਸਾਡੀ ਨਹੀਂ. ਇਸ ਕਿਸਮ ਦੇ ਉਤਪਾਦਾਂ ਦੀ ਵਰਤੋਂ ਗਾਹਕ ਲਈ ਵਿਕਾਸ ਦੇ ਸਮੇਂ ਦੀ ਬਚਤ ਕਰਦੀ ਹੈ ਅਤੇ ਸਕ੍ਰੈਚ ਤੋਂ ਉਸੀ ਕਾਰਜਸ਼ੀਲਤਾ ਨੂੰ ਬਣਾਉਣ ਨਾਲੋਂ ਬਹੁਤ ਸਸਤਾ ਹੈ. ਕੋਈ ਵੀ ਕੰਮ ਕੀਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਅਸੀਂ ਇਸ ਨੀਤੀ ਬਾਰੇ ਸਪਸ਼ਟ ਹਾਂ. ਬੇਸ਼ਕ, ਜੇ ਗਾਹਕ ਕਸਟਮ ਕੰਟਰੋਲ ਵਿਕਾਸ ਲਈ ਭੁਗਤਾਨ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ (ਤੀਜੀ ਧਿਰ ਦੁਆਰਾ ਪੂਰਵ ਨਿਰਮਾਣ ਵਾਲੇ ਉਤਪਾਦ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਬਜਾਏ) ਅਸੀਂ ਉਸ ਸਭ ਕੁਝ ਦੇ ਨਾਲ ਉਸ ਕਸਟਮ ਕੰਟਰੋਲ ਲਈ ਸਰੋਤ ਕੋਡ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਾਂ.

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

    ਜਿਵੇਂ ਕਿ ਦੂਜਿਆਂ ਨੇ ਕਿਹਾ ਹੈ, # 4 ਹਮੇਸ਼ਾਂ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ. ਸਦਾ!

    ਸਹਿਤ,
    ਟਿੰਮ ਯੰਗ

ਤੁਹਾਨੂੰ ਕੀ ਲੱਗਦਾ ਹੈ?

ਇਹ ਸਾਈਟ ਸਪੈਮ ਨੂੰ ਘੱਟ ਕਰਨ ਲਈ ਅਕਕੀਮੈਟ ਵਰਤਦੀ ਹੈ. ਜਾਣੋ ਕਿ ਤੁਹਾਡੇ ਟਿੱਪਣੀ ਡੇਟਾ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਿਵੇਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ.