Как простому пользователю социальных сетей стать графом и зарабатывать на этом

Для целей Профсоюза солидарности пользователей социальных сетей просто идеально подходят цели, которые реализует в Google Бред Фицпатрик. Единственное отличие: там, где мы говорим единая Веб 3.0-платформа социальных сетей - Фицпатрик употребляет термин "Социальный граф".

Вот эти наши общие цели, цитирую:

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

1а. Создание некоммерческого (под некоммерческим копирайтом) программного обеспечения с открытым кодом, которое собирает графы у всех сайтов социальных сетей, объединяет их в единый глобальный агрегированный граф и публикует его. Таким образом, этот граф является доступным для всех сайтов или пользователей. Для малых (или редко им интересующихся) пользователей - через публичные API. А для крупных потребителей - в виде скачиваемых дампов. Во втором случае должно поддерживаться итеративное обновление графа - через скачивание или через API.

1б. Поддерживающие такой глобальный граф некоммерческие сервера и базы данных первоначально будут централизованными. Но спроектированы они должны быть так, чтобы все желающие могли создавать собственные сервера, обмениваясь данными друг с другом. По типу "Git", а не "Subversion". Тогда - решение, чьи API/сервера использовать (или запускать свой собственный), - это зависит уже от вас, как владельца сайта.

2. Для разработчиков, которые не хотят сами заниматься анализом исходных данных графа, должны быть обеспечены следующие API-функции высокого уровня:

2а. Эквивалентность узлов. Отправляем API одиночный узел, скажем "brad в ЖЖ", и получаем список всех узлов-эквивалентов: "brad" в ЖЖ, "bradfitz" в Vox и 4caa1d6f6203d21705a00a7aca86203e82a9cf7a (мой FOAF mbox_sha1sum).

2б. Ребра графа для узла - входящие и выходящие. Задача - найти все исходящие и все входящие ребра графа. Ребра понимаются как "утверждения" (claims), как "истины" (truths), друзья, рекомендации и т.д.

2в. Найти для узла всех совокупных "друзей" (с учетом всех его эквивалентных узлов), дополнить этих друзей их эквивалентными узлами, а затем отфильтровать по типу узла назначения. Эта процедура есть суперпозиция операций [2а], [2б], и снова [2а] в одном обращении к API. Например, для "brad" на LJ нужно получить всех друзей Брэда, по всем его эквивалентным узлам, при условии, что эти узлы-друзья имеют тип либо "mbox_sha1sum", либо "Twitter".

2г. Поиск пропавших друзей узла. Нужно "расширить" исходный узел (просмотреть все его эквивалентные узлы). Потом - найти всю совокупность его друзей. Потом - расширить их тоже. И, наконец, - найти все недостающие ребра (соединяющие узлы, находящиеся в одной социальной сети). Такое API позволяет пользователю синхронизировать свои социальные сети, точнее - списки друзей в различных сетях. Если двое - друзья во Friendster, но не знают, что оба они участвуют в MySpace, то это API даст им знать об этом.Но в более общем плане (кроме перечисленных API), у разработчиков просто появится возможность думать о совершенно новых видах приложений.

3. Для конечных пользователей

3а. Пользователь должен иметь возможность впервые зайти на "социальный сайт" (например dopplr.com) - в идеале, по OpenID, но не обязательно, - и увидеть диалог такого примерно вида:"Эй, мы видим по общедоступным данным, что у вас есть уже 28 друзей здесь, на dopplr.com. Вот их список (с обоснованием, как (откуда) он составлен и с никами этих людей на других сайтах). Кого из них вы хотите считать друзьями здесь? Можно нажать 'выбрать всех'." Кроме того, если вы уже используете сайт dopplr.com, то вы будете узнавать, когда люди, с которыми вы дружны на других сайтах, появляются на нем. И вам будет предлагаться выбор: дружить с ними здесь или нет.

3б. Снабжение (конечного) пользователя инструментами (типа браузерных надстроек, add-ons), позволяющими ему управлять своими социальными сетями (имеющими или не имеющими соответствующих API), синхронизировать сети друг с другом или делать что-то еще, что угодно, но - в соответствии с выбранной самим пользователем политикой.

3в. Граф данных должен быть настолько же переносим (портабелен, portable), как документы на персональном компьютере (хотя, наверное, слово "граф" может быть вообще не известно конечным пользователям).

Что целью НЕ является

1. Целью не является заменить Facebook. В самом деле, большинство людей, с которыми я разговаривал, любят Facebook и хотят просто, чтобы их и так уже открытые данные были немного более доступны. И хочется смягчить опасения владельцев сайтов по поводу монополизма одной какой-либо платформы. Кстати, предварительные переговоры с Facebook об участии в реализации данного проекта - были удивительно многообещающими.

