разработчик
0,0
рейтинг
24 апреля 2014 в 19:11

Разработка → Linux Foundation и крупнейшие IT-компании создают фонд для поддержки критически важного открытого ПО

Amazon, Facebook, Google, Intel, Microsoft, Cisco, Dell, IBM, Fujitsu, NetApp, VMware Qualcomm и RackSpace стали сооснователями и первыми участниками созданного под эгидой Linux Foundation фонда Core Infrastructure Initiative, задача которого — поддерживать разработку ПО, от которого зависит нормальное функционирование глобальной информационной инфраструктуры. Создание такого фонда — ответ на обнаружение катастрофического бага Heartbleed в OpenSSL, которое поставило под угрозу безопасность всего интернета. Именно проект OpenSSL первым получит поддержку фонда.



Фонд уже собрал первые 3,9 миллиона долларов. Компании-сооснователи фонда пообещали вкладывать в него не меньше 100 000 долларов в год на протяжении ближайших трёх лет. Участвовать в пополнении фонда может любой желающий. Совет фонда, в который войдут представители компаний-участников и сообщества программистов, будет определять, каким проектам прежде всего необходима финансовая поддержка.

Исполнительный директор Linux Foundation Джим Землин сказал, что разработчики ключевых проектов мировой компьютерной инфраструктуры фактически будут получать полноценную зарплату от фонда, чтобы иметь возможность на 100% сосредоточиться на их поддержке и развитии. Нельзя допускать ситуацию, когда разработчики технологий, на которых буквально держится весь интернет, вынуждены работать над ними в свободное время, а пожертвования носят скорее символический характер — так, проект OpenSSL получал в среднем около 2000 долларов в год.
Среди проектов, которые могут получить финансирование фонда, Землин назвал Mod_SSL, Open Crypto Audit и GPG.

