Как объяснить, что написание универсального кроссплатформенного кода C ++ и поставки продуктов для всех ОС не так просто?

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

• мы жадная корпорация
• все наши технические специалисты недооцененные идиоты

Наш средний продукт - что-то вроде 3 миллионов строк кода на C ++.

Мой и мои коллеги анализ следующие:

• написание кроссплатформенного кода на C ++ не так просто
• подготовка большого количества дистрибутивных пакетов и их поддержка для всех распространенных версий Linux требует времени
• По нашим оценкам, рынок Linux составляет около 5-15% всех пользователей, и эти пользователи, вероятно, не захотят платить за наши усилия.

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

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

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

Вы правы, конечно, сделать программное обеспечение для x-платформы такого масштаба - непростая вещь. Особенно, если вы не являетесь компанией, в которой работают десятки разработчиков и миллионы пользователей. И это не просто технические ограничения. Это все о стоимости против выгоды. Да, вы могли бы потратить в следующем году на перенос приложения в Linux (несмотря на то, что, как вы заметили, оно уже работает в WINE). Конечно, этот год разработки не приходит бесплатно. И в конце концов, будет чистая вам , возможно ,дополнительные 5-15% пользователей (по вашей оценке). Или вы можете взять те же деньги / усилия и сосредоточить их на разработке Windows, как на новой версии, или потратить на маркетинг и добавить 50% к своей базе пользователей. Что звучит как разумный выбор? (очевидно, цифры должны быть адаптированы к вашей компании, и конечный результат может быть предпочтительным для портирования).

Я не знаю, поможет ли это убедить «истинных верующих», но это умный бизнес. И если вы не делаете умные деловые шаги, вы вне бизнеса. И тогда точно не будет версии для Linux.

Я думаю, что здесь есть две вещи:

Во-первых, в каком-то смысле они правы. Написание кроссплатформенного C ++ не так сложно, если вы планировали это с самого начала . Это почти наверняка проблема, которую вы видите. Большинство приложений с открытым исходным кодом (большинство приложений, которыми пользователь Linux пользуется в среднем за день), абсурдно кроссплатформенны. Подумайте о количестве приложений, с которыми ежедневно сталкивается средний пользователь Linux, написанных на C или C ++ и работающих не только в Windows и Linux, но также в MacOS, BSD, Solaris и т. Д. На x86, x86-64, ARM, SPARC, и т. д. Это отчасти потому, что люди, которые жаждут портировать код для запуска в своих системах, а также потому, что в таком случае принято планировать кросс-платформенную переносимость.

Во-вторых, рынок может быть более жизнеспособным, чем вы думаете. Существует огромное заблуждение, что люди в Linux не хотят платить за программное обеспечение. Для некоторых людей это может быть правдой, но есть много людей (большинство, я думаю), которые используют Linux, потому что он работает лучше для них, и они предпочитают его, а не из-за цены. Кроме того, если ваша компания производит продукт, который используется в основном в профессиональной среде, компании хорошо привыкли платить за программное обеспечение для работы в системах Linux.

Что касается того, что вы говорите об упаковке, как уже говорили другие, вам действительно нужно просто создать пакеты для последней версии основных дистрибутивов. На самом деле создание пакетов не так уж сложно, и большинство основных дистрибутивов используют либо пакеты Debian (Debian, Ubuntu и т. Д.), Либо RPM (Fedora, Suse, Centos, Mandrake), поэтому очень незначительно изменить некоторые скрипты чтобы создать несколько пакетов из базового .deb и базового .rpm, а для всех остальных просто создать архив с двоичными файлами и файлом readme, люди поймут, как его установить. В качестве альтернативы, вы можете пропустить всю упаковку и просто опубликовать один архив с bash или perl-скриптом, чтобы выполнить установку.

Что касается того, как обращаться к пользователям на ваших форумах, жалующихся, как сказал Джо Интернет, они могут быть просто процентом людей, которые собираются жаловаться, несмотря ни на что, но в первую очередь я постараюсь объяснить, что у вас есть большое количество устаревшего кода, который не был разработан с учетом кроссплатформенной поддержки. Во-вторых, честно посмотрите, получит ли финансовая поддержка создание Linux-порта, и откройте для себя результаты этого. Наконец, если порт финансово неосуществим, посмотрите, что нужно сделать, чтобы программа хорошо работала с WINE. WINE не должно быть первым решением, но оно может успокоить людей, которые просто хотят использовать ваше приложение в Linux, и быть менее дорогим проектом, чем полный порт. Фактически, если вы добавите код в кодовую базу WINE в рамках проекта, вы не только сможете открыть себя для нового рынка,