2. Целью не является создание социальной сети или чего-либо столь же забавного для (конечных) пользователей. Скорее, цель - "создать начинку" (build the guts), которая позволит расцвести тысячам новых социальных приложений (таким как dopplr.com и подобным). Сделайте одну вещь, но сделайте ее хорошо. Будет намного более эффективно, если мы объединим маленькие отдельные социальные графы в один большой социальный граф и распространим его повсеместно, чтобы все могли им пользоваться.

Допущения

1. Социальный граф содержит как публичные узлы, так и приватные (частные) узлы, как публичные ребра, так и приватные ребра. Мы фокусируемся сейчас только на публичных данных, которые участники согласны свободно распространять по сети, ни от кого не скрывая. Это не решает 100% задачи, но решает, скажем, 90% задачи, занимающие 10% по сложности (реализации). Частные данные могут быть добавлены позднее, возможно, на более высоком уровне реализации. На начальном этапе - работаем только с открытыми (публичными) данными.

2. Кроме того, внимание уделяется в первую очередь связям - данными о "друзьях". А не таким данным, как фотографии (см. movemydata.org), дата рождения, город, интересы и т.д. Есть идеи о том, как включить в граф множество таких публичных не контентных(?) данных, не относящихся к "профилю знакомств". Но заняться этим, несомненно, следует позже - на втором этапе.

3. Существуют как "склонные к сотрудничеству" (кооперативные, cooperative), так не склонные к сотрудничеству сайты. Почти все небольшие сайты, с владельцами которых я разговаривал, желают сотрудничать, понимая при этом, что их собственные (социальные) графы незначительны (are incomplete), и что это - не их специализация ... Они просто хотят, чтобы социальный граф стал им доступен. Их совсем не заботит, откуда он возьмется, и они не считают, что их относительно небольшие объемы данных внесут заметный вклад в улучшение глобального социального графа. Не склонные к сотрудничеству сайты, с другой стороны, - это те, которые уже имеют огромную аудиторию, и либо придают повышенное значение своим правам собственности по отношению к информации, содержащейся в их социальном графе, либо - настолько крупны, что просто равнодушны к этой теме.

4. Весь мир не возможно заставить перейти в массовом порядке ни на какой "протокол взаимодействия социальных сетей", игрушечный XML или что-либо подобное. Этого просто не случится. Система должна поддерживает любые (и все!) способы сбора данных, нотации и т.д. Хитрые новые протоколы и XML/YAML/JSON форматы могут быть решением для взаимодействия с сайтами, настроенными на сотрудничество (и такой подход уже начал разворачиваться для нескольких сразу готовых к сотрудничеству сайтов), но - в общем и целом - большинство сайтов не будут на первых порах готовы к сотрудничеству, а некоторые (например MySpace), возможно, никогда не согласятся на это (работу с "хитрыми протоколами").

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

5. Большинство пользователей не интересует XML, протоколы, стандарты, форматы данных, централизация/децентрализация, хранилища, блокировки и т.п. Вы, читатель этого документа, - не обычный пользователь. Чтобы привлечь нормальных пользователей, мы должны предложить им нечто полезное: некоторые функциональные возможности, легкость, блеск, полезности, - что-то, что они не могут получить в других местах. Хорошие данные порождают пользователей, а пользователи порождают хорошие данные. Есть достаточно идей о том, как раскручивать этот процесс. Подробнее об этом нужно будет думать позже, но, к счастью, уже есть много хороших данных в публичном доступе - через хорошие API и с открытыми форматами данных. 6. Надстройки для браузеров (add-ons) или другие инструменты, которые конечному пользователю требуется загружать, - с этого нельзя начинать. На первом этапе все должно осуществляться исключительно стандартными средствами Интернета. Некоторая функциональность - для некоторых (не склонных к сотрудничеству) сайтов потребует браузерных плагинов, но большинство - не потребует.

