> решать задачу, которая всем нужна, но не еще решена, подкрепляться маркетингом, обладать искоробочностью

По-моему, можно ограничиться маркетингом.

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

> Стабильность, скорость, качество кода и свободность нужны в меньшей мере

Они нужны в той мере, в какой их отсутствие мешает «решению задачи, которая всем нужна».

обладать искоробочностью

Искоробочность - это слишком узкое понятие. Более общее понятие - юзабилити. В том числе, необходимость чтения документации - залог низкой популярности.

и то при наличии конкурентов

Имхо можно исходить из того, что конкуренты очень быстро нарисуются.

Забыл самое главное

Рентабельность.

В обозримом будущем проект должен быть выведен на самоокупаемость, так, чтобы от отбивал вкладываемые в него трудозатраты. Если нет четкого плана: кто, когда и сколько денег тебе заплатит - то лучше даже не начинать.

Вот любопытный пример расчетов по самоокупаемости http://slouken.blogspot.com/2011/04/exploring-galaxy.html , в исполнении автора известной lgpl-библиотеки SDL.

Он должен быть свое рода «сексуальным» для покупателя.

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

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

> Если нет четкого плана: кто, когда и сколько денег тебе заплатит - то лучше даже не начинать.

Хорошо, что Линус так не думал :)

http://www.sequoiacap.com/ideas - если сумеешь ответить на все вопросы внятно и воплотить в коде и у тебя есть шанс :)

> Хорошо, что Линус так не думал :)

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

>> Хорошо, что Линус так не думал :)

Если считаешь себя вторым Наполео^W Линусом

Гг. А кем себя считал Линус? %)

> Гг. А кем себя считал Линус? %)

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

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

Мне это не нужно - я видел развитие Arch (не дистра, а DVCS).

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

Поэтому, если заниматься опенсорсом, нужно делать что-то, интересное (а хорошо бы, чтобы полезное) лично тебе. Хотя это не спасет от судьбы Тома Лорда.

> Поэтому, если заниматься опенсорсом, нужно делать что-то, интересное (а хорошо бы, чтобы полезное) лично тебе.

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

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

> Опенсорс или не-опенсорс - это вторичный вопрос

Это один из первичных вопросов. Опенсорс дает тебе возможность завербовать союзников, которые сделают часть работы. А если ты собираешься писать закрытый коммерческий софт - значит, тебе либо придется нанимать людей (сложно), либо делать всё самому (ставит крест на 99% проектов).

Работа по вечерам в отрыве от основной работы

Многие так начинали.

это не вариант

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

> если ты сначала захочешь найти того, кто будет кормить тебя N месяцев

Я для начала хочу понять, начиная с какого месяца проект начнет кормить себя сам. Если в обозримом будущем не начнет, то можно его не начинать.

Разумеется, just-for-fun поделка, которую стряпают долгими зимними вечерами, с самого начала самоокупаема. Нет затрат - не нужны источники дохода. Здесь проблема в том, что fun заканчивается раньше, чем программа достигает production quality. Весело и интересно накидать работающий прототип, а шлифовать его до блеска - занятие унылое. Итого мы имеем на сорцфордже стабильный приток программ-недоделок, тухлятины, которую уже никто и никогда не будет доводить до ума.

> Я для начала хочу понять, начиная с какого месяца проект начнет кормить себя сам. Если в обозримом будущем не начнет, то можно его не начинать.

Кхм, и сколько проектов ты поднял?

> Кхм, и сколько проектов ты поднял?

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

Позови-ка лучше в тред того дядю, на которого работаешь. Его советы будут ТС-у полезнее твоих, потому что именно он думал «с какого месяца проект начнет кормить себя сам», а не ты, как тут пишешь.

> Позови-ка лучше в тред того дядю, на которого работаешь.

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

Его советы будут ТС-у полезнее твоих

Советов полны интернеты, гугль в помощь.

Хотя буду любезен, и предоставлю первую ссылку: http://www.linux.org.ru/forum/talks/4144384

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

Да можешь сказать. Всё равно я туда не пойду. Только сначала прекрати врать и рассусоливать о рентабельности проектов.

> Только сначала прекрати ... рассусоливать о рентабельности проектов

Да, тут ты прав: рассусолено уже достаточно. У кого голова на плечах есть, тот выводы сделает. А всем остальным - не в коня корм.

ИМХО. Если говорить о большой аудитории, то:
Люди должны быть уверены, что этот проект может дать им то, без чего их жизнь намного печальнее. Все. =) Т.е. потакание человеческим слабостям + активная реклама.

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

Не согласен. Это может затормозить развитие проекта.

решать задачу, которая всем нужна, но не еще решена

Это, вроде, задача исследовательских центров. Недавно только копипастил цитату Дейкстры, придется опять это делать: «Задача Университета - не предлагать то, что просит общество, а давать то, что обществу необходимо.» А вот давать обществу то, что оно просит - это как раз задача «успешных проектов».

Кстати, а что случилось с Арчем, я пропустил.. Вроде ж годная система?

В ветке об ынтерпрайзе, верно? Большинство проектов на форже и хабе - даже успешных проектов - так и не дотянули до ынтерпрайза. Так шо вы все правы =)

Достаточно маркетинга. Вон - у мелкософта все ОС сплошное убожество изначально. Зато за счёт маркетинга добились распространения.

Или у яббла - низкокачественные ноуты и мобилки, но их берут, и при этом за тысячи баксов. Маркетинг, фигли.

> Кстати, а что случилось с Арчем, я пропустил..

Том Лорд был годным инженером, никаким менеджером, и нытиком с комплексом примадонны. В результате Том выгорел, а Arch (и его инкарнация - tla) просто никуда не пошел; для Ubuntu некоторое время использовали Bazaar, производный от tla, потом наняли команду для разработки Bazaar-NG (который сейчас известен как bzr).

И еще Том был лиспером.

Вроде ж годная система?

Для 2002 года и сурового Unix-ветерана - да (я, например, был недостаточно суров).

Если нет четкого плана: кто, когда и сколько денег тебе заплатит - то лучше даже не начинать.

Стивен Бланк с тобой не согласен. Если конечно речь не идет об автоматизации какого-то узкоспециального безнес-процесса для ограниченного круга заказчиков. В случае сервисов для широкой публики само достаточно большое количество пользователей уже является ценностью, даже если они не приносят прямых денег - бизнес-модель может нарисоваться или по ходу дела по обстоятельствам, или появится человек, который пожелает купить все (или частично) дело вместе с пользователями, вложить в него еще денег и найти бизнес-модель самому. Примерно в этой же области работает правило «release early, release often» - если начал проект без бабла и без явного видения бизнес-модели (как вариант - без уверенности, что запланированная бизнес-модель сработает) - нужно стремиться как можно раньше выпустить в жизнь живой продукт, чтобы сразу понять как к нему относится народ и есть ли смысл продолжать всю затею (важно, чтобы продукт был хоть и ранним, но полностью рабочим - минимальное количество функционала это не тоже самое, что падения и глюки на кажом шагу).