If you're using source control, it's easy to track source and control access — or revoke access — if someone leaves the company.

Also, your developers should have signed a contract about the project itself that clearly places the source code under your/the client's/the company's control, and if/when they leave, they release all rights to code created under that contract.

You can never be 100% sure, but these small steps will at least ensure a legal high ground should anyone steal code.

Good luck!

I have intern for a company that sees a lot of developers for projects, along with a different company that was very strict with VPN access.

First of all: contract, contract, contract. Non-compete and NDA at the least. We can have all of the security protection in the world, but if you don't put in legal writing that the IP and any code that you write for the project belongs to them (including anything written on the machine you provide), then there's no legal bounds for stealing the code.

One common way is to minimize local files on the computer; if an employee steals the computer, all of the files could be there. Host that on a secure server with authentication. You can also add another layer of protection with VPN access to the server. Doing this, you don't have public access to the server that hosts your code. Hard drive encryption also protects the employee and yourself from theft; even if the computer is stolen, BitLocker will render that data useless when the thief tries to take the laptop out the computer.

There are many many other mechanisms you can have in place, but that should get you started about the mindset you'll need to protect your source code.

What programming languages are using ? What operating system ?

If you are on windows platform , you can enforce security so the devices and operating system. If you are using Microsoft compatible programming languages, you can use TFS as a source control and ticketing system. You can also use token based systems / cisco vpns and enforce security policies so that users can only use the internal servers / network to commit the code. ( Your IT Department security consultant can help with that ) .

If platform level security can't be guaranteed, you can still use distributed source controls, like GIT or SVN. Software management systems, like Jira or Versionone, can be used for the ticketing, and you can use smart commits for every commit, to help link code on feature basis . That also can be a base for a future plan for implenting TDD and continuous integration .

Finally, your team should be singing an NDA and make sure you work with people with work ethics. Motivate your team to be your asset and grow with you. This is your 100% guarantee.

Let me know if you need more help. .

Good Luck!

As everyone has mentioned , it all starts with your NDA and your employment agreement. Next keeping a highly motivated team that has a healthy culture of ethics. Finally from an architecture perspective you might be well advised to figure out a way to modularize things so not all people get all source. There are ways to do this which can be a benefit to the system you are making, the teams and responsibilities of the staff as well as a physical separation of concerns and access to help mitigate your problem of code availability.

Good luck!

Protecting the source code isn't trivial, since there are plenty of ways to get access to it, one way or the other, with the right motivation.

Step one is NDAs and non-competes, so that you can protect the IP if needed, in extreme cases.

Step two is hiring people with certain reputation. A lot of the good developers are involved with communities of some sort - related to the programming platform or something else. They maintain GitHub profiles and use other methods to be respectable in their niche. Those people are less likely to turn against you and perform shady activities, since their reputation can also be affected.

Step three is communication. Most of the internal conflicts happen due to the lack of proper communication - people getting rejected in a rude way, or not treated properly. Whatever happens over the months (years) can be communicated properly. Even if you part ways one day, it would be clear what the reason is, and it will be justifiable.

Most conflicts happen after a serious company drama that escalated with time, and with the right contract and attitude they could be prevented as well.

Legally or physically?

Unfortunately, the reality is that you just have to assume that everyone who has access to your code has a copy of it on their home PC. They probably don't, but there's very little that you can do to stop them if they wanted to. Think of it this way - have you ever met someone in sales who didn't have a copy their rolodex and some good sample contracts at all times?

The "good" news here is that just having IP is not enough. Software development is so fast and efficient these days that even starting with code, unless you have some very particular formulae (and if you do you should keep them somewhere else with limited access to that code), most of your code is not particularly relevant. To anyone wishing to compete with you its probably fairly simple to copy your product, but much harder to copy the business itself. If you have reasonable employment agreements you can probably make the risk of copying greater than the benefit that a new competitor would get by doing so, and that's often the best you can do.

That's both a blessing and a curse. I've started a few successful "product" companies that relied on SaaS software and would be happy to discuss it further if you like.

As a startup founder, I have the same problem as you do. I researched online and found very few tools (https://ontoborn.com/ontoarmour) that solve this problem.