Vältige oma arendajate pantvangi sattumist

pantvang100107Sel nädalavahetusel alustasin vestlust kohaliku kunstnikuga, kes on abistanud tema ülemust paari tema ülemuse omatavate veebirakenduste haldamisel.

Vestlus võttis pöörde ja mõningane õhutamine kulges iganädalaste arendustasude maksmisel, nägemata arengut arendajaga, kellega nad on töötanud. Nüüd soovib arendaja neilt projekti lõpuleviimiseks nõuda veel ühekordset tasu, samuti iganädalast hooldustasu muude taotluste katmiseks. See läheb hullemaks.

Arendaja viis domeeninimed üle, et saaks neid hallata. Arendaja majutab rakendust ka oma hostikontol. Ühesõnaga, arendaja hoiab neid nüüd pantvangis.

Õnneks nõudis naine, kellega ma töötan, varem saidi mallifailide muutmiseks administraatorijuurdepääsu. Arendaja oleks võinud pakkuda talle piiratud juurdepääsu, kuid ta seda ei teinud. Ta andis (laisalt) talle saidile administraatori sisselogimise. Täna õhtul kasutasin seda juurdepääsu saidi kogu koodi varundamiseks. Samuti sain aru, millist haldustarkvara ta kasutab, ja jõudsin andmebaasi halduse juurde, kus sain eksportida nii rakenduste andmeid kui ka tabelistruktuure. Vat.

Omanik kavandas saitide viimist uutele domeeninimedele, kui arendus oli lõpule viidud. See on tohutu, sest see tähendab, et praegused domeenid võivad aeguda juhul, kui arendaja ja ettevõte lähevad vihaselt lahku. Olen seda varem juhtunud.

Mõned näpunäited, kui soovite hankida allhankega arendustiimi:

  1. Domeeni registreerimine

    Registreerige oma domeeninimed oma ettevõtte nimes. Pole halb, kui teie arendaja on kontol tehnilise kontaktisikuna, kuid mitte kunagi anda domeeni omandiõigus üle kellelegi väljaspool teie ettevõtet.

  2. Teie rakenduse või saidi majutamine

    On tore, et teie arendajal võib olla hostimisettevõte ja ta saab teie saiti teie eest majutada, kuid ärge tehke seda. Selle asemel küsige tema soovitusi rakenduse majutamiseks. On tõsi, et arendajad tutvuvad haldustarkvara, versioonide ja ressursside asukohaga ning see aitab teie toodet kiiremini valmis saada. See tähendab, et omage hostimiskontot ja lisage oma arendaja oma sisselogimise ja juurdepääsuga. Nii saate pistikust tõmmata, kui vaja.

  3. Oma kood

    Ärge arvake, et kood kuulub teile, pange see kirjalikult. Kui te ei soovi, et teie arendaja kasutab talle makstud lahendusi mujal arendamiseks, peate selle lepingu sõlmimisel otsustama. Olen sel viisil välja töötanud lahendusi, kuid olen neid ka välja töötanud, kus mul on õigused koodile. Viimasel juhul pidasin rakenduse maksumuse väiksemaks, nii et ettevõttel oli ajend mulle õigusi anda. Kui te ei pahanda, et teie arendaja kasutab oma koodi mujal, siis ei peaks te maksma parimat dollarit!

  4. Hankige teine ​​arvamus!

    Minu tunnetele ei tee haiget, kui inimesed ütlevad mulle, et nad teevad pakkumisi või peavad nõu teiste spetsialistidega. Tegelikult ma soovitan seda!

Lõpptulemus on see, et maksate oma arendaja ande eest, kuid peate säilitama idee üle kontrolli ja omandiõiguse. See on sinu. Sina investeerisid sellesse, sina riskisid sellega oma äri ja kasumlikkust ... ja sina peaksid seda hoidma. Arendajaid saab asendada ja see ei tohiks kunagi teie rakendust või veelgi hullem - teie ettevõtet - ohtu seada.

