1. 5

I have created a pull request for a port of Google’s FlatBuffers’s serialization library to Python, so that I could use it in my projects. My work is based off of the previous port of that project to the Go language, and is heavily tested (especially with fuzzing, and exact byte-layout tests). Another contributor is working on a competing Python port. That person’s port has much less test coverage, is somewhat more complicated, but also uses faster endian-specific struct/pack calls.

I have offered to merge our work together, but the other contributor keeps wishing that I would merge my work ‘into’ his.

I’d like to maintain etiquette but I’m not sure how to proceed. Any ideas? Am I shooting myself in the foot here?


  2. 5

    him - “If you don’t mind I’ll use parts of your builder implementation and put datatype definitions in separate module as you did and remove hardcoded datatype sizes.”

    you - “I’d rather you keep your PR at its current scope…"lifting” code is not the kind way to do things."

    The bad news is that you’re the asshole. Once you contribute code to an open source project it’s the project maintainer’s right to use it in full or partially. Complain all you want, but never accuse someone of stealing what you already gave them. Kindness has nothing to do with it.

    1. 1

      If you can’t come to an agreement on how to merge your forks together then don’t. You don’t have an obligation to collaborate and it doesn’t sound like the other contributor is that interested. The only reason where I could see merging as being important is if one fork “wins” so to speak. Then it might make sense to port your test suite or their lower level optimizations. It doesn’t sound like this is the case however.

      It’s not ideal that there is more than one fork but it’s certainly not the end of the world.