Comments 50
Вполне может взлететь, если подумать не только о заказчиках, но и о исполнителях.
у меня бы, как минимум, возник вопрос лицензирования конечного приложения и исходного кода.
Кстати, нечто подобное уже не раз обсуждалось в сообществе open source.
Предположим, кому-то не хватает какой-то фичи в свободной программе, пусть это будет поддержка смены мак-адреса в network manager. Я делаю заявку, мол, нужна такая функция и предлагаю свои $5. Заявка публикуется на сайте и к ней присоединяется еще несколько десятков человек, в итоге получается $200. Разработчик смотрит заявки, выбирает понравившиеся ему, и пишет патч. После этого программу рассматривает специальная комиссия (пусть ей за эту работу достается 5% от денежной суммы), после ее одобрения деньги зачисляются разработчику. Все счастливы: производитель получил деньги, пользователи получили фичи по низкой цене.
Предположим, кому-то не хватает какой-то фичи в свободной программе, пусть это будет поддержка смены мак-адреса в network manager. Я делаю заявку, мол, нужна такая функция и предлагаю свои $5. Заявка публикуется на сайте и к ней присоединяется еще несколько десятков человек, в итоге получается $200. Разработчик смотрит заявки, выбирает понравившиеся ему, и пишет патч. После этого программу рассматривает специальная комиссия (пусть ей за эту работу достается 5% от денежной суммы), после ее одобрения деньги зачисляются разработчику. Все счастливы: производитель получил деньги, пользователи получили фичи по низкой цене.
Как разруливать ситуацию, если кто-то из заказчиков «сойдёт с дистанции» посреди проекта?
Вероятнее всего, сервис должен резервировать средства.
Предоплата?
И как разруливать, если исполнитель сойдет с дистанции?
Если, как написал amarao, будет резервирование средств, то при отказе исполнителя, сервис перераспределяет или перенаправляет средства другому(им) исполнителю(ям).
Можно делать предоплату не исполнителю, а сервису. Т.е. сервис резервирует предоплату, которая будет гарантией исполнителю, что заказчик не сбежит, не передумает и сможет оплатить работу.
Можно делать предоплату не исполнителю, а сервису. Т.е. сервис резервирует предоплату, которая будет гарантией исполнителю, что заказчик не сбежит, не передумает и сможет оплатить работу.
Отлучение от сервиса навечно. Или вы имеете в виду сход после сдачи проекта?
У меня был опыт разработки трех модулей для одно уже известно CMS. В этой разработке принимало участие по 10-20 человек (кто был готов купить после окончания). Плюс, когда разработка закончилась я давал бесплатные версии тем кто нашел больше всего багов.
В принципе, в том случае такая схема была оправдана по следующим причинам:
1. Это модуль, который планировалось в последствии продавать широким массам, соответственно массовый продукт и при нескольких заказчиках лучше понимаешь что нужно массам.
2. Сам процесс подогревал клиентов, которые в итоге всё купили. Был своего рода пиар
Если же продукт не массовый, а индивидуальный, то всё сложнее. Основная проблема — согласнование требований
В принципе, в том случае такая схема была оправдана по следующим причинам:
1. Это модуль, который планировалось в последствии продавать широким массам, соответственно массовый продукт и при нескольких заказчиках лучше понимаешь что нужно массам.
2. Сам процесс подогревал клиентов, которые в итоге всё купили. Был своего рода пиар
Если же продукт не массовый, а индивидуальный, то всё сложнее. Основная проблема — согласнование требований
Идея хороша. Меня, правда, заинтересовало другое:
>Сюда же относим сеошников, манимейкеров и прочих.
Кто такие манимейкеры? Те, которые сразу приходят в голову не могут заниматься этим за деньги.
>Сюда же относим сеошников, манимейкеров и прочих.
Кто такие манимейкеры? Те, которые сразу приходят в голову не могут заниматься этим за деньги.
Это правильная идея. Особенно она подойдет для написания/продаж всяких SEO-шных сервисов и систем статистики. Можно и вложиться в написание подобного сервиса/биржи
Хорошая мысль, причём, я хочу сказать, это касается не только всякой бижутерии типа «перделка с веб-интерфейсом», но и вполне разумных вещей — например, я бы готов был заплатить немножко человеку, который допилит дрова для специфичного VIA'шного SATA-контроллера. Думаю, сотня владельцев оного — и вполне человеку оплата.
Раньше один заказчик ё# мозг в процессе разработки, сейчас будет в 10 раз больше :)
Почему бы не взять обычный принцип — с исполнителем работает один человек, аккумулирующий общие требования от всех остальных?
И тут же получается красивая схема. Классный заказ. Все подключились. Основной заказчик сговаривается с исполнителем, исполнитель делает полную фигню, основной заказчик ее принимает, деньги пополам.
В предложенной системе есть два слабых/сложных места: сбор требований и приемка. Нужно уж очень красиво их разрулить, чтобы заработало. Но идея хороша
В предложенной системе есть два слабых/сложных места: сбор требований и приемка. Нужно уж очень красиво их разрулить, чтобы заработало. Но идея хороша
Возможно, потребуется регламентировать процесс взаимодействия группы заказчиков с исполнителем. Как минимум, позволить общаться с разработчиком только создателю заказа(или избранным заказчикам).
У меня идея 3-х летней давности — создание сервиса, на котором в процессе голосования/обсуждения будут выставляться приоритеты допиливания и доработки функционала необходимых программных продуктов (само собой open source). Организовать прозрачную систему сбора пожертвований. Средства будут уходить на оплату работы программистов, дизайнеров, всех тех, кто возьмётся за доработку ПО, будь то сами авторы программ или случайный энтузиаст. Это как бы суть. Очень похоже на то, что описал автор этой статьи. Уверен, что от этого выиграют как сами разработчики, так и пользователи.
разница опен сорс и коммершиал разработки, что если тебя что-то не устраивает в опен сорс, то ты берешь напильник (программиста) и допиливаешь до нужного тебе функционала. С коммершиал софтом это нифига не будет работать, потому что «из коробки», тем более ты заплатил за разработку, а не купил готовый продукт, ты хочешь все свои потребности уже реализованными. Теперь представь, что заказчиков (ну так по скромному возьмем) 10. У тебя 10 тех заданий, 10 видений как это должно работать и 10 человек (в лучшем случае) будут е##ть тебе мозг. Утопия однозначно :)
Смотря как ставить задачу, конечно. Я хочу реализованную мультиязычность в LinuxDC, к примеру, но я не программист. Уверен, что не я один так хочу. Итого — есть задача. Вскладчину оплачиваем работу программиста, если нет добровольца, получаем доработанный продукт. Ну опять же, не воспринимайте буквально, это лишь идея. А никакая идея не имеет ценности и смысла, пока не реализована.
при этом каждому отдельно мультиязычность нафиг не надо — мне надо русский интерфейс, пете — китайский, а джамалу — на урдмунском. при этом за возможность переключения я не хочу платить, ведь каждому надо только конкретный, зачем мне другие?
Идея в идеале прекрасна, но рынком не регулируемая. Если у вас что-то очень ходовое, то скорее всего вы найдете на фриланс бирже исполнителя который это уже делал и сможете получить с большим дисконтом, если у вас специфика, то будете долго искать тех, кому это тоже нужно и будут проблемы с постановкой задачи и приемкой, а так же согласованиями в процессе работы. Увы.
Ровно об этом я и писал выше в комментарии. Идея очень хорошая и правильная, при грамотной реализации в плюсе останутся все.
Я так понимаю, что речь идет о небольших и не сильно специфичных проектах, так как групповое составление ТЗ совесем не гарантия того, что заказчикам понравится конечный результат. Тем более что касается бизнес правил и другого функционала — они могут начать конфликтовать друг с другом, а разработка хорошей системы конфигурации потребует дополнительных и, возможно серьезных, затрат.
Я хотел написать примерно то же — кастомное ПО на то и кастомное что для каждого заказчика нужно что-то свое. И еще — если людям нужен схожий ф-л, вполне возможно, что они конкуренты в одной области, и в этом случае работать друг с другом они не захотят.
делать модульную систему, каждый клиент платит за свой комплект фич
каркас ПО станет значительно дороже, а дальнейшее допиливание под каждого клиента может и вовсе съесть выгоду от группового заказа и сделать для каждого клиента это ПО еще дороже.
Но вобщем я не против. Это новая бизнес модель. Как и open source она где-то кажется не состоятельной, но надо попробовать, может и выстрелит :))
Но вобщем я не против. Это новая бизнес модель. Как и open source она где-то кажется не состоятельной, но надо попробовать, может и выстрелит :))
Мне кажется, что идея все же сводится к незначительной доработке существующего ПО (модули к существующему ПО, добавление конкретных фич и т.д). Разрабатывать по такой модели полноценное ПО будет тяжело, потому что его надо будет сдавать не одному, а множеству заказчиков, и процесс с большой вероятностью может не сойтись. Даже в случае с одним заказчиком он часто не сходится.
Ну и для полноценного ПО есть такая вещь, как внедрение. Мало кто заказывает ПО без внедрения. Только если в модели аутсорсинга, но тогда начинаются вопросы совместимости того, что разрабатывается, с тем, что есть у множества заказчиков.
Ну и для полноценного ПО есть такая вещь, как внедрение. Мало кто заказывает ПО без внедрения. Только если в модели аутсорсинга, но тогда начинаются вопросы совместимости того, что разрабатывается, с тем, что есть у множества заказчиков.
А есть кто может и хочет заняться этим проектом?
Записал себе в список идей. Если топикстартер не против — я займусь, когда закончу текущий проект.
Уже есть готовый. Не совсем так как преставляет автор getdone.ru/fund/list Ниже, здесь распишу подробнее.
Есть еще один способ. Не претендую на оригинальность:
Приходит клиент А и заказывает продукт. Студия делает этот продукт по заниженной цене себе в убыток, но часть кода этого продукта публикуется под LGPL (или любой OpenSource-лицензией). Далее когда приходят следующие клиенты — уже используются эти наработки и тем самым получается удешевить последующие разработки.
На словах все просто. На деле — а не так как кажется.
Это довольно сильная организация структуры и парадигмы программирования, потому что разрабатывать и предсказывать универсальные части между несколькими проектами — задача иногда посложнее чем реализация самих проектов.
Отличным примером такой схемы являются prototype, script.aculo.us (особенно когда они начинались).
Но: ни одна CMS-ка не подходит под этот пример, так как она убивает гибкость (пусть и не сильно).
P.S.: мы тоже используем именно такую схему, первые несколько лет она не прибыльна, зато последующие проекты строятся в несколько раз быстрее, чем может предложить конкуренция.
Приходит клиент А и заказывает продукт. Студия делает этот продукт по заниженной цене себе в убыток, но часть кода этого продукта публикуется под LGPL (или любой OpenSource-лицензией). Далее когда приходят следующие клиенты — уже используются эти наработки и тем самым получается удешевить последующие разработки.
На словах все просто. На деле — а не так как кажется.
Это довольно сильная организация структуры и парадигмы программирования, потому что разрабатывать и предсказывать универсальные части между несколькими проектами — задача иногда посложнее чем реализация самих проектов.
Отличным примером такой схемы являются prototype, script.aculo.us (особенно когда они начинались).
Но: ни одна CMS-ка не подходит под этот пример, так как она убивает гибкость (пусть и не сильно).
P.S.: мы тоже используем именно такую схему, первые несколько лет она не прибыльна, зато последующие проекты строятся в несколько раз быстрее, чем может предложить конкуренция.
На деле бывает так. При ходит клиент и говорит: Надо вот это это и это. Ты погадав на кофейной гуще :) и высчитав сферические человеко/часы в вакууме говоришь цену. Если добро, то заказчик получает продукт, а если приходит другой заказчик, которому надо что-то похожее, то тут уж как получится. Если заказчик не денежный то отдается с дисконтом, если смог уболтать, то да… получил еще раз за плевание в потолок. При этом давате говорить объективно и не тыкать мне в нос красивые слова о копирайте и т.д. Т.к. даже в самом тяжелом случает код можно немного переписать, а большинство этого и не будут делать.
Мораль такова, что кушать хочется каждый день, и работать себе в убыток никто адекватный не будет (я говорю про бизнес, основная задача которого зарабатывать деньги и платить зарплаты/налоги).
Мораль такова, что кушать хочется каждый день, и работать себе в убыток никто адекватный не будет (я говорю про бизнес, основная задача которого зарабатывать деньги и платить зарплаты/налоги).
Кстати, «модуль» является антипарадигмой программирования.
Чисто програмерский вариант майнд-мапа :)


Я уже делал похожий проект: getdone.ru/fund/list
Там идея такова, что кто-то один из заказчиков берет на себя функцию по созданию проекта. Остальные лишь комментируют и учатсвуют в голосовании (можно создавать голосования). А также финансируруют его.
А вот идея, чтобы куча заказчиков начала работать над одним проектом утопична. Получится как в басне про лебедя, рака и щуку.
Там идея такова, что кто-то один из заказчиков берет на себя функцию по созданию проекта. Остальные лишь комментируют и учатсвуют в голосовании (можно создавать голосования). А также финансируруют его.
А вот идея, чтобы куча заказчиков начала работать над одним проектом утопична. Получится как в басне про лебедя, рака и щуку.
В общем-то, я заинтересован в популяризации такого проекта. Но в рунете мне кажется это не будет пользоваться спросом. Поэтому я забросил этот проект. Хотя в доткоме сейчас появляются похожие проекты, например www.kickstarter.com/
Если планируется по такой схеме разработка с нуля нового программного продукта, то мне видится проблема поиска на сайте нужного для себя заказа.
Ведь если описание заказываемого функционала делает не разработчик, а конечный пользователь, то сформулировано оно может быть крайне коряво. А это значит, что последующие заказчики, которым нужно примерно то же, просто не найдут этот заказ. И по каким вообще параметрам предполагается поиск? Какой-то каталог ПО по категориям? Или просто полнотекстовый поиск ключевых слов в описании функционала.
Вот напишет какой-нибудь заказчик «Хочу такую программу, где пользователь может играть лесными эльфами, охраной дворца и злодеем. И можно грабить корованы...», т.е. просто невнятный поток мыслей на тему того, как он это себе представляет. И хрен кто этот заказ найдёт по такому сумбурному описанию, чтобы к нему присоединиться.
Ведь если описание заказываемого функционала делает не разработчик, а конечный пользователь, то сформулировано оно может быть крайне коряво. А это значит, что последующие заказчики, которым нужно примерно то же, просто не найдут этот заказ. И по каким вообще параметрам предполагается поиск? Какой-то каталог ПО по категориям? Или просто полнотекстовый поиск ключевых слов в описании функционала.
Вот напишет какой-нибудь заказчик «Хочу такую программу, где пользователь может играть лесными эльфами, охраной дворца и злодеем. И можно грабить корованы...», т.е. просто невнятный поток мыслей на тему того, как он это себе представляет. И хрен кто этот заказ найдёт по такому сумбурному описанию, чтобы к нему присоединиться.
Слишком много сторон получается. Одному заказчику с одним исполнителем не всегда легко договориться и все обсудить, а тут еще и много заказчиков будет.
готов написать данный сервис бесплатно сам или с кем-либо еще
Может немного не в тему, но есть ещё одна модель: разработчик разрабатывает бесплатную программу с урезанным функционалом, а затем открывает багзиллу. Юзеры просят доработать то-то и то-то, причём голосуют рублём.
Тут есть существенная разница. В прадигме топикстартера разработчик получит столько, сколько по общественному мнению стоит его труд. Причем, скорее всего получит минимум, и тут ещё можно усомниться в способности заказчиков-непрограммистов адекватно прикинуть цену.
В описанной мной прадигме разработчик получает столько, сколько готовы отдать ему юзеры, т.е. в зависимости от популярности проекта это могут быть существенные деньги.
Старая моральная дилема: сколько должен получать автор шедевра — по затраченному труду или по популярности?
Тут есть существенная разница. В прадигме топикстартера разработчик получит столько, сколько по общественному мнению стоит его труд. Причем, скорее всего получит минимум, и тут ещё можно усомниться в способности заказчиков-непрограммистов адекватно прикинуть цену.
В описанной мной прадигме разработчик получает столько, сколько готовы отдать ему юзеры, т.е. в зависимости от популярности проекта это могут быть существенные деньги.
Старая моральная дилема: сколько должен получать автор шедевра — по затраченному труду или по популярности?
Sign up to leave a comment.
Совместный заказ разработки ПО