в худмаге поблизости нету, в метизах например, тоже не помню чтобы был… в питере нашел только гельветику, но до нее добраться еще нужно, да и черт его знает — работают ли они с физиками?..
в худмаге поблизости нету, в метизах например, тоже не помню чтобы был… в питере нашел только гельветику, но до нее добраться еще нужно, да и черт его знает — работают ли они с физиками?..
Но с другой стороны разработка ПО все-таки не написание статей на хабре — фрилансеры-разработчики живут на заказных проектах, а вот писателей-фрилансеров как-то не очень много.
Подобный сервис должен получится где-то между githab'ом и биржей фрилансеров — проекты с багтрекерами как на githab'е и трудовые резервы со страждущими спонсорами как на бирже. Все-таки мне кажется несколько другое измеренение получается.
Но удивила меня публика на хабре :)) Сам я не блещю талантами писательства, но и отношение к, пусть мезерному, но заработку, меня все-таки очень удивили :)
Мдаааа… Такой реакции не ожидал… Т.е. сервис в принципе бесплатный — то хобби, а если есть возможность получать с него деньги — работа…
Очень интересное исследование по психологии получилось с очень неожиданным (для меня) и, откровенно говоря, весьма негативным результатом…
Почему это? Просто такие фичи не будут пользоватся популярностью у классических фрилансеров. Зато будут пользоватся популярностью у начинающих (для набирания опыта, репутации, авторитета :) ) и у тех, кому просто интересно.
Выборы… Это да, вопрос очень интересный…
Я как раз думаю про минимальные рамки, только лишь те, которые обеспечат взаимодействие разработчиков и пользователей. Чем может принципиально отличатся процесс разработки десктоп-программы от программы для компании?
Делать — да, но приниматся за работу без плана работы… Семь раз отмерь, один отрежь :)
Мне кажется что искать баланс между «быстро» и «качественно» должен тимлид, куратор проекта (вопрос только — а нормально ли будет если кураторов будет несколько? и как между ними тогда организовать взаимодействие?).
А вот насчет мотивации — нужно думать. Если мотивация нематериальная (как писали выше — репутация, авторитет, доверие), то это разве подразумевает отказ от материальной мотивации? Хорошо, материальная мотивация заставляет сделать как можно быстрее не взирая на качество. Может тогда организовать что-то вроде торгов по реализации фич, только в качестве ставок — код? Либо обязать разрабтчиков, которые будутся за реализацию проставить отметку «взял в работу» и в процессе работы проставлять процент выполнения? По этим меткам можно будет судить сколько разработчиков принимает участие в реализации, на какой стадии находится написание кода и принимать решение о проставлении некоего дедлайна?
Хорошо, но все эти три показателя зарабатываются только путем работы в проектах. Не вижу препятствий, которые могут помешать реализовывать фичи и закрывать баги без вознаграждения. И нужна система измерения репутации, авторитета и т.д. Карма + активность как на хабре?
Насчет проталкивания не понял. Есть заявка на фичу, есть разработчики, которые ее реализуют. Если разработчику не интересен сей проект — то и наблюдать он за ним не будет, а значит и братся за реализацию фич в этом проекте тоже врятли захочет. Вообще можно предусмотреть ленту фич-реквестов. Или не ленту — таблицу с фильтрацией.
А вот насчет патчей пожалуй у меня опыта не хватает — как обычно принимаются патчи в основную ветку? Кто этим занимается?
В пределе количество фондов стремиться к количеству спонсору (каждуму спонсору — свой фонд).
Понимаю что фонды создаются не просто так, и скорее всего этот мехзанизм удобен и крупным компаниям и мелким начинаниям. Но мне кажется что лучше всего создать механизм, подобный описанному в комменте habrahabr.ru/blogs/open_source/132979/#comment_4430866
Допустим такой вариант: пользователь размещает заявку на приложение, эту заявку рассматривают тимлиды, кто-то берет курирование этой заявки на себя (или не берет никто), создается предварительный план действий (ТЗ, или набор фич), принимаются пожертвования (ставки, донейты, спонсорские отчисления) на конкретные фичи или приложение в целом, деньги (например за реализацию фичи) отправляются первому реализовавшему в полном объеме (решение о качестве реализации может приниматся тимлидом, либо голосованием, либо еще как). Для заинтересованности в работе самого тимлида — отчисляем 5-10% от денег, отправляемых программистам за реализацию. Чтобы сама система была на самоокупаемости — 5-10% от денег, отправляемых программистам за реализацию. Итого программисту достанется 80-90% денег от общей суммы за реализацию фичи.
Цифры буквально с потолка, без каких-либо расчетов, как и сам план работы.
Не пойдет. Фонд — это централизованное управление. Сам мир OpenSource — децентрализованный. Да и почему кто-то один (ну или одна группа из 100 человек) должен решать какой проект сколько денег будет получать? Кстати децентрализованная система управления множеством проектов у меня почему-то ассоциируется с генетическими алгоритмами — множество проектов, множество пользователей, множество спонсоров…
Да, насчет архитектуры не спорю, просто мне совершенно не понятно как они умудряются обходится без тактовой частоты (по крайней мере как заявлено). Даже у простейшего RS-триггера на входе сигнал обязан присутсвовать некоторое время (да собственно в этом весь смысл дискретности), а значит должен присутствовать генератор, который бы позволял это время отследить (т.е. создавал бы эту самую тактовую частоту).
Карочи что-то либо недоговаривают, либо подменяют понятия.
Тоже не понимаю… А как вообще состояния триггеров переключаются? В обычныъ процессорах тактовая частота — что-то типа команды сверху «считать входы!», а тут как?
Где из бетона??? Я кругом вижу только блоки. Либо кирпичные блоки, либо стеновые. Бентон не так уж и часто применяется. Бетон нужен там, где нужна прочность. Например многоэтажки очень часто строят каркасным методом — каркас из железобетона, который после зашивают кирпичом. Либо складывают дома из стеновых блоков (как обеспечивают устойчивость конструкции — тут уже не знаю). Да, стеновые блоки из бетона, но благодоря унифицированному производству на заводе готовые блоки получаются дешевле, нежели заливать бетонные стены на месте.
Стоимость робота определяется его сложностью (как сложностью проектирования, так и сложностью построения). Если робот получается дороже, чем работа каменщика за какой-то период — значит сама выполняемая работа обладает какими-то трудностями/тонкостями и автоматизировать этот процесс пока сложно.
Я вот например пытаюсь представить себе робота, который будет класть кирпичные стены. Исхожу из основных правил — простота конструкции (ибо цена) и универсальность в области кирпичной кладки (конечно в разумных пределах, иначе простотой и не пахнет). И я не могу себе представить ничего вменяемого — либо манипулятор хитрый требуется, либо с подачей кирпичей что-то городить нужно. Ну либо ставить человека, который будет в манипулятор будет подсовывать кирпичи и жамкать кнопку «положить-вот-так».
Так что что, повторюсь, но мне кажется, что это весьма не тривиальная задача.
Дом из бетона все-таки дороговато выйдет по сравненияю с кирпичным. Но портал — интересная идея, решить бы проблему с подачей и укладкой кирпичных блоков…
Подобный сервис должен получится где-то между githab'ом и биржей фрилансеров — проекты с багтрекерами как на githab'е и трудовые резервы со страждущими спонсорами как на бирже. Все-таки мне кажется несколько другое измеренение получается.
Но удивила меня публика на хабре :)) Сам я не блещю талантами писательства, но и отношение к, пусть мезерному, но заработку, меня все-таки очень удивили :)
Очень интересное исследование по психологии получилось с очень неожиданным (для меня) и, откровенно говоря, весьма негативным результатом…
Я как раз думаю про минимальные рамки, только лишь те, которые обеспечат взаимодействие разработчиков и пользователей. Чем может принципиально отличатся процесс разработки десктоп-программы от программы для компании?
Делать — да, но приниматся за работу без плана работы… Семь раз отмерь, один отрежь :)
А вот насчет мотивации — нужно думать. Если мотивация нематериальная (как писали выше — репутация, авторитет, доверие), то это разве подразумевает отказ от материальной мотивации? Хорошо, материальная мотивация заставляет сделать как можно быстрее не взирая на качество. Может тогда организовать что-то вроде торгов по реализации фич, только в качестве ставок — код? Либо обязать разрабтчиков, которые будутся за реализацию проставить отметку «взял в работу» и в процессе работы проставлять процент выполнения? По этим меткам можно будет судить сколько разработчиков принимает участие в реализации, на какой стадии находится написание кода и принимать решение о проставлении некоего дедлайна?
Насчет проталкивания не понял. Есть заявка на фичу, есть разработчики, которые ее реализуют. Если разработчику не интересен сей проект — то и наблюдать он за ним не будет, а значит и братся за реализацию фич в этом проекте тоже врятли захочет. Вообще можно предусмотреть ленту фич-реквестов. Или не ленту — таблицу с фильтрацией.
А вот насчет патчей пожалуй у меня опыта не хватает — как обычно принимаются патчи в основную ветку? Кто этим занимается?
Понимаю что фонды создаются не просто так, и скорее всего этот мехзанизм удобен и крупным компаниям и мелким начинаниям. Но мне кажется что лучше всего создать механизм, подобный описанному в комменте habrahabr.ru/blogs/open_source/132979/#comment_4430866
Допустим такой вариант: пользователь размещает заявку на приложение, эту заявку рассматривают тимлиды, кто-то берет курирование этой заявки на себя (или не берет никто), создается предварительный план действий (ТЗ, или набор фич), принимаются пожертвования (ставки, донейты, спонсорские отчисления) на конкретные фичи или приложение в целом, деньги (например за реализацию фичи) отправляются первому реализовавшему в полном объеме (решение о качестве реализации может приниматся тимлидом, либо голосованием, либо еще как). Для заинтересованности в работе самого тимлида — отчисляем 5-10% от денег, отправляемых программистам за реализацию. Чтобы сама система была на самоокупаемости — 5-10% от денег, отправляемых программистам за реализацию. Итого программисту достанется 80-90% денег от общей суммы за реализацию фичи.
Цифры буквально с потолка, без каких-либо расчетов, как и сам план работы.
Карочи что-то либо недоговаривают, либо подменяют понятия.
Я вот например пытаюсь представить себе робота, который будет класть кирпичные стены. Исхожу из основных правил — простота конструкции (ибо цена) и универсальность в области кирпичной кладки (конечно в разумных пределах, иначе простотой и не пахнет). И я не могу себе представить ничего вменяемого — либо манипулятор хитрый требуется, либо с подачей кирпичей что-то городить нужно. Ну либо ставить человека, который будет в манипулятор будет подсовывать кирпичи и жамкать кнопку «положить-вот-так».
Так что что, повторюсь, но мне кажется, что это весьма не тривиальная задача.