How do I deal with a difficult programmmer joining an open source project?

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/206321

  •  29-09-2020
  •  | 
  •  

Question

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!

Was it helpful?

Solution

  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.

OTHER TIPS

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.

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.

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.

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.

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.

Licensed under: CC-BY-SA with attribution
scroll top