Came across the discussion in this PR and because this kind of pattern can be seen more often than one might think I wonder how this can be avoided in the first place? In huge open source repositories like flutter there are so many people, teams and individual contributors working on a single project that it seems to be difficult sometimes to communicate the expected path forward. Especially if you're not in the core team of developers it's difficult to know what is actually wanted and if your own idea or solution for an issue matches the desired pattern of the repository etc.
If you have any experience (e.g. from other open source projects) how this can be handled in a positive way for everyone feel free to submit your idea here in the comments.
I will use the terminology which I invented and use, I don't know more appropriate words.
There's technical open source (code licensed under free license), social open source (accepting contributions, working towards the user, maintaining), and stewarded open source ("the product" with the team, roadmaps, release cycles, but the code is open and free).
Technical vs social: many projects are made to solve the issue of the author, and just published on the internet under a FOSS license for everyone, nothing more. For a random project on the internet, you should not by default assume that the author is willing to fix the issue you report, implement the feature you'd like to have, or merge your contributed code — author may not be interested in solving your issue, they already solved theirs. That's open source which does not have social component.
What you have here is a stewarded open source: a Google project which have a team on a salary. The team has their own plans and goals on their product, and in addition they accept contributions. They might not be interested in them, or even be hostile to external contributions, because some PRs just disrupt their plans, not suitable in their architecture view, or could be seen as a maintenance burden which they didn't ask for. Check CONTRIBUTING.md in the repository: the code contribution is in the bottom of the list, and they have a hour and a half movie on how to contribute!
Since this is a team on a salary, your task is first and foremost to explain the issue you have, and make it clear what is wrong currently, why is it wrong, and how it could be improved. The code contribution should follow only after you've been understood and the issue has been confirmed as an issue. Only then you can make a suggestion PR if you feel so ("I fixed it this way, it works for me, take a look").
Issues with your PR:
- Minor one: used only what-have-been-done technical description instead of just describing the issue in plain words. Not "Reduce iOS pointer latency by dispatching pending input before BeginFrame" and a wall of refactoring later, but "Faster vsync and pointer painting performance", with short technical summary inside of PR message (maybe even video/tests of vsync latency before/after), and all the meat inside the commit message. Keep PR worded in a simple terms.
- Used PR comments as a chat: you wrote like 8 messages one after another in an hour. Give the developers some time to think, to maybe reconsider their decision or vision. The person might just had a bad day and you're just nagging them with questions which require thinking and remembering the code. Wait at least a day, or better a week, before responding to the message with outcome you did not expect.
- After "the infrastructure is broken, we're trying to remove it completely" message it'd better to ask if the developers have ideas, plans, or maybe draft implementation on how it could be improved, and if anybody is working on that already, instead of defending your position when you received decline.
You've got frustrated and disappointed that your PR did not get merged. I understand you and I was in your shoes. However keep in mind what I wrote about stewarded projects and take a closer look where are you contributing at: a project which requires you to sign CLA, which means to give your code authorship to the company. Do you really want to improve the product which is developed for money, without you getting money and giving away code authorship?
Won't write anything in addition, just recommend reading these two articles:
Came across the discussion in this PR and because this kind of pattern can be seen more often than one might think I wonder how this can be avoided in the first place? In huge open source repositories like flutter there are so many people, teams and individual contributors working on a single project that it seems to be difficult sometimes to communicate the expected path forward. Especially if you're not in the core team of developers it's difficult to know what is actually wanted and if your own idea or solution for an issue matches the desired pattern of the repository etc.
If you have any experience (e.g. from other open source projects) how this can be handled in a positive way for everyone feel free to submit your idea here in the comments.
I will use the terminology which I invented and use, I don't know more appropriate words.
There's technical open source (code licensed under free license), social open source (accepting contributions, working towards the user, maintaining), and stewarded open source ("the product" with the team, roadmaps, release cycles, but the code is open and free).
Technical vs social: many projects are made to solve the issue of the author, and just published on the internet under a FOSS license for everyone, nothing more. For a random project on the internet, you should not by default assume that the author is willing to fix the issue you report, implement the feature you'd like to have, or merge your contributed code — author may not be interested in solving your issue, they already solved theirs. That's open source which does not have social component.
What you have here is a stewarded open source: a Google project which have a team on a salary. The team has their own plans and goals on their product, and in addition they accept contributions. They might not be interested in them, or even be hostile to external contributions, because some PRs just disrupt their plans, not suitable in their architecture view, or could be seen as a maintenance burden which they didn't ask for. Check CONTRIBUTING.md in the repository: the code contribution is in the bottom of the list, and they have a hour and a half movie on how to contribute!
Since this is a team on a salary, your task is first and foremost to explain the issue you have, and make it clear what is wrong currently, why is it wrong, and how it could be improved. The code contribution should follow only after you've been understood and the issue has been confirmed as an issue. Only then you can make a suggestion PR if you feel so ("I fixed it this way, it works for me, take a look").
Issues with your PR:
- Minor one: used only what-have-been-done technical description instead of just describing the issue in plain words. Not "Reduce iOS pointer latency by dispatching pending input before BeginFrame" and a wall of refactoring later, but "Faster vsync and pointer painting performance", with short technical summary inside of PR message (maybe even video/tests of vsync latency before/after), and all the meat inside the commit message. Keep PR worded in a simple terms.
- Used PR comments as a chat: you wrote like 8 messages one after another in an hour. Give the developers some time to think, to maybe reconsider their decision or vision. The person might just had a bad day and you're just nagging them with questions which require thinking and remembering the code. Wait at least a day, or better a week, before responding to the message with outcome you did not expect.
- After "the infrastructure is broken, we're trying to remove it completely" message it'd better to ask if the developers have ideas, plans, or maybe draft implementation on how it could be improved, and if anybody is working on that already, instead of defending your position when you received decline.
You've got frustrated and disappointed that your PR did not get merged. I understand you and I was in your shoes. However keep in mind what I wrote about stewarded projects and take a closer look where are you contributing at: a project which requires you to sign CLA, which means to give your code authorship to the company. Do you really want to improve the product which is developed for money, without you getting money and giving away code authorship?
Won't write anything in addition, just recommend reading these two articles:
https://sneak.berlin/20250720/the-agpl-is-nonfree/, it's about completely different topic, but read from "Gifts absolutely do not work like that". And https://dri.es/license-only-versus-stewarded-open-source