Sharing sourcecode in informal startup

Question

Context:

I am currently part of a small group of students/professionals which is attempting to build a startup. We are in the early stages, MVP development and validation, but not yet incorporated.

Originally, when conforming the team and assigning the tasks and roles, I took over the technical aspects, including the server setup, database administration, and software development (both front & back-end). We are now more than half a year in, and all we have from a technical standpoint was put together single-handedly by me.

Problem:

Another member of the team keeps asking for me to "share my code", "give him access", and to "let him tinker with it". It should be noted that although this colleague has a technical background, he steered away from the technical tasks during the role assignment, and is now responsible for an entirely different area. Moreover, he has up until now not been involved on any level in the development process.

To better illustrate his usual requests with an example, during our latest exchange, he brought up the request with the following motivation: "I've got some ideas to add to our project and I would like to tinker with it. I also want to add this skill to my CV. Could you [make the code available] so that I can add a few bits here and there aswell?"

---

Argument Summary

I am able to see see both sides of the conundrum and realize that this is a somewhat common dispute. I'll try to summarize the main arguments for and against this request:

On the one side, sharing and opening access to the code might make sense when considering that:

• Team mentality: The project is a group endeavor, and hence it makes sense to share all of its aspects, resources and developments with the group.

• Growth: As the project grows, it is unlikely that it will be manageable by a sole developer, hence it will eventually need to be opened up.

• Dynamics: We have been working together for some time now, and intend to keep doing so until this project hopefully becomes a business. Hence, maintaining good dynamics and team-relationships seems like the preferable way to go, and rejecting his request will likely sour said dynamics.

On the other side, granting access to my code at this stage seems risky, and I am wary of doing so given that:

• Lack of agreements: There are no formal agreements in the group yet. That is, no shareholder agreement, no intellectual property agreement, no binding contracts, no schemas for future compensation based on initial contributions, and so on. Hence the lines defining ownership and credit are somewhat blurry, and given past experiences, yielding my work willingly under such circumstances would be unwise.

• Credit: The technical aspects of the project has always been my responsibility, and hence my work and relevance in the project are easy to substantiate. This will hopefully eventually translate into weight when negotiating the shareholder agreements / remunerations. Giving away the code would undermining my relevance and would make a new way of attributing credit necessary.

• Unnecessary overhead: Having to manage the "tinkering" and potential version control issues induced by a new developer who has little to no knowledge of the project's technicalities, with no pressing need for it at this stage, would add an unjustified burden and a time overhead to my workflow.

• Honesty and legitimacy: The development of what we now have required a substantial investment of time and effort. Giving access to another developer to chip in "some cool ideas" to be able to claim having "co-developed" the project on his resume seems dishonest, and in my opinion takes away from the seriousness and legitimacy of what I have built.

• Role Conflict: As the "CTO"/"Lead Developer" of the project, I should have some say in who enters the development flow of the project, and in which capacity. This is being trumped over by the fact of the other person also being a "founder".

• Personality Clash: A more subjective argument is a simple personality mismatch. This teammate and I have on previous occasions clashed on how certain aspects of the project should have been carried out, and the results have almost always been "his way or his way". This, in my opinion would be mayhem in a development environment, and would severely impair my decision making capability as a lead developer.

---

Questions

I hope this is not too abstract and that perhaps some of you can offer some advice on how to more forward. In order to make my doubts more tangible, I have written down some concrete questions:

• Is granting access to critical source-code for others to "tinker with" common in informal startup scenarios?

• How can a main developer maintain control over his work and protect his relevance in a group/startup/company after opening it up to other developers, in settings where no contracts or formalities have yet been drawn?

Thank you in advance.

Answer 1

Is granting access to critical source-code for others to "tinker with" common in informal startup scenarios?

Yes, but unrestricted access to committing "tinkered" code is not. You'll know already that there's a world of difference between some hacked demo stuff and production solid code (even/especially in a startup).

How can a main developer maintain control over his work and protect his relevance in a group/startup/company after opening it up to other developers

Source Control. Use Github/Bitbucket/something and allow your colleagues to pull the code. You could put the libraries etc in different repositories and only reference them as binaries (Chocolatey/Nuget/npm/etc) and only expose the surface they want to tinker with.

in settings where no contracts or formalities have yet been drawn?

This is a huuuuuuuge mistake. get it done soonest. Of course, you should only be in business with people you trust. You do trust him/her, right?

This will hopefully eventually translate into weight when negotiating the shareholder agreements / remunerations. Giving away the code would undermining my relevance and would make a new way of attributing credit necessary.

Hopefully!?? They won't need your code and they'll rewrite it anyway as business requirements/focus change. They only need something demonstrable to sell the idea to investors. I don't want to frighten you, but without the shareholder agreements in place, you're just expensive luggage.

Answer 2

I would say that giving your coworkers access to 'see' and 'tinker with' code is a normal and productive practice in startup environments. Giving anyone (and this goes double for anyone who is not officially tasked with specific deliverables) free ability to commit/merge to master is a terrible idea. With a proper github settings and code review process, you can have the best of both worlds, allowing your startup to benefit from more people's ideas and effort without obscuring who did most of the work or allowing someone who is less skilled to mess up your working demo. Remember that it will be obvious who wrote what when using a tool like GitHub (if you made 100 commits and he made 2, it should be pretty clear that it's an exaggeration when your colleague calls himself a 'co-developer').

In the bigger picture, most modern start-up type tech companies value collaboration and have strong cultural aversion to coders who try to 'make themselves indispensable' by creating obfuscated code that isn't maintainable by others, withholding documentation, and the like. I have seen people fired for trying to ensure job security that way, with management holding the position that if it's a pain to figure out how to work with what that dev has created so far, it's going to way more of a pain if they put it off a couple years and then that dev moves on to a new job, leaving behind even more unreadable code and arcane processes. This isn't really your situation, but it could start to look similar from the outside, so it is something to consider.

Overall, my advice, which is based more on being a later-comer to a startup, rather than a founder, is to strongly consider opening your code up to be read and tried and tinkered with without allowing any commits without a demo proving that that new functionality is worth the effort of code reviews and testing on your end.

In your specific case I would see a co-founder of a new startup openly looking to pad his CV as a potential red flag all on it's own, so I think it's important to start with contracts and agreements ASAP, and clarify where you all stand on this project before you take any actions in the direction of opening up your codebase to him.

Answer 3

Tell him that your role is developer, that you have capacity to implement new features, and that he should submit a feature request, which the whole team will review and decide if it is worth your implementing it.