Стало понятно, что идея жизнеспособна ). Самое сильное тому подтверждение - это статья на хабре (http://habrahabr.ru/blogs/startup/122190/) с красивыми и грамотными словами и практически 100%-ым совпадением идеи. Да, умение грамотно выражать свои мысли - это, несомненно, талант )).. да и огромное подспорье в бизнесе.
Что ж, посмотрим, во что эта идея выльется в дальнейшем...

На днях один глубоко уважаемый мною человек прошелся в твиттере по поводу проектов, все название которых пишется большими буквами. Так как до этого дня я все никак не мог определиться с написанием: WNS.RU, wns.ru или WNS.ru, этот тви послужил поводом для окончательного решения. WNS.RU как проект больше не упоминается, теперь жить будет сайт "Мобильные проекты". в конце-концов, почему бы и нет )).
Теперь возвращаемся к wns.ru..., тьфу, к "мобильным проектам" )). Новостей на сегодня две:

Во-первых, немного переделал дизайн основных разделов (главная, проекты), вспомогательные - по остаточному принципу попозже. Стало ли лучше - сложно сказать, но, по крайней мере, отторжения не вызывает. Пока будет так. Кроме того, сильно изменился расчет индикаторов (показателей "завершенности") направлений и проекта в целом. Пока индикатор считается только на основании голосов посетителей ("количественно"), в дальнейшем будут учитываться и качественные показатели. Как - пока не скажу, сам думаю ))...

Во-вторых, определился с "головным" проектом - MoWoP (Model of Work On Project - Модель Работ над Проектом). Кто не в курсе - это проект (опять проект ) создания онтологии процесса работы над неким абстрактным проектом. Основные элементы и их взаимосвязь выглядят вот так: "проекты" -> "этапы проекта" -> "направления этапов" -> "цели направлений" -> "Веб-сервисы". Предполагается, что связка первых четырех уровней будет описана на OWL, а веб-сервисы (действующие) будет пристегиваться через WSDL и OWL-S. В теории это позволит в действующих проектах работать с сервисами намного более гибко: создавать иерархии, заменять сервисы "на лету", мгновенно перераспределять деньги на их оплату.

Описание MoWoP (и комментирование) доступно по адресу http://www.mowop.pbworks.com в виде вики, когда появится хоть альфа результата - выложу на отдельный ресурс.

David Taber - автор книги "Salesforce.com: секреты успеха" и CEO компании SalesLogistix, специализируется на совершенствовании бизнес-процессов с помощью CRM систем. Клиенты SalesLogistics находятся в Северной Америке, Европе, Израиле, Индии и David уже более 25 лет ведет исследования в своей области.

Текст основан на статье "Интеграция облачных приложений: какой путь лучше?", но не является калькой и включает отступления от базового текста.

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

На базовом уровне, облачные приложения могут интегрироваться как "внутри" - разработчиком сервиса, так и "снаружи" - внешним субъектом, например сервисным брокер (CSB - Cloud Service Broker). В рамках данной статьи мы ограничимся рассмотрением четырех методов интеграции "снаружи".

Интеграция уровня 0 - использование для интеграции возможностей платформы, на которой развернуто приложение. Пример: сервис представляет собой сайт, написанный на PHP и использующий базу MySQL. Владелец сервиса может разрешить клиентам использовать собственные дополнения в виде php-скриптов, имеющие доступ к базе сервиса. Основная проблема заключается в том, что далеко не все владельцы сервисов предоставляют доступ на таком уровне.

Интеграция уровня 1 - используются коннекторы "точка-точка" для которых устанавливается однозначное соответствие данных в двух сервисах. Например, необходимо синхронизировать сервис блогов на сайте проекта и twitter-ленту проекта. Коннектор представляет собой скрипт, расположенный на внешнем по отношению к обоим сервисам ресурсе (например, у CSB), который отслеживаем изменения в RSS блога проекта, находит новые сообщения, выделяет заголовок, начало текста и ссылку на пост блога, формирует из них сообщение twitter и передает его в ленту. Такой коннектор сам по себе является веб-сервисом (в данном случае рассматривался TwitterFeed).

Интеграция уровня 2 - это практически аналог уровня 1, но при этом коннекторы строятся между сервисом и неким промышленным стандартом, например, ODBC или JDBC. Такой подход имеет более гибкие возможности, так как не ограничен заданными полями соответствия, тем не менее продолжает оставаться тем же набором коннекторов "точка-точка".

Интеграция уровня 3 - это использование интеграционного сервера. В данном случае подразумевается, что Интеграционный сервер хранил всю информационную модель (таблицы БД, схемы XML и т.д.), синхронизируется с внешними сервисами и самостоятельно обрабатывает информацию. В данном случае интегратор получает максимальные возможности, за что платит максимальным объемом работ.

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

