I've been working for big and small companies, for the last 5 years. I've noticed that nobody, or at least on the places where I've worked for, is worried about the source code of the applications. For example I could at any time bring my usb key and get a copy of the whole system, some companies put it on a contract that you can't take the source code, but if you never make your copy public nobody will never note that you took that code.

So my question is, how could I organize a project/company in order to avoid developers to steal the source code?

Could that be a good option make everyone just work on one part of the software and then the have the manager to merge it and only risk that the manager will get a copy of it? For example will a software developer that work at Salesforce or at adobe has a full copy of the source on his pc?

Thanks :)

  • What is the real-world problem you're trying to solve here, and how does it relate to project management? – Todd A. Jacobs Aug 7 '14 at 1:02
  • This question appears to be off-topic because it is about software development issues. Please see help center for more guidance. – jmort253 Aug 7 '14 at 8:04
  • Ahh ok I didn't know that project managers are not related with software development projects - – Bruno Quintana Fleitas Aug 7 '14 at 8:10

At the very least you need to provide the developers the code they work on. This limits your ability to restrict their access. You can provide libraries for other sections of code, but this can create barriers to resolving bugs.

There have been cases where employees stole code and tried to create competing services. Those I know of have been successfully dealt with through legal means after the fact. Ownership of the code should be handled by contractual terms with those that use it. Copyright may also apply.

Other than frameworks and libraries, which are increasingly pulled from or available the open source community, their is little code I have worked on that would be of much use on future projects. Those in-house frameworks that I have used were not as robust as the competing open-source frameworks.

I have worked in restrictive code control environments, but they only had checkpoints and future code work was done on code version not extracted from teh code control environment. This lead to significant issues, where source code for released versions could not be retrieved as it wasn't tracked anywhere.

Having managers merge the code limits the access to the full copy. However, managers may be more likely to be able to successfully make use of that access. I would rather restrict the code access to the developers.

Most developers will only have the code they need to work with on their system. This can be a significant portion of the system, but likely not the full system. With good code reuse, they may have a significant portion of the system available as libraries. Larger sites generally have multiple repositories, and limit access to the teams requiring access. Code browsers can allow developers to browse the code from other projects they need to resolve related bugs.

Code locking systems tend to add friction to the development process. I have seen little if any value added by code locking. Good communication and revision tracking add significant value. Having a manager merge the code would appear to be a another approach to code locking.

There are advantages to using a review process to gateway changes into the released code. There are various approaches that can be used. They all require tracking changes, which increases change management overhead.

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