Comments 57
Давно пора.
Отлично, интересно какие еще проекты получат поддержку
т.е. все таки модель opensource без дотаций не жизнеспособна? Вопрос без холивара.
Зависит от конкретного проекта.
Любой разработчик нуждается в финансировании, иначе ему просто не на что будет жить. А, как известно, мёртвый программист код не пишет. Тут больше вопрос какими путями идёт финансирование.
Любой разработчик нуждается в финансировании, иначе ему просто не на что будет жить. А, как известно, мёртвый программист код не пишет. Тут больше вопрос какими путями идёт финансирование.
Модель чего? Бизнеса — да. На openssl бизнеса не сделали. Разработки ПО — вполне жизнеспособна. Если бы openssl был нежинеспособен, про heartbleed никто не услышал бы.
Red Hat?
Не видел, чтобы RH зарабатывал деньги на donation. Я вообще знаю только один проект (увы, не opensource), который способен жить целиком на donation. Это dwarf fortress. Во всех остальных случаях модель всегда включает в себя что-то, чем «просто писать код».
Так вот именно, что донейта нет, а бизнес построен вокруг opensource.
>Я вообще знаю только один проект (увы, не opensource), который способен жить целиком на donation. Это dwarf fortress.
Еще вроде бы AdBlock: getadblock.com/ -> About Us
Но «только один» или «целых два» — разница небольшая :)
Еще вроде бы AdBlock: getadblock.com/ -> About Us
Но «только один» или «целых два» — разница небольшая :)
Это легко проверяется предельным случаем: когда человек занимается _только_ opensource-ом и не получает за это вознаграждения (деньгами либо едой), то он довольно быстро умирает с голоду и перестаёт заниматься opensource-ом.
Либо отпускает бороду и начинает грызть свои ноги :)
Ага, «В рот мне ноги, я, кажется, закончил эту либу!»
Шутки шутками, но opensource — это не вопрос затрат на разработку, а это именно вопрос лицензии на использование, на доступ к исходникам. Вы можете написать бесплатное ПО, но запретить его копировать без вашего разрешения, можете писать код за з/п (или на грант) от крупной и богатой корпорации, но раздавать полученное на условиях, скажем, GPL.
Другое дело, что компании часто не отдают оплаченное ими «в мир», и потому привычно считать «платно — значит не open sorce», но это неверно.
Без холивара, да — это уже я в сторону задавшего вопрос про «т.е. все таки модель opensource без дотаций не жизнеспособна?» Sserge )
Шутки шутками, но opensource — это не вопрос затрат на разработку, а это именно вопрос лицензии на использование, на доступ к исходникам. Вы можете написать бесплатное ПО, но запретить его копировать без вашего разрешения, можете писать код за з/п (или на грант) от крупной и богатой корпорации, но раздавать полученное на условиях, скажем, GPL.
Другое дело, что компании часто не отдают оплаченное ими «в мир», и потому привычно считать «платно — значит не open sorce», но это неверно.
Без холивара, да — это уже я в сторону задавшего вопрос про «т.е. все таки модель opensource без дотаций не жизнеспособна?» Sserge )
Сколько раз уже говорено-переговорено, Столлман не занимается опенсорсом.
Предложенная модель в полностью повторяет грантовую системы финансирования фундаментальной науки.
Это называется «пока жареный петух в задницу не клюнет — никто и не почешется».
Про них отлично на днях сказал Steve Marquess, президент OpenSSL Software Foundation:
Про них отлично на днях сказал Steve Marquess, президент OpenSSL Software Foundation:
«I’m looking at you, Fortune 1000 companies,» Marquess wrote. «The ones who include OpenSSL in your firewall/appliance/cloud/financial/security products that you sell for profit, and/or who use it to secure your internal infrastructure and communications. The ones who don’t have to fund an in-house team of programmers to wrangle crypto code, and who then nag us for free consulting services when you can’t figure out how to use it. The ones who have never lifted a finger to contribute to the open source community that gave you this gift. You know who you are.»Полный текст тут: veridicalsystems.com/blog/of-money-responsibility-and-pride/
Оффтоп немного. Думаю начальство практически и не знает какой бесплатный софт используется в копание, главное чтобы лицензия подходила. Перед покупкой платного софта обычно идет а стоит ли тратить столько $$$ на него.
Ваша, %habrauser%, компания когда вообще донейтила в OpenSource проект?
Ваша, %habrauser%, компания когда вообще донейтила в OpenSource проект?
Ну вот этот президент, на самом деле, перекладывает с больной головы на здоровую. Это лично его, как президента OpenSSL Software Foundation просёр, что они получали $2000 в год — не смог он обеспечить разработку продукта необходимыми ресурсами.
Возможно, имеет смысл не столько платить з/п разработчикам open source проектов (они сейчас их пишут не за деньги, и далеко не факт, что получив за эту работу стабильную з/п они начнут работать больше и/или лучше), сколько потратить их на оплату той деятельности, которой бесплатно занимаются неохотно: аудит кода, фикс багов, награды за обнаружение дыр. А з/п имеет смысл платить если разработчик хочет переключиться на full time работу над этими проектами — но в этом случае понадобится традиционный контроль за удалёнщиком.
Сопровождение и рефакторинг кода тоже не самая интересная работа.
Кстати, сама позиция очень сложная: «мы будем платить только за то, чем вы не хотите заниматься бесплатно». Это плохая позиция.
Правильная позиция: «вы хотите этим заниматься, и мы теперь будем вам за это платить, чтобы вы могли не отвлекаться».
Кстати, сама позиция очень сложная: «мы будем платить только за то, чем вы не хотите заниматься бесплатно». Это плохая позиция.
Правильная позиция: «вы хотите этим заниматься, и мы теперь будем вам за это платить, чтобы вы могли не отвлекаться».
Я имел в виду то, что если бы разработчикам OpenSSL платили з/п последние пару лет, то скорее всего это никак не повлияло бы на ситуацию с heartbleed. А вот если бы вместо этого платили за аудит, багфиксы и поиск дыр — качество кода проекта за те же два года значительно бы улучшилось и была бы вероятность найти и пофиксить этот баг значительно быстрее (а то и вообще не допустить его при качественном аудите кода перед принятием патча).
Конечно, я не имею ничего против того, чтобы платили и за обычную разработку — у меня у самого куча open source проектов. Но, объективно, денег обычно на всё не хватает, и приходится выбирать, на что их эффективнее потратить. Более того, имея з/п выдаваемую просто за работу над проектом приоритеты разработчиков вряд ли изменятся — как занимались тем, что по-интереснее, так и будут. А вот если денег давать за не самую интересную работу (либо платить и за то, и за другое, но за менее интересную работу платить значительно больше) — тогда пользы для проекта будет намного больше.
Конечно, я не имею ничего против того, чтобы платили и за обычную разработку — у меня у самого куча open source проектов. Но, объективно, денег обычно на всё не хватает, и приходится выбирать, на что их эффективнее потратить. Более того, имея з/п выдаваемую просто за работу над проектом приоритеты разработчиков вряд ли изменятся — как занимались тем, что по-интереснее, так и будут. А вот если денег давать за не самую интересную работу (либо платить и за то, и за другое, но за менее интересную работу платить значительно больше) — тогда пользы для проекта будет намного больше.
Аудит кода перед принятием патча.
Не бывает такого. В аудит перед релизом могу поверить. При принятии патча — noway. Оно не так выглядит.
Не бывает такого. В аудит перед релизом могу поверить. При принятии патча — noway. Оно не так выглядит.
Почему? Насколько я знаю, в ядре линуха это стандартная практика. И у нас в проектах временами практикуется. И в OpenSSL вроде бы тоже, хотя там это не помогло. Может проблема в термине — надо было использовать слово ревью вместо аудит?
Возможно мы разное понимаем под «аудитом». Если аудит — это code review — всегда пожалуйста. Но при этом нужные особые энтузиасты, которые будут пытаться узрить проблемы раз, и при этом не быть выкинутыми из комьюнити за занудность, два.
code review — это такая душеспасительная процедура, которая _иногда_ позволяет отлавливать фигню. Если в коммите не слишком много букв.
Если много — влетит только так. (не нашёл чья это шутка, что если заслать патч на 5 строчек, можно получить 5 замечаний, если заслать патч на 500 строчек, то скажут «ну, ок»).
code review — это такая душеспасительная процедура, которая _иногда_ позволяет отлавливать фигню. Если в коммите не слишком много букв.
Если много — влетит только так. (не нашёл чья это шутка, что если заслать патч на 5 строчек, можно получить 5 замечаний, если заслать патч на 500 строчек, то скажут «ну, ок»).
Но, чисто теоретически, так можно писать код с дырами, а потом получать за латание этих дыр деньги =)
> не меньше 100 000 долларов в год
Мда, 3,5 миллиона рублей в год для компаний уровня Майкрософта\Интела — огромные деньги, как от сердца оторвали.
Мда, 3,5 миллиона рублей в год для компаний уровня Майкрософта\Интела — огромные деньги, как от сердца оторвали.
Они и это не обязаны были тратить. Для многих здесь $100 небольшие деньги, но многие ли поддержат инициативу?
Не обязаны. Но внезапно оказалось, что зияющая дырка в софте, который мы бездумно и бесплатно использовали, обошлась нам очень сильно дороже, чем $100K в год.
dpkg -l|wc -l
2601
Это из установленного. Libssl в этом списке — только две строчки (libssl/libssl-dev).
2601
Это из установленного. Libssl в этом списке — только две строчки (libssl/libssl-dev).
Если эта команда выдана на системе, которая торчит наружу по https и хранит нетривиальные данные клиентов и SSL тухлый, то остальные 2599 строк значения не имеют.
Да ладно.
Люблю такой… эм… максимализм.
ldd /usr/sbin/nginx|awk '{print $1}'|xargs -n 1 dpkg -S|sort -u
(лениво дупликаты отлавливать)
Любая из этих библиотек может сделать из nginx'а «ssh для анонимов». А у меня на «первом попавшемся» сервере 23 открытых порта с десятком приложений (nginx, rpc.mountd, rpcbind, rpc.statd, sshd, named, pptpd, postfix, и это не трогая сервисы в ядре).
Заметим, это не особо нагруженный сервер, на котором пока ещё никакой динамики нет.
Любая компонента, которой касается сетевое приложение, может оказаться «неожиданно дырявой». Предсказать и предотвратить это невозможно. Некоторые распространённые случаи можно отловить, все — невозможно. Потому что «все» — это задача занятых бобров. Не решаемая в общем случае.
Люблю такой… эм… максимализм.
ldd /usr/sbin/nginx|awk '{print $1}'|xargs -n 1 dpkg -S|sort -u
libaudit1:amd64: /lib/x86_64-linux-gnu/libaudit.so.1 libaudit1:amd64: /lib/x86_64-linux-gnu/libaudit.so.1.0.0 libc6:amd64: /lib64/ld-linux-x86-64.so.2 libc6:amd64: /lib/x86_64-linux-gnu/libcrypt.so.1 libc6:amd64: /lib/x86_64-linux-gnu/libc.so.6 libc6:amd64: /lib/x86_64-linux-gnu/libdl.so.2 libc6:amd64: /lib/x86_64-linux-gnu/libm.so.6 libc6:amd64: /lib/x86_64-linux-gnu/libpthread.so.0 libexpat1:amd64: /lib/x86_64-linux-gnu/libexpat.so.1 libexpat1:amd64: /lib/x86_64-linux-gnu/libexpat.so.1.6.0 libfontconfig1:amd64: /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 libfontconfig1:amd64: /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.8.0 libfreetype6:amd64: /usr/lib/x86_64-linux-gnu/libfreetype.so.6 libfreetype6:amd64: /usr/lib/x86_64-linux-gnu/libfreetype.so.6.11.1 libgcrypt11:amd64: /lib/x86_64-linux-gnu/libgcrypt.so.11 libgcrypt11:amd64: /lib/x86_64-linux-gnu/libgcrypt.so.11.8.2 libgd3:amd64: /usr/lib/x86_64-linux-gnu/libgd.so.3 libgd3:amd64: /usr/lib/x86_64-linux-gnu/libgd.so.3.0.0 libgeoip1:amd64: /usr/lib/x86_64-linux-gnu/libGeoIP.so.1 libgeoip1:amd64: /usr/lib/x86_64-linux-gnu/libGeoIP.so.1.6.0 libgpg-error0:amd64: /lib/x86_64-linux-gnu/libgpg-error.so.0 libgpg-error0:amd64: /lib/x86_64-linux-gnu/libgpg-error.so.0.10.0 libjbig0:amd64: /usr/lib/x86_64-linux-gnu/libjbig.so.0 libjbig0:amd64: /usr/lib/x86_64-linux-gnu/libjbig.so.0.0.0 libjpeg8:amd64: /usr/lib/x86_64-linux-gnu/libjpeg.so.8 libjpeg8:amd64: /usr/lib/x86_64-linux-gnu/libjpeg.so.8.4.0 liblzma5:amd64: /lib/x86_64-linux-gnu/liblzma.so.5 liblzma5:amd64: /lib/x86_64-linux-gnu/liblzma.so.5.0.0 libpam0g:amd64: /lib/x86_64-linux-gnu/libpam.so.0 libpam0g:amd64: /lib/x86_64-linux-gnu/libpam.so.0.83.1 libpcre3:amd64: /lib/x86_64-linux-gnu/libpcre.so.3 libpcre3:amd64: /lib/x86_64-linux-gnu/libpcre.so.3.13.1 libpng12-0:amd64: /lib/x86_64-linux-gnu/libpng12.so.0 libpng12-0:amd64: /lib/x86_64-linux-gnu/libpng12.so.0.50.0 libpng12-0:amd64: /usr/lib/x86_64-linux-gnu/libpng12.so.0 libssl1.0.0:amd64: /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 libssl1.0.0:amd64: /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 libtiff5:amd64: /usr/lib/x86_64-linux-gnu/libtiff.so.5 libtiff5:amd64: /usr/lib/x86_64-linux-gnu/libtiff.so.5.2.0 libvpx1:amd64: /usr/lib/x86_64-linux-gnu/libvpx.so.1 libvpx1:amd64: /usr/lib/x86_64-linux-gnu/libvpx.so.1.3 libvpx1:amd64: /usr/lib/x86_64-linux-gnu/libvpx.so.1.3.0 libx11-6:amd64: /usr/lib/x86_64-linux-gnu/libX11.so.6 libx11-6:amd64: /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0 libxau6:amd64: /usr/lib/x86_64-linux-gnu/libXau.so.6 libxau6:amd64: /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 libxcb1:amd64: /usr/lib/x86_64-linux-gnu/libxcb.so.1 libxcb1:amd64: /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 libxdmcp6:amd64: /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 libxdmcp6:amd64: /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 libxml2:amd64: /usr/lib/x86_64-linux-gnu/libxml2.so.2 libxml2:amd64: /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.1 libxpm4:amd64: /usr/lib/x86_64-linux-gnu/libXpm.so.4 libxpm4:amd64: /usr/lib/x86_64-linux-gnu/libXpm.so.4.11.0 libxslt1.1:amd64: /usr/lib/x86_64-linux-gnu/libexslt.so.0 libxslt1.1:amd64: /usr/lib/x86_64-linux-gnu/libexslt.so.0.8.17 libxslt1.1:amd64: /usr/lib/x86_64-linux-gnu/libxslt.so.1 libxslt1.1:amd64: /usr/lib/x86_64-linux-gnu/libxslt.so.1.1.28 zlib1g:amd64: /lib/x86_64-linux-gnu/libz.so.1 zlib1g:amd64: /lib/x86_64-linux-gnu/libz.so.1.2.8
(лениво дупликаты отлавливать)
Любая из этих библиотек может сделать из nginx'а «ssh для анонимов». А у меня на «первом попавшемся» сервере 23 открытых порта с десятком приложений (nginx, rpc.mountd, rpcbind, rpc.statd, sshd, named, pptpd, postfix, и это не трогая сервисы в ядре).
Заметим, это не особо нагруженный сервер, на котором пока ещё никакой динамики нет.
Любая компонента, которой касается сетевое приложение, может оказаться «неожиданно дырявой». Предсказать и предотвратить это невозможно. Некоторые распространённые случаи можно отловить, все — невозможно. Потому что «все» — это задача занятых бобров. Не решаемая в общем случае.
Я бы наверно не дал, хотя мог бы выделить и больше. Я неоднократно donate'ил бесплатные проекты с закрытым исходным кодом, в opensource где мог — участвовал соавтором, ревьюверов, баг-репортером, контрибьютером. Вливание денег в такие проекты (за исключением обязательных расходов вроде хостинга) в моем понимании меняет идеологию процесса, построенного на авторитете и бескорыстности участников. IMHO.
Собственно, это очень грустно. Я только это хотел сказать.
На Хабре была статья, про дыры с использованием OpenSSL на сайтах крупнейших российских банков. Есть большое подозрение, что эти небедные банки не дадут даже 100$ на поддержку open source software. Т.ч. лучше что-то, чем ничего.
Для этих банков разница между $100 и $100000 в год фактически отсутствует, если рассматривать весь геморрой, связанный с получением согласований и оформлением передачи этих денег.
Представьте себя на месте человека, согласовывающего этот пункт бюджета у бизнеса, вообще не знающего, что такое OpenSSL и опенсорс. Как обоснуете трату? Благотворительность?
Представьте себя на месте человека, согласовывающего этот пункт бюджета у бизнеса, вообще не знающего, что такое OpenSSL и опенсорс. Как обоснуете трату? Благотворительность?
Я смотрю, слова «не меньше» никто так и не прочитал. Уверен, что те, кто покрупнее в этом списке — дадут больше.
разработчики ключевых проектов мировой компьютерной инфраструктуры фактически будут получать полноценную зарплату от фонда, чтобы иметь возможность на 100% сосредоточиться на их поддержке и развитии.
Собрались, значит, ведущие американские IT-работодатели, в которых трудятся сотни тысяч программистов и громко и торжественно согласились платить open-source разработчикам меньше одной зарплаты программиста в любой из этих компаний. Неоценимая помощь по переводу опенсорса на профессиональные рельсы!
На мой взгляд, по сравнению с ничем — да, «неоценимая».
Мне кажется, что даже если мыслить категориями бизнеса, а не высшей справедливости, это несколько… эээ… низкая минимальная граница. Как минимум потому, что потенциальные риски сильно превышают эти суммы, что Heartbleed и показал.
Впрочем, им, разумеется, виднее. Более того, я практически уверен, что фактические донейшены будут выше, а 100к — это своего рода SLA.
Просто громкие заявления от компаний такого масштаба, в которых фигурируют такие суммы лично мне кажутся несколько издевательскими — я сам работаю в Амазоне и имею некоторое представление, сколько и на что Амазон тратит.
Впрочем, им, разумеется, виднее. Более того, я практически уверен, что фактические донейшены будут выше, а 100к — это своего рода SLA.
Просто громкие заявления от компаний такого масштаба, в которых фигурируют такие суммы лично мне кажутся несколько издевательскими — я сам работаю в Амазоне и имею некоторое представление, сколько и на что Амазон тратит.
Да и тут явно прослеживается связь между использованием openSSL и участием в данном фонде. Это бизнес.
Apple — дороже всех компаний, которые участвуют в фонде, не дала ни цента, хотя использовала openSSL до 2011 года. Но теперь у них свой API и — «никто никому не должен».
Apple — дороже всех компаний, которые участвуют в фонде, не дала ни цента, хотя использовала openSSL до 2011 года. Но теперь у них свой API и — «никто никому не должен».
А каков регламент распиливания этих денег? Допустим, с расходами вроде хостинга более-менее ясно (те же репозитории пакетов, думаю, едят много денег на раздаче контента). Та же экспертиза независимых фирм — тут наверно будет тендер или что?
А остальное — что в виде зарплаты/бонусов? Не приведет ли это к гонке за некие синтетические показатели, что может очень сильно демотивировать действительно годные open-source кадры? Это что-то вроде ситуации, когда финансовые дела становятся поводом разрыва в прошлом крепких дружеских отношений.
А остальное — что в виде зарплаты/бонусов? Не приведет ли это к гонке за некие синтетические показатели, что может очень сильно демотивировать действительно годные open-source кадры? Это что-то вроде ситуации, когда финансовые дела становятся поводом разрыва в прошлом крепких дружеских отношений.
Странно что RedHat нет
Red Hat давно уже самостоятельно поддерживает «ПО, от которого зависит нормальное функционирование глобальной информационной инфраструктуры», безо всяких там инициатив Linux Foundation. Если точнее, то с 1999 года, когда они объединились с Cygnus Solutions. Мне кажется, что к Core Infrastructure Initiative они наверняка присоединятся, когда будет понятен эффект от этого — в последнее время в Red Hat очень осторожно относятся к шагам подобного рода, не знаю с чем это связанно.
RedHat с другой стороны.
«Церковь никогда не жертвует сама».
«Церковь никогда не жертвует сама».
Чего бы еще такого ломануть, чтобы его профинансировали?
Sign up to leave a comment.
Linux Foundation и крупнейшие IT-компании создают фонд для поддержки критически важного открытого ПО