0

I have an android app idea, I want to make the app along with a few batch-mates in my collage.

(1) How do I make sure that these guys will not compromise the intellectual properties involved? In the sense that they will not leak out confidential information, new theories, new ideas, new features descriptions either freely on any medium or to some other company developing similar software. Also, these people will most likely have access to the entire source code (with comments) of the project, how do I make sure that in the future they will co-operate with me,

(2) will not release any part of the code,

(3) Will not freely release alpha versions containing features meant only for premium users. Also,

(4) is there way to effectively work without granting them access to the entire source code?

I am open to all kinds of answers: trust, technical, managerial - leadership, good friendship - relationship with collegues.

UPDATE: We all live in India.

Improve this question
7
  • 1
    The answer depends a lot on the country: in the United States you could have your lawyer draft a non-disclosure agreement, and have your partners sign it. Enforcing it would be tough, because you would have to prove wrongdoing beyond a reasonable doubt, but it is doable, at least theoretically. In Russia, on the other hand, you would have to rely on personal trust, or do it yourself: even if you had an agreement in place, law enforcement system would not get in the middle of your conflict unless there are money in it for them.
    – Sergey Kalinichenko
    Commented Jul 17, 2013 at 10:47
  • @dasblinkenlight We like in India, can't afford lawyers and NDAs. Anyhow, enforcing any law is real touch and law enforcing system is slow and takes lot of money. I was looking some form of project management solution in which they will never have a chance to cause troble.
    – user52009
    Commented Jul 17, 2013 at 10:54
  • 5
    They can always cause trouble with code that they write, and also with the code that they see because their code must integrate with someone else's code. If you do not have full trust in these people, do not bring them in as partners.
    – Sergey Kalinichenko
    Commented Jul 17, 2013 at 10:56
  • @dasblinkenlight They are not 'Partners'-not in the complete sense of the word because they are just starting to program with me. The whole idea, concepts, new features, UI and decisions on what-all the program will include is mine.
    – user52009
    Commented Jul 17, 2013 at 11:03
  • 4
    How much are they paid?
    – Pieter B
    Commented Jul 17, 2013 at 11:22

3 Answers 3

Reset to default
2

Ok, you have an idea, good. I'm sure your friends have their own too. If you want them to work on yours, I see few options:

  1. pay them for their work.

  2. talk with them, pool the best ideas, come up with a new one that belongs to everybody.

  3. start it yourself, when it's already rolling, call them.

In the first case, you can be sure to make it clear who owns what, and talk very specifically about what you expect they won't do.

In the second case, you share the interest and the risks. drafting a compromise not to stab each other in the back is still a good idea.

In the third case, it might be easier to convince them to work in your idea, and it's a little obvious that you started it all; but still have to write somewhere what belongs to whom, from the start. That also implies recognizing their work, and making sure they get back what they feel is fair.

In any case, you still have to trust them, there's no magic jail where you could put anybody to make them loyal to you.

Improve this answer
3
  • I have already started programming - is that what you mean by "rolling"? Or do you mean that when the project actually starts getting some recognition?
    – user52009
    Commented Jul 18, 2013 at 15:10
  • when you have something to show. maybe not to the general public, but when it's more than just an idea.
    – Javier
    Commented Jul 18, 2013 at 15:23
  • 1
    of course, when it's already generating some income (even if it's not enough to pay any bills), then that makes very clear that it's your project.
    – Javier
    Commented Jul 18, 2013 at 15:24
3

I know little about India's legal system but consider intellectual property laws. For example, if your idea is patentable, consider patenting it. Yes, this is expensive (and not popular with some people) but this is what patents are for. Make sure each source code file includes a copyright notice. IP law will not stop people stealing your code and ideas but you may be able to prevent them from using them.

If your idea builds upon or integrates with another product or organization. Consider talking to that organization and see if you can work out a preferred or sole licensing arrangement. Hypothetically, if your app is going to market soft drinks, approach soft drink companies and pitch your idea. If they like it, they might fund it, give you technical help and deny that assistance to others.

For technical controls, consider componentizing the system and using segregation of duties. Specifically:

  1. Split the development team into separate teams. Physically separate them so the developers in one team cannot talk to others.
  2. Split the product into components with well defined interfaces and assign each team a different component.
  3. Place the source code of each component in a separate source control system and deny other teams access to that component.

When componentizing, consider vertical slices of the system (e.g. UI, business logic and storage) rather than horizontal layers (e.g. 1 UI team, 1 business logic team, etc). Otherwise, each team may see too much of the system.

This way, each team will know their component but, if someone talks or takes code elsewhere, the worst they can do is talk about their component. You often see this approach in very security-sensitive systems.

For network accessible components, use authentication, auditing and using different development and production credentials. Specifically:

  1. Have each interface require authentication, e.g. a user name and password.
  2. Supply development testing credentials but use different credentials in production
  3. Keep an audit log of accesses and regularly review it.

This ensures any these components are used only for their intended purposes. This may be a reason to move some functionality off the app and onto cloud services, for example.

That said, anything that impairs information sharing within the team is likely to impact team morale and performance. Effectively, you are saying you do not trust your development team. In that case, how can you expect them to trust you? If you trust your developers and share your success with them, they will work harder because it is their product, too.

Also, be aware that the key to most new projects is its execution, not the initial idea. Your idea might be great but, chances are, it is going to change a lot as you develop your product and expose it to customers.

Improve this answer
2
  • 1
    +1 for "key to most new projects is its execution, not the initial idea".
    – Javier
    Commented Jul 17, 2013 at 14:30
  • 1
    i won't comment on the feasibility of you scheme. i feel one disadvantage is the express distrust towards the effective co-founders / initial development team that every single measure reflects. you won't build a team spirit this way and i'd actually expect the disclosure risk to be higher. you won't attract the brighter minds with this methodology either. though you should, since your actual edge are the capabilities of your coders rather than the source code they produce. disclaimer: never founded a start-up (have worked in one, however) nor knowing about cultural specifics.
    – collapsar
    Commented Jul 17, 2013 at 14:57
1

i'm convinced that you won't succeed by founding your business endeavour on open distrust towards your colleagues - remember, you actually need them to build the system, otherwise you wouldn't be concerned with the issue your question adresses.

i'm also convinced that you focus on the wrong aspect wrt intellectual property: while it's correct that the source code embodies your product the edge of your fledgling company will be the brains of the members at the founding stage. the more you suggest dishonorable behaviour or outright violation of the law amongst your coders, the less likely you will attract gifted personnel (or if you do, the easier you'll alienate them). but the more gifted your team the better, in particular as your product will probably evolve (possible far from the inchoate concept) to meet customer demand - so a source code snapshot might be less valuable than it seems at first glance.

a constructive remark at last: source code, even in high-level languages, can be hard to understand. even more so, if comments and documentation are sparse and incomplete. your best protection might be

  • a gifted team
  • component-wise development
  • a coding style of 'no comments'.

it violates basic tenets of sw engineering but will protect you even if a member of your team does leave you: as he will naturally have specialized in only some of the components of your application, the disclosure impact will be somewhat mitigated.

disclaimer: i'm no founder and have not worked in india, so take the ideas with some grain of salt.

Improve this answer