Adobe, это ты?

А если серьезно, выставьте какую-то награду, чтобы они могли предзаказать версии Linux. Если вы получаете достаточно заказов, чтобы сделать порт достойным, вложите его вовремя, в противном случае верните их, и у вас теперь есть доказательства, что недостаточно людей заботятся о том, чтобы это стоило.

Если вы что-то портируете, просто нацельтесь на последний выпуск Ubuntu LTS, RHEL, SLED и, возможно, предоставьте tar.gz, чтобы люди могли попытаться начать работать, если они хотят использовать что-то другое. Это оставляет вам 3 пакета для беспокойства, и любой другой, вероятно, знает достаточно, чтобы запустить версию tar.gz.

написание кроссплатформенного кода на C ++ не так просто

Наоборот. Когда вы планируете кросс-платформенную работу и предоставляете абстракции для используемых вами платформо-зависимых API, подавляющее большинство вашего кода уже кроссплатформенное. Если вы уже используете популярную библиотеку, такую ​​как Boost, Qt или NSPR, вы уже очень близки к работе кроссплатформенной сборки.

Проблема, наиболее часто возникающая при выполнении порта в конце цикла разработки, заключается в том, что в некоторых частях кода есть значительная часть кода, использующего API-интерфейсы для конкретной платформы, которые не нуждаются в их прямом использовании и, вероятно, вообще не должны. (Хороший дизайн будет иметь сильно отделенные модули, и группы классов могут быть заменены переписанными заменами по желанию. Если это не так для данного модуля, это сильный запах кода.)

Самый простой выход - просто написать класс «Утилиты» и выбросить туда все свои специфичные для платформы вещи. Это не «легко и безболезненно», но, конечно, не так сложно, как вы думаете.

подготовка большого количества дистрибутивных пакетов и их поддержка для всех распространенных версий Linux требует времени

Это неудачное заблуждение. Хотя это правда, что поддержание сборок для нескольких платформ требует дополнительных усилий (при настройке выделенного ежедневного сервера сборки и обучении пакетированию для конкретного дистрибутива), но это неправда, что вам нужно поддерживать их для «большого количества дистрибутивов [s». ] «. Наоборот. Вам нужно лишь поддерживать небольшое количество пакетов - скажем, Ubuntu, Fedora и один LSB-совместимый tarball - и остальные сообщества Linux займутся остальной работой. Особенно, если ваше программное обеспечение популярно, HOWTO будут появляться для каждого дистрибутива, предоставляя необходимые инструкции по установке. Или, если ваше программное обеспечение может свободно распространяться (что вы можете сделать, даже если это не бесплатный продуктПри условии, что ваша лицензия позволяет это), более популярные дистрибутивы будут иметь какой-то альтернативный репозиторий, содержащий копии вашего программного обеспечения.

Сообщества, как правило, очень хороши в этом, и опытные пользователи охотно сделают для вас большую часть этой работы, если вы позволите им.

По нашим оценкам, рынок Linux составляет около 5-15% всех пользователей, и эти пользователи, вероятно, не захотят платить за наши усилия.

Еще одно неудачное и очень ошибочное заблуждение.

То, что пользователи Linux получают свою операционную систему бесплатно, не означает, что они не хотят платить за программное обеспечение. Если программное обеспечение очень хорошее и пользуется большим спросом, пользователи Linux часто будут более охотно расставаться со своими деньгами, чем пользователи Windows. Достаточно взглянуть на Humble Indie Bundles , где пользователи Linux в среднем платили более чем вдвое больше, чем пользователи Windows.

Также возможно, что ваш продукт будет иметь больший спрос среди пользователей Linux, чем на других платформах (которые мы не можем знать, не зная о вашем продукте), в зависимости от того, какие виды программного обеспечения существуют на этой арене. У вас может быть больший потенциальный рынок, чем вы думаете.

С таким отношением я бы просто проигнорировал их. Они звучат как сегмент X, где X может быть чем угодно , что будет жаловаться независимо от того, что вы делаете. Выпускать версию для Linux или нет, это ваш выбор, а не их.

Если вы работаете на Nvidia ...

Ради любви к Богу, смирись и напиши уже несколько приличных водителей.

В противном случае, если вы работаете с обычными бизнес-приложениями, ориентируйте будущие проекты на C #.

Mono полностью совместим с .NET 3.5 и может даже использовать графический интерфейс winforms. Единственные модули, на которые нужно обратить внимание - это специфичные для ОС, но они немногочисленны.