Исходный текст программы

Skull · Сообщение **Skull** » 28 мар 2016, 16:29

Коллективное творчество дает несовместимость версий, разброд и шатания. + копирование багов друг у друга. Стоит вспомнить как в алгоритме датчика 18В20 ошибка определения 0-1 градуса разошлась по тырнету и усиленно копировалась друг у друга с периодически вспыхивающими холиварами по поводу этой ошибки.
Не забываем еще одно: То, что информация ничего не весит, еще не означает, что она ничего не стоит.
И тот факт, что автор любезно предоставляет программу нахаляву, еще не означает, что ему не принадлежит авторское право и он незаслуженно "зажимает" исходники.
К тому же пользовательские блоки вполне доступны, лично я не вижу смысла лезть в оболочку.

Сообщение **support** » 28 мар 2016, 18:50

Честно сказать я не очень поддерживаю, и понимаю идею Open Sourse.
В своё время я шесть лет проработал в проекте Cadel (собственно говоря я его и придумал, так что могу считаться папой), и после создания через полгода от начала работы команды, нас в ней было четыре человека. Так вот и при четырёх разработчиках, даже с учётом того что каждый занимался своей частью работы, и мы работали в одной комнате во время мержа веток происходили страшные коллизии. Доходило до того что приходилось откатываться на предыдущие версии кода. А что будет при 10- 20 разработчиках, тем более которые работают независимо друг от друга, и при этом не согласовывают между собой свои цели. Я же повешусь собирать между собой ветки и в конце концов забью на это.
Тут возможно создание нескольких независимых версий программы но тогда встаёт вопрос о совместимости версий файлов проекта. Пока мне в основном удаётся поддерживать версии файлов проекта начиная с первой версии программы, но при наличии даже пары - тройки вариаций самой программы, получится каша.
Ну и конечно остается вопрос о языке программирования. Программистов на SmallTalk действительно мало, и переход на этот язык сложен (по крайней мере по моему опыту). Так что я даже не знаю кто сможет занятся собственной доработкой программы.
Так что открытых исходников не будет. Но если я когда ни будь решу завязать с проектом по каким-либо причинам (надеюсь этого не произойдет но мало ли что в жизни бывает), вот тогда я выложу исходники и отправлю проект в свободное плаванье.

Parkhom · Сообщение **Parkhom** » 28 мар 2016, 21:33

Коллеги, позвольте вставлю свои 5 копеек: я категорически против "ветвления" проекта! И вот по какой причине: Автор привел пример работы в проекте "Cadel", это только один фрагмент негатива в работе "команды", на самом деле их гораздо больше. Не понаслышке знаю, т.к. принимал участие в коллективном творчестве в молодые годы. Я прекрасно понимаю, что многим, и я не исключение, хочется получить законченный продукт со всеми наворотами, без багов, который мог бы удовлетворить любую прихоть не программиста. Мне тоже этого хочется. На самом деле этим пожеланиям есть очень много препятствий: проект реализует один человек, бесплатно. В свое свободное время. Как у каждого человека у Автора есть некие периоды, когда нет вдохновения, нет решения той или иной ситуации, в конце концов, просто хочется отдохнуть) Давайте не будем дергать Сергея за рукава с просьбами "скорее" или другим образом принуждать как то ускорить свою работу. Честно, я с ужасом думаю о том моменте (не дай Бог!) когда Автор вдруг решит оставить свой проект. Извините, написал несколько сумбурно, можно было бы сократить до одного предложения: не мешайте человеку творить!

Max · Сообщение **Max** » 29 мар 2016, 06:11

В принципе, возможность создания собственных блоков и конструирование по коду Си достаточно хорошо расширяет возможности программы и дает нестандартные решения в частных случаях. По моему, это уже многим пользователям очевидно.
А единоначалие необходимо для контроля и эффективного управления самим ядром.
Так что, я за единоначалие и код открывать не надо.

Олег · Сообщение **Олег** » 29 мар 2016, 08:58

Тоже поддержу - лучше медленное развитие с минимумом глюков, чем бурное с бесконечным количеством заплаток после каждого релиза.

SirYorik · Сообщение **SirYorik** » 29 мар 2016, 20:36

страшные коллизии.

определенно в GNU/Linux, FreeBSD, етц... с этим умеют справляться без адовых мук.

так что количество девелоперов точно не аргумент.

Сообщение **support** » 29 мар 2016, 20:39

SirYorik писал(а):определенно в GNU/Linux, FreeBSD, етц... с этим умеют справляться без адовых мук.

Ну я все таки инженер а не проффесиональный программист. Программирование для меня хобби, и работа в команде не оставила у меня положительных эмоций. С людьми без проблемм, мужики подобрались хорошие, а вот с программой всё очень тяжело

SirYorik · Сообщение **SirYorik** » 29 мар 2016, 20:45

я к тому, что если вдруг захочется перейти на коллективный подход, то можно найти маинтайнеров АЛЬТ Линукс например и пообщаться. в целях построения правильной инфраструктуры, как софтовой так и иерархии разработчиков.

Сообщение **support** » 29 мар 2016, 20:49

Честно сказать - не хочу. Меня пока устраивает текущая ситуация

Max · Сообщение **Max** » 29 мар 2016, 21:41

SirYorik писал(а):то можно найти маинтайнеров АЛЬТ Линукс например и пообщаться.

Ну, если есть возможности работать с Линуксом, то может функциональные блоки FLProg банально переведите на платформу Raspberry Pi...

SirYorik · Сообщение **SirYorik** » 30 мар 2016, 06:14

Max писал(а):работать с Линуксом

ну Макс!?, какая еще работа с линуксом?

FlProg