24

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.

18
  • 28
    I know that I (and no other sane, competent developer) would consider working under the conditions you have hinted at (disabled pendrives, dvd writers…). Oct 9, 2010 at 17:54
  • 5
    Simply poisonous. Oct 9, 2010 at 17:57
  • 55
    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. Oct 9, 2010 at 20:08
  • 8
    @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 Murphy
    Oct 11, 2010 at 22:08
  • 38
    @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 Murphy
    Oct 11, 2010 at 22:41

9 Answers 9

78

You need to trust your developers.

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. If they did offer it for sale to a new employer then the likely outcome is them being shown the door and possibly even arrested (as Bob Murphy points out in his comment). 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.

8
  • 2
    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 Murphy
    Oct 10, 2010 at 3:08
  • 47
    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 Murphy
    Oct 10, 2010 at 3:29
  • 1
    @Bob Murphy I hope everyone is so sincere even at the bottom of the food chain.
    – abel
    Oct 11, 2010 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.
    – TheBuzzSaw
    Oct 28, 2012 at 20:53
  • 2
    Two words: Edward Snowden (en.wikipedia.org/wiki/Edward_Snowden). Even the most secretive divisions within the US Federal Government don't have a good solution to this problem. What makes you (the OP) think you can do any better? Build your solution on trust and reasonable containment, not on superficial technological restrictions!
    – rinogo
    Feb 4, 2014 at 20:05
74

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

THEY DON'T NEED TO STEAL IT.

They can just simply rewrite it in a fraction of the time it took to originally develop it. Yes, it's true, developers aren't 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.

7
  • 3
    Is that an argument for a non-compete clause? ;)
    – Tim
    Oct 10, 2010 at 7:23
  • 8
    Indeed: your programmers have already copied your code, by virtue of having that knowledge in their heads. Oct 11, 2010 at 7:25
  • I understand that. I do not want newly joined developers scalping code.
    – abel
    Oct 11, 2010 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. Oct 11, 2010 at 18:06
  • 11
    +1 for truth... and for making me fall out my chair laughing. Cows don't need to steal milk. 8D
    – TheBuzzSaw
    Oct 28, 2012 at 20:56
22

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.

2
  • 9
    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 Murphy
    Oct 10, 2010 at 3:24
  • 1
    Related: sivers.org/multiply . Bad ideas wouldn't even be worth 2 pence, but good ideas can well be worth over $20.
    – Pacerier
    Oct 4, 2015 at 20:28
6

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.

6

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.

4

Why should your potential customers trust you with there finances?

After all you may run off with the money.

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.

3

As others have mentioned, this primarily seems to be a people concern.

However, there are a number of major security vendors who market software solutions to data leaks:

I can't comment to their effectiveness or appropriateness as I have limited experience with these solutions, but just thought that it might be helpful to point this out.

1
  • 3
    Like the idea, the only worry is that these products are full of corporate language and don't explain what they are actually doing :) Nov 12, 2012 at 13:51
2

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.

0

Dated question but still not totally irrelevant. Rather than being paranoid about code theft/resell, NDA is a balanced approach. Here is a sample Non-Disclosure Agreement.

See section "Obligations of the Parties" and "Consequences of Breaching the Contract". These can of course be edited to suit your purpose. That's probably the best you can do. Hope this helps somebody.

https://relevant.software/blog/how-to-write-an-nda-for-software-development-template-included/

Not the answer you're looking for? Browse other questions tagged or ask your own question.