|
Да, только не нужно путать наличие четкого представления о строении будущей системы, а также плана/стратегии развития, которые должны присутствовать в любом нормальном osdev-проекте, и порядок ведения коллективного проекта, распределение ролей в проекте между его участниками.
Согласен, что сначала нужно согласовать и озвучить концепцию будущей системы. Отсюда уже будет понятно, кто в принципе может участвовать в проекте, а кто нет. Т.е. решили к примеру писать микроядро, а мне как разработчику ядра это не интересно и (опять к примеру) разработкой сайта для проекта я тоже не горю особым желанием заниматься, но потестить дистрибутив, пусть даже и примитивный на первых порах, можно - делов-то. Тогда записываете меня в тестеры, пока к примеру я вдруг не захочу поучаствовать в разработке ядра (с уже принятой концепцией) и прямо не скажу разработчикам ядра об этом. Отсюда кстати следует, что после озвучки концепции отдельными людьми может образоваться несколько групп по интересам в плане концепции ядра и в принципе может зародиться сразу несколько коллективных проектов. Я в своих рассуждениях отталкиваюсь именно от архитектуры ядра как основополагающем факторе в концепции будущей системы, но в общем-то можно поискать и другие отправные точки, например, люди решили, что им хочется сделать систему, которая бы лучше других подходила для решения какой-то узкой задачи, и им не так важно, будет ли в основе этой системы микроядро или монолитное ядро, тогда обсуждение по выбору архитектуры ядра для данной системы будет проходить более спокойно, без травм и потерь в личном составе, что в конечном счете повышает живучесть коллективного проекта.
|
Вход
Регистрация
FAQ
Поиск
