Я никогда не был слишком сосредоточен на деталях проекта с открытым исходным кодом и лицензированием, несмотря на то, что работал вокруг коллег, которые очень обеспокоены этими проблемами. Поэтому, хотя я был заинтригован внезапной ссорой в сообществе Руби, этот пост не станет историей рубиновых драгоценных камней, изучением мотивации Руби -Сентрала или личной политики Дэвида Хейнемера Ханссона (DHH). Вы можете прочитать все «он сказала, сказала она» в нашем анализе или из недавней статьи в 404 СМИ. Этот пост о Как разработчик должен подходить к любому риску в программном обеспечении и как он выглядит.
Я отмечу, что инфраструктурная служба Ruby Central, возможно, стала слишком важной для Shopify, основного спонсора и спонсора, чтобы продолжать доверять творческому сообществу с открытым исходным кодом.
Я также добавлю, что лично я использую как Ruby, так и Rails. Я зависел от них на платных концертах и использовал Бундлер, чтобы разобраться в своих драгоценных камнях и драгоценных камнях команды. На самом деле, я был в некоторых разговорах с открытым исходным кодом, касающимися Руби — в будущем Ruby Shoes, чей, который, как известно, исчез. Я также был на другой стороне комнаты, когда Oracle взял на себя солнечные микросистемы, а разработчики обнаружили, к своему ужасу, что Ларри Эллисон владел Java.
Парадокс успешного программного обеспечения с открытым исходным кодом
Сообщество разработчиков с открытым исходным кодом сделало возможной индустрию программного обеспечения, но, по иронии судьбы, некоторые из этих языков, систем и инструментов стали настолько финансово ценными, что они стали подвергаться большему контролю и давлению — и необходимы ресурсы, чтобы противостоять угрозам.
Модель с открытым исходным кодом работает, потому что после того, как проблема понята и решена, это решение может быть использовано в библиотеке или упаковке в качестве постоянного понимания. Но это только начало вещей. Пакет должен храниться, обновлен и обслуживаться. Когда они обновляются, кто -то также должен понять, какие версии пакетов все еще работают друг с другом.
Мы склонны думать о программном обеспечении с открытым исходным кодом, которое мы используем, как было передано с более высокого места и поддерживаемого FIAT. Конечно, их обычно поддерживают добровольцы, которые слишком рады принять какое-то необходимое финансирование. Между тем, работающие разработчики наивно предполагают, что личности, эго и деньги не играют никакой роли в своих любимых языках и инструментах.
Понимание фидуциарной обязанности и доверия к программному обеспечению
Одним из симптомов сложного общества является то, что формальный и неформальный могут существовать вместе. Если я куплю фрукты на уличном рынке, и это заставляет меня болен, это, казалось бы, я ничего не могу сделать. Но на самом деле, вы можете прибегнуть к местному офису здравоохранения окружающей среды, и на рынке, вероятно, есть менеджер. То, что я получаю, так это то, что, даже если вы не согласились с контрактом, все еще есть юридические ожидания. За всем этим потоки и вихри доверия, которые в основе абсолютно всех форм торговли. Рынкам нужно доверие потребителей и поставщиков. Городам нужно доверие рынков.
Программное обеспечение с открытым исходным кодом похоже на лоскутное одеяло — все встроено в сообщество, и это основа нашего доверия. Но края неровно.
Когда компания владеет программным обеспечением, корпоративное право и ответственность делают права потребителя довольно простыми. Хотя такие корпорации, как Microsoft, в значительной степени безличны, они жестко удерживаются в соответствии с законом, и мы можем доверять этому в определенной степени. Программное обеспечение с открытым исходным кодом больше похоже на лоскутное одеяло. Все встроено в сообщество, и это основа нашего доверия. Но края неровно.
Оценка современных рисков цепочки поставок программного обеспечения
Рубин Централ обвинил атаки цепочки поставок за их необходимость внезапного контроля. Сегодня риски цепочки поставок очень реальны. Прежде чем думать об этом, просто рассмотрим проблему краудстика. Одно плохое обновление помогло разбить более 8 миллионов систем и привело к огромным финансовым потерям для аэропортов. Это не было результатом кибератаки или какой -либо формы организованного нарушения. Тем не менее, Delta Air Lines подала иск на 500 миллионов долларов против Crowdstrike, утверждая валовую халатность и обманчивую практику бизнеса. Delta утверждала, что Crowdstrike развернул непроверенные обновления программного обеспечения.
Сегодня поставщик автомобилей Jaguar Land Rover борется с кибератакой. Это на самом деле угрожает здоровью сторонних поставщиков, у которых нет альтернативных покупателей для их деталей. На более знакомым уровне я говорил о атаке VSX пару месяцев назад.
Просто не нужно добавлять окончательный фактор, вмешательство в государство противника, чтобы увидеть проблемы.
Как разработчики могут смягчить технологические риски
Так что же должен делать разработчик? Первое, что не посвятить себя «рельсам». Будьте разработчиком, у которого есть твердое понимание модели MVC, поддерживаемой практическим опытом рельсов и, возможно, общественной деятельностью. Не удерживайте свой энтузиазм выше того, что нужно вашему клиенту или работодателю. Если вам нравится самоуверенный характер рельсов, поощряйте его в другом месте. Тебе нравится Руби? Кто нет! Но будьте готовы использовать Python с Django вместо рельсов. Хотя действия DHH могут иметь отношение к тому, как вы себя чувствуете, вы обнаружите, что такие проекты, как Rails, имеют много лидеров.
Тебе нравится Руби? Кто нет! Но будьте готовы использовать Python с Django вместо рельсов.
Цените все риски во всей вашей цепочке рабочих процессов. Изначально это звучит как академическая работа или что -то в этом роде для управления. Если вы подходите к старшему уровню, это в значительной степени ваша работа. Ваш менеджер будет отложить вам, если вы доказали, что вы Grok как цели компании и то, как можно улучшить развитие. Если вы просто думаете, что «ржавчина круто», это не обрежет ее. Ваша цепочка означает буквально все, что идет на создание продукта. А «риск» означает любые изменения (от цен до контроля компаний), которые повлияют на продукт.
Построить карьеру на концепциях, а не конкретных инструментах
Самый простой профессиональный способ практически справиться с риском-это знать, как заменить все в вашей цепочке, а также то, что готовит проекты, управляемые сообществом и почему. Если вы работаете с корпоративными продуктами, где компания является конкурентом сверстников, это риск; Если вы работаете с общественными продуктами, которые не прозрачны, это также риск. Развивайте любопытство к тому, что заставляет компании принимать плохие решения. И будьте честны со своей собственной записью; Вы доверяли людям в отрасли, которые позже подвели вас?
Каждое действие с целью имеет хотя бы одну оценку риска. Мы все отправились в магазин, который может быть закрыт, и разработали, каковы альтернативы. Но мы все используем доверие, чтобы принять окончательное решение о вероятных результатах.
Не попадайте в один язык программирования — попадайте в его цели. Скорость, параллелизм, диапазон и т. Д.
Так что не попадайте в один язык программирования — попадайте в его цели — скорость, параллелизм, диапазон и т. Д. Затем ценят, как язык достигает этих целей. Мне нравится C#. Мне нравится, как это улучшается на Java. Я ценю это, потому что Microsoft поддержала его, она стабильна. Но что, если они попадут в ржавчину? Посмотрев на ржавчину, возможно, я смогу смягчить риск, устраняя сомнения в своем уме — или понимая, что могут увидеть некоторые разработчики Microsoft.
Быть членом сообщества, а не просто потребителем
Как мы знаем, программное обеспечение может быть поддержано крупными компаниями или сообществами с открытым исходным кодом. По этой причине разработчики должны понимать, действуют ли они в качестве потребителей или членов сообщества.
Если ваши отношения с программным обеспечением являются потребителем, у вас есть права и ожидания. Есть твердое здание, в которое вы можете бросить яйца. Вы можете жаловаться на социальные сети. В конечном счете, акционеры боятся вас.
Если ваши отношения в том, что вы используете открытый исходный код, вы являетесь частью сообщества. Начните впрыскивать свой путь. Так вас будут увидеть ваши сверстники и в конечном итоге оценены как разработчик. Причина, по которой программное обеспечение до сих пор имеет сообщества с открытым исходным кодом, заключается в том, что разработчик является частичным ремесленником, отчасти энтузиаз, частично садовника.
Но в конечном итоге речь идет о развитии доверительных отношений, которые находятся под поверхностным маркетингом или личностями. Потратьте время, чтобы понять окружающую среду. Если вы создаете вещи с помощью программного обеспечения, вы не пассивный призрак.
Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Дэвид был лондонским профессиональным разработчиком программного обеспечения в Oracle Corp. и British Telecom, а также консультантом, помогающим командам работать более гибким образом. Он написал книгу по дизайну пользовательского интерфейса и с тех пор пишет технические статьи …. Подробнее от Дэвида Истмана