6 Kommentaarid

  1. 1

    I’m a web app developer and I agree with most of your points (perhaps all) but I’d like a clarification on #3.

    Wholesale duplication of a site or application sold to another company (or worse a competitor) is unethical and should always be stipulated as not acceptable in your contract. However, I have developed innovative solutions to common problems while working on a client’s project that has nothing to do with their particular biz nor does it represent a significant portion of the overall solution.

    Näide:
    Client wanted page level and field level control tied to user roles. The “out of the box” functionality for ASP.Net does folder level permissions. So I extended the native permissions for .Net and delivered the solution as part of an overall web appplication.

    I believe that they are entitled to the entire codebase (as stipulated in the contract) but I feel justified in using the same methodology and chunks of code to accomplish this extension on future projects.

    Another wrinkle:
    I did this while being farmed out by a consulting company. Would the consulting company have the right in your opinion to go back and copy that solution, marketing it as their own?

    • 2

      Notreally,

      I think we agree. My point in this is to ensure that you have the code and can walk out the door with it. If your developer is compiling code for you and pushing it out to your site – you don’t have the code. I’ve seen this happen with everything from graphics, Flash, .NET, Java… anything that requires a source file and is outputted.

      Doug

  2. 3

    I see where you’re coming from and while I don’t agree with everything 100% (I have caveats), companies should always keep this in mind.

    1. ABSOLUTELY. Can’t stress this enough. I’ve worked for a small company that did this and I felt crushing guilt over being involved. I’m so glad I was able to get out of there. Customers should absolutely retain control of their domains. If they have someone savvy enough, don’t give the developer access to this. If not, make sure the developer has a way for you to change info/transfer the domain via a reseller interface of some kind in the very least.

    2. I’d partly agree with this but then it depends on the situation. If you’re deploying a simple PHP app and need low cost hosting, by all means, get a LunarPages or DreamHost account or something and dump it there. Give the developer access. However, low-cost shared hosting certainly has it’s drawbacks… especially for bigger things. But if you’re big enough to be worrying about that you should have someone technical on staff that can deal with it. A lot of it is obviously about trust. Sure as hell put something in a contract if you can about this kind of thing (restrictions and such). Third party hosting is great if the developer doesn’t need to do anything fancy. I admit I’m torn because it’s really a situational thing. It also depends on the size of the site, the array of technologies used. If it’s gonna be big, considering hiring a person on staff. Not always an option, but safer for big stuff.

    3. This is also something my former company did. You could leave, they would give you the HTML, images etc…. but no code. The code was a leased service basically. That being said, there’s owning and owning. I’ve always done a non-exclusive sale. Basically, I need to be able to reuse my components. I have no issue with the client owning it, doing what they want with it and having someone else work on it down the line… but I ain’t gonna mortgage myself and have to reinvent the wheel every time.

    4. Always. Always. Always.

  3. 4

    Nice post… well done although I disagree with one item (#2):

    “It?s great that your developer might have a hosting company and can host your site for you, but don?t do it.”

    Though I understand the logic behind this, it can be counter-productive in some cases to mandate that your project be hosted somewhere else. If the company developing your site or app has a hosting platform that they prefer to use, chances are it will be more efficient and productive for them to use it.

    Additionally, from a philosophical standpoint, if you refuse to utilize your developer’s hosting platform because you don’t want to be “held hostage”, then this sets a tone of distrust from the start. If you really don’t trust your developer enough to host with them, then do you really want to be working with them in the first place?

    I know that many horror stories do exist about this sort of situation, but in general I would recommend that you focus on finding a developer that you trust. You can utilize your developer’s hosting and still protect yourself by requesting administrative access and making your own backups.

    Again, good post and very useful information.

    Aitäh!
    Michael Reynolds

    • 5

      Hi Michael,

      It may sound like a trust issue but I don’t think it is – it’s really a control and responsibility issue. If you’re going to invest a significant amount in your web site development, then you must be sure that you can control its environment.

      Things happen in business that break relationships and they need not be negative. Perhaps your developer/firm gets a very large client and can’t afford you the time. Perhaps they shift business objectives. Sometimes their hosting company can have issues.

      I’m advocating that you control and be responsible of your hosting so you can depend on your developer for what he’s great at – developing!

      I appreciate the push-back, Michael.

  4. 6

    I’m also a web app developer, and I think you’ve hit the nail on the head. Some thoughts:

    I think most everyone would agree (and has based on the comments below) #1 is a absolute. Never, ever do it. Ever. Under any circumstance.

    I have a different take on #2 than perhaps some of my fellow developers: we refuse to host the final product for our customers (of course, we host a testing server for clients to test drive the product during development). We’re happy to help clients get set up to host it themselves or find a hosting provider. We simply don’t want to get in the business of hosting. If that means turning work away, so be it. There are lots of great hosting companies or infrastructure firms out there than can provide this service at a much cheaper price. We encourage the portability of our work, and will do whatever we can to assist getting it hosted, even if the client switches hosting providers years down the road.

    For #3, our clients get all the source code of the final product with one caveat: For third party products that are used in the solution (such as web controls from Telerik or Component One), we can give the client the compiled dll for the third party control (say a grid). Our licensing agreements with those third party companies (which we provide to the client) prohibit us from redistributing the source code for those type of controls, because it is the third parties’ intellectual property, not ours. The use of these types of products saves development time for the client and is much cheaper than building the same functionality from scratch. We are upfront about this policy before any work is done. Of course, if the client wishes to pay for custom control development (instead of using the prebuilt product from the third party) we provide the source code for that custom control along with everything else.

    When it comes to code reuse, we are upfront about the fact that we may reuse portions of the code unless it was expressly developed exclusively for the client’s use (say for a proprietary business process) before any work is done. If the client wants to have exclusive code developed of course, that is available to them.

    As others have said, #4 is always recommended. Always!

    soovidega,
    Tim Young

Mis sa arvad?

Sellel saidil kasutatakse rämpsposti vähendamiseks Akismetit. Vaadake, kuidas teie andmeid töödeldakse.