We're considering hiring a contractor or intern to work with us on our iOS project but this causes me to get really paranoid that we're giving somebody who doesn't work for the company access to our precious codebase. I mean, I could just give them access to the classes I'd like them to work on but that seems rude and it would make it more difficult for them to develop what we need them to.
How paranoid should one be about people running off with their entire application?
You should have a non compete and/or Non disclosure agreement in place when you bring them on. This will allow you to bring in a contractor and should they choose to run off on their own and create the next Face book with out you, based on your work, you can take it all back. But realistically that does not happen often. If you go through a reputable company then you will probably get a professional who wants to help you succeed. Do not hinder them by trying to compartmentalize them to the point that they want you to fail.
The don't need access to code they don't need; it will only confuse them or waste their time.
There should be legal agreements that this is your code and they're not alowed to use it for other purposes or there will be consequences. This should all be very standard.
If you've hired quality professionals there is nothing rude about it and for them to protest too much would be suspicious.
I have previously worked as a contractor who was not allowed to see the customers "Crown Jewels". This was an operation with Military contracts, confidentiality printed on every page, rooms with locks and more locks and "If you go in there we will have to shoot you" kind of things going on. I was GIVEN the "Crown Jewels" several times by accident. I gave up reporting it deleted it if I was ever given it.
My advise is unless you have an exceptionally robust process don't bother, you won't succeed in locking down the code.
Hire professionals, stitch them in NDA's (Which are pretty much unenforceable until the losses get into millions of dollars), and trust them to get on with the job. If you cannot trust them, why give them access to any code, let alone let them program for you?
I've worked as a contractor in a number of companies on a number of different codebases over the years and in nearly all cases there's been a pretty standard catch-all clause in the contract I sign that says anything I see or do there is confidential.
The wording varies but the intent is the same - to protect the company in the case of me running off to a competitor with their trade secrets. That's understood and accepted (by me anyway, I can't speak for anyone else) and it means that the company in turn can just let me dive in and do my job without having to be hindered by constantly asking for permission to see another piece of source.
In one place I worked the crown jewels of the company were bound up in some highly specialized IP that had restricted access even within the regular employees. That code was wrapped up in a library so it could just be called without ever knowing how it did what it did which is another option for you if you need to protect some core code against prying eyes. Even that is probably not completely foolproof, but then again you do need to have a certain level of trust in the people working for you otherwise nothing will ever get done!
You use NDA & non-compete agreements, but basically you trust them.
Self-reflection is also important. It would be much better to hire an employee right? You probably don't because of the cost, especially to keep and retain a good one.
If you have the next killer-app that would be fine, however if you're not there 'yet' and you're still out-sourcing, this is part of the risk and the cost.
If you have an idea that people will throw money at even to get 1% of the equity, then you have a killer idea and you'll have the $$ to match.
There's a certain amount of pretty killer Darwinism going on in this space right now. It's not always logical but it's actually a lot more saner that the dot-com time that I also lived through professionally.