6. Хотя надстройки для браузеров (add-on), вероятнее всего, потребуются (пользователю) для того, чтобы осуществлять процедуры добавления/удаления друзей и сбора (от имени пользователя) данных в некоторых не склонных к сотрудничеству социальных сервисах (сайтах), - браузер пользователя никогда не должен использоваться (с его IP-адресом и с его строкой user-agent) для сбора и отправки данных, не являющихся собственностью этого пользователя. Так, например, сбор информации о друзьях пользователя в сети MySpace - это приемлемо (если MySpace это позволит). Но выуживание друзей-его-друзей - уже не катит (isn't cool) потому, что это уже не данные, принадлежащие этому пользователю. Эти данные уже принадлежат либо его друзьям, либо самому MySpace ... но заведомо не пользователю, который скачал (и установил) add-on.

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

Бизнес в сообществах

1. ИНСТРУМЕНТЫ

Сервис по необходимости". Пример - известное сообщество Ezhe.ru, которому 10 лет: оно образовалось вокруг почтовой рассылки и благополучно существует до сих пор. Здесь сервисы добавляются по мере развития сообщества, по мере роста его неоднородности - появляются каталоги, рейтинги, ленты новостей и т.д. Помимо общей органичности этой схемы, она еще и прозрачна в плане бизнеса. Особенно, если мы сравним ее с "телегой перед лошадью", где возникает шум, осваиваются инвестиции, и лишь после возникает проект, который не известно кому нужен. Если же сервис возникает по необходимости, значит, у сообщества уже есть в нём определенная нужда, выраженная в конкретных деньгах, которые сообщество готово заплатить за появление этого сервиса.

И, в связи с этим, возникает перспектива, которую я назвал "социальной CMS". Правда, хорошо было бы иметь такую систему управления контентом, которая включала бы в себя всё, где та или иная опция применялась бы за пользовательской необходимостью. Но на сегодняшний день таких систем нет, и большинство CMS страдают от авторитарности в управлении. Я привел здесь в пример Drupal.org - это система недостаточно гибкая, но в ней хотя бы есть функция раздачи ролей.

2. РЕКЛАМА

Другой вид бизнеса в сообществах - рекламный, создание "сообществ бренда"."

Конец цитаты.

От графа Фицпатрика сразу перейдем к простым пользователям: как им на этом пиршестве технологий зарабатывать?

Способ №1:
Рекомендательный поиск: Зарегистрированные в единой системе пользователи, будут делиться своим опытом пользования тем или иным товаром, услугой - которые заинтересованные компании будут предоставлять им даром.

Способ №2:
Пользователи социальных сетей, обрабатывающие контент – должны получать компенсацию от владельцев сетей. Это как раз и станет возможным при объединении социальных сетей: тогда общая аудитория станет сравнима с телевизионной, и перераспределение рекламных бюджетов от теряющих аудиторию телеканалов к набирающим медиа-вес интернет-порталам – позволит делиться возросшими доходами с пользователями. Потому что стоимость видеорекламы – на порядок выше обычной. А получить видеорекламу можно только на аудиторию, исчисляемую миллионами человек.

Способ №3:
Обмен опытом. Прогресс, ежедневное появление новых технологий – заставляет крутиться как белка в колесе: остановился на отпуск – безнадежно отстал от жизни. Единственное спасение – социальная сеть коллег: чем она у тебя обширнее и качественнее, тем быстрее можно найти нужную информацию - и вознаградить советчика "кармой" - как на Хабрахабре. А эксперты с высокой кармой получают доступ к рекламным бюджетам, выделямых рекламодателями на BTL

Способ №4:
Совместная работа фрилансеров: в условиях, когда ты привязан к своему узлу, партнер может быть уверен в том, что ты не "кинешь", а заказчики - уверены в профессионализме исполнителей!

Способ №5:
ПРодажа своего креатива, как это сейчас происходит на стоках фотографий. В новых условиях, ты сможешь быть уверен, что никто не украдет твое произведение.

Способ №6:
Виртуальная "Фабрика звезд". С объединением баз социальных сетей, впервые появляется шанс у каждого заявить о себе во всеуслышание, и получить признание своих заслуг! Иностранные продюсеры найдут тебя, где бы ты ни жил.

Способ №7:
Смена принципов рекламного дела: индивидуальная наводка на потребителей – вместо рекламных ударов "по площадям". ГУГЛ уже ввел в США такую систему: пользоватлеи получают вознаграждение за то, что пересылают своим знакомым именно ту рекламу, которая тем требуется!

И конкретный пример, как американские пользователи еще зарабатывают.

Компания Snocap, чей сервис MyStore дает артистам возможность продавать треки со своих страниц на MySpace, недавно запустила новую услугу Spread The World, позволяющую меломанам "копировать" музыкальный магазин на свои персональные страницы, включая блоги и
вообще любое свое "присутствие" в Сети.

Описанная выше система уже начинает заявлять о себе на практике: по данным статистики, с момента запуска MyStore в декабре прошлого года количество зарегистрированных пользователей (регистрация необходима для покупки музыки через этот сервис) ежемесячно увеличивается на 50%. Количество загрузок купленных файлов увеличивается на 40% в месяц.

Индустрия не собирается останавливаться на опыте Snocap: полным ходом идет разработка стратегии монетизации музыки, предлагаемой на Last.fm и IMEEM. За социальными сетями последуют блог-сервисы вроде TypePad, Blogspot и WordPress.

"Социальные сети – это сети будущего.Их можно назвать MTV нынешнего поколения, - заявил глава этой фирмы Расти Руефф в интервью западной прессе. – Если вы хотите продавать музыку там, где желание покупателя максимально совпадает с его возможностью ее приобрести, делайте это в месте, где находятся слушатели".