Free software development usually proceeds dialectically.

Or, why I've seen community contributions to free software struggle, and why that's probably ok.

By this I mean specifically community-driven software projects, not corporate-backed open source projects. Those projects tend to make contributions too easy, in order to monetize free community labor.

In my experience, outsider contributions to actively maintained upstream free software project are usually not welcome. And by this, I do not mean that free software maintainers are unwelcoming, but that actually getting a patch accepted by such projects is often disproportionately difficult.

I see a few reasons for this:

First, actively maintained projects tend not to have low hanging fruit, at least with regards to bugfixes. Maintainers tend to pluck such fruit.

Second, and much more interestingly, particular programming styles and project-specific paradigms are often not documented well, leading to maintainers receiving patchs they view as unaligned with their wishes for the code in ways that are not obvious to would-be contributors.

In other words, for projects beyond a certain size, would-be contributors need to spend much more time studying the parts of the codebase they don't intend to modify than they need to implement their specific desire of the software.

The friction differential between developing a patch on some software and upstreaming that patch is, as I see it, the origin of the dialectical nature of free software development.

Maintainers usually have a specific vision for the software they maintain, or a least a common understanding of the types of things they'd like to work on. Long-time contributors to a project can be much more productive at developing larger features or refactorings than any new contributor could be. And that's good!

But it's also one-sided. Taken to its limit, a small group of highly productive long-time contributors open the door for inexperienced community members to bring a wildly different perspective to the project, which permits significant jumps in functionality, utility, or performance that would otherwise have been neglected by the long-time contributors.

Of course these independent developments are also one-sided. They are necessarily limited in scope, even if their developments hit above their weight in terms of utility per development time.

All the points of friction described earlier contribute to conflict. Now we have a well-maintained upstream project with lots of velocity, a public roadmap, a versioning scheme...and, next door, Jenny's Favorite Project which has none of those things but runs 9x as fast.

Finally, when both one-sided tendencies have reached their limit, when the relative goodness of each aspect becomes too much for either to ignore, a process of reconciliation occurs: The hard work of upstreaming the performance improvements are taken up and the maintainers adopt them, or maybe the community slowly migrates and builds a new team around Jenny's Favorite Project, or maybe some other project works to convert Jenny's tree into a patchset atop the upstream, etc etc. There's innumerable ways the reconciliation can play out.