Родилась мысль делать тестовые аккаунты на сервисах и давать доступ всем для ознакомительных целей.
С одной стороны - это соответствует целям проекта.
С другой стороны - это не очень корректно по отношению к владельцам сервисов.
Рабочий вариант - регистрировать, заполнять и давать доступ к одному из собственных проектов WNS, но тут есть риск получить в данные разный бред нецензурный.
Пока думаю

На сайте стартаппойнта (startuppoint.ru) засветилось "агентство рейтингового мониторинга "ОмниГрейд" - примерный образец того, к чему хотелось бы привести систему рейтингов wns.ru (с определенными поправками, конечно). А поправки основываются вот на чем:
во-первых, судя по обилию умных слов на сайте, да и по европейском происхождению компании - они ориентируются на оформившийся стартап-рынок, на государственную систему, при которой бизнес-план пишется сразу после появления идеи, пишется на года и содержит действительную оценку рынка, расчеты доходов/расходов и т.д. Подавляющее большинство так "стартапов" в России не в состоянии планировать свое будущее более чем на 2-3 месяца вперед да и вообще, откровенно нацелены продаться как можно быстрее. К сожалению, в 90% случаев (по личному опыту) серьезными бизнес-планами обладают лишь жульнические проекты, нацеленные на получение особо крупных кредитов. Вобщем, попроще бы )
во-вторых, Агентство явно не будет в состоянии обрабатывать тот немалый поток проектов и проектиков, который способны сгенерировать наши сограждане. К тому же, "Омнигрейд" - это коммерческая организация, а не благотворительное учреждение. Значит, изначально будут выбираться те области деятельности, которые способны при минимуме вложений принести максимум прибыли в наикратчайший срок. А это значит, что в настоящее время по умолчанию будут откидываться все проекты, связанные с производством и, наоборот, приветствоваться быстро реализуемые software-проекты. Т.е. будут плодиться очередные социальные сети.
Получается, что основной цели - выйти на прямой контакт с авторами/менеджерами проектов (ведь такова цель "Предложения участникам StartupPoint"?) Агентство все же не достигнет.

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

мудрые люди говорили: "лучшее - враг хорошего". но тут бы до хорошего доползти...) очевидно, что информационный раздел в существующем ныне виде просто не нужен. с другой стороны, постоянно появляется информация, которой хотелось бы делиться с заинтересованными людьми (например, нарисовалась весьма подробная статистика по основным сотовым операторам и мобильным сервисам за последний год - очень даже может пригодиться при расчетах БП). так куда ее девать? так что инфораздел будет полюбому. текущее решение - сделать в вики-формате. в эту сторону и буду копать.

Пришло некоторое понимание в отношении "инструментов".
Итак, "инструмент" - это возможность, функция, сервис, которые облегчают какие-либо задач при создании или реализации проекта. Например, создание списка работ и отслеживание их выполнения - это задача, а teamer.ru - это инструмент. Фактически смысл всего проекта wns.ru заключается в том, что бы предоставлять пользователям готовые заточенные под беспроводную отрасль инструменты ведения проектов.
Сложность заключается в том, что инструменты бывают разные: платные и бесплатные, с открытым кодом и проприетарные, предоставляемые в виде SaaS и вообще не реализуемые через Интернет. Для того, что бы все это многообразие хоть как-то систематизировать, будем считать, что "инструментов" четыре вида:

1. Предоставляемые в виде SaaS
Инструмент, доступ к которому (платный или бесплатный) можно программно получить через Интернет. Такие инструменты в рамках wns.ru будут собираться, проверяться и классифицироваться, по возможности, к ним будет предоставляться доступ со скидкой или вообще бесплатный. Функционал будет интегрироваться в единое пространство с проектом внутри wns. Пример - twitter.

2. Доступные через интернет, но не имеющие собственного API
Понятно, что здесь можно только описать инструменты, протестировать их, дать рекомендации и инструкции. Также предполагаются льготный и/или бесплатный доступ (как договоримся). Если функционал действительно важный и полезный, аналогичные инструменты будут создаватся внутри wns.ru и интегрироваться в единое пространство проектов. Пример - cofounder.ru.

3. Инструменты, не имеющие Интернет-реализации
Примером такого инструмента может быть, например, помощь в создании презентации проекта. В таком случае проект будет лишь классифицировать услуги и описывать их. И в этом случае для пользователей wns.ru будут предоставляться скидки.

4. Собственные инструменты wns.ru
Стратегия wns.ru заключается в максимальном развитии собственных сервисов. Я не собираюсь копировать твиттер или basecamp, но множество мелких инструментов должны и будут работать внутри проекта. ИМХО только так можно обеспечить полноценное взаимодействие всех компонентов и получить действительно удобную систему. Конечно, исключительно виджетами ограничиваться не хочется, поэтому в ближайших планах - собственные хостинг и репозиторий (естесственно, бесплатные для проектов).

Описание всех доступных инструментов по категориям можно будет увидеть здесь, а функционал доступен по ссылке "работать над проектом" в профиле проекта.