архив
Комментарии к статье
Приглашение к новой дискуссии:
О жизненном цикле и open source
Есть ведь такой интересный момент... IBM например давно вкладывает большие средства в развитие OpenSource проектов, несколько подразделений IBM ведут более сотни проектов, связанных с Linux. Был открыт код VisualAge, с которого начался Eclipse Project. Rational опять же... Так что заинтересованные компании вкладывают деньги в OpenSource, и разработка там ведется на высоком уровне. Также наблюдается тенденция открытия кода известных коммерческих приложений. Похоже, что это выгодно - развивать среду, на которой потом будет функционировать платный софт. Что касается крупных проектов OpenSource "от сообщества" - в конечном итоге деньги на них все равно зарабатываются (консалтинг, тех.поддержка, выпуск "надежных" или "оптимизированных под нужды заказчика" платных версий открытых решений и т.п.), а для этого просто необходимо производить качественный код. Так что "коммерческая" организация фазы сопровождения (да и разработки) - залог самофинансирования таких проектов. Средства же будут поступать не впрямую от продажи продукта, а из смежных областей, извлекающих выгоду из его существования. Остается только их найти:)
Так называемый unix way служил в свое время для преодоления данного препятствия в среде программистов - разработка нишевых утилит с резко очерченной функциональностью рулит! ;)
А еще интересен пример Мозиллы... Но это уже совсем другая история...
А еще интересен пример Мозиллы... Но это уже совсем другая история...
Хорошая статья. Спасибо за ценную информацию.
Самое главное, что в проекты OpenSource следует вкладывать деньги, и в той же IBM, да и MICROSOFT , я думаю, понимают, что вложив деньги, кстати, не такие уж и большие, в эти проекты, заставляешь кучу людей, достатно высокого профессионального уровня, выявлять, для вложившего в эти проекты деньги, практически все тупиковые решения, которые следует отсекать при разработке коммерческого софта.
К тому же, при разработке такого софта появляются и новые идеи, которые также можно отслеживать и доводить уже в своих лабораториях до коммерческих продуктов.
Иначе говоря, как в анекдоте про скульптора, помните: - "Беру большую глыбу и отсекаю все лишнее..."/
Только в данном случае всю черновую работу делают другие и практически бесплатно.
К тому же, при разработке такого софта появляются и новые идеи, которые также можно отслеживать и доводить уже в своих лабораториях до коммерческих продуктов.
Иначе говоря, как в анекдоте про скульптора, помните: - "Беру большую глыбу и отсекаю все лишнее..."/
Только в данном случае всю черновую работу делают другие и практически бесплатно.
>>следует вкладывать деньги
Во многие из них и так вкладывают деньги и не малые.
>>отслеживать и доводить уже в своих лабораториях до коммерческих продуктов
Центры есть всегда и везде. Другое дело, что результатом open source проекта будет пользоваться все в том числе и сам разработчик. А для чего он вообще этим занимается за бесплатно? Для себя, конечно же. Никто не берется за то, что ему на х<CENSORED>р не нужно.
Во многие из них и так вкладывают деньги и не малые.
>>отслеживать и доводить уже в своих лабораториях до коммерческих продуктов
Центры есть всегда и везде. Другое дело, что результатом open source проекта будет пользоваться все в том числе и сам разработчик. А для чего он вообще этим занимается за бесплатно? Для себя, конечно же. Никто не берется за то, что ему на х<CENSORED>р не нужно.
По стилю изложения статья написана студентом и соответственно содержит ноль полезной информации
Когда-то, ещё студентом я в одиночку написал систему VTMS/370 - систему распределения и виртуализации ресурсов для IBM S/370 OS 6.1 SVM. Часть кода по приказу начальства выложили в общий депозитарий. В итоге я оказался не только в "стороне" от собственной работы, но даже не имеющим к ней отношения "посторонним лицом"! В СССР это было нормой. Но, я не жалею об этом. Благодаря нескольким украденым у меня работам я получил знания и опыт которые иначе получить невозможно. И сейчас, с учётом более 20 лет инженерного опыта могу утверждать точно - ни один сложный проек нельзя сделать качественно если группа разработчиков изолированна от среды своих коллег, и в тоже время не все свои решения можно альтруистки раздавать всем желающим - всегда нужен какой-то личный "задел для скачка выше своей планки" иначе творец превратиться в простого ремесленника.
Добавлю: с точки зрения этапов разработки многие проекты как коммерчиские, так и открытые это всего лишь аванпроекты, этап на котором определяются все возможные пути решения сформулированной в Техническом Задании (ТЗ) цели проекта. И данная статья просто излагает доступным большынству языком сухой язык стандартов очерчивая общие принципы всех разработок. А учитывая, что в наше время понятие Инженер фактически приравняли к понятию "бездельник" эта стать необходима для того чтобы хотябы ответить людям на вопрос "А создать что-то новое просто? Почему мы должны платить этим бездельникам учёным и инженерам, ведь они не выпускают реальной продукции и не растят хлеб, чтот ищут в своё удовольствие.".
Вменяемый автор, вменяемая статья,вменяемые комментарии (почти все).
Статья баяновая какая-то.
Не сочтите за ламоту и пр., но я не особо доверяю опенсурцу и подобным вещам. А опен сурс в основном является бесплатным ПО. Можно понапихать туда что угодно, и вирей, и спая и прочей дряни, и никакой ответственности. Если продукт коммерческий, то будет хотя бы малая доля ответственности со стороны разработчика и бОльшие гарантии.
Не сочтите за ламоту и пр., но я не особо доверяю опенсурцу и подобным вещам. А опен сурс в основном является бесплатным ПО. Можно понапихать туда что угодно, и вирей, и спая и прочей дряни, и никакой ответственности. Если продукт коммерческий, то будет хотя бы малая доля ответственности со стороны разработчика и бОльшие гарантии.
ну и чушь. вы путаете open source и free ware. open source проги идут с исходниками -
не доверяешь - посмотри и скомпиль, да и глупо это именно по этой причине. если
в коммерческой проге будет подобная шняга, особенно под вендой, всегда можно
сказать - у вас на машине был неизвестный доселе науке вирус.
ага БОЛЬШИЕ гарантии, если та же венда накроется, что то никто не подает на M$ в суд.
M$ как пример. если коммерческая прога глюкнет - придется ждать обновления незнамо скоко.
вот так сразу исправлять никто не рванется. даже если за это заплачено. не везде так, но
есть.
и любителям всяких кряков - а вы никогда не задумывались, что в такой проге может
быть как раз такой доселе неизвестный вирус или троян? то то, когда набрал в гугле: свиста кряк, столько заголовков о
троянах.
не доверяешь - посмотри и скомпиль, да и глупо это именно по этой причине. если
в коммерческой проге будет подобная шняга, особенно под вендой, всегда можно
сказать - у вас на машине был неизвестный доселе науке вирус.
ага БОЛЬШИЕ гарантии, если та же венда накроется, что то никто не подает на M$ в суд.
M$ как пример. если коммерческая прога глюкнет - придется ждать обновления незнамо скоко.
вот так сразу исправлять никто не рванется. даже если за это заплачено. не везде так, но
есть.
и любителям всяких кряков - а вы никогда не задумывались, что в такой проге может
быть как раз такой доселе неизвестный вирус или троян? то то, когда набрал в гугле: свиста кряк, столько заголовков о
троянах.
в серьезных дистрах все пакеты вообще подписаны производителем
Вообще-то тут не упомянута такая категория как администраторы, которые как раз и занимаются тестированием-внедрением-сопровождением. Иногда эту роль играют создатели дистрибутивов, но чаще всего именно администратор, а не конечный пользователь принимает решение о готовности продукта к использованию. И именно администраторы должны финансировать команду поддержки. К тому же администратор как правило непосредственно контактирует с конечным пользователем и именно его труд оплачивается с наименьшими возражениями.
Я скажу так: любая программа будет плохо сопровождаться, если нет заказчика в виде физического или юридического лица. И никакие менеджеры-хренеджеры в этом ничего не изменят, если разработчик не знает, что от него хочет потребитель. Для современного ПО роль заказчика выпролняет либо сам разработчик (open source), либо менеджер, который практически всегда нихрена не смыслит в тех задачах, которые должно решать ПО, однако "реагирует на пожелания потребителя". В первом случае получаем софт с психоделической логикой, который делает все, что надо, но перед этим нужно вывихнуть мозги в ту же сторону, что и автор (т.к. разработчик свою программу знает и наивно думает, что и остальные разберутся), во втором - выходит гигабайтный уродец, который удовлетворяет ВСЕХ, но пока найдешь нужную удовлетворялку - сдохнешь от старости над восьмиуровневыми меню, именно потому, что разработчики засунули в эти меню ВСЁ, что только можно.
>я не особо доверяю опенсурцу и подобным вещам. А опен сурс в основном является бесплатным ПО. Можно понапихать туда что угодно, и вирей, и спая и прочей дряни, и никакой ответственности.
Логически верно. Я пользуюсь Open Souce ОС и приложениями много лет, и не затруднял себя исследованием исходного кода, и теоретически, мог нахватать много всякой заразы. Но на практике, всегда найдется тот, кто посмотрит в исходник, и скажет - вот автор фигню заложил. Вобщем не известны мне случаи когда в программу с доступным исходным кодом осознанно закладывали какую нибудь вредоносную функциональность. А уязвимости в безопасности есть, тут ничего не попишешь.
С другой стороны, если в программах с закрытыми исходниками имеют место быть easter eggs, естественно появляется подозрения, что и spyware можно всунуть в них так-же легко и непринужденно, а если кто и заметит - списанть на неизвестный вирус.
Ответственность-же равнозначна для всех разработчиков, вне зависмости от методов распространения. Уверенность, что "я плачу бабки == я получаю качественный продукт", не более чем мещанское заблуждение. Какая нафиг разница, кто оплачивает банкет?
Логически верно. Я пользуюсь Open Souce ОС и приложениями много лет, и не затруднял себя исследованием исходного кода, и теоретически, мог нахватать много всякой заразы. Но на практике, всегда найдется тот, кто посмотрит в исходник, и скажет - вот автор фигню заложил. Вобщем не известны мне случаи когда в программу с доступным исходным кодом осознанно закладывали какую нибудь вредоносную функциональность. А уязвимости в безопасности есть, тут ничего не попишешь.
С другой стороны, если в программах с закрытыми исходниками имеют место быть easter eggs, естественно появляется подозрения, что и spyware можно всунуть в них так-же легко и непринужденно, а если кто и заметит - списанть на неизвестный вирус.
Ответственность-же равнозначна для всех разработчиков, вне зависмости от методов распространения. Уверенность, что "я плачу бабки == я получаю качественный продукт", не более чем мещанское заблуждение. Какая нафиг разница, кто оплачивает банкет?
>>Для современного ПО роль заказчика выпролняет либо сам разработчик (open source), либо менеджер, который практически всегда нихрена не смыслит в тех задачах, которые должно решать ПО, однако "реагирует на пожелания потребителя".
Всех в кучу только не надо. Вчера читал статью о KDE4. Над этим проектом трудятся не только программисты, переводчики, всех спецов и не припомню, но и спецы по юзабилити.
Всех в кучу только не надо. Вчера читал статью о KDE4. Над этим проектом трудятся не только программисты, переводчики, всех спецов и не припомню, но и спецы по юзабилити.
>>С другой стороны, если в программах с закрытыми исходниками имеют место быть easter eggs, естественно появляется подозрения, что и spyware можно всунуть в них так-же легко и непринужденно, а если кто и заметит - списанть на неизвестный вирус.
В случае со свистой пользователь сам под этим подписывается не читаю лицензию и называется это красивыми словами - доверительный компьютинг.
В случае со свистой пользователь сам под этим подписывается не читаю лицензию и называется это красивыми словами - доверительный компьютинг.
>>С другой стороны, если в программах с закрытыми исходниками имеют место быть easter eggs, естественно появляется подозрения, что и spyware можно всунуть в них так-же легко и непринужденно, а если кто и заметит - списанть на неизвестный вирус.
В случае со свистой пользователь сам под этим подписывается не читаю лицензию и называется это красивыми словами - доверительный компьютинг.
В случае со свистой пользователь сам под этим подписывается не читаю лицензию и называется это красивыми словами - доверительный компьютинг.
Если в Этом тексте вазде заменить Open Source на Closed Source,
Смысл практически не изменится
Смысл практически не изменится
Смысл один - хорошее дешевым не бывает, а темолее бесплатным. Только вот причем опен сорсе.
> Смысл один - хорошее дешевым не бывает, а темолее бесплатным. Только вот причем опен сорсе.
Тут ведь как, за хорошую вещь надо платить, лучшее - дается бесплатно. Это первое. Второе - хорошее тоже может быть бесплатным, но у людей в голове это не укладывается вообще никак.
Тут ведь как, за хорошую вещь надо платить, лучшее - дается бесплатно. Это первое. Второе - хорошее тоже может быть бесплатным, но у людей в голове это не укладывается вообще никак.
Не понимаю истерии по поводу вредоносного кода в Open Source aka ПООК. Да, нужно конечно обладать познаниями в конкретном языке программирования, чтобы разобраться кто куда и что к чему. Я лично сомневаюсь, что адекватному программисту придёт в голову напихать в своё детище болячек... Это подорвёт кредит доверия и запросто поставит крест на его развитии. С другой стороны отморозков тоже предостаточно. НО это либо скрипткидди, либо ксакепы и иже с ними. Кто-нибудь может привести примеры сознательного или непреднамеренного заражения ПООК и тем более распространения и вреда? На память приходит BitKeeper, отлавливающий всякого рода гадость в ядре Linux. Реально отлавливает. Так чтослухи об опасности ПОДЧЁРКИВАЮ OperSource мягко говоря преувеличены.
ЗюЫю Помню, бооольшая хохма была с первой локализованной версией Heroes of Might and Magic III (ROE). По-моему, от Буки. Так вот в тараж вышел троян. :))
ЗюЫю Помню, бооольшая хохма была с первой локализованной версией Heroes of Might and Magic III (ROE). По-моему, от Буки. Так вот в тараж вышел троян. :))
Елена Сальникова>>выступление на конференции LinuxWorld в
>>Лондоне 25-го октября 2006 г. Алана Кокса
>>Он, в частности, заявил, что утверждения о том, что ПО с
>>открытыми кодами по определению является более безопасным
>>и надежным, чем проприетарное ПО, необоснованы и вредны.
>>Высокое качество обеспечивается лишь в нескольких проектах,
>>в которых участвуют квалифицированные исполнители, и
>>поддерживается должная работа с кодом
Прав человек на 100%, чтобы убедиться, стоит покопаться в открытых проектах на freshmeat, sourceforge и т.п.: у некоторых проектов до того непрофессиональный код, что волосы дыбом встают.
>>Лондоне 25-го октября 2006 г. Алана Кокса
>>Он, в частности, заявил, что утверждения о том, что ПО с
>>открытыми кодами по определению является более безопасным
>>и надежным, чем проприетарное ПО, необоснованы и вредны.
>>Высокое качество обеспечивается лишь в нескольких проектах,
>>в которых участвуют квалифицированные исполнители, и
>>поддерживается должная работа с кодом
Прав человек на 100%, чтобы убедиться, стоит покопаться в открытых проектах на freshmeat, sourceforge и т.п.: у некоторых проектов до того непрофессиональный код, что волосы дыбом встают.
Ganesha, пятница, 2 марта 2007 г. 18:34:10:
Не понимаю истерии по поводу вредоносного кода в Open Source aka ПООК.
..............................................
Вы не учитываете еще одн нюанс - есть ещё и треий вариант - элементарная безграмотность программиста, ну не хотел он этого, просто играл, не ведая того, на грани фола. В комерчиских проектах как правило, квалификация персонала - забота фирмы. Конечно Open Source это хорошо, безусловно. Но, нужен в этом случае более жесткий контроль - а это, согласитесь, в этом случае сделать несколько сложнее.
Не понимаю истерии по поводу вредоносного кода в Open Source aka ПООК.
..............................................
Вы не учитываете еще одн нюанс - есть ещё и треий вариант - элементарная безграмотность программиста, ну не хотел он этого, просто играл, не ведая того, на грани фола. В комерчиских проектах как правило, квалификация персонала - забота фирмы. Конечно Open Source это хорошо, безусловно. Но, нужен в этом случае более жесткий контроль - а это, согласитесь, в этом случае сделать несколько сложнее.
>>Прав человек на 100%, чтобы убедиться, стоит покопаться в открытых проектах на freshmeat, sourceforge и т.п.: у некоторых проектов до того непрофессиональный код, что волосы дыбом встают.
Я бы даже сказал так - современная культура программирования сама по себе не блеск. На старой работе приходилось заниматься рефакторингом чужого кода - дописывать новые фичи, править ошибки. Пишешеь и думаешь - убил бы гада, если бы встретил, руки оторвал бы и ведь считаются вроде как профи. Узанаешь о них вроде бы даже не которые из них ушли в серьезные фирмы - по крайней мере так считается. И ведь никто и никогда этого не увидит.
Я бы даже сказал так - современная культура программирования сама по себе не блеск. На старой работе приходилось заниматься рефакторингом чужого кода - дописывать новые фичи, править ошибки. Пишешеь и думаешь - убил бы гада, если бы встретил, руки оторвал бы и ведь считаются вроде как профи. Узанаешь о них вроде бы даже не которые из них ушли в серьезные фирмы - по крайней мере так считается. И ведь никто и никогда этого не увидит.
tux>>>>Я бы даже сказал так - современная культура программирования
>>сама по себе не блеск. На старой работе приходилось заниматься
>>рефакторингом чужого кода - дописывать новые фичи, править
>>ошибки. Пишешеь и думаешь - убил бы гада ...
Вашу ситуацию трудно комментировать: возможно вы делали рефакторинг на прототайп или трейс код, который для того и предназначен, чтобы быть "тяп-ляп на коленке за короткий срок". После этого привлекается специалист или группа специалистов способных "за определенное вознаграждение" довести этот код до ума. Трудно предположить, что, к примеру, всю эту груду некачественного кода на sourceforge или freshmeat будет рефакторить высококласные специалисты, т.е. 95% кода так и будет отаваться некачественным.
>>сама по себе не блеск. На старой работе приходилось заниматься
>>рефакторингом чужого кода - дописывать новые фичи, править
>>ошибки. Пишешеь и думаешь - убил бы гада ...
Вашу ситуацию трудно комментировать: возможно вы делали рефакторинг на прототайп или трейс код, который для того и предназначен, чтобы быть "тяп-ляп на коленке за короткий срок". После этого привлекается специалист или группа специалистов способных "за определенное вознаграждение" довести этот код до ума. Трудно предположить, что, к примеру, всю эту груду некачественного кода на sourceforge или freshmeat будет рефакторить высококласные специалисты, т.е. 95% кода так и будет отаваться некачественным.
:) Это уже много лет продают и за довольно нехилые бабки. И такого добра можно много найти - к нам приходили такие демки от вроде бы серьезных фирм (из одного города, который я упоминать не буду) - пользоваться ими было не возможно - вводиться все через ж..., да еще и падает постоянно. А на торгах нас тогда прокатили.
У нас используется софт-довольно серьезный по назначениею, пока не залезиш в исходники. Простой пример (уся клиентская часть делалась на Delphi...)
Для того, что бы спросить у пользователя - желает-ли сей господин покинуть систему, автор исходника создаёт целую форму и т.д. Не подсчитывал до запятой, но на вскидку - 10% работает, остальные - комментарии. При этом, это не только коммерчиский продукт, но еще и АСУ ТП. Т.е. фирмачи делали. Еслибы вдруг настало счастье... и все открылось - мир сощель бы с ума, от собственной глупости - что бы делали те именитые разработчики, у которых все увидели бы такую шнягу...
Для того, что бы спросить у пользователя - желает-ли сей господин покинуть систему, автор исходника создаёт целую форму и т.д. Не подсчитывал до запятой, но на вскидку - 10% работает, остальные - комментарии. При этом, это не только коммерчиский продукт, но еще и АСУ ТП. Т.е. фирмачи делали. Еслибы вдруг настало счастье... и все открылось - мир сощель бы с ума, от собственной глупости - что бы делали те именитые разработчики, у которых все увидели бы такую шнягу...
В дополнение - как не странно, почему-то вместе с софтом, разработчик и исходники положил. Система долго была в опытной эксплуатации и как я понял, разработчик просто приезжал на объект и эти самые свои портянки правил - вот, типа Open Source. По мне, так я не за что бы не взялся, не то что ощибки вылавливать (быстрее в этом случае нормальный код отфильтровать) даже править. Проще написать самому. :)
Блин, зацепило :) OpenSource-ну спустили нам задачу с исходниками, уж по какому принципу её выбирали - нам не доложили, но таких задач, кривых полностью (не у всех правда src есть) полно. И что делать прикажите? Не думаю, что кто-то из оплачивающих счета - заглядывал внутрь... Да и что менеджер там увидит? А править самому - рад бы, даже бесплатно (дабы облегчить свой труд по сопровождению) да стоп! Прав у меня таких нет, ежели что, косяк разработчика принесет ущерб - у того будет полный резон отказаться от ответственности.
Ganesha, пятница, 2 марта 2007 г. 18:34:10:
" Я лично сомневаюсь, что адекватному программисту придёт в голову напихать в своё детище болячек..."
Работа серверной части одной АСУ - усеми антивирусами определяется как "сканирование...". Т.е. работает эта бодяга с определеной группой технологических машин по определеному протоколу. А народ в офисе задолбал уже воплями "Вирусы!!!". Конечно это не "болячки" в софте - скорее ото болячки тех, кто ответсвенен за работу этого софта. К стати, работает это дело под линуксом. Что делать?
" Я лично сомневаюсь, что адекватному программисту придёт в голову напихать в своё детище болячек..."
Работа серверной части одной АСУ - усеми антивирусами определяется как "сканирование...". Т.е. работает эта бодяга с определеной группой технологических машин по определеному протоколу. А народ в офисе задолбал уже воплями "Вирусы!!!". Конечно это не "болячки" в софте - скорее ото болячки тех, кто ответсвенен за работу этого софта. К стати, работает это дело под линуксом. Что делать?
Что, всё все понятно?
Автор явно лукавит или действительно глуп, говоря об отсутствии бизнес-модели при групповой опен сорс разработке. Бизнес-модель есть, и довольно простая. Дело в том, что 90% бюджета проприетарных продуктов уходит на маркетинг и агрессивное продвижение, код же так называемых профессиональных оплачиваемых по традиционной схеме разработчиков ни чем не лучше кода "бесплатного". Естественно, что чаще всего группа довольно граммотных разработчиков могут не иметь изначальных средств на продвижение, рекламу и развитие своего продукта, поэтому различные схемы свободного или условно свободного распространения для них выход. Сам пользуюсь в профессиональных целях целым набором свободного софта -- от фрибсд до постфикса и снорта, и доволен.
Программисты вообще склонны переоценивать свою роль в проекте и во вселенной вообще ;). Функциональность и качество продукта не определяются "качеством кода". Важнее граммотная архитектура и управление проектом.
Программисты вообще склонны переоценивать свою роль в проекте и во вселенной вообще ;). Функциональность и качество продукта не определяются "качеством кода". Важнее граммотная архитектура и управление проектом.
2 Рупперт
Видите ли, юноша, автор статьи имеет некоторое представление о предмете, потому как застал еще те времена, когда бизнес-модели таковыми не назывались. И за ошибки в бизнес-моделировании следовало суровое служебное порицание - вплоть до высшей меры. Если бы Вы чуток потрудились и ознакомились с материалами сайта - Вы бы не говорили таких глупостей...
Видите ли, юноша, автор статьи имеет некоторое представление о предмете, потому как застал еще те времена, когда бизнес-модели таковыми не назывались. И за ошибки в бизнес-моделировании следовало суровое служебное порицание - вплоть до высшей меры. Если бы Вы чуток потрудились и ознакомились с материалами сайта - Вы бы не говорили таких глупостей...
>Программисты вообще склонны переоценивать свою
>роль в проекте и во вселенной вообще ;).
>Функциональность и качество продукта не
>определяются "качеством кода".
>Важнее граммотная архитектура и управление
>проектом.
"Качество кода" - чаще одна из х-к компилятора.
Любому приличному программисту совершенно очевидно, что постановка задачи, правильная архитектура и организация проекта на порядок важнее приёмов рутинного программирования.
Беда в том, что постановщика и руководителя программного проекта вне среды программистов, как правило, просто не найти. Вот и приходится "жертвовать ферзя".
>роль в проекте и во вселенной вообще ;).
>Функциональность и качество продукта не
>определяются "качеством кода".
>Важнее граммотная архитектура и управление
>проектом.
"Качество кода" - чаще одна из х-к компилятора.
Любому приличному программисту совершенно очевидно, что постановка задачи, правильная архитектура и организация проекта на порядок важнее приёмов рутинного программирования.
Беда в том, что постановщика и руководителя программного проекта вне среды программистов, как правило, просто не найти. Вот и приходится "жертвовать ферзя".
Знаете, мне, как и подавляющему большинству, не важно какие времена застал автор, что ему грозило и какой у него жизненный багаж. Я читаю и выражаю своё мнение о прочитанном. Время больших массивных "коробочных" разработок проходит, как и всё больше растворяются старые подходы к созданию программного продукта. Лет через пять большая часть обычных пользователей забудут, что такое персональный компьютер и установка на него программам и о прочей рутине. Онлайновые сервисы будет предоставлять всё: от утюга до фонарного столба. Классические крупные разработчики потеряют свои ведущие позиции на потребительском рынке, а борьба переместиться на поле платформенных базовый серверных решений. А там совсем другие критерии выбора и уровень потребителей, так что опыт открытой разработки не пропадёт даром и будет всё более востребован.
2Владимир Попов
да, программистам очевидно, но это "очевидно" из разряда, что "жизнь -- #авно", т.е. за ним нет никакого практического смысла и методики решения проблемы. В обществе, да и в кругу самих программеров, бытует мнение о непомерных умственных возможностях программистов (ну ещё, пожалуй, шахматистов :)). Опыт показывает обратное, хороший программист может написать неплохой код под заданную технологию, но когда его продвигают как архитектора проекта или аналитика чаще всего получается в лучшем случае плохо.
да, программистам очевидно, но это "очевидно" из разряда, что "жизнь -- #авно", т.е. за ним нет никакого практического смысла и методики решения проблемы. В обществе, да и в кругу самих программеров, бытует мнение о непомерных умственных возможностях программистов (ну ещё, пожалуй, шахматистов :)). Опыт показывает обратное, хороший программист может написать неплохой код под заданную технологию, но когда его продвигают как архитектора проекта или аналитика чаще всего получается в лучшем случае плохо.
Рупперт
Очень жаль, что Вы, юноша, плохо представляете себе процессы создания средних и больших программных продуктов, особенно группой или несколькими группами.
Вам бы почитать Брукса мл., или поучаствовать в таких разлаботках (если возьмут).
А про модные бизнес-планы и о том что будет - сказки расказывать не надо.
Человек высказал свою точку зрения - это его право. Но флудить, самоутверждаясь таким образом, наверно не слишком прилично...
Очень жаль, что Вы, юноша, плохо представляете себе процессы создания средних и больших программных продуктов, особенно группой или несколькими группами.
Вам бы почитать Брукса мл., или поучаствовать в таких разлаботках (если возьмут).
А про модные бизнес-планы и о том что будет - сказки расказывать не надо.
Человек высказал свою точку зрения - это его право. Но флудить, самоутверждаясь таким образом, наверно не слишком прилично...
Я люблю Билла Гейтса
Рупперт, пятница, 14 сентября 2007 г. 17:13:55:
Я люблю Билла Гейтса
Пассивно?
Я люблю Билла Гейтса
Пассивно?
Люди, давайте лучше поговорим с чего живут опенсоурсники!! Как прожить разрабатывая опенсоурс и при этом не подрабатывая?
To: аноним, воскресенье, 11 мая 2008 г. 17:34:57:
>Люди, давайте лучше поговорим с чего живут опенсоурсники!! Как прожить разрабатывая опенсоурс и при этом не подрабатывая?
--Ув., когда ж Вы выучите, что ОТКРЫТЫЙ =/= БЕСПЛАТНЫЙ.
Значительная часть утилит написана системными администраторами для своих нужд. Крупные разработки спонсируются из кармана "железнячников" или крупных софтверных фирм, см. Sun, RedHat, Google и т.п. Что-то разрабатывается в научной среде, что-то спонсируется государством (к-либо). Часть программ разрабатывается теми, кто этими программами зарабатывает деньги, т.е. не продажей программ, а создавая этими программами конечный продукт на продажу; сообщество в данном случае выступает как тестеры и помощники.
>Люди, давайте лучше поговорим с чего живут опенсоурсники!! Как прожить разрабатывая опенсоурс и при этом не подрабатывая?
--Ув., когда ж Вы выучите, что ОТКРЫТЫЙ =/= БЕСПЛАТНЫЙ.
Значительная часть утилит написана системными администраторами для своих нужд. Крупные разработки спонсируются из кармана "железнячников" или крупных софтверных фирм, см. Sun, RedHat, Google и т.п. Что-то разрабатывается в научной среде, что-то спонсируется государством (к-либо). Часть программ разрабатывается теми, кто этими программами зарабатывает деньги, т.е. не продажей программ, а создавая этими программами конечный продукт на продажу; сообщество в данном случае выступает как тестеры и помощники.
Елена Сальникова 2006-11-01 07:44:56.199092+03
Интересным дополнением к дискуссионной заметке Сергея Кузнецова можно считать выступление на конференции LinuxWorld в Лондоне 25-го октября 2006 г. Алана Кокса, известного (отчасти скандально) разработчика open source и сотрудника компании Red Hat.
Он, в частности, заявил, что утверждения о том, что ПО с открытыми кодами по определению является более безопасным и надежным, чем проприетарное ПО, необоснованы и вредны. Высокое качество обеспечивается лишь в нескольких проектах, в которых участвуют квалифицированные исполнители, и поддерживается должная работа с кодом (анализ, отладка, тестирование и т.д.).
Подход open source при наличии хороших программистов и сформированного сообщества пользователей может обеспечить высокое качество ПО. Но этот подход сам по себе представляет собой лишь правила лицензирования и методологию разработки. Он может привести как к хорошим, так и плохим результатам, как к надежному, так и ненадежному коду.
Подробнее см. здесь