What we do where I work really depends on the client and their contract. We don’t host any of the sites ourselves; instead, we host our sites using the Rackspace Cloud. So long as the client is paying their monthly hosting bills, we have no problem giving them FTP access to their site, as well as giving them database access. They have access to this information anyway via their control panel, though generally they are not fully aware of this fact, since they rarely explore the features available to them.
If they do specifically ask for FTP access, the first thing we do is make sure they understand that any changes made to the code or structure of the site - outside of any requests made directly to us - become their responsibility, and time spent fixing any errors or bugs they may introduce will be billed and expected to be paid in order to keep the hosting service active.
The main idea behind this is the fact that they paid for the site, our contracts state that they own everything that we create for them; we only reserve the right to reuse portions as we see fit. Because they own it, we cannot ethically deny them access to do what they wish, so long as they know the potential consequences.
Privacy concerns are understandable, which is one of the driving reasons behind our switch to Rackspace. All the accounts are kept separate, and security is maintained more reliably with them than we would be able to achieve on our own. Previously when we were hosting sites ourselves, we rarely gave access to sites without first transferring them to another, separate host in order to maintain integrity of our own server.
for about me: I try not ot give access to ftp, as I got a real world examples when a ‘bad’ webmasters change micro code somewhere and ten you don’t know - where and how to find mistake.
We deliver all high resolution images we produce to our clients along with everything needed to embed our Flash components on clients’ websites. Unless our hosting service is used, in which case we pretty much manage everything for them.
The reason i posted this thread is because our circumstance is that, often the client or another developer on their behalf makes changes to the site, but it’s still expected of us to make more complex changes when required.
We have a local development environment that ought to have the most up-to-date version of the code (so we can test all changes prior to making live). A client using FTP therefore has to inform us of any changes they make to the code or else we have to check the live version for changes before making our own updates, to avoid overwriting client changes. Even if the client is capable, and NOT breaking stuff - unless we do our checking in this scenario, WE might break stuff.
We’re proposing to implement SVN and strongly encourage clients to use it if they want to make changes themselves. But in the case of clients who insist on using FTP, there is internal debate about whether we should flat-out refuse FTP (possibly leading to dissatisfied + lost clients), or let them continue as is with all the inherent issues that go with that - which also means we’ll be implementing SVN only to not even use it (for certain clients).
My personal stance is we’ll have greater integrity in a client’s mind, by arguing the case for SVN only access, for sites that we continue to be a developer for.
If we implement SVN only to ‘cave in’ and let them use FTP anyway, we’re not doing anyone any favours.
I think it’s worth pointing out that when I work with a client, they either have their own hosting or I set them up with hosting (or just issue them the files to do what they want with it), I rarely tie in their stuff with my own services because I feel there’s an issue of control in respect to ownership of the materials. As such when the contract is fulfilled I’ll pass over the stuff to them and it’s up to them if they want to mess up the design or go elsewhere post it’s completion. It’s surprising how often they’ll come back to you after they break the thing and ask you to fix it for them (that’s a recurring form of revenue you can count on).
It depends on the circumstances, if my contract with them is complete, I have no problem with them getting other people involved (post me getting paid for what was agreed upon), however if they just want someone else to “assist me” I downright disagree purely on the basis that I need to have control over how the code is produced and managed to ensure that no bugs or additional glitches occur during the process - it’s a case of too many cooks spoiling the broth.
It depends, if you retain ownership of the code then fine, it’s probably acceptable, but if it’s the normal case of you do the work, give it to the end user on a non-exclusive license or giving them full ownership over the code then vendor lock-in’s is a pretty bad decision ethically (IMO). I doubt anyone here would enjoy the same situation if your web hosts did that (as in you host your site with them, they prevent you moving hosts or lock you out of your account for attempting to do it). It should be the quality of your work bringing your clients back, not some mechanism which prevents them using their purchase to their own end.
Agreed, there’s a lot of times where FTP access may even be necessary to achieve their goals, what if they have a static website (with no CMS) and they want to attach files, with no FTP access their pretty much screwed unless they go through you (which will cost them every time they do it). I’ve heard of website maintenance but really, this is one step too far. I think such trappings would put people off returning to your services in the future rather than act as a good thing.
How long would that last
I think this is the key clincher, if you own the hosting and the code, it’s reasonable to want to control it’s usage out of benefit for the end user… however, if it’s a host of their choice (or one you setup on their behalf) and the contract is finished, there’s no genuine reason to prevent them from controlling what is effectively their property (as their paying for the service). Keeping on the clients good side is probably one of the best lessons you can gain from such situations.
The best thing you can do is ensure you keep regular backup’s of the website (as incremental changes occur) and therefore, if something gets messed up you can quickly and easily restore the original version. Yes they’ll lose all their changes but it’s better to have a working website that functions as expected (and then make their changes on their behalf post-restoration) than to keep patching other peoples handiwork. It’ll also give them a good reason to return to you as you’ll be able to upgrade the base version with all the latest tweaks they require, all the content additions they want and as you’ll have the “master copies” they’ll have a fail-safe in place for as and when they or their representation screw up (so you can ride in like a knight in shining armour and fix their mess-up’s - for a fee of course).
Clients and myself have full access to the FTP server. If I find my client is not tech savvy, it IS actually safer to not give it to them unless requested. If the hosting company is under my own records, then its usually my own ftp, my own passwords.
Seems to development is client access if we need them to do something for us. And Hosting, for security reasons if you are hosting you don’t provide access but if they have their own hosting give them access with a clear warning that if you have to roll back the site its to your last copy.
In a long term development case, like this reads. A) you have to check and copy etc any changes a client makes, its a cost to the client. B) do you offer an affordable updating fee vs the programming the fee option?
Find someone affordable you like to do these updates and pass the affordable rate onto the client. They will be happier and you will be happier.
I don’t have a problem with the client having FTP access to a hosting account they are paying for. It’s not my problem if they are foolish enough to play where they shouldn’t be… I provide a backup disk of the original site. Most clients ask “What am I supposed to do with this?”.
I wouldn’t work for you. The vector files are mine, unless you want to pay me extra for them. I’m sure you’ve run into more than one designer who feels this way. Good luck to you.
If they paid for it, they get access. To me, it does not make too much business sense to deny a client a product or service that they paid for. It is almost like that the client bought a car but is not allowed to drive it.
Why shouldn’t an employer get the base/vector files that an employee produces on company time and at company expense? Unless it is a freelance contract and stated at the outset that the employer only gets the finished files then he owns all files produced
I’m a freelancer in the United States. I am never an employee of the company I’m doing work for. If they are not providing benefits and a workspace for me, or are not paying an additional fee for the original files, the files belong to me. I explain this to the client ahead of time. If they don’t agree, I don’t take the job. I have walked away from projects before. Clients have opted not to use me, as well. I’m not in the business of providing templates. You aren’t either. Turning over original art files, without figuring a charge for them into the project, is shooting the industry in the foot.
If you are considered an employee of the company (hired with all benefits, or…), the employer, by law, owns the files you create.
Ah well, different strokes and all that. In the UK it is standard business practice that the client owns all the files associated with a project (unless otherwise specified, esp where custom code is concerned- in which case it is usually encrypted)
If a client asks for access/files I give it to them. It’s their site, and if they wish to migrate away from using my services for ongoing site maintenence that’s their perogative. I never try to hold a client hostage.
However, if a client wishes to continue using my services I do not want them giving outside developers access to their website, unless it is for a specific purpose and I agree to it. Version control gets all messed up when people start modifying files willy nilly, and development/design consistency is compromised.
For me it’s not an issue of ownership, but of maintaining an effective workflow.
The last time I ran into this situation I told my client that if they wished for someone else to take over maintenence of the site then I was happy to perform a full handover, but that I was didn’t think it served their interests or mine for the development work to be shared between myself another developer. The client agreed with my point of view - it was never their intention to “fire” me, they were just unaware of the complications that might arise from having two separate developers working on the site simultaneously.
If the client has an in-house IT guy who doesn’t mess up my SVN repo, he can get an account. Certainly they can get an FTP account if they ask for it—it’s after all their site—but I will not provide it unless they specifically want it. I then inform them that any changes will have to be committed to SVN which can give me trouble, so if they make FTP changes, tell me everything.
Client hosts the website and I manage their hosting:
Obviously it’s their hosting and website—they will get everything they need.
No way never let your penny pinching client access to your server. They will more often than not allow someone else to cause problems or cause problems themselves. Always sell the full service approach. Sell the omlet and not the cheese, onions, sausage, etc;)
