Ну так объясни, о великий гуру ты наш.
О-ока-ай. Гуру объясняет. Все пишу чисто из своего опыта работы в опенсорсе.
Есть проект (как он начался - вопрос отдельный, очень часто подобные проекты вырастают из университетов как раз (это на поганом прогнившем западе), впрочем из университетов вырастают многие проекты, как например гугл)), вокруг него так или иначе есть сообщество разработчиков. Этот проект (приложение) используется какой-то конторой, от качества этого софта у них зависит бизнес (то есть они НЕ продают софт, а скорее всего предоставляют услугу - например они провайдер, либо они просто используют этот софт в своем производственном процессе). В этом случае у конторы есть несколько вариантов:
1) Оплатить на фултайм одного из имеющихся разработчиков. То есть так человек работал в свободное время, а так будет фултайм.
2) Если у конторы есть свои разработчики, то на регулярной основе начать комиттить в проект. То есть по сути это введение своего разработчика/группы разработчиков в основную группу разработки. Ну или по мелочи комитить просто - багфиксы критичные для конторы и так далее.
3) Повышать приоритет тех задач в проекте, которые выгодны данной конторе путем оплаты времени одного из основных разработчиков. То есть это не фултайм, а просто доп. подработка получается для такого разработчика.
4) В сочетании с (3), если денег достаточно, а разработчик не хочет/не может уделять этим таскам достаточно времени (он скажем пилит ядро, а это просто масса багфиксов малоинтересных), то контора предоставляет разработчику возможность выбрать и нанять еще одного разработчика (уже на фултайм) в проект для, скажем багофиксов. То есть при этом выходит что основной разработчик работает (с точки зрения конторы) на не полный рабочий день и выступает ментором для нанятого им же разработчика, который скажем багфиксит то, что приоритетно для конторы.
Крупные конторы, вроде интела, в отношении GCC рабтают по (2) варианту. Apple, работает по (1) и (2). AdaCore - тоже (2).