What to do when someone is pushing to take control of a hobby project?

Question

I'm working on a hobby project for a game - it's in an alpha state right now and I have users using it.

For the past 9 months I have been the sole developer, but now I found someone who was willing to do the web development side. In a few weeks time they have made great strides in rewriting the website so that it looks and feels so much better.

Over the past few days we've been talking on Discord about how to merge our work, and this is where things have gotten frustrating...

He's suggesting large swaths of changes on functionality that already works. 'Stop using Stored Procedures, do it the Laravel way and build the query in your api', 'Stop using sockets, switch to web sockets and send http requests', 'scrap your mvc project, and rewite everything as a rest-api', 'rewrite your database in postgresql or mariadb', 'if it was any other developer, they would tell you to scrap .net and use Go and Vue'.

I've spent more time arguing and defending the code I wrote vs actually cooperating and getting the project further.

I've tried my best to explain why I am against these sorts of things. I'm not familiar with even half the technology frameworks/languages he was suggesting we switch over to, and I don't feel like rewriting my entire codebase in some new framework that I have zero experience in.

I'm starting to think that the two of us are too different (he's a linux, cutting edge, hate MS kind of guy; My main stack is .NET, and I don't follow the recent web trends as closely')

I wonder if it's best to just end the partnership and go our separate ways? Or continue to try reasoning with him?

Answer 1

Define an interface and clearly divide responsibility

Like most web projects, yours has a clearly separated front- and backend (probably more so after the frontend rewrite), with a specific interface inbetween. Explain that you're willing to give him the interface he's asking for (REST API), but that the backend code - any part of it - is off limits. Hammer out the functionality of that interface together, but treat the code that connects to it as a black box - on both sides.

In any project that involves more than one developer, it is good practice to code against well defined interfaces. This way you isolate your code against implementation level changes and allow for parts of the project to be modified or replaced without affecting the rest. It also allows developers to work together on a project without having to know, understand or agree on all of the code and technologies involved.

Insist on writing down a specification (can be simple) for this interface, and insist that changes in this document have to go through both of you.

This approach serves three purposes:

1. It should help you work together more effectively by clearly stating responsibilities and expectations. Whenever he brings up an implementation detail on the backend, point out that it's not in the scope of your discussion.
2. You can use it as a basis for discussing shared concerns like gameplay.
3. If you end up going separate ways (and he takes his code with him) or a few years down the line you notice your tech stack really doesn't scale well enough, you're left with separate, functional codebases and can replace parts as needed. Which you can worry about when it actually becomes a concern instead of wasting time arguing over it now.

If he's willing to agree to these terms, I believe there's a good chance you can be very productive together. If he still insists of a complete rewrite, your best course of action is probably to end the cooperation there.

Answer 2

From the sounds of things, your fellow developer is going to be unflinching in his opinion of your approach. The more work you both do on this game, the more argumentative he will get. It also reads as if he has not provided any convincing reasons for making the large-scale changes he is demanding.

Assuming you have never given him official joint-ownership of the game, politely tell him that your practices are too different to work effectively and that you two should part ways amicably. The loss to you is that he will probably take the work he has done with him, but it will pay off in the long run to work alongside someone who is more appreciative of the current setup.

Answer 3

Couple of things. First of all: this is a hobby project. Your hobby project. The other developer was brought on to help you out with the website. Maybe I'm missing some information, but why does he think he has a say in what you're doing with your project? You are most likely in a learning process while enjoying something you like to do in your spare time (assuming you are going to school/working). You have already spent 9 months on the project, are you willing to throw that all in the bin by porting it to other languages opposed to developing new features or improving stuff? His suggestions hint at scalability. I do not think that applies to a hobby project such as this unless you really plan on achieving a large user base.

To come back to your question, seeing he wants to change a lot of made decisions it's best (in my opinion) to let him go and move on solo. He's helped you out with the website as per your request (and according to your story he had no other role) and you are happy with the work he delivered. It's fine to leave it at that.

Also, opposed to what BoboDarph suggested in his answer, I would not allow him to fork your work. Again, this is my opinion, but this project is quite proprietary and has cost you a lot of hours (and not to mention possible headaches). Are you willing to let others run free with all that you've worked hard for to achieve (read: game in current state)?

Answer 4

Thank him for his time and his contributions, then politely but firmly end the partnership.

You should of course keep this amicable, and you can give reasons if you wish (such as your approaches with the tech stacks you want to use are too different), but don't compromise. If it's open source, then you could encourage him to fork it and make the changes that he wants until his own guise.

In the future, my advise is to vet people thoroughly before letting them on board, and don't be afraid to turn them away.

I have a reasonable amount of experience in a similar light - I've been the lead developer for the best part of a decade on a niche, but at least moderately successful open source project. We regularly get offers of development help now - perhaps a couple a month. On average, we've probably had about one helpful person a year - the rest have been turned away in various forms. The usual approach we take when we get someone who seems interested is this:

• We have a copy / paste paragraph about how they can submit a pull request, but we're not obliged to take it, they shouldn't assume that we will, if it's something that doesn't have a ticket filed against it then it's unlikely to be accepted at all, code is subject to these quality rules, etc. Around half we never hear anything back from after this.

• Whenever someone suggests a major change (framework change, major code restructure, etc.) we have another copy / paste paragraph thanking them for their suggestion, and saying that we'll consider it over the course of the next few months, but we won't accept PR's for such changes. We had at least one guy try once anyway.

• Almost no-one gets commit access. All other contributors work through PR's that are code reviewed, and one of the three regular developers has the final say (usually if unsure we'll decide together.) The decision is final.

Have we offended anyone this way, or got rid of useful contributors / contributions? Almost certainly. But this is a hobby project, and so I choose not to bog myself down with self-created debates and bureaucracy. If you enjoy engaging with people in this way and having these long debates about whether their idea / approach is better, and whether it's worth rewriting the entire system from scratch then by all means, go for it. But if not, then don't let yourself get sucked into it either.

Answer 5

If push comes to shove (and from the looks of it, it has), tell your helper she can always fork your project and then she's free to use anything she wants on the backend. Otherwise it's your way or the highway. People seem to think developing opensource software is a democracy. It's not. Someone will always have to say "use this, not that" or "we do it this way not another way". And for the time being, that someone is you.

Answer 6

If you focus and your "friend" or "teammate" is to create a bigger, more polite hobby game (focus on hobby here), let's focus on better features, not tecnologies: what is best for your players? Fixing bugs/add new features or change tecnologies?

Be pragmatic: change tecnologies like you notice involve a lot of learning and time, so maybe is not best commitment for your free time.

Side note: if someone is trying to help you, listen first. From your questions seems to be after listeing phase and already on "defense" side of communications, means that you already decided to not switch tecnologies or change anything. What are reasons to change stack ?