Вороны на помойке

[vitus_wagner]

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

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

Недоеденные объедки еды выкидывают на помойку. Где этими объедками кормятся вороны.

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

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

А что людям невкусно - так это ж мелочи. Главное - вороны, они определяют судьбу.


К чему я это все? А именно так выглядит сегодня мир OpenSource. От разработчиков, которые что-то полезное делают и обмениваются этой пользой друг с другом постоянно требуют прогнуться под интересы "обычного пользователя". Волю которого толкуют специальные жрецы-авгуры.

Живьем того пользователя никто не видел, и почему именно его интересы должны быть приоритетны - непонятно. Он не приносит сообществу никакой пользы. Не пишет кода, не шлет багрепортов. Только подбирает то, что сделано другими. Благо операция копирования бесплатна.

Но талантливые демагоги-авгуры уже добились того, что для людей, то есть для существ наделенных речью, и способных выразить свои мысли (на языке, понятном компьютеру) open source среды стали крайне неудобны.

Comments

[vitus_wagner]

Конечно. Потому что у меня пользователь это user, то есть человек, которому работа с программой дана в непосредственных ощущениях. А у Циречного - customer, то есть тот, кто тем или иным способом мотивирует программиста продолжать разработку.

Мой пойнт заключается в том, что проргаммист - всегда тоже пользователь. И не имеет смысла участвововать в разработке open source проектов, которыми сам не пользуешься.

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

[http://users.livejournal.com/_arty/]

спасибо за пояснение, но ваша точка зрения достаточно хорошо ясна из текста поста

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

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

[vitus_wagner]

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

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

[http://users.livejournal.com/_arty/]

я вкладываю в слово «удобство» более широкий смысл, вплоть до расстановки кнопок в GUI и понимания собственно задач проекта. Такое хорошей архитектурой не исправить, но у каждого есть своё мнение об этом, и каждому хочется пользоваться тем, что удобно именно ему.

[vitus_wagner]

Э, какие-такие "задачи проекта"? Какого хрена ПОЛЬЗОВАТЕЛЮ знать "задачи проекта"? У пользователя есть свои задачи, которые он с помощью данной программы решает. И проект это сущность исключительно инструментальная, помогающая ему решать эти задачи.

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

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

А вот задачу расположения кнопок в GUI правильная архитектура должна решать. Поскольку должна позволять легко перелопатить GUI с трудозатратами на несколько порядков меньшими, чем написание основной фукнциональнсти.

[http://users.livejournal.com/_arty/]

я сейчас написал пространный ответ, но понял, что тема уходит куда-то в сторону. Возвращаясь к истокам: можно делать GUI настроек сети, понятный совсем тупому, а можно не делать, обойдясь очень удобным текстовым конфигом, но тогда зарабатывающая на совсем тупых компания не проспонсирует такой форк. Когда таких отличий от дистриба «для тупых» станет слишком много, подтягивать из него полезные изменения станет совсем трудно. Если же плюнуть и не брать из него эти изменения, есть риск через пять лет не найти железа, на котором запустится свой удобный, логичный и стройный дистриб.

[xarkonnen.livejournal.com]

Мой пойнт заключается в том, что проргаммист - всегда тоже пользователь. И не имеет смысла участвововать в разработке open source проектов, которыми сам не пользуешься.

тогда ряд приложений просто никогда не обретёт опенсорсную инкарнацию.

пример из моей профессиональной сферы: спуск полос. у простых приложений (например, плагин для Adobe Acrobat QI Plus, весит около полмегабайта) ценник стартует примерно с тысячи евро. более развесистые приложения (например, PrePS) в зависимости от могут стоить как автомобиль представительского класса. и это при том, что собственно алгоритм спуска полос весьма несложен по сравнению, скажем, с алгоритмом веб-сервера.

однако Apache есть, а вот опенсорсного аналога даже не препса, а хотя бы квайт импозинга нет..

[vitus_wagner]

Ну почему никогда? До тех пор пока кто-то из тех, кому нужно этой функциональность пользоваться, не соберется ее запрограммировать.

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

Написал же Кнут ТеХ. Ровно для того чтобы самому верстать в нем свои математические работы.

Хотя в данном случае, может быть и никогда. Просто бумажная публикация отомрет раньше. Ну и хрен бы с ней.

[permea-kra.livejournal.com]

Честно говоря, у меня создалось впечатление, что лучше бы не писал. Проект явно пережил своё время и отмирать не собирается - а зря.

[d4s.livejournal.com]

честно говоря, пройдя эволюцию от plain text до всяких WYSIWYG текстовых редакторов, сейчас жутко хочу перейти на tex.
пока задерживают только сотни страниц текстов, написанных во всяких опенофисах за последние лет 7 :(

[permea-kra.livejournal.com]

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


А замены адекватной нет и не предвидится. Не считаться же таковой xsl:fo