When joining open source project, how to get out of the code review swamp?

Question

This is not my work. I am free just to walk away, but would be interesting to know if any better solution could possibly exist. I do not name the project because discrediting it is not between my goals. I just want to help the open source community by publicizing the known and recommended ways to solve my problem, that is for me real.

The project is popular, has many users, so understandably they accept new contributions via merge requests and code review, at least from newcomers. I have opened four requests for them without any evil intention expecting to join an interesting community. Two were rejected and one is now stuck deep in the review swamp without big hope to push it through. Only the first one has been merged.

I see the reasons of rejection as quite frivolous: "I think this should be fixed in a completely different way" (but the fix works, is clear to understand and does not break anything, why would you rather live with that bug?), "I think this is superniche and we do not need this feature" (why do you keep this entry in Bugzilla if you do not even accept it already implemented?), "I think the error message you proposed is still difficult for the users to understand" (the message it replaced is so mangled that "no meaning can be inferred" as written in bug report not by me), "this bug is not relevant when code runs in a sandbox" (and what? in many cases it still does not) and the like. Plus "code style issues" not documented anywhere (what is written down, I attempt to follow). Still, looks like there is more than one person working on the project. How do they find a common talk between themselves? I think that some developers either do not get the code reviewed or just get very shallow check. How to get into this circle with the goal to be productive?

I tried to make very small changes, assuming this would leave little room for any criticism. Nope, small changes attract the most of negativism. But any more complex changes, obviously, leave a lot of room to think that something could be different and also resolving merge conflicts eat lots of work while you fix that is not broken.

I worked in some notable open source projects in the past, but it was at the time when this pull request pipeline was not so tough. Changes were sent as patch files into mailing list first, and if nobody objected much (that usually was the case) most of serious developers had rights to commit into master. Reverting committed patch was big event seldom done. Now looks like any elite developer is free to say veto for whatever reason comes to they mind when the contributor even has no right to discuss (when I attempted once the request was immediately closed).

Apart from that call of complete rewrite, I was generally responsive to proposals from reviewers, not that they propose to rename a variable and I stick to my version regardless what. It still feels like carving the code in stone: I would be five to ten times more productive if left alone just on my own, instead of endlessly changing one working version of the code into another that is I agree not worse but looks just about the same.

Should I maybe fork the project? It is under GPL license.

Is it a way to get respect in this community and do something constructive there or should I just leave them? My level in general should be good enough for them; I am software engineer working multiple years with the programming language they use.

Answer 1

It appears that you want to help with the best intentions, but you don't help in the way the maintainers would want you to.

In order to find out what the maintainers would like you to do and how, you need to get in touch with them. Find out where they communicate and how, and try to join the discussion. I can't help you with that, because every project has its own unique communication culture and I don't even know which project you are talking about.

Before you start to implement your solution to one of their problems, propose your solution to them on their preferred communication platform and find out if that solution is acceptable to them. When your solution gets rejected anyway, then contact the person who rejected it and ask them directly to elaborate on what you would need to change in order for them to accept it.

I know that it's frustrating to have to talk with everyone about every little fix. But software development is teamwork. When people don't communicate and everyone just does what they think is best, then the whole codebase will sooner or later become a mess of inconsistent code styles, conflicting architectural patterns, features which don't properly build upon each other and a general lack of clear direction.

Should you fork the code and just do your own? Well, there is an old proverb:

If you want to travel fast, travel alone. If you want to travel far, travel together.

When you start your fork, then you will notice that you are going to make really fast progress over the first couple days. But there is only so much you can do as a single person. You are going to run out of low-hanging fruits to pick, and start to face the really complicated and tedious problems which take much longer to solve. You won't have time to properly promote your fork, so many end-users will probably not know that it even exists. Development of the main version will move on, so you will have to merge changes from upstream, which will conflict with your own changes. The conflicts will be both on a technical and a conceptual level, because you and the upstream team didn't communicate. Soon you will wish for people to help you out. So you will have to take other people onto the project. And then you are going to notice that you run into the same tedious communication overhead you wanted to avoid.

Answer 2

Adding on to Philipp's accepted answer above, I'd like to suggest that rather than see the objections as "frivolous" that you try to understand the reasons for them, and then work towards that goal. You're trying to be part of a team, right?

You gave some examples:

"I think this should be fixed in a completely different way"

And you wondered

but the fix works, is clear to understand and does not break anything, why would you rather live with that bug?

There is a third option. You can redo the bug fix in the way that the maintainer requested it. Is there technical reason not to do it that way? If so, then explain your reasoning, because that can be valuable. If not, you can go ahead and do the fix in the way they've asked.

Another example:

"I think this is superniche and we do not need this feature"

and you wondered

why do you keep this entry in Bugzilla if you do not even accept it already implemented?

That's a good question. Maybe they're not aware of it still being in Bugzilla. You could say "If this feature isn't going to be added, could you close the ticket? It's confusing to someone new like me." Maybe you could add a note to the ticket "On 2022-04-18, MAINTAINERNAME noted in email that this feature should not be added."

Another example:

"I think the error message you proposed is still difficult for the users to understand"

So you can ask how it might be improved, or what is difficult for the users? Explain that you want to help, and with some guidance on their intent, you could come up with something better.

In all these cases, it requires you as the prospective team member to assume that those running the project are competent and have good intentions. Assume that any differences in understanding are because of knowledge you don't yet have. Work to overcome that knowledge.

Yes, there are projects out there run by people who don't know what they're doing, but that should be the conclusion of last resort.

Answer 3

Adding on to the above: A GPL project is still protected under copyright, and the "official" version is still under the control of the copyright holder(s). They still have the right to include or reject any contributions to the master codebase they choose to, for whatever reasons they want. Rejecting someone's code because "I just don't like you" is still a valid reason, albeit a spiteful one.

(Side note: I think there might be some issues if you're blatantly being racist/homophobic/etc. in your contribution acceptance, but as long as you haven't specified such discrimination in your license, the only real consequence for that behavior is likely to be bad will for the project and maybe having code hosting providers remove you for ToS or something.)

It does suck to get rejected especially when you're trying to contribute to the open source community, and especially when you're doing it for free, but that's still the nature of open-source. As others have said, you can either engage with the project owners to see if you can argue your case or work within their boundaries, or you can move on to other projects - there's thousands of projects to contribute to, and if you're feeling negatively towards a project there's no need to stick with it - as you said, you can always walk away at any time.

If your contributions are extremely significant, a fork might be worth it. You can still pull in upstream changes (you should, in fact, lest your fork quickly become irrelevant and out of date), but odds are if it's a very major project your fork will get little attention unless it's radically better.

Answer 4

Here is a brief summary of the communication problems that forced me to abandon the contribution to the project under discussion:

• You need to find the relevant architect on IRC and discuss in depth the planned changes. It is your responsibility to find the right person to talk with, to catch the moment when he is online and not too busy and discuss with him, not with random persons that just happen to be in the chat room. Somebody who can dedicate only few fixed hours per week just do not have resources for such a communication.
• For some reason these architects do not respond to comments on bug requests and discourage the usage of the mailing lists. Communication means that keep the history of previous messages are not preferred.
• The code review talks are kept very brief, questions and suggestions are not even answered, so the following attempts to rewrite as asked tend to miss the target again.
• While there are few (conflicting) documents on the basic coding rules, the internal architecture of the project and the right ways of using it is not documented.

The reasons probably can be viewed as belonging to the category "poorly managed", or maybe aiming to the different group of contributors. Maybe they would accept something like valuable algorithms or support for additional file formats but they are not interested in lower level changes like fixing simple bugs, even if these do exist and do get fixed. This takes about as much time of the reviewer as the time of the contributor, so even a complete well working patch is not as much of the help as it may look.

Forking in such cases is probably an option if you want to work on exactly that piece of software.