I am currently planning to develop a J2EE website and wish to bring in 1 developer and 1 web designer to assist me. The project is a financial app within a niche market.

I plan to keep the source closed. However, I fear that my would-be employees could easily copy the codebase and use it or sell it to a third party. The app development will take 4-6 months, perhaps more, and I may bring in additional employees after the app goes live.

But how do I keep the source to myself. Are there techniques companies use to guard their source?

I foresee disabling USB drives and DVD writers on my development machines, but uploading data or attaching the code in email would still be possible.

My question is incomplete. But programmers who have been in my situation, please advice. How should I go about this? Building a team, maintaining code-secrecy,etc.

I am looking forward to sign a secrecy contract with the employees if needed too.
(Please add relevant tags)

Update

Thank you for all the answers. I certainly won't be disabling all USB ports and DVD writers now. But I think I should be logging activity(How exactly should I do that?) I am wary of scalpers who would join and then run off with the existing code. I haven't met any, but I have been advised to be wary of them. I would include a secrecy clause, but given this is a startup with almost no funding and in a highly competitive business niche with bigger players in the field, I doubt I would be able to detect or pursue any scalpers.

How do I hire people I trust, when I don't know them personally. Their resume will be helpful but otherwise trust will develop only with time.

But finally even if they do run away with the code, it is service that matters after the sale is made. So I am not really worried for the long term.

To be honest, when I meet someone who refuses to extend any trust, I always think it says more about their own trustworthiness than mine - which is to say, if you think I can't be trusted, it's because you know you can't be trusted.
–
James McLeodOct 9 '10 at 20:08

6

@abel: Boiling down some of your previous remarks, you don't have any experience doing professional software development. But you're trying to enter a "highly competitive business niche", and succeed against "bigger players" when you have "almost no funding". You have much bigger fish to fry than worrying about programmers running off with your code. If I were you, I'd write up a business plan and have it reviewed by businesspeople who've already succeeded in your target area, and then think about whether you really have the resources to succeed.
–
Bob MurphyOct 11 '10 at 22:08

32

@abel: After your update, your question is like this. You don't have much money, and you've never even worked in a restaurant, let alone run one. But you're determined to open a restaurant anyway - and in San Francisco, which already has lots of great restaurants struggling to make a profit. So you go to a chefs' convention, and ask how to hire a chef who won't poison the food. And when they tell you chefs don't poison food, you admit that nobody you've ever known was poisoned, but somebody told you that you should worry about it so you're going to worry anyway.
–
Bob MurphyOct 11 '10 at 22:41

8 Answers
8

Virtually all professional developers won't steal your source. It's understood that if you work for somebody else, it's the employer that owns the code that you write. Developers might copy code for reference purposes, but it's highly unlikely they will offer it for sale to anyone else. Getting caught isn't worth the risk.

More importantly, distrust breeds distrust. Disabling USB ports and DVD writers will engender a feeling of distrust which will, paradoxically, make it more likely that the developers will copy the code.

By all means add a secrecy clause to your contract, but it's probably unnecessary to highlight it as the most important part of the contract.

A brief secrecy clause is perfectly normal in development contracts and employment agreements - but as ChrisF said, don't go overboard with it. To anyone who's done more than a handful of contract development projects, a long secrecy agreement with dire threats just says you're a clueless amateur. There are standard clauses you can find online that run anywhere from 6-20 lines of text. That's plenty if you're willing to lawyer up in case of breach - and if you aren't, any secrecy agreement is pointless.
–
Bob MurphyOct 10 '10 at 3:08

38

Also, in the real world, third parties don't want stolen code. The risk is too great. Back when Informix and Oracle were duking it out for the enterprise relational database market in the mid-90s, one of Informix's developers quit to join Oracle (which was quite common), and took a hard drive full of Informix source with him (which wasn't). He told his new boss at Oracle, expecting a warm welcome, but instead he got a security team and an arrest. Then Oracle security called Informix security, and the hard drive went back to Informix without anyone from Oracle having looked at it.
–
Bob MurphyOct 10 '10 at 3:29

1

@Bob Murphy I hope everyone is so sincere even at the bottom of the food chain.
–
abelOct 11 '10 at 9:08

1

I was just about to type up this exact answer. Trust is actually critical to the success of the project. As ChrisF stated, disabling components of developers' computers will only sour the relationship and inform those developers that they are not trusted. The only way to truly protect your code would be to control where the developers sleep, where they eat, whom they talk to, etc. Just make sure you have a well written contract to give you the legal ammunition you need to punish any violators.
–
TheBuzzSawOct 28 '12 at 20:53

If these programmers can write the software in the first place, then...

THEY DONT NEED TO STEAL IT.

They can just simply rewrite it in a fraction of the time it took to originally develop it. Yes, its true, developers arent complete idiots... once they figure out how to do something, they can often remember how they did it.

So, I guess you're just going to have to trust them, or write the software yourself.

Is that an argument for a non-compete clause? ;)
–
TimOct 10 '10 at 7:23

8

Indeed: your programmers have already copied your code, by virtue of having that knowledge in their heads.
–
Frank SheararOct 11 '10 at 7:25

I understand that. I do not want newly joined developers scalping code.
–
abelOct 11 '10 at 9:10

3

@abel, stolen code just isnt as useful as you seem to think it is. An app can be 'cloned', even without the source code. proprietary algorithms, now thats what you want to keep safe. Developers dont need to 'steal' code to learn those, just read it and then recreate it. Heck, just using the program might be enough to deduce an algorithm. So, as others have said, a simple non-compete clause will do the trick and is about all you can do. Physically securing the code is just a waste of your time because any developer worth their salt can easily bypass that.
–
GrandmasterBOct 11 '10 at 18:06

I've heard it said that no idea on its own is worth more than $20 (and that's Canadian dollars!) The idea only has value if it is executed well. Even if it comes to them stealing the code and trying to make a go of it themselves, odds are you have a better idea of what the next steps are, and more contacts with prospective buyers of the software.

You should definitely only hire people you trust, but even if they steal your code and try to sell it, they are unlikely to get very far.

This is absolutely true. Forget keeping your Unique Idea super-secret and concentrate on executing it better than anybody else. Most ideas are a product of their time and occur to several people independently. (Henri Poincaré was working on relativity in the early 1900s, too, but Einstein beat him to publication.) Chances are there are eight other crews trotting your idea around to the VCs on Sand Hill Road this month; it's the ones with credible business plans and professional teams who will get funding.
–
Bob MurphyOct 10 '10 at 3:24

The hard truth is that nobody wants your code.
You may think that you develop a solution everybody wants to know how it works. But more often than not you don't.

What would you do if you took over the source code of your competitors? You can't distribute it. You can't copy any parts of it into your project (even if it wasn't so hard to integrate thirdparty code into your codebase). What you can do? You can study it. But often it's harder to read the code than to write it in the first place.

Look at the open source software. It is a closest analogy to a stolen source code. There is a vast amount of unmaintainted code. A large portion has a license that doesn't suit your needs. Others has incompatible programming language or needs porting to your platform. The code which suits your needs will take plenty of time to read.

There are many open source projects with a closed source mentality. I.e. they don't accept patches. Soon enough your version of code will deviate so much that it would be impossible to merge new versions.

You should understand that what's the most valuable is your team who maintains your code, moves it forward. Not the code itself.

If this is some sort of startup, then the number one thing you need to do is get a product built. You need good developers who will work hard and be dedicated to the project.

One really easy way to get rid of them, or at least to sap their morale and dedication, is to show them up front that you don't trust them. In fact, they're likely to start thinking of ways they can get the code out (although they almost certainly won't follow through), and if they can come up with a way they'll think you not only paranoid but stupid. (There are organizations where this level of caution is justified, and a financial website startup will not be considered one of them.)

A few clauses in the contract about how the software is your property will be fine. If somebody will violate that, they'll violate any more severe language you've got, and probably feel more justified. Non-compete clauses that aren't narrow and time-limited will just chase off the people you want, and may in fact not be legal in your jurisdiction (consult a local lawyer to find out).

If you hire good people, they can rewrite the software later. If you hire beginners, they won't know how to further develop what they walk off with, and anybody building on it will be running serious legal risks to come in late with an inferior version of what you've got.

In short, this should be way low on the things you worry about. If you hire bad people, you're sunk no matter what. Concentrate on hiring good people and let this slide.

Companies like Microsoft, Google, IBM employ thousands of people to write reams of closed source software, and, are not unduly worried about their staff walking off with the code. Copyright protection and a clear "any code belongs to your employer" clause in the employment contract seems to cover it, and, court cases against former employees for stealing code are extremely rare.

Furthermore once you release your software to the wide world, unless the core involves some really advanced math, any competent team of programmers could reproduce your application without ever seeing the source code.

Honestly, like everyone else said, you just need to trust your programmers.

However, I will add to that by saying you should really consider that open sourcing your project in today's environment is more likely to help you than to hurt you, with the exception of a few specific markets. Just being more open to the idea will make you less worried about your source code growing legs and running off, even if you don't do it yourself. Garner all the goodwill you can, and you're more likely to earn money, in my opinion. Even if the Empire offered the best app in the world, I don't think Luke Skywalker would've downloaded it, because the Empire's ideals were in the wrong place.