I have an open source script for a specific site (I'm trying not to call anything by name here) that I and a few other developers recently moved to GitHub. We've gotten several new developers since we moved to the new system, including one very active one in particular. However, this active one has started changing a lot of the project.

First of all, he deleted our versioning system (not like Git, but like that -- we called it versions v4.1.16) and said it would be better to simply push the code to the site when we think it's ready. Now there's no centralized place to put release notes, which has gotten annoying.

The thing that has gotten me just about ready to pack my bags and go was the push script. Another developer on the project wrote a simple Python-based push script. Since we keep multiple versions of the script online in various places, I began coding a larger Java program with a graphical interface that will replace the Python script. I went on IRC to notify everyone about it, and I got a very annoying response from the programmer saying that the old Python-based script can do everything mine can do and is so much more lightweight (he also commented about the fact that he thought Python was better than Java and so on). I looked over the code for the old push script and saw that none of the features he said existed were there.

So now I want to know what to do. I've spent a lot of my time on this project, so I don't want to just get up and leave, but I'm finding it hard to work with this new developer. On the flip side, he is now the #1 committer on the project, with even more commits than the lead developer. I'm not really sure what to do about this. Has anybody else experienced this problem? If so, what did you do?

UPDATE 1: I have disabled everyone's commit access and I am requesting people go through pull requests. I also proposed several measures to fix the other issues. Everyone else hasn't shown any support for it. The troublesome dev has simply said that people who don't follow the "commit action" closely can think that the project is disorganized when it really isn't. I obviously don't agree with this, so I am seriously contemplating resigning from the project.

UPDATE 2: The lead developer began ranting about the fact that one of my commits supposedly deleted three newlines in the code (the revert commit showed up just after I posted the discussion, and doesn't even reference my "commit"), and then the two of them began discussing whether to revoke my commit access. So, I have done the logical thing and left the project. Thanks for your help with this everyone!

  • 46
    How can one person change the versioning system all by himself? Surely he must have had popular support, at least among some of the folks. And, judging by another comment, there was a license change to cap it all - Why aren't you guys more vocal when the foundations of your project are suddenly shaken/replaced? Commented Jul 28, 2013 at 19:40
  • 33
    You're missing the point of the question. How did a newcomer join your project and seemingly take the whole thing over? It may be open source but it's implied that there's a leader or a group of leaders, and presumably that/those leaders would be the only ones who have the ability to change such important portions of how the project is operated.
    – alroc
    Commented Jul 28, 2013 at 20:41
  • 36
    This is your project on github, correct? Is there a reason you cant remove his access to the project? Or have him make his own fork that you can pull from if you like the changes? If someone just took it on their own to change how the code was being versioned in a project of mine, they'd be gone right away. Commented Jul 28, 2013 at 20:51
  • 6
    What do you do? You post in on TheDailyWTF and share the link with everyone. You will shame him into submission.
    – rath
    Commented Jul 28, 2013 at 22:22
  • 25
    Honestly, and regardless of the other issues at stake here, replacing a Python script with a graphical Java program for pushing software to a website looks like insane overengineering to me. Commented Jul 29, 2013 at 8:30

8 Answers 8

  1. You can quit. Not the most constructive thing to do, but sometimes it's the only option. If you do, don't sit around and moan about how you had to give it up, take that energy and put it straight into something else - 'move on' in other words.

  2. You can fork it. There's no reason why you have to work with anyone. Fork, improve the code and let the others continue to have a little ego-fest of their own. Your new project will simply compete with the old and its up to you whether you make a success of it, or the old one beats you in terms of users and features.

  3. You can engage with the rest of the development team on the project to voice your concerns. Don't make it personal, but make out that you're unhappy with code churn, or lack of established quality processes, or unhappy that the new decisions are just pushed out without agreement from everyone. You'll either be told that nothing's wrong enough to change, or you'll get a few others agreeing with you that the team needs to fix things up. That might end up with the disruptive guy losing his commit access. Maybe you'll all agree that some of the changes are not improvements and the project needs to be reverted. (This latter option is the most likely outcome, unless it turns into a massive argument of entrenched opinions.)

It can be difficult when someone comes along and changes the safe and comfy routines you've become used to, but it could be said that having someone come along and shake up the old, cozy practices are good things in themselves.

  • 2
    I'd propose a fork();
    – ott--
    Commented Jul 28, 2013 at 19:06
  • 1
    Why is leaving stated as solution #1? If the project is really that exciting, shouldn't that be the last option? Commented Jul 28, 2013 at 19:35
  • 2
    @DeerHunter: I didn't read the order of possibilities as order of preference, but it is useful to have 1,2 listed first as these possibilities can inform the discussion of 3.
    – hardmath
    Commented Jul 28, 2013 at 19:41
  • 36
    options are listed in order of easiest to type out.
    – gbjbaanb
    Commented Jul 28, 2013 at 22:14
  • Swap #3 with #1, you have to push back because a lone-wolf with no regard for anything else can destroy a good project.
    – Coder Guy
    Commented Mar 12, 2015 at 20:55

You've made it a little unclear exactly what your role is here. The answer depends on how you fit in.

If you're leading the project and control the git repository

Take back control. If this guy is making commits you don't like without consulting you, remove his direct commit access. He can fork the project and make pull requests to merge his commits. Thats how open source should work until a user builds up trust. You don't need to, and shouldn't, give full access right away.

If somebody else controls the repo

Express your concerns to the person who does,and encourage a more disciplined process for planning and approving changes. If the leadership is not amenable to a process, then you can choose to accept the status quo and keep contributing, you can fork the project and work on your own version (bringing along anyone who agrees with you), or you can choose to leave and work on other things. In any case you are not required to continue to deal with this.


Please forgive my bluntness, but your post reads like a rant.

You say it's the other guy who wants mindless changes, but then you contradict yourself when talking about this new shiny Java program of yours.

Take a break; it's not a one-way street, please try to find compromises (if you want to continue working on the project - forking is the easiest decision but it won't lead you anywhere useful, although it may stroke your ego).

Please also think thoroughly about the division of labor in the project - turf wars are inevitable if you don't have clean boundaries telling you who's competent at what. Yes, you have to trust other people's judgment sometimes.

  • 4
    @Nathan2055 - Simple and working is better, in my book (maybe that's just me). Anyway, it seems the project is adrift without much guidance. Commented Jul 28, 2013 at 19:37
  • 1
    I agree with the adrift part. One of the things I forgot to mention is that the same developer randomly relicensed the project without telling anyone.
    – Nathan2055
    Commented Jul 28, 2013 at 19:40
  • 24
    How, exactly, did one new developer unilaterally change the license on an existing body of code he does not have sole copyright control over? How did he get such access/authority and why hasn't it been taken away?
    – KutuluMike
    Commented Jul 28, 2013 at 20:56
  • 7
    This whole situation doesn't add up. No one can go and unilaterally change the license on an OS project. Since you've not agreed to it and (I assume) you've made contributions, his change means squat.
    – Norcross
    Commented Jul 29, 2013 at 5:11
  • 9
    @Nathan2055 Changing a project's license without authorization is probably grounds for instant dismissal, even in open source projects. Just because it's open source doesn't mean some random dude can just walk in and assume control. No matter how epic his programming skills are, if he can't work in a team you don't want him there and you need to talk with him and/or kick him out. Unless you're not telling us everything..
    – Thomas
    Commented Jul 29, 2013 at 11:09

It is already mentioned in several answers that division of labor is one way to reduce conflict. Here are some concrete examples:

  1. Balance productivity vs. stability. To borrow an analogy from strategy games, a team must consist of a mix of Boom, Turtle and Rush, and teammates must be prepared to change roles in response to the situation.
    • When one is in a productivity craze, others can work on:
    • Other features
    • Bug fixing
    • Specifications (managing new feature requests, and verifying that the software meets the agreed-upon criteria)
    • Quality assurance
      • Manual (exploratory) testing
      • Automated testing
    • Documentation
    • Refactoring and code cleanup
    • Conduct user studies to collect ideas for improvements
    • etc.
  2. A project can be modularized (as in software architecture), or even compartmentalized (as in project management) so that each module can be worked on independently.
    • In general, most software that contains both a front-end and a back-end should be modularized, because they have different velocity of development.
    • UX-rich software may be hard to modularize due to their heavy use of cross-module event routing.
    • A project's maintainer may want to keep the project simple by avoiding modularization.
  3. Feature branch. Each developer can fork the project, work on his/her favorite pet feature, and request merge when the implementation is complete. The lead developer can have final say in whether to accept the merge.

Aside from the conflict-avoidance aspect, it is apparent that the project may have insufficient governance.

Why is governance important? Imagine one day a former teammate took a piece of the software, and sue the team for infringement. Or the team sued by patent troll. Or a nobody-knows-who decided to send DMCA notices to the project hosting site and demand the project's source code erased.

At the minimum:

  • The licence to be used by all contributed source code
  • The license(s) under which the project's source code can be published
    • In case a new public license is sought, how to get consent from every contributor
  • Who can have administrative access to the project
  • Who will be designated to respond to legal requests (such as the DMCA notices or patent trolls)
  • Who will manage the finance for the project (paying for server expense and bookkeeping the advertisement revenue or donations)
  • Who will have voting rights to include new members and expel members.
  • etc.

Most open-source project sites can provide ready-made project governance charters.

  • 1
    +1 for governance. Sooner or later all open source projects need some written rules as well as some code, whether it's full-blown governance for large projects, or just a simple code of conduct (like wiki.gnome.org/CodeOfConduct) for whatever forums, mailing lists, bug databases or SCCS you all share.
    – calum_b
    Commented Jul 29, 2013 at 9:48

I have seen the problem before. But after few years you really get tired of the project, so my solution was to leave the project. It might not work for you, but the problem is fundamentally that different people think in different ways. Features that you think are very important are not at all important to other people.

Good plan would be to divide tasks of different people. If you can agree with the persons which part of the project is in each person's responsibility, then only one person is doing decisions on certain part of the project. But teamwork is always difficult. You're still never going to like the decisions made by other programmers. Best solution is to never look at what other programmers decided. Just trust them to do the right thing is enough.

Common goal will focus your efforts to the important stuff. Everyone working to the same direction is difficult to get, and conflicts will anyway happen. Deciding common goal requires knowing what's the current status of the project, and then deciding where it needs to be after some time.

Here's example of stuff to avoid: For example, large number of c++ programmers think that code that is not using STL library is broken. Other programmers think that every dependency to external libraries is broken, including STL. Such conflicts just cannot be solved properly - both situations cannot be fullfilled simultaniously - and the most problematic people will push their opinion no matter what opposition they will encounter.

  • A good point on the division of labor. Commented Jul 28, 2013 at 19:33
  • 3
    Never look at what other programmers decided, just trust them? Sounds dangerous to me. What about quality control?
    – Stephan B
    Commented Jul 29, 2013 at 6:20

Four choices, I'd reckon.

  1. Kick him out. You're (allegedly) still the main dude on this project; revoke his push privileges and call it a day. The most likely outcome is him forking the project, dividing its community, and then a war breaks loose, and when the dust settles, one of the fork will be the popular one.
  2. Fork it and continue elsewhere. Less aggressive than 1., but the consequences are otherwise the same. You will have to be active in the community though to pull people over to your side.
  3. Leave it be: just let him do what he's doing, calm down, and hope for the best.
  4. Discuss with the community, compromise as required, and resolve the situation.

Personally, I'd prefer option 4.


Google had a couple of tech talks about this a few years ago. Watch them: 1,2. In a nutshell:

  1. Comprehend: Understand your community's motivation to work on your project vs all other opportunity costs, and preserve those reasons.
  2. Fortify: Build a healthy community with social norms of politeness, respect, trust, and humility.
  3. Identify: Look for tell-tale signs of poisonous people (too many to list, but if you're asking this question then you probably already know many of them).
  4. Disinfect: Be calm and stand your ground, remain unreactive to insults, slights, challenges, disrespect, etc., and persistent in reinforcing your community norms.

A comprehensive written outline is available too if you prefer to read instead of watch.

  • 3
    would you mind expanding a bit on what each of these resources have and why do you recommend these as answering the question asked? "Link-only answers" are not quite welcome at Stack Exchange
    – gnat
    Commented Jul 29, 2013 at 6:42
  • 1
    Added summary, how's that?
    – bgibson
    Commented Jul 30, 2013 at 20:25

You can't just quit without taking an effort to express your concerns and difficulties. I know it can be difficult. If fact if you and your team members are young enough not to experience first hand many social problems happening in any development team, it can be really hard.

Having said that, I strongly believe you should express your concerns. You can write them down in the email and show it to your trusted friends who are not part of the team and have no or little interest in what you do. In this case you may get a good feedback so that wording of your email is not too harsh. Stick to the facts though. Don't accuse or blame. Just facts that it's hard to do something for you because 'blah' is missing. Why 'blah' is missing should be clear to every team member, i.e. "the new programmer" deleted or didn't accomplish something.

Again, sending this email is hard but that by itself is a great experience that may be very useful for you going forward. Great lesson to learn.

PS: I didn't mean to sound too parental. However it's indeed something I would say to anyone including my kids.

  • 7
    "You can't just quit"... Yes you can. It's not a choice to make lightly as it means you'll burn every bridge with everyone else on the team if you do, but if the situation is bad enough (to the point of causing emotional distress), just walking away is always an option. Commented Jul 29, 2013 at 7:21

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