Здравствуйте, Scorpion, Вы писали:

S>Меня очень заинтересовала Ваша идея. Могу предложить несколько своих вариантов, а если точнее сделать попытку навязать понравившееся мне идеи.

S>Файловый менеджер
S>Это наиболее понравившийся мне вариант. Год назад я делал попытку разработать таковой. До реализации дело не дошло, из-за малого количества разработчиков. Поэтому идей по этому поводу у меня куча. Могу поделиться. Основные тезисы:
Мне кажется, файловый менеджер — это не очень удачная идея. Почему? Объясняю:
1. Вы сами говорите, что не хватило ресурсов для разработки. Если в проект подключать несколько разработчиков, то задача должна хорошо делиться на самостоятельные фрагменты. Параллельная разработка фрагментов должна быть синхронизирована, а значит, команда должна жестко координироваться. Иначе незавершенные части будут тормозить остальных. Учитывая тот факт, что работа будет выполняться "на общественных началах" сомнительна возможность подобной слаженности.
2. Файловые менеджеры — это ниша "с явными лидерами" — т.е. мало сделать функционально насыщенную программу, ее еще нужно продать, а это сделать будет непросто, учитывая наличие лидеров. Причем цены на продукты-лидеры не сильно высоки — демпинг не пройдет.
3. Не хочу сказать, что файловыми менеджерами никто не пользуется, но ими пользуется очень узкий круг пользователей. ( Я не пользуюсь ) Этот узкий круг имеет уже свои предпочтения и для того, чтобы "переманить" их на свой продукт нужно не только продублировать возможности имеющихся менеджеров, но и предложить весьма ощутимое "нечто". У Вас есть на примете такое "нечто"? Для поиска такой уникальной и нижной, но почемуто никем не реализованной возможности нужно провести очень серьезное исследование как имеющихся продуктов, так и пользователей этих продуктов. А без уникальной "фичи" получится просто клон.

S>

S>
• Чтобы файл-менеджер был юзабельный, он должен быть быстр (прототип по скорости — Far), совместим со множеством платформ (достаточно все Win32 операционки). Следовательно реализация должна быть на чистом API (хотя бы ядро)
  S>
• Должен обладать открытой архитектурой, т. е. должен обладать API желательно для програмистов разных уровней — от C++ до скриптов. Обладать возможностью расширять функциональность с глубокой степенью интеграции (виртуальные файловые системы, редакторы, утилиты и т. п.)
  S>
• Интерфейс должен быть максимально гибким. Настраиваться, поддерживать uxtheme и т. п.
  S>
• Важно!!! Нужно очень хорошо всё спроектировать! Разработчику нужно вести с разделением на роли (как вариант по технологии MSF)
  S>

Все вышеперечисленное — с точки зрения программиста. На продаваемость продукта не повлияет. Зачем нужно делать гибкий настраиваемый интерфейс и заставлять пользователя настраивать его? Нужно делать УДОБНЫЙ интерфейс! Про открытый интерфейс для программистов я вообще молчу...

WBR, Александр Мова