Back

@DoctorBLLK I'm not an expert, but in my limited experience it varies from project to project. Sometimes an existing open source project gets "adopted" by a company, and employees start spending work hours contributing to the project. In that case, it might require careful negotiation with the existing open source merge gatekeepers, to make sure contributions align with their vision for the project and will get merged.

Elsewhere...

@DoctorBLLK Elsewhere, a company might create an open source project from scratch (or fork an existing one), in which case the company owns the copyright and their employees are entirely in control of what gets worked on and merged.

The Linux kernel is an example of the first type, whereas many Ubuntu components are examples of the second.

@DoctorBLLK The virtualization project LXC is an example of the second, managed by Canonical, but recently the employee who was the major contributor & visionary resigned in order to fork the project and make different management decisions than the company were making.

@tartley so this perspective makes me think, if the changes wanted or needed are "too large," then it will essentially *always* be the responsibility of the community to implement (via fork or otherwise). The project owner just won't ever have a vested interest in conceptual improvements without immediate gain.

@DoctorBLLK I don't think *never*. Some commercial stewards are enlightened long term thinkers. But yeah, I'd wager you are right that there is a substantial weighting towards change only for immediate or possibly foreseeable gain. And arguably there is merit to that. YAGNI, right? I guess it depends on what sort of large changes you are thinking of, and what motivates them.

@tartley it's such an unfamiliar topic to me I had trouble finding how to even ask.

It arises from a small project where a contributor has a notable fork, but decries the original project (firmware specifically) as bad for a variety of reasons (outside my skill to understand).
I believe their expectation is that the complaints should be acted upon, but I questioned that reality.
Thus, my question!

@DoctorBLLK That might stray into messy human territory.

The onus is on the individual to clearly communicate why the proposed changes will be helpful to a subset of the project users and maintainers - the larger the subset, the better. If they can't, or aren't volunteering to do the work, or have had fraught relationships with company employees in the past, then chances are that gatekeepers will not be inclined to agree.