How do you protect your code?
For a startup, the product is the most important asset, but it seems that in many/most startups (I know), the complete code base is shared among every member of the team. Even complete database access is shared, too.
I know that accessing the complete code base may make the process easier and faster, but it's very dangerous and unprofessional because, in a startup, employees come and go so often. And you are the one who fire them.
I assume that most startup doesn't want to get involved in any kinds of lawsuits, which take unnecessary time and money. Thus, protection beforehand is much better.
How could you deal with this situation? What's your method of protecting your code base?
-
Don't hire people that will steal your code. If you spend your time worrying about your employees doing wrong by you then you don't have the right people working for you. – Joel Friedlaender 12 years ago
4 Answers
The main differences between development at a startup and at any other enterprise are that at a startup, you are more likely to have fewer developers, rapid releases, scattered code and deployments, and overall, more chaos.
However, in a modern software company -- startup or otherwise -- it is unrealistic to expect that your employees won't have access to your codebase. Even if you attempt to partition the code based on access rights to repositories, your developers are likely to intermix and re-deploy your code as it suits their productivity.
There are some basic best practices you should follow, some of which it sounds like you already are:
- Store your code in an enterprise-ready source management tool, and make sure each person who has access rights has their own account. If possible, use a solution that can log check-outs in addition to check-ins. As stated, this will not really prevent people from copying your code around, but it is a good first line of defense.
- Restrict access to your source repository to your VPN if you have one, or if not, see if you can configure it in such a way that nobody in the outside world can "see" your server. Again, this does not guarantee anything, but minimizes the risk of unauthorized accesses to your repository, and discourages employees from doing things like checking out code at home.
- Minimize the number of deployments to necessary systems. Too often, a startup moves rapidly enough that pieces of code get strewn all over servers in development environments, temporary servers, and so on. Often times developers will be deploying things themselves to test configurations, and nobody ever cleans things up. Just because it is a startup doesn't mean you shouldn't strive to have a clean set of environments with a minimal number of code deployments. Make sure that when developers deploy code, they are doing it only to systems that you own or maintain.
- Restrict access to non-production environments to your VPN if you are able. Restrict access to product environments to as few people as possible. Restrict access to actual production data to the fewest number of people possible. None of these will necessarily protect your code, but in many cases, the only thing worse than giving up your code is giving up your (customer) data, for privacy and other reasons.
- Every in-house developer has signed an employment agreement that specifies the work they do for you as work for hire. This is not always straightforward but best practices do exist and they hold up pretty well in court.
- Every external developer or development firm has signed a contract prior to any work being completed that clearly specifies the design requirements, and clearly identifies your company as the owner of any resulting software. There can be a lot of gray areas in third party work, especially when requirements are loosely given, and copyright of the resulting software can often be claimed by the third party after the fact.
- Every developer, internal or external, has signed some form of a no-compete agreement in your area. Generally speaking, these are not very enforceable in court. However, just by having it, it will often discourage developers from attempting to do things like steal and repurpose code or ideas, and it certainly won't hurt you.
- Finally, that copyright notices, licenses, and so forth are all correctly inserted into your code and checked in to your repository, and logged, so that you have a pristine legal record of the creation and ownership of your software. If you do need to challenge somebody on the ownership of your code down the line, you will want a timestamped record of your claim of ownership.
Although there are best practices for some of these, the law around software is constantly evolving, and many gray areas do exist. There is no substitute for real legal counsel on these matters, and if you are serious about protecting proprietary software inventions, you need to have somebody audit everything and make sure you are on track.
These issues are ones that every software company faces, regardless of size. My final advice is, don't get bogged down worrying about all of these details, but do spend as much time as you feel is necessary given your investment in the software. If, as you say, the entire value of your company is in the software product, then you stand to lose a lot if somebody attacks the code. Were it me in that situation, I would immediately seek legal counsel and look for next steps in securing your investment in your product.
-
While all of your points are very helpful, I am still so surprised that most people are too careless about this serious issue. My current solution is to give separated repos for each developer. While it seems to be safe with checkin/checkout, it isn't safe at all because people can write a program (in their program) to read the code. I find no way to prevent it because their code need to be executable, so it could almost do everything in the central server. – Hiro 12 years ago
-
If you are able to segregate developers' code, and it works for you, great -- go for it. As a business grows, though, it seems very unrealistic to do this, as pieces of code simply must interact with one another, and creating these compartments really hinders an engineering team and productivity. I'd still highly recommend the legal protection; as always, hope for the best (there is never a problem with your code ownership), but plan for the worst (somebody takes it and does something with it). Try to pick the best solution that will have the least impact on your employees' productivity. – Futureal 12 years ago
-
I want to add two things. First, requiring all dev to work with the whole code base is a signal of bad modularity. Second, as the business grows, it seems more important for the code base to be separated. In a company like Google, Facebook, sharing the complete code base is unrealistic. – Hiro 12 years ago
-
I don't disagree, but it's also a bit difficult to compare a startup to Google, Facebook, etc. The vast majority of startups have **relatively** small codebases, which is likely why (as you state in your original question) you see most of them exposing the entire codebase to developers. Personally, I find it very unrealistic to have each developer work in his or her own repository; it's like squashing an ant with a sledgehammer. If it works for you, go for it, but just be careful not to make things so restrictive that you cause other problems. – Futureal 12 years ago
Does your code need to be protected - is it the "secret sauce" of your product? Unless your code is your competitive advantage, I wouldn't worry about others walking away with some knowledge of it, unless you deal with ecommerce and customer data, especially personally identifiable information (PII is email, name, dob, etc).
Basics: All programmers should have their own accounts for your code repo, no sharing. If you have sensitive data, have separate accounts to manage that data with only your most senior developers using those accounts. Have people running DB reports use read-only accounts, ideally with limited access to tables they run reports on.
-
As I said, the product is the most important, so is the code. It's not a blog, nor an outsource. If the product is not competitive advantage, why do people even consider to take risk with startup, don't they? Do you have suggestions for an industrial solution, something that people often use? – Hiro 12 years ago
Everyone so far has given great advice, but protecting the code isn't as important as protecting the client list is. if I had Microsoft's Windows 8 code, it really wouldn't mean much as I don't have the resources to monetize it.
Source code isnt the product unless you are literally selling source code. Everything is the product, from the app to the customer support, the public face, the problem that it solves for the customer, etc, etc, etc.
ex: having Stack Exchange's source code means nothing because you don't have Stack Exchange's customers. That isn't to say this isn't necessarily a bad problem to solve, just that there are more pressing and urgent matters.
Webbie has good practical advice. I'd add "Keep journals of access to the code." That way, if a version of it shows up in the wild, you may be able to track it back to when it was pulled from the repository. Some repositories will also add a watermark. Also:
- Get a good non-disclosure agreement in place
- Make sure you own the code, either as a work made for hire or an outright copyright assignment.
