Comment by michaelt

  If you have a patch, and others know how
  to make it better, why would you forgo
  that chance to learn something?

If I have patched the code to scratch an itch of mine, by the time I submit the patch my itch is scratched - no subsequent changes will contribute to scratching my itch, no matter how good they are.

At the same time, many open source projects are subject to constraints or requirements that are entirely reasonable from their perspective but that take time and don't much help or educate me as a one-off contributor.

For example:

* Paperwork like contributor license agreements

* Supporting obsolete (or nearly obsolete) platforms, and avoiding modern language features to maintain that support.

* Compatibility with project features I don't use, but other people do.

* Getting all the integration and test features of a finicky build pipeline to work, not just those needed to make a build.

* Correctly dividing up changes in multiple areas into multiple patches reflecting the fact different changes will need to be reviewed by different people.

* Requirements like code style and automated test coverage that contribute statistically to lower bug counts at the project level, but that don't reveal any bugs in my specific contribution.

* Code structure issues specific to the project, which as a one-shot contributor it isn't productive for the project to educate me about.

* Conflicts with planned future changes that aren't really documented very well anywhere - or that are documented only in places I didn't find, like the archives of a high-traffic mailing list.