VSHY
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Не с тем вы боретесь.
В OpenSource люди пишут в первую очередь для себя. А если даже и не для себя, то жизнь идёт, всё меняется (семья, проблемы, смена ориентиров и приоритетов в жизни, возраст и т.д.), и наступает момент, когда разработчик перестаёт поддерживать продукт. Это аксиома, и с этим нужно смириться. Это избавит от неправильных технических решений разработчиков и неоправданных ожиданий от пользователей. Что-то требовать здесь, по моему, странно.
Чтобы на проекте были разработчики он должен быть максимально прост и гибок, если в кратце. Если он будет таким, тогда потеря разработчиков будет не так критична, т.к. будет постоянное их движение.
Подробнее по проблемам:
1. Сильно переусложнённая структура проекта - код построен на событиях, что в сотни, если не тысячи, раз увеличивает время с тем, чтобы разобраться. И так сложности на алгоритмы выше крыши, а тут проект тебе постоянно выкручивает руки... Потому разработчики и не хотят этим заниматься. А те, кто берётся, в ходе видят, что разобраться и поддерживать это невероятно затратно по времени, потому и эти желающие в конце концов отпадают.
2. Плохо кастомизируемый UI. После перехода Qt на закрытую лицензию для OpenSource-проекта это перестало иметь какой-либо смысл. Ещё гвоздь в крышку гроба - при переходе на Qt6 поддержка XP практически отпала (а скоро отпадёт Win7 и далее).
Бороться с этими родовыми проблемами бесполезно и бесперспективно.
Чтобы проект не умер окончательно, выход единственный - взять какой-нибудь современный бесплатный платформонезависимый и перспективный фреймворк для UI, который в плане цветов, отступов и т.д. будет легко настраиваться с помощью css, и реализовать максимально простую и понятную структуру - наклацал галочками или указал в полях все необходимые параметры и нажал кнопку "Обработать" или "Обработать всё", и дальше код бы выполнялся линейно. Это в тысячи раз бы упростило проект, и время занимаемое на то, чтобы разобраться разработчику. А конкретный код обработки (алгоритмы) можно было бы практически без изменений перетащить из имеющихся проектов, отобрав лучшие по функциональности и скорости. Как более гибкий вариант вообще предлагалось из UI вызывать внешние утилиты или плагины для обработки.
Иначе всё будет как сейчас - пришёл новый "разработчик", приделал к нему какую-то свою финтифлюшку, на этом всё и закончилось. Или создал новый форк, который также не решает всех вышеперечисленных проблем, а тянет одеяло на себя.
В отсутствие разработчиков можно было бы попробовать смотивировать имеющихся, кто ведёт уже какой-то из форков. Либо тогда наше ТЗ (с главными целями - простота и гибкость для поддержки в будущем имеющимися силами) и отдать на фриланс. |