Илья Сименко @ilya42
карма
526,7
рейтинг 0,0
разработчик
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (57)

  • +15
    Давно пора.
  • 0
    Отлично, интересно какие еще проекты получат поддержку
  • +4
    т.е. все таки модель opensource без дотаций не жизнеспособна? Вопрос без холивара.
    • +5
      Зависит от конкретного проекта.
      Любой разработчик нуждается в финансировании, иначе ему просто не на что будет жить. А, как известно, мёртвый программист код не пишет. Тут больше вопрос какими путями идёт финансирование.
    • +5
      Модель чего? Бизнеса — да. На openssl бизнеса не сделали. Разработки ПО — вполне жизнеспособна. Если бы openssl был нежинеспособен, про heartbleed никто не услышал бы.
      • 0
        Red Hat?
        • +3
          Не видел, чтобы RH зарабатывал деньги на donation. Я вообще знаю только один проект (увы, не opensource), который способен жить целиком на donation. Это dwarf fortress. Во всех остальных случаях модель всегда включает в себя что-то, чем «просто писать код».
          • 0
            Так вот именно, что донейта нет, а бизнес построен вокруг opensource.
          • 0
            >Я вообще знаю только один проект (увы, не opensource), который способен жить целиком на donation. Это dwarf fortress.

            Еще вроде бы AdBlock: getadblock.com/ -> About Us

            Но «только один» или «целых два» — разница небольшая :)
            • 0
              А как же «особо привилегированный список рекламы», за который доплачивают adblock'овцам?
              • 0
                Так то Adblock Plus. Другой продукт. Этот — это хромовый плагин.

                Ну и у Adblock Plus реклама не привилегированная, а «ненавязчивая».
                • 0
                  Ага, тогда следующий вопрос. Команда адблока целиком живёт на донейшен и это их единственный источник средств к существованию @
    • +6
      Это легко проверяется предельным случаем: когда человек занимается _только_ opensource-ом и не получает за это вознаграждения (деньгами либо едой), то он довольно быстро умирает с голоду и перестаёт заниматься opensource-ом.
      • –1
        Либо отпускает бороду и начинает грызть свои ноги :)
        • +2
          Ага, «В рот мне ноги, я, кажется, закончил эту либу!»

          Шутки шутками, но opensource — это не вопрос затрат на разработку, а это именно вопрос лицензии на использование, на доступ к исходникам. Вы можете написать бесплатное ПО, но запретить его копировать без вашего разрешения, можете писать код за з/п (или на грант) от крупной и богатой корпорации, но раздавать полученное на условиях, скажем, GPL.

          Другое дело, что компании часто не отдают оплаченное ими «в мир», и потому привычно считать «платно — значит не open sorce», но это неверно.

          Без холивара, да — это уже я в сторону задавшего вопрос про «т.е. все таки модель opensource без дотаций не жизнеспособна?» Sserge )
          • –4
            Не, насчет ног — это был намек на Столлмана :)
        • 0
          Сколько раз уже говорено-переговорено, Столлман не занимается опенсорсом.
          • +1
            Он занимается строгим подмножеством опенсорса.
          • 0
            Лучше бы я этого не читал…
            Сделайте мне развидеть это
            image
    • +3
      Предложенная модель в полностью повторяет грантовую системы финансирования фундаментальной науки.
  • +15
    Это называется «пока жареный петух в задницу не клюнет — никто и не почешется».

    Про них отлично на днях сказал 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/
    • +5
      Оффтоп немного. Думаю начальство практически и не знает какой бесплатный софт используется в копание, главное чтобы лицензия подходила. Перед покупкой платного софта обычно идет а стоит ли тратить столько $$$ на него.

      Ваша, %habrauser%, компания когда вообще донейтила в OpenSource проект?
    • –3
      Ну вот этот президент, на самом деле, перекладывает с больной головы на здоровую. Это лично его, как президента OpenSSL Software Foundation просёр, что они получали $2000 в год — не смог он обеспечить разработку продукта необходимыми ресурсами.
  • –3
    Возможно, имеет смысл не столько платить з/п разработчикам open source проектов (они сейчас их пишут не за деньги, и далеко не факт, что получив за эту работу стабильную з/п они начнут работать больше и/или лучше), сколько потратить их на оплату той деятельности, которой бесплатно занимаются неохотно: аудит кода, фикс багов, награды за обнаружение дыр. А з/п имеет смысл платить если разработчик хочет переключиться на full time работу над этими проектами — но в этом случае понадобится традиционный контроль за удалёнщиком.
    • +9
      Сопровождение и рефакторинг кода тоже не самая интересная работа.

      Кстати, сама позиция очень сложная: «мы будем платить только за то, чем вы не хотите заниматься бесплатно». Это плохая позиция.

      Правильная позиция: «вы хотите этим заниматься, и мы теперь будем вам за это платить, чтобы вы могли не отвлекаться».
      • 0
        Я имел в виду то, что если бы разработчикам OpenSSL платили з/п последние пару лет, то скорее всего это никак не повлияло бы на ситуацию с heartbleed. А вот если бы вместо этого платили за аудит, багфиксы и поиск дыр — качество кода проекта за те же два года значительно бы улучшилось и была бы вероятность найти и пофиксить этот баг значительно быстрее (а то и вообще не допустить его при качественном аудите кода перед принятием патча).

        Конечно, я не имею ничего против того, чтобы платили и за обычную разработку — у меня у самого куча open source проектов. Но, объективно, денег обычно на всё не хватает, и приходится выбирать, на что их эффективнее потратить. Более того, имея з/п выдаваемую просто за работу над проектом приоритеты разработчиков вряд ли изменятся — как занимались тем, что по-интереснее, так и будут. А вот если денег давать за не самую интересную работу (либо платить и за то, и за другое, но за менее интересную работу платить значительно больше) — тогда пользы для проекта будет намного больше.
        • 0
          Аудит кода перед принятием патча.

          Не бывает такого. В аудит перед релизом могу поверить. При принятии патча — noway. Оно не так выглядит.
          • 0
            Почему? Насколько я знаю, в ядре линуха это стандартная практика. И у нас в проектах временами практикуется. И в OpenSSL вроде бы тоже, хотя там это не помогло. Может проблема в термине — надо было использовать слово ревью вместо аудит?
            • +4
              Возможно мы разное понимаем под «аудитом». Если аудит — это code review — всегда пожалуйста. Но при этом нужные особые энтузиасты, которые будут пытаться узрить проблемы раз, и при этом не быть выкинутыми из комьюнити за занудность, два.

              code review — это такая душеспасительная процедура, которая _иногда_ позволяет отлавливать фигню. Если в коммите не слишком много букв.

              Если много — влетит только так. (не нашёл чья это шутка, что если заслать патч на 5 строчек, можно получить 5 замечаний, если заслать патч на 500 строчек, то скажут «ну, ок»).
        • +1
          Но, чисто теоретически, так можно писать код с дырами, а потом получать за латание этих дыр деньги =)
          • 0
            Не особо. Пару раз прокатит, но на поток этот процесс не поставишь — по именам того, кто закоммитил баг, и тех, кто будет пытаться заработать на фиксах это быстро отследят.
            • 0
              Идеальный код невозможен. Баги будут всегда независимо от желания и старательности разработчиков.
  • +3
    > не меньше 100 000 долларов в год
    Мда, 3,5 миллиона рублей в год для компаний уровня Майкрософта\Интела — огромные деньги, как от сердца оторвали.
    • +3
      Они и это не обязаны были тратить. Для многих здесь $100 небольшие деньги, но многие ли поддержат инициативу?
      • –1
        Не обязаны. Но внезапно оказалось, что зияющая дырка в софте, который мы бездумно и бесплатно использовали, обошлась нам очень сильно дороже, чем $100K в год.
        • +2
          dpkg -l|wc -l
          2601

          Это из установленного. Libssl в этом списке — только две строчки (libssl/libssl-dev).
          • +1
            Если эта команда выдана на системе, которая торчит наружу по https и хранит нетривиальные данные клиентов и SSL тухлый, то остальные 2599 строк значения не имеют.
            • +3
              Да ладно.

              Люблю такой… эм… максимализм.

              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, и это не трогая сервисы в ядре).

              Заметим, это не особо нагруженный сервер, на котором пока ещё никакой динамики нет.

              Любая компонента, которой касается сетевое приложение, может оказаться «неожиданно дырявой». Предсказать и предотвратить это невозможно. Некоторые распространённые случаи можно отловить, все — невозможно. Потому что «все» — это задача занятых бобров. Не решаемая в общем случае.
      • 0
        Я бы наверно не дал, хотя мог бы выделить и больше. Я неоднократно donate'ил бесплатные проекты с закрытым исходным кодом, в opensource где мог — участвовал соавтором, ревьюверов, баг-репортером, контрибьютером. Вливание денег в такие проекты (за исключением обязательных расходов вроде хостинга) в моем понимании меняет идеологию процесса, построенного на авторитете и бескорыстности участников. IMHO.
      • 0
        Собственно, это очень грустно. Я только это хотел сказать.
    • +3
      На Хабре была статья, про дыры с использованием OpenSSL на сайтах крупнейших российских банков. Есть большое подозрение, что эти небедные банки не дадут даже 100$ на поддержку open source software. Т.ч. лучше что-то, чем ничего.
      • +1
        Для этих банков разница между $100 и $100000 в год фактически отсутствует, если рассматривать весь геморрой, связанный с получением согласований и оформлением передачи этих денег.

        Представьте себя на месте человека, согласовывающего этот пункт бюджета у бизнеса, вообще не знающего, что такое OpenSSL и опенсорс. Как обоснуете трату? Благотворительность?
    • 0
      Я смотрю, слова «не меньше» никто так и не прочитал. Уверен, что те, кто покрупнее в этом списке — дадут больше.
  • –2
    разработчики ключевых проектов мировой компьютерной инфраструктуры фактически будут получать полноценную зарплату от фонда, чтобы иметь возможность на 100% сосредоточиться на их поддержке и развитии.


    Собрались, значит, ведущие американские IT-работодатели, в которых трудятся сотни тысяч программистов и громко и торжественно согласились платить open-source разработчикам меньше одной зарплаты программиста в любой из этих компаний. Неоценимая помощь по переводу опенсорса на профессиональные рельсы!
    • +5
      На мой взгляд, по сравнению с ничем — да, «неоценимая».
      • 0
        Мне кажется, что даже если мыслить категориями бизнеса, а не высшей справедливости, это несколько… эээ… низкая минимальная граница. Как минимум потому, что потенциальные риски сильно превышают эти суммы, что Heartbleed и показал.

        Впрочем, им, разумеется, виднее. Более того, я практически уверен, что фактические донейшены будут выше, а 100к — это своего рода SLA.
        Просто громкие заявления от компаний такого масштаба, в которых фигурируют такие суммы лично мне кажутся несколько издевательскими — я сам работаю в Амазоне и имею некоторое представление, сколько и на что Амазон тратит.
    • +4
      Да и тут явно прослеживается связь между использованием openSSL и участием в данном фонде. Это бизнес.

      Apple — дороже всех компаний, которые участвуют в фонде, не дала ни цента, хотя использовала openSSL до 2011 года. Но теперь у них свой API и — «никто никому не должен».
  • 0
    А каков регламент распиливания этих денег? Допустим, с расходами вроде хостинга более-менее ясно (те же репозитории пакетов, думаю, едят много денег на раздаче контента). Та же экспертиза независимых фирм — тут наверно будет тендер или что?
    А остальное — что в виде зарплаты/бонусов? Не приведет ли это к гонке за некие синтетические показатели, что может очень сильно демотивировать действительно годные open-source кадры? Это что-то вроде ситуации, когда финансовые дела становятся поводом разрыва в прошлом крепких дружеских отношений.
  • 0
    Странно что RedHat нет
    • 0
      Red Hat давно уже самостоятельно поддерживает «ПО, от которого зависит нормальное функционирование глобальной информационной инфраструктуры», безо всяких там инициатив Linux Foundation. Если точнее, то с 1999 года, когда они объединились с Cygnus Solutions. Мне кажется, что к Core Infrastructure Initiative они наверняка присоединятся, когда будет понятен эффект от этого — в последнее время в Red Hat очень осторожно относятся к шагам подобного рода, не знаю с чем это связанно.
    • +1
      RedHat с другой стороны.

      «Церковь никогда не жертвует сама».
  • 0
    Чего бы еще такого ломануть, чтобы его профинансировали?